Westrum’s Organizational Model in Technology Organizations

Mike's Notes

Interesting point of view from IT Revolution authors. I agree 100% with Westrum's model of;

  • Pathological (power-oriented) organizations are characterized by large amounts of fear and threat. People often hoard information or withhold it for political reasons, or distort it to make themselves look better.
  • Bureaucratic (rule-oriented) organizations protect departments. Those in the department want to maintain their “turf,” insist on their own rules, and generally do things by the book—their book.
  • Generative (performance-oriented) organizations focus on the mission. How do we accomplish our goal? Everything is subordinated to good performance, to doing what we are supposed to do.
I'm not sure that I agree with the cause of this phenomenon.

Resources

References

Accelerate: the Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Nicole Forsgren, PhD, Jez Humble, and Gene Kim.

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

21/01/2026

Westrum’s Organizational Model in Technology Organizations

By: 
IT Revolution: 5/05/2021

.

This post was adapted from Chapter 3 of Accelerate: the Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Nicole Forsgren, PhD, Jez Humble, and Gene Kim.

It is practically a truism in DevOps circles that culture is of huge importance. However, culture is intangible; there exist many definitions and models of culture. Our challenge was to find a model of culture that was well-defined in the scientific literature, could be measured effectively, and would have predictive power in our domain. Not only did we achieve these objectives, we also discovered that it is possible to influence and improve culture by implementing DevOps practices.

Modelling and Measuring Culture

There are many approaches to modelling culture in the literature. You can choose to look at national culture—for example, what country one belongs to. You may also talk about what organizational cultural values are enacted that influence the way teams behave. And even within organizational culture, there are several ways to define and model “culture.”

According to Edgar H. Schein, organizational culture can exist at three levels in organizations: basic assumptions, values, and artifacts. At the first level, basic assumptions are formed over time as members of a group or organization make sense of relationships, events, and activities. These interpretations are the least “visible” of the levels—and are the things that we just “know,” and may find difficult to articulate, after we have been long enough in a team.

The second level of organizational culture are values, which are more “visible” to group members as these collective values and norms can be discussed and even debated by those who are aware of them. Values provide a lens through which group members view and interpret the relationships, events, and activities around them. According to a paper by Pratima Bansal, values also influence group interactions and activities by establishing social norms, which shape the actions of group members and provide contextual rules. These are quite often the “culture” we think of when we talk about the culture of a team and an organization.

The third level of organizational culture is the most visible and can be observed in artifacts. These artifacts can include written mission statements or creeds, technology, formal procedures, or even heroes and rituals, as Andrew Pettigrew states in his paper “Studying Organizational Cultures”.

Westrum’s Organizational Typology

Based on discussions in DevOps circles and the importance of “organizational culture” at the second level, we decided to select a model defined by sociologist Ron Westrum. Westrum had been researching human factors in system safety, particularly in the context of accidents in technological domains that were highly complex and risky, such as aviation and healthcare. In 1988, he developed a typology of organizational cultures:

  • Pathological (power-oriented) organizations are characterized by large amounts of fear and threat. People often hoard information or withhold it for political reasons, or distort it to make themselves look better.
  • Bureaucratic (rule-oriented) organizations protect departments. Those in the department want to maintain their “turf,” insist on their own rules, and generally do things by the book—their book.
  • Generative (performance-oriented) organizations focus on the mission. How do we accomplish our goal? Everything is subordinated to good performance, to doing what we are supposed to do.

Westrum’s further insight was that the organizational culture predicts the way information flows through an organization. Westrum provides three characteristics of good information:

  • It provides answers to the questions that the receiver needs answered.
  • It is timely.
  • It is presented in such a way that it can be effectively used by the receiver.

Good information flow is critical to the safe and effective operation of high-tempo and high-consequence environments, including technology organizations. 

Westrum organizational typology

An additional insight from Westrum was that this definition of organizational culture predicts performance outcomes. 

What the Research Shows

Culture enables information processing through three mechanisms, According to Westrum in his 2014 paper. First, in organizations with a generative culture, people collaborate more effectively and there is a higher level of trust both across the organization and up and down the hierarchy. Second, “generative culture emphasizes the mission, an emphasis that allows people involved to put aside their personal issues and also the departmental issues that are so evident in bureaucratic organizations. The mission is primary. And third, generativity encourages a ‘level playing field,’ in which hierarchy plays less of a role.”

We should emphasize that bureaucracy is not necessarily bad. As Mark Schwartz points out in The Art of Business Value, the goal of bureaucracy is to “ensure fairness by applying rules to administrative behavior. The rules would be the same for all cases—no one would receive preferential or discriminatory treatment. Not only that, but the rules would represent the best products of the accumulated knowledge of the organization: Formulated by bureaucrats who were experts in their fields, the rules would impose efficient structures and processes while guaranteeing fairness and eliminating arbitrariness.”

Westrum’s description of a rule-oriented culture is perhaps best thought of as one where following the rules is considered more important than achieving the mission—and we have worked with teams in the US Federal Government we would have no issue describing as generative, as well as startups that are clearly pathological.

What Does Westrum Organizational Culture Predict?

Westrum’s theory posits that organizations with better information flow function more effectively. According to Westrum, this type of organizational culture has several important prerequisites, which means that it is a good proxy for the characteristics described by these prerequisites.

First, a good culture requires trust and cooperation between people across the organization, so it reflects the level of collaboration and trust inside the organization.

Second, better organizational culture can indicate higher quality decision-making. In a team with this type of culture, not only is better information available for making decisions, but those decisions are more easily reversed if they turn out to be wrong because the team is more likely to be open and transparent rather than closed and hierarchical.

Finally, teams with these cultural norms are likely to do a better job with their people, since problems are more rapidly discovered and addressed.

We hypothesized that culture would predict both software delivery performance and organizational performance. We also predicted that it would lead to higher levels of job satisfaction. Both of these hypotheses proved to be true. We show these relationships in the figure below.

Consequences of Westrum’s Theory for Technology Organizations

For modern organizations that hope to thrive in the face of increasingly rapid technological and economic change, both resilience and the ability to innovate through responding to this change are essential. Our research into the application of Westrum’s theory to technology shows that these two characteristics are connected. Initially developed to predict safety outcomes, our research shows it also predicts both software delivery and organizational performance. This makes sense, because safety outcomes are performance outcomes in a healthcare setting. By extending this to technology, we expected this type of organizational culture to positively impact software delivery and organizational performance. This mirrors research performed by Google into how to create high-performing teams.

Google wanted to discover if there were any common factors among its best-performing teams. They started a two-year research project to investigate what made Google teams effective, conducting “200+ interviews with  .  .  .  employees and [looking] at more than 250 attributes of 180+ active Google teams.” They expected to find a combination of individual traits and skills that would be key ingredients of high-performing teams. What they found instead was that “who is on a team matters less than how the team members interact, structure their work, and view their contributions.” In other words, it all comes down to team dynamics.

How organizations deal with failures or accidents is particularly instructive. Pathological organizations look for a “throat to choke”: Investigations aim to find the person or persons “responsible” for the problem, and then punish or blame them. But in complex adaptive systems, accidents are almost never the fault of a single person who saw clearly what was going to happen and then ran toward it or failed to act to prevent it. Rather, accidents typically emerge from a complex interplay of contributing factors. Failure in complex systems is, like other types of behavior in such systems, emergent, according to Charles Perrow in his book Normal Accidents.

Thus, accident investigations that stop at “human error” are not just bad but dangerous. Human error should, instead, be the start of the investigation. Our goal should be to discover how we could improve information flow so that people have better or more timely information, or to find better tools to help prevent catastrophic failures following apparently mundane operations.

How Do We Change Culture?

John Shook, describing his experiences transforming the culture of the teams at the Fremont, California, car manufacturing plant that was the genesis of the Lean manufacturing movement in the US, wrote, “what my  .  .  .  experience taught me that was so powerful was that the way to change culture is not to first change how people think, but instead to start by changing how people behave—what they do.”

Thus we hypothesize that, following the theory developed by the Lean and Agile movements, implementing the practices of these movements can have an effect on culture. We set out to look at both technical and management practices, and to measure their impact on culture. Our research shows that Lean management, along with a set of other technical practices known collectively as continuous delivery, do in fact impact culture, as shown below.

You can act your way to a better culture by implementing these practices in technology organizations, just as you can in manufacturing. 

Groundbreaking visuals capture how our bodies repair damaged DNA

Mike's Notes

Nature is not digital. Beautiful work by animator Drew Berry.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Aeon
  • Home > Handbook > 

Last Updated

20/01/2026

Groundbreaking visuals capture how our bodies repair damaged DNA

By: Drew Berry
Aeon: 9/01/2026

The biomedical animator Drew Berry is known for his dazzling visualisations of biological processes that unfold on microscopic scales.

https://youtu.be/lWbXGIuCsmo?si=2w7e4uPwTKv5HQNP

The biomedical animator Drew Berry is known for his dazzling visualisations of biological processes that unfold on microscopic scales. As enlightening as it is arresting, his imagery straddles the line between science and art, as seen in his work as the in-house animator for the Walter and Eliza Hall Institute of Medical Research (WEHI) in Melbourne, Australia, and in his music video collaboration with Björk. This animation illustrates a process called homologous recombination, in which specialised proteins repair damaged DNA by using an intact copy as a template – failures of which can increase one’s risk of cancer. Through this glimpse into the worlds within us, Berry highlights the intricate biology that plays out inside each of us unseen, shaped by millennia of evolution.

Video by the Walter and Eliza Hall Institute of Medical Research

Animator: Drew Berry

A Critique of Iceberg REST Catalog: A Classic Case of Why Semantic Spec Fails

Mike's Notes

I like the specification and hope to enable its use via a future Pipi plugin. Here is an article by Ananth Packkildurai about some flaws that need fixing. His weekly newsletter is worth subscribing to.

Resources

References

  • Iceberg REST Catalog Specification.
  • Designing Data-Intensive Applications, by Martin Kleppmann.

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Data Engineering Weekly
  • Home > Handbook > 

Last Updated

19/01/2026

A Critique of Iceberg REST Catalog: A Classic Case of Why Semantic Spec Fails

By: Ananth Packkildurai
Data Engineering Weekly: 9/01/2026

Ananth Packkildurai is a data engineering leader, writer, and author of Data Engineering Weekly, sharing insights on modern data platforms, large-scale pipelines, and AI-driven architectures..

How a Semantically Correct API Becomes Operationally Unreliable at Scale.

“Latency is not just a performance characteristic; it is a fundamental part of correctness.” — Designing Data-Intensive Applications

In Designing Data-Intensive Applications, Martin Kleppmann makes a subtle but critical point: the CAP theorem omits latency, yet in real systems, latency often determines whether a system is usable at all. A system that is correct but slow is, in practice, incorrect.

This observation is directly applicable to the Apache Iceberg REST Catalog specification. While the specification achieves semantic clarity, it fails to define the operational realities that enable distributed systems to remain predictable at scale. The result is a standard that is formally correct, yet operationally fragile.

Semantic Interoperability Without Predictability

Over the past two years, the Iceberg REST Catalog specification has emerged as the de facto standard for metadata access in the Iceberg ecosystem. We have seen the outburst of the catalog war around the REST spec. It promises a universal interface that allows engines such as Trino, Spark, Flink, and StarRocks to interact with Iceberg tables via a common REST abstraction, independent of the underlying catalog implementation.

At the semantic level, this promise largely holds. The specification rigorously defines metadata structures: tables, schemas, snapshots, and namespace operations. A LoadTable or CreateNamespace request looks identical across implementations. This semantic interoperability has been critical to Iceberg’s rapid ecosystem adoption.

However, semantic interoperability alone is insufficient. The specification defines what metadata operations mean, but it avoids specifying how they must behave in real-world conditions, such as concurrency, latency sensitivity, and cross-catalog synchronization.

This gap—between semantic interoperability and operational interoperability—is where systems begin to fail in production.

The Core Problem: No Operational SLA, No Predictability

The Iceberg REST Catalog specification is intentionally silent on performance guarantees. There are no latency expectations, no throughput baselines, and no service-level objectives. While this flexibility lowers the barrier to implementation, it creates an ecosystem where:

  • Two catalogs can both be “compliant” yet differ by orders of magnitude in response time.
  • Clients cannot reason about metadata latency during query planning.
  • Synchronization behavior across catalogs becomes unpredictable.

In distributed data systems, predictability matters more than raw performance. Without a strict operational SLA—or at least defined behavioral constraints—clients are forced into defensive, retry-heavy designs that amplify load and increase tail latency.

The “List Tables” Problem: Cross-Catalog Sync Failure

The ListTables endpoint (GET /v1/namespaces/{namespace}/tables) is semantically straightforward. It allows clients to enumerate tables within a namespace and supports pagination through pageSize and pageToken.

The primary issue is not pagination itself. The real failure emerges when the same Iceberg tables are registered in multiple catalogs, a pattern that is increasingly common in hybrid and multi-platform deployments.

A Realistic Scenario

  • An Iceberg table is registered in Catalog A and Catalog B
  • Both catalogs point to the same underlying metadata and object storage.
  • One catalog is used by ingestion and streaming workloads.
  • Analytics engines or BI tools use the other.

The Sync Pathology

When a client connects to Catalog B and issues a metadata discovery operation—such as listing tables or syncing namespace state—the catalog must:

  1. Enumerate all tables
  2. Resolve metadata pointers
  3. Validate access permissions
  4. Reconcile the state with the underlying storage.

Because the REST specification defines no operational expectations:

  • There is no SLA for how long this sync should take
  • There is no distinction between a “lightweight” listing and a fully validated listing.
  • There is no mechanism to express intent (e.g., names only, no ACL validation)

As table counts grow into the tens of thousands, synchronization latency grows non-linearly. In practice, sync operations can take minutes—or fail—causing engines to stall, time out, or repeatedly retry.

The result is not merely slow metadata access. It is system-wide unpredictability. Query engines cannot determine whether a delay is transient, systemic, or catastrophic.

Latency Is Treated as an Implementation Detail—But It Is a Contract

The REST Catalog specification implicitly treats latency as an implementation concern. From a standards perspective, this is understandable. But in data-intensive systems, latency is part of the correctness contract.

The specification does not define:

  • Upper bounds on metadata retrieval latency
  • Maximum metadata payload sizes
  • Limits on metadata fan-out operations
  • The number of round-trip required to plan a query

As a result, a compliant catalog may require megabytes of JSON metadata and dozens of HTTP calls just to validate a single query plan. Engines appear slow and unstable, even though the root cause lies in an underspecified protocol.

This is precisely the class of problem Kleppmann warns about: correctness without latency guarantees is operationally meaningless.

Commit Semantics Under Contention: Undefined and Unfair

Iceberg relies on optimistic concurrency control. When multiple writers attempt to commit simultaneously, conflicts are expected and resolved through retries.

The REST specification defines the 409 Conflict response, but stops there. It does not define:

  • Backoff expectations
  • Retry fairness
  • Starvation prevention

In a multi-engine environment, this creates asymmetric outcomes. A high-frequency streaming writer with aggressive retries can permanently starve batch compaction jobs that follow conservative retry policies. Over time, table health degrades due to file explosion and unbounded metadata growth.

Once again, the issue is not semantic correctness. It is the absence of operational guarantees.

Caching Without a Freshness Model

While HTTP caching is permitted, it is not part of the correctness model. Support for conditional requests, ETags, or freshness validation is optional.

This forces clients into a pessimistic stance: always re-fetch, always revalidate, always assume staleness. The REST protocol degenerates into a chatty, high-latency control plane that negates its own architectural benefits.

Without a standardized freshness contract, caching becomes a gamble rather than a reliability tool.

Behavioral Conformance Is Missing

The Iceberg ecosystem has strong conformance testing for table formats. It lacks an equivalent for catalog behavior.

Today, “REST Catalog compliant” means:

  • The endpoints exist
  • The JSON schema is correct.
  • The happy path works.

It does not mean:

  • Predictable latency under load
  • Stable pagination during concurrent updates
  • Graceful overload signaling
  • Bounded retry amplification

Without behavioral conformance tests, compliance guarantees syntax, not operability.

Underspecification Is Still a Design Decision

The absence of operational constraints is not accidental. It reflects a deliberate choice to prioritize adoption and flexibility.

However, in distributed systems, underspecification pushes complexity downstream. It burdens clients, operators, and platform teams with the need to implement compensating logic. As Iceberg becomes core infrastructure rather than experimental tooling, this trade-off increasingly limits its reliability.

Semantic agreement without behavioral agreement leads to fragile systems.

Toward Operational Interoperability

Operational interoperability does not require rigid SLAs or centralized control. It requires acknowledging that latency, retries, and fairness are part of the interface.

Concrete improvements could include:

  • Defined operational profiles with minimum latency and concurrency expectations
  • Lightweight metadata views to avoid synchronization amplification
  • Standardized retry and backoff semantics for conflict scenarios
  • Explicit freshness and caching contracts

Semantic interoperability enabled Iceberg’s success. Operational interoperability will determine whether it remains dependable at scale.

Until then, the Iceberg REST Catalog remains a textbook example of why semantic specifications alone are not enough.

Journey Mapping 101

Mike's Notes

I'm wondering whether Journey Maps could be added to Pipi.

  • To better understand the needs of the different users of Pipi visually
  • As a tool for customers.
I first used Journey Mapping a few months ago while testing Krobar.ai, an excellent simulation platform from Kromatic.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > NNg Newsletter
  • Home > Handbook > 

Last Updated

18/01/2026

Journey Mapping 101

By: Sarah Gibbons
NN Group: 09/12/2018

Vice President of Nielsen Norman Group. She works at the intersection of research, strategy, and design.

Summary

A journey map is a visualization of the process that a person goes through in order to accomplish a goal.

Journey maps are a common UX tool. They come in all shapes, sizes, and formats. Depending on the context, they can be used in a variety of ways. This article covers the basics: what a journey map is (and is not), related terminology, common variations, and how we can use journey maps.

In This Article

  • Definition of a Journey Map
  • Key Components of a Journey Map
  • Journey-Map Variations
  • Why Use Journey Maps
  • Conclusion

Definition of a Journey Map

Definition: A journey map is a visualization of the process that a person goes through in order to accomplish a goal.

In its most basic form, journey mapping starts by compiling a series of user actions into a timeline. Next, the timeline is fleshed out with user thoughts and emotions in order to create a narrative. This narrative is condensed and polished, ultimately leading to a visualization.

Most journey maps follow a similar format: at the top, a specific user, a specific scenario, and corresponding expectations or goals in the middle, high-level phases that are comprised of user actions, thoughts, and emotions;  at the bottom, the takeaways: opportunities, insights, and internal ownership.

The terms ‘user journey map’ and ‘customer journey map’ can be used interchangeably. Both reference a visualization of a person using your product or service.

While the argument can be made that the term ‘customer’ does a disservice to the method (because, especially for certain business-to-business products, not all of end users are technically customers, i.e., product buyers), alignment on what you call the map is far less important than alignment on the content within the map.

Key Components of a Journey Map

Journey maps come in all shapes and sizes. Regardless of how they look, journey maps have the following 5 key elements in common:

  1. Actor
  2. Scenario + Expectations
  3. Journey Phases
  4. Actions, Mindsets, and Emotions
  5. Opportunities

Actor

The actor is the persona or user who experiences the journey. The actor is who the journey map is about — a point of view. Actors usually align with personas and their actions in the map are rooted in data.

Provide one point of view per map in order to build a strong, clear narrative. For example, a university might choose either a student or a faculty member as actor — each would result in different journeys. (To capture both viewpoints, the university will need to build two separate maps, one for each of the two user types.)

Scenario + Expectations

The scenario describes the situation that the journey map addresses and is associated with an actor’s goal or need and specific expectations. For example, one scenario could be switching mobile plans to save money, and expectations for it include to easily find all the information needed to make a decision.

Scenarios can be real (for existing products and services) or anticipated — for products that are yet in the design stage.

Journey maps are best for scenarios that involve a sequence of events (such as shopping or taking a trip), describe a process (thus involve a set of transitions over time), or might involve multiple channels.

Journey Phases

Journey phases are the different high-level stages in the journey. They provide organization for the rest of the information in the journey map (actions, thoughts, and emotions). The stages will vary from scenario to scenario; each organization will usually have data to help it determine what these phases are for a given scenario.

Here are some examples:

  • For an ecommerce scenario (like buying Bluetooth speakers), the stages can be discover, try, buy, use, seek support.
  • For big (or luxury) purchases (like buying a car), the stages can be engagement, education, research, evaluation, justification.
  • For a business-to-business scenario (like rolling out an internal tool), the stages could be purchase, adoption, retention, expansion, advocacy.

Actions, Mindsets, and Emotions

These are behaviors, thoughts, and feelings the actor has throughout the journey and that are mapped within each of the journey phases.

Actions are the actual behaviors and steps taken by users. This component is not meant to be a granular step-by-step log of every discrete interaction. Rather, it is a narrative of the steps the actor takes during that phase.

Mindsets correspond to users’ thoughts, questions, motivations, and information needs at different stages in the journey. Ideally, these are customer verbatims from research.

Emotions are plotted as single line across the journey phases, literally signaling the emotional “ups” and “downs” of the experience. Think of this line as a contextual layer of emotion that tells us where the user is delighted versus frustrated.

Opportunities

Opportunities (along with additional context such as ownership and metrics) are insights gained from mapping; they speak to how the user experience can be optimized. Insights and opportunities help the team draw knowledge from the map:

  • What needs to be done with this knowledge?
  • Who owns what change?
  • Where are the biggest opportunities?
  • How are we going to measure improvements we implement?

An example of a simplistic, high-level customer-journey map depicting how the persona “Jumping Jamie” switches her mobile plan. While all comprehensive journey maps should include key components, what the map chooses to prioritize can (and should) depend on the goal of the journey-mapping initiative. (For your convenience, we provide a journey-map template that you can use.)

Journey-Map Variations

There are several concepts closely related and thus easily confused with journey maps.

It is important to note that this section is only meant to help your personal understanding and clarification of these terms. It is not advised to debate or attempt to shift a whole organization’s language to abide by the definitions stated here. Instead, use these definitions to guide you towards aspects of another method that your team has not previously considered.

Journey Map vs. Experience Map

Think of an experience map as a parent to a journey map. A journey map has a specific actor (a singular customer or user of a product) and specific scenario (of a product or service), while an experience map is broader on both accounts — a generic human undergoing a general human experience.

The experience map is agnostic of a specific business or product. It’s used for understanding a general human behavior; in contrast, a customer journey map is specific and focused on a particular business or product.

For example, imagine the world before the ridesharing market existed (Uber, Lyft, Bird, or Limebike, to name a few). If we were to create an experience map of how a person gets from one place to another, the map would likely include walking, biking, driving, riding with a friend, public transportation, or calling a taxi. Using that experience map we could then isolate pain points: unknown fares, bad weather, unpredictable timing, paying in cash, and so on. Using these pain points, we would then create a future journey map for specific product: how does a particular type of user call a car using the Lyft app?

Journey Map vs. Service Blueprint

If journey maps are the children to experience maps, then service blueprints are the grandchildren. They visualize the relationships between different service components (such as people or processes) at various touchpoints in a specific customer journey.

Think of service blueprints as a part two to customer journey maps. They are extensions of journey maps, but instead of being focused on the user (and taking the user’s viewpoint), they are focused on the business (and take its perspective).

For the Lyft scenario above, we would take the journey map and expand it with what Lyft does internally to support that customer journey. The blueprint could include matching the user to a driver, contacting the driver, calculating fares, and so on.

Journey Map vs. User Story Map

User stories are used in Agile to plan features or functionalities. Each feature is condensed down to a deliberately brief description from a user’s point of view; the description focuses on what the user wants to do, and how that feature will help. The typical format of a user story is a single sentence: “As a [type of user], I want to [goal], so that [benefit].” For example, “As a checking account holder, I want to deposit checks with my mobile device, so that I don’t have to go to the bank.”

A user story map is a visual version of a user story. For example, take the user story above (“As a checking account holder, I want to deposit checks with my mobile device, so that I don’t have to go to the bank.”) and imagine writing out the different steps that the team plans for the user to take when using that functionality. These steps could be: logging in, beginning deposit, taking picture of check, and entering transaction details. For each step, we can document required features: enabling camera access, scanning check and auto filling numbers, and authorizing signature. In a user story map, these features are written on sticky notes, then arranged based on the product release that each functionality will be added to.

While, at a glance, a user story map may look like a journey map, journey maps are meant for discovery and understanding (think big picture), while user story maps are for planning and implementation (think little picture).

Although a journey map and user story map may contain some of the same pieces, they are used at different points of the process. For example, imagine our journey map for Lyft indicated that a pain point appeared when the user was in a large group. To address it, the team may introduce a multicar-call option. We could create a user story map to break this feature (multicar call) into smaller pieces, so a product-development team could plan release cycles and corresponding tasks.

Why Use Journey Maps

The benefits of journey maps (and most other UX mappings) are two-fold. First, the process of creating a map forces conversation and an aligned mental model for the whole team. Fragmented understanding is a widespread problem in organizations because success metrics are siloed; it is no one’s responsibility to look at the entire experience from the user’s standpoint. This shared vision is a critical goal of journey mapping, because, without it, agreement on how to improve customer experience would never take place.

Second, the shared artifact resulting from the mapping can be used to communicate an understanding of your user or service to all involved. Journey maps are effective mechanisms for conveying information in a way that is memorable, concise, and that creates a shared vision. The maps can also become the basis for decision making as the team moves forward.

Conclusion

Journey mapping is a process that provides a holistic view of the customer experience by uncovering moments of both frustration and delight throughout a series of interactions. Done successfully, it reveals opportunities to address customers’ pain points, alleviate fragmentation, and, ultimately, create a better experience for your users.

Additional articles are available, discussing: 

  • When to create customer journey maps
  • The 5-step process
  • Journey mapping in real life

The Feynman Lectures are now online and free

Mike's Notes

Physicist Richard Feynman shared a Nobel Prize for quantum electrodynamics and was a wonderful teacher of physics. This is a resource of his lectures for my future study of particle physics.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

17/01/2026

The Feynman Lectures are now online and free

By: Nurin Ludin
From Quarks to Quasars: 13/03/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Science often loses its allure in a maze of jargon, with wonder quickly giving way to dry facts and equations.

The problem is particularly noticeable in classrooms, where rote memorization trumps ingenuity and understanding. However, when Richard Feynman taught science, this was never a problem. 

His eccentricity and flair for showmanship made science accessible and exciting, leaving his listeners wide-eyed and eager to learn more. 

But perhaps this is to be expected. He was, after all, one of the greatest and most influential theoretical physicists in history. But, of course, he wasn't infallible.

Richard Feynman: Early beginnings

Feynman was born in 1918 in New York City to a Jewish family — though he was a professed atheist from his early teenage years on. Unfortunately, Feynman’s Jewish heritage often made life difficult. At the time, antisemitism was widespread in the United States, and Feynman was rejected when he applied to Columbia University. Today, many argue that this rejection was due to the university's quota on Jewish admissions.  

He was, however, accepted to MIT. Feynman subsequently completed his doctoral work at Princeton University. 

Feynman married his high school sweetheart, Anne Greenbaum, in 1942. The previous year, Greenbaum had been diagnosed with lymphatic tuberculosis. It was a death sentence, with doctors stating that she only had two years to live. But she was the love of Feynman's life, and so they married. Directly after the ceremony, Feynman took her Greenbaum to the hospital, where he would visit her every weekend.

Greenbaum died with Feynman by her side in 1945. She was twenty-five. 

The science years

Feynman began his career in science as a junior physicist in the Manhattan Project, working toward producing the world’s first atomic bomb. Specifically, Feynman worked on a theory of how to separate Uranium 235 from Uranium 238. 

Later in the project, he became the leader of the Theoretical Division and developed a formula to calculate the yield of a fission bomb with Hans Bethe. 

After the war ended, he moved on to teaching as a professor of theoretical physics at Cornell University and the California Institute of Technology, where he conducted his most groundbreaking work.

Feynman's primary contributions were to quantum mechanics. He introduced diagrams (now called “Feynman diagrams”) that are graphic analogs of the mathematical expressions needed to describe how particles interact.  

While his partners, Julian Schwinger and Sin-Itiro Tomonaga, approached quantum electrodynamics mathematically, Feynman drew pictures of every possible interaction between photons and electrons. His iconic doodles helped transform the very foundation of physics, allowing scientists to calculate the probability of each scenario and add them up to get the correct answer. 

David Kaiser eloquently articulates the significance of Feynman’s diagrams: "With the diagrams’ aid, entire new calculational vistas opened for physicists. Theorists learned to calculate things many had barely dreamed possible before....It might be said that physics can progress no faster than physicists’ ability to calculate. Thus, in the same way that computer-enabled computation might today be said to be enabling a genomic revolution, Feynman diagrams helped to transform the way physicists saw the world, and their place in it."

In 1965, Feynman was awarded the Nobel Prize in Physics alongside Schwinger and Tomonaga for this work and its contributions to quantum electrodynamics. But, of course, Feynman was much more than just a theoretical physicist.

Feynman’s lectures

During his tenure at Caltech in the early 1960s, Feynman delivered a series of lectures that revolutionized the teaching of introductory physics. These lectures subsequently spawned a book that explained the most basic principles of astonishingly complex and formidable theories, like general relativity and quantum mechanics, in a way that was accessible, accurate, and comprehensive. 

In 2013, Caltech and the Feynman Lectures website collaborated to post these lectures online, and they’re completely free. 

In the first two years alone, the site was accessed more than 8 million times by roughly 1.7 million people — a testament to his teaching abilities and demonstrating just how timeless his lectures are. 

That’s not to say that Feynman did it alone. Fellow physicists Matthew Sands and Robert Leighton took turns editing and compiling the individual lectures, which took between 10 to 20 hours each. 

Although, Feynman did face some controversy — and it must be noted that such critical reflections are very much valuable and needed — by nurturing a sense of wonder for nature and fostering a desire to understand the mechanisms that govern the physical world in so many, Feynman forever transformed our world and our understanding of it.

Ontology Documentation Tools and Workflows

Mike's Notes

Marcelo Xavier started a fascinating discussion on the Ontolog Forum about creating online documentation for an Ontology. My friend Alex Shkotin used Gemini to identify a possible solution. Nico Matentzoglu also made valuable points, including suggestions around using DiataxisOBOOK (Open Biological and Biomedical Ontologies Organised Knowledge) is a fantastic resource and a great example of how to organise successful training material.

I have copied the whole thread here, along with the resources, for future reference. I can use all of this in future development of the Pipi Ontology Engine (ont).

Update

Michael DeBellis provided an alternative approach and an example for documenting using Widoco.

Dear community,

I would like to kindly request suggestions on the best way to create online documentation for an ontology currently being developed in WebProtégé.

We are looking for tools or approaches that enable us to share the progress and structural details of the ontology in a clear and accessible manner for all stakeholders involved.

Thank you very much in advance for your help and recommendations.

Sincerely,

Marcelo Xavier


"Dear Marcelo,

I am personally for self documented code, then we need one or another rendering engine. Did you ask OBO Foundry and [protege-user] list?

I asked Gemini, have a look https://gemini.google.com/share/6e091b60d275

Best,

Alex"

https://www.linkedin.com/in/ashkotin/


Dear Marcelo,
Unfortunately I cannot answer your question for WebProtege specifically; Note that independently of your issue (and despite this: https://github.com/protegeproject/webprotege/issues/284), I would urge anyone developing an ontology regardless of where it is curated/edited to use a standard version control system like GitHub or GitLab for community engagement and "open science best practice" (standard workflows, etc).
A lot of OBO ontologies use the Ontology Development Kit (ODK) which comes with some built-in functions to generate an mkdocs (material-themed) documentation scaffolding which can then be extended by the ontology team. This is usually deployed on github.io (which you seem to have some personal experience with as well). Some of our docs pages are very detailed, others vanilla, see for example:
https://obophenotype.github.io/uberon/
https://obophenotype.github.io/human-phenotype-ontology/
https://oborel.github.io/obo-relations/
We mostly curate our documentation manually, but claude code or similar can, with some guidance and careful review, generate quite reasonable pages as well. 
On a more personal note:
- I like the clarity of the diataxis framework (https://diataxis.fr/) for organising docs, which we more or less try to follow in OBO Academy (https://oboacademy.github.io/obook/). 
- I really like it if modelling patterns in the ontology are documented explicitly using something like DOSDP: https://github.com/monarch-initiative/mondo/blob/master/src/patterns/dosdp-patterns/autoimmune.yaml. It is trivially possible to generate documentation pages from these to have something like this: https://mondo.readthedocs.io/en/latest/editors-guide/patterns/ (I find this is, if I may be so bold, the most important part of ontology documentation - even though hardly anyone does it).
Good luck!

Nico


I'm not sure I understand the question. There isn't anything special about an ontology developed in WebProtege. Well except that (at least IMO) developing an ontology and ONLY using WebProtege is a really bad idea. WebProtege doesn't support reasoners so you can't define axioms on classes, SWRL rules, etc. If you aren't going to use the cool stuff from OWL why use OWL at all? Go with something like just RDF or Neo4J. It's like asking "are there any tools for documenting code written using PyCharm?" The IDE shouldn't dictate how you document your code and the tool you use to develop your ontology shouldn't dictate how you document it. 

But IMO, the clear answer... at least a very good answer is Widoco which is the same tool that many people use already to document ontologies: https://github.com/dgarijo/Widoco You can export your ontology from WebProtege and use Widoco. One thing to look out for, at least this confused me for a long time, is if your ontology is just on your local file system (although it sounds like that isn't an issue for you) and you use Widoco the results will be virtually empty documentation. This isn't because of a limitation of Widoco, actually I guess in some ways it is, it is because Widoco is designed for ontologies that are hosted on the Internet and if you don't currently host on the Internet but on your local file system Widoco will generate your documentation but when you try to look at it your Operating System will block it and it will look mostly  empty. One way around that is to host Widoco documentation on GitHub. Which IMO is a much better solution in the long term than leaving it in WebProtege. WebProtege is a great collaboration tool but doesn't have the support for real software development like branching, merging, issues, etc. that GitHub does. Here's an example where I did that for an ontology I developed last year on the social science research called Climate Obstruction: https://mdebellis.github.io/Climate_Obstruction/ 

Also, in my revision of the Pizza Tutorial: https://www.michaeldebellis.com/post/new-protege-pizza-tutorial I added a chapter (chapter 11) that talks about Web Protege and how you can go back and forth between WebProtege and Desktop Protege which is what I recommend. That way you get the collaboration features of WebProtege but you can write axioms and get other features only available on the Desktop version of Protege. The nice thing is that WebProtege was designed to do what we used to call in the CASE world "round trip engineering" I.e., you can export the ontology, make changes in Desktop Protege (and/or other tools) then re-import the ontology into WebProtege and the changes are a part of the WebProtege history as if you made them in WebProtege. Also, WebProtege does some odd things to IRIs that I talk about in the tutorial.

Cheers,

Michael

https://www.michaeldebellis.com/blog 

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Ontolog Forum
  • Home > Handbook > 

Last Updated

29/01/2026

Ontology Documentation Tools and Workflows

By: Alex Shkotin
Gemini: 14/01/2026

Alex is an independent researcher in Moscow.
https://www.linkedin.com/in/ashkotin/

Gemini

Some responses below were generated according to the creator's saved info and preferences. Learn moreOpens in a new window 14 January 2026 at 21:51

Published on 14 January 2026 at 21:53

Prompt

request suggestions on the best way to create online documentation for an ontology currently being developed in WebProtégé.

We are looking for tools or approaches that enable us to share the progress and structural details of the ontology in a clear and accessible manner for all stakeholders involved.

Output

Creating online documentation for an ontology in WebProtégé is a common challenge, as the platform is excellent for editing but doesn't have a built-in "one-click" public documentation site.

To share structural details with stakeholders, the best approach is to export your ontology from WebProtégé and then use a specialized documentation generator. Here are the most effective tools and methods for 2026.

1. Top Documentation Tools

Once you export your ontology (usually in Turtle or RDF/XML format), use one of these tools to generate a human-readable website.

Tool Best For Key Features
WIDOCO Standard-compliant Docs A "Wizard" that generates a complete HTML site with metadata, cross-references, and a visual diagram (via WebVOWL).
LODE Quick Previews A web service that turns an OWL file into a single, clean HTML page. Great for non-technical stakeholders to read class definitions.
WebVOWL Visual Stakeholders Provides an interactive, graphical view of the ontology. Excellent for showing relationships and hierarchy visually.
OnToology Automated Workflows If you use GitHub, this tool automatically runs WIDOCO and WebVOWL every time you push a change to your repository.

2. Recommended Workflow: The "Professional" Route

If you want a live site that stays updated as your team works in WebProtégé, follow these steps:

  1. Export from WebProtégé: Go to Project > Export and select the Turtle (.ttl) or RDF/XML format.
  2. Upload to GitHub: Create a repository for your ontology.
  3. Use WIDOCO: Run the WIDOCO wizard. It will ask you for a title, description, and logo. It then generates a folder full of HTML files.
  4. Host on GitHub Pages: Enable GitHub Pages on your repository to turn that folder into a public URL (e.g., https://your-org.github.io/ontology-doc).

3. Collaborative Alternatives (Internal)

If you aren't ready to publish a full website yet, you can use WebProtégé’s internal features to keep stakeholders in the loop:

  • Sharing & Permissions: You can invite stakeholders to the WebProtégé project with "View Only" or "Comment Only" permissions. This allows them to see the structure without accidentally changing anything.
  • Threaded Comments: Use the "Comments" tab in WebProtégé to discuss specific classes or properties. Stakeholders can leave feedback directly on the entity they are concerned about.
  • Project Feed: This provides a timeline of changes, which is helpful for stakeholders to see the "velocity" of the project and what has been added recently.

4. Enriching Your Documentation

For any documentation tool to work well, stakeholders need clear descriptions. Ensure your team fills out these Annotation Properties in WebProtégé for every class and property:

  • rdfs:label: A human-friendly name (e.g., "FinancialTransaction" vs "financial_transaction").
  • rdfs:comment or skos:definition: A clear, non-circular definition of the concept.
  • dc:creator: To show who is responsible for that part of the model.

Would you like me to help you draft a set of "Documentation Best Practices" for your team to follow within WebProtégé to ensure the final output is high quality?

Net-SNMP for PDU?

Mike's Notes

I'm looking for a solution to a problem. Some working notes.

"The first Data Centre

Once scaling begins, Pipi 9 will then need a data centre to use as a render farm to automatically create customised SaaS enterprise applications based on user requirements. The data centre will be completely isolated from the internet to maximise security. It can be expanded in stages if it is planned appropriately.

Each industry and each enterprise customer will get a dedicated server to store a mirrored copy of their deployment configuration and parameters, including localisation. No user data will be stored." - On A Sandy Beach

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

15/01/2026

Net-SNMP for PDU?

By: Mike Peters
On a Sandy Beach: 15/01/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

The future Pipi 9 data centre must be fully automated and physically isolated from the internet.

Power

19" rack-mounted intelligent PDU will distribute power to servers.

According to Server Room Environments

Intelligent Rack PDUs

Intelligent PDUs add a level of sophistication to power distribution within IT server racks and include:

  • PDU and Outlet Metering: metered PDUs provide power-related information locally and remotely, which can include Amps (A), Volts (V), Frequency (Hz), Watts (W), Energy (kWh) and Power (kVA). The power readings can be for individual outlets and the total PDU usage. The information can be used by IT managers for capacity planning, the prevention of circuit overloads, client and cost centre billing (with +/- 1% accuracy) and efficiency calculations, including Power Usage Effectiveness (PUE).
  • Switched and Outlet Switched: a switching PDU will include metering and add the ability to remotely control (ON/OFF) to the PDU and the outlets. Outlet-switched PDUs provide a way for IT and data centre managers to remotely reboot or power down connected loads and allow for cascading power-ups to manage load inrush currents. Switching PDUs adds a layer of security to a server room or data centre power plan in terms of controlling unauthorised access to rack-level loads and their power connections. Costs are also reduced, as an onsite engineer visit is removed in most instances.
  • Remote IP Monitoring: the PDU provides connectivity for remote monitoring and can include HTTP/HTTPS, iPV4 and iPV6, Telnet, SSH, Virtual Serial, SNMP (v1, v2c, v3), JSON-RPC, LDAP, FTP/SFTP and RADIUS for secure login. The monitoring provides a way to view the status of the PDU and its individual socket outlets using a browser, monitoring software or a data centre infrastructure management (DCIM) software suite. The PDU may also offer a RESTful API for bespoke communications applications. Dual Ethernet ports can provide communications redundancy, and the communications module will typically be a ‘hot-swap’ type.

This means that each individual power outlet can be remotely switched on and off via IP. That could be controlled by another server.

A server can power up automatically when the power outlet is turned on. The server can be made to run a program (Pipi 9), do some work, create a backup, and then shut down.

My question is:

"Could the PDU detect that the server has shut down and then turn off the power outlet?"

According to a post on the Schneider Electric forum, this can be done with scripting using Net-SNMP.

Net-SNMP

It runs on Linux and Windows and is open-source.

"Net-SNMP is a suite of software for using and deploying the SNMP protocol (v1, v2c and v3 and the AgentX subagent protocol). It supports IPv4, IPv6, IPX, AAL5, Unix domain sockets and other transports. It contains a generic client library, a suite of command line applications, a highly extensible SNMP agent, perl modules and python modules." - Wikipedia

Pipi 9 in production

Pipi 9 is large but also very power-efficient (it's not an LLM). Each copy of Pipi 9 requires its own server. In this data centre, each enterprise customer has its own backend server running a customised Pipi 9 as a digital twin. I'm experimenting to see whether a small-form-factor refurbished PC could do the job.

There would need to be hundreds of these PCs in racks, autonomously coming online and offline as required to run batch jobs. Massive redundancy is provided by having spare PCs synced, NAS storage, VMs, etc.

This means that single-phase PDUs can be used. Maybe 1 PDU per 10-15 PCs per shelf, with only a few PCs running at any given time. 1 UPS per cabinet at the bottom, supplying multiple shelves.

Mechanical air-lock

Data needs to pass between this isolated data centre and customer deployments hosted in the cloud. My thought is to add a staging area (or several) between the two and pass data back and forth via network switches that are mechanically cycled (analogue). A bit like a double air-lock in space.

This would make it impossible for an external attacker to breach the system.

Robots in control

Pipi 9 is designed to serve as the system administrator for all customer cloud deployments. Coming on only as needed and in quiet times to minimise any disruption.

  • Updates
  • Configuration
  • Security
  • Databases
  • Deploying Docker
  • etc