Book Notes #25: Creating Agile Business Systems by Amar Gupta and Amit Mitra

Title: Creating Agile Business Systems with Reusable Knowledge
Author: Amit Mitra and Amar Gupta
Year: 2006
Pages: 384

Have you ever wondered why business systems feel so fragile, even when we throw the best tools, frameworks, and people at them?

Why a tiny change in one part of the business can create a ripple of unexpected problems everywhere else?

This book takes that everyday pain and traces it all the way back to how we represent knowledge itself.

It’s not about writing better code or holding better meetings—it’s about how we build meaning into our systems from the ground up. And that shift?

It might just change the way you see technology, change, and agility forever.

As a result, I gave this book a rating of 7.0/10.

For me, a book with a note 10 is one I consider reading again every year. Among the books I rank with 10, for example, are How to Win Friends and Influence People and Factfulness.

3 Reasons to Read Creating Agile Business Systems with Reusable Knowledge

Book Overview

Imagine walking into a grocery store where everything works smoothly. The cashier knows your loyalty card by heart, your receipt reflects every discount instantly, and your order history syncs perfectly with your app. Now imagine the same company tries to launch a new promotion or adjust a business rule—and everything breaks.

That’s the problem Amit Mitra and Amar Gupta explore in Creating Agile Business Systems with Reusable Knowledge. It’s not just about IT. It’s about meaning—and how systems today are built on brittle foundations because they’ve never truly learned to understand the world they’re trying to help us manage.

This is not an easy book. It’s a dense, thought-provoking read filled with deep concepts, formal logic, and plenty of real-world frustration. But if you stay with it, the reward is a whole new way of thinking about business systems—one that goes far beyond code and enters the realm of intelligence, behavior, and meaning.

At the heart of the book is a simple but powerful idea: systems today are failing not because they lack computing power, but because they lack reusable knowledge. Businesses keep repeating the same rules across departments, systems, and codebases—and every time something changes, the whole thing turns into spaghetti. So instead of empowering change, technology becomes the bottleneck.

The authors argue that the key isn’t more tools or faster delivery pipelines. It’s representation. Systems must be able to represent business knowledge in a way that’s meaningful, shared, and reusable across contexts. And to do that, we have to start from the ground up: by redefining how we model the real world inside our machines.

That journey starts with objects—not in the programming sense, but in the behavioral, meaningful one. An object, in this framework, isn’t just a car or a customer. It’s a thing that behaves, that responds to events, and that carries a state through time. A pane of glass isn’t just “glass”—it’s something that can be whole, cracked, shattered, and it reacts differently depending on what happens to it. This kind of modeling brings us closer to how we actually think and reason about the world.

But describing behavior isn’t enough. We also need to describe what an object is. That’s where attributes come in. Attributes like weight, color, or status aren’t just labels. Each one is deeply tied to a domain of meaning—a structured space of possible values, rules, and constraints. For example, temperature isn’t just a number; it lives in a domain that includes scales (like Celsius), formats (like numeric fields), and boundaries (like minimum and maximum allowed temperatures). By respecting these domains, we can stop treating business data as just digits and start treating it as meaningful, coherent knowledge.

The book goes even deeper—showing how meaning is expressed through patterns, how objects evolve through state machines, and how proximity, clustering, and constraints help us capture reality as it unfolds. It’s as much a philosophy of systems as it is a methodology. And that’s what makes it so compelling.

Take this analogy: Imagine every piece of business knowledge—every rule, goal, or exception—as a Lego brick. In most companies, those bricks are glued into place, buried in different systems, replicated by hand, and painted over. Changing anything means tearing everything down. But what if those bricks were clean, reusable, and stored in a single shared place? You could redesign your business processes like snapping together new models—faster, safer, and with far less risk.

That’s the promise of reusable knowledge. But the authors are clear: this isn’t something you can bolt onto legacy systems. It requires rethinking everything—from how we define attributes and domains, to how we manage change across teams. It’s as much a cultural shift as it is a technical one.

The beauty of this book lies in its ambition. It doesn’t settle for small tweaks or short-term fixes. It invites us to question the very foundations of business systems and imagine a future where change isn’t scary, expensive, or fragile—but natural, structured, and supported by a knowledge fabric that’s built to last.

It’s not an easy read. But it’s worth the effort—especially for those who have ever been stuck between what the business wants and what the system can deliver. If you’ve ever felt that frustration, this book offers a deeply reasoned, surprisingly human, and genuinely radical alternative.

You may never look at a business rule—or a pane of glass—the same way again.

So if you decide to read this book—what will you actually learn?

You’ll learn how business knowledge really works—and why it’s so hard to manage. Most organizations treat knowledge like scattered Post-it notes across systems. This book shows how to bring it all together in one structured, meaningful model that reflects how the business actually runs.

You’ll understand what an object really is—not just in code, but in reality. It’s anything that behaves, changes, and carries a state over time. The book teaches you how to model objects in ways that reflect their real-world behavior, not just their current status.

You’ll see that attributes are much more than fields in a database. They carry deep meaning, tied to structured domains that define their limits, formats, and rules. Learning how to model attributes properly means building systems that are precise, consistent, and adaptable.

You’ll discover how domains give structure to meaning. Instead of treating data like raw numbers, you’ll learn how to build systems that respect the scale, structure, and nature of what those numbers represent—like temperature, color, or ranking.

You’ll rethink how patterns and state space can help model behavior. This is where things get abstract but incredibly useful. Patterns let you express complex ideas, constraints, and behaviors in reusable ways. Once you understand this, you start to see how to model almost anything—from a customer journey to a logistics process—in a way that’s structured and flexible.

You’ll finally grasp the true meaning of reusability. Not in the programming sense, but in the knowledge sense. When you normalize rules, relationships, and behaviors, you stop rewriting the same logic in ten different systems. That makes change faster, cheaper, and far less risky.

In short, this book teaches you how to design for understanding—not just execution. You’ll leave with a deeper appreciation for the hidden messiness of business systems and a clearer path for making them cleaner, smarter, and far more resilient.

It’s not a casual read, but it’s a transformative one.

If you’re the kind of person who’s always asking “Why is this so complicated?” or “Why do systems make simple changes so hard?”—this book will feel like someone finally answering those questions with clarity, logic, and a whole lot of insight.

And once you see what’s broken, you won’t want to go back to the old way of working. You’ll start to imagine a new kind of system—not one that just runs the business, but one that understands it. And that might be the most agile thing of all.

Some key concepts include:

Reusable Knowledge: At the heart of the book is the idea that knowledge—business rules, logic, goals, constraints—should be stored once and reused across systems. Instead of duplicating logic in different places, reusable knowledge creates a single, structured source of meaning that can be applied wherever it’s needed. This makes systems easier to change and align with business goals.

Object: An object is anything in the real world that behaves and changes over time. It’s not just a static thing—it’s something that can be in different states, respond to events, and carry a history. In this model, objects are the basic building blocks of systems, and every object must have at least one unique identifier to track its evolution.

Attribute: An attribute is a specific kind of object that describes a property of another object. For example, color or weight are attributes of a glass. But attributes aren’t just labels—they connect an object to a domain of meaning and define what values are valid or allowed. They are how we describe the current state of an object.

Instance Identifier: This is a special attribute that uniquely identifies each instance of an object. It ensures that we can track a specific object through time, even as its other attributes change. This is essential for managing behavior, state, and history within systems.

Domain of Meaning: Domains define the set of possible values and meanings an attribute can take. For example, the domain of temperature includes values like 20°C or 68°F, but also carries rules about how to interpret and compare those values. Domains are the foundation for understanding and structuring meaning in systems.

Formatting Domain: A formatting domain determines how values from a domain of meaning are expressed visually, aurally, or through other senses. It’s how we translate meaning into symbols that systems and people can perceive and interact with—like text, numbers, images, or sounds.

Nominal, Ordinal, Difference-Scaled, and Ratio-Scaled Domains: These are four types of domains based on how much information they carry. Nominal domains classify without order (e.g., colors), ordinal domains introduce ranking (e.g., satisfaction levels), difference-scaled domains support meaningful subtraction (e.g., temperature), and ratio-scaled domains support meaningful division (e.g., weight or age).

State: The state of an object is the combination of all its attribute values at a given moment. State reflects the current condition of the object, and changes in state reflect behavior over time. Systems must model not just the current state, but the rules governing how objects move between states.

State Space: State space is the full set of all possible states an object can be in, given its attributes and domains. It helps define what’s allowed, what’s possible, and what’s invalid. Understanding an object’s state space is essential to modeling real-world behavior accurately in a system.

Event: An event is something that happens in time and triggers a change in an object’s state. Events are the dynamic drivers of behavior—like a hammer striking a glass or a customer placing an order. They connect time, action, and state change in the object model.

Effect: The effect is the outcome of an event. It defines how an object changes (or doesn’t) in response to something happening. For example, striking a whole pane of glass might shatter it, but striking an already broken pane may have no effect. Effects are tied to both the current state and the event that occurs.

Pattern: A pattern is a structured arrangement of symbols or values that carries meaning. Patterns define how we recognize things like forms, behaviors, or sequences. In the system model, everything—data, rules, interfaces—is ultimately a pattern. Understanding and modeling these patterns lets us build systems that can interpret and reuse knowledge effectively.

Degree of Freedom: Degrees of freedom refer to the ways in which a pattern or object can vary. The more degrees of freedom something has, the more information it can carry or express. For example, a 3D model has more degrees of freedom than a 2D image, allowing for richer interactions.

Similarity and Proximity Metrics: These are methods for comparing patterns or states to determine how close they are in meaning or behavior. Depending on the type of domain (nominal, ordinal, etc.), different metrics apply. These metrics help systems identify related states, group similar cases, or trigger appropriate rules based on “closeness.”

Normalization of Knowledge: Normalization means organizing knowledge so that it is stored only once in a consistent, unambiguous form. Just like data normalization removes redundancy in databases, knowledge normalization prevents the duplication of rules and logic across systems. It’s key to making knowledge reusable and systems maintainable.

Inclusion and Exclusion Sets: These define what values are allowed (inclusion sets) or disallowed (exclusion sets) for an attribute. They act as constraints on the domain, helping refine what values are valid for a given object in a specific context.

Unknown vs Null Values: The model makes a critical distinction between unknown and null. An unknown value means the attribute exists, but its value isn’t currently known. A null value means the attribute does not exist for that object at all. Treating these differently is crucial for clarity and avoiding system errors.

Agent: An agent is a system component that acts on behalf of a person or object. It’s a representation that can sense events, make decisions, and initiate actions. Agents are key to building systems that not only respond but behave in meaningful ways.

Composite and Aggregate Objects: These are objects made up of other objects. For example, an insurance policy might be a composite object made up of terms, clauses, and customer data. Understanding how to model these relationships helps systems reflect real-world structures and interactions.

Constraints and Optionality: Constraints define the rules for valid attribute values. Optionality refers to whether an attribute must have a value or not. These ideas help systems handle variability without ambiguity—and ensure flexibility without losing structure.

Trajectory: An object’s trajectory is the path it takes through state space over time. It’s a record of how its state has changed, influenced by events and rules. This concept allows systems to model not just what something is, but what it has been—and maybe predict what it could become.

Chapter by Chapter

Chapter 1 – On the Nature of Reality and the Nature of Business

The big idea

This chapter dives into the philosophical core of the book. It’s a bold, sweeping reflection on what knowledge really is, why our current systems fail to deal with it properly, and how that failure creates a massive obstacle to agility in business. The authors argue that if we want to build systems that support real-world business change, we need to start by understanding how meaning and knowledge work in the real world—and then model that in our systems.

Why this matters

Businesses today face a lot of pressure: fast-changing markets, picky customers, global operations, and complex partnerships. But ironically, the systems they depend on—often built with rigid code and disconnected processes—are the very things holding them back. Every time something changes, those systems react like dominoes falling: unpredictably and chaotically.

The root of the problem? Business knowledge—goals, rules, processes—isn’t stored in one consistent place. It’s fragmented, duplicated, and misaligned across systems. So when a change happens, there’s no single source of truth to guide it smoothly through. The authors say this happens because knowledge in systems is not normalized—it’s not stored the way it naturally exists in the real world.

What is knowledge, really?

The chapter defines knowledge as meaning—how rules, goals, policies, and behaviors work together in harmony to drive the business forward. Knowledge isn’t just information. It’s coordinated information. And coordination is everything. It’s what makes the difference between a smooth operation and a chaotic mess.

This coordination, they argue, happens naturally in the real world. For example, when we say “Jenny has a son named Michael,” that fact carries meaning that can’t be chopped up too much without losing context. Some rules or facts are indivisible. These are called irreducible facts or atomic rules. If we divide them too much in systems, we lose meaning—and then things go wrong.

The problem with current systems

Two real-world stories illustrate how things break down. In one, a phone company offers voice mail to a customer, bills them, but forgets to actually activate the service because different systems didn’t recognize voice mail in the same way. In another, a courier company builds two separate systems for scheduling deliveries: one for trucks and one for warehouse conveyors. Both handle routing and capacity, but improvements made in one system don’t benefit the other—even though they deal with the same concepts. The opportunity cost is hidden but huge.

In both cases, the systems failed not because of faulty tech, but because the same atomic rules were repeated differently across systems without coordination. When knowledge is fragmented, even simple changes become hard and risky.

Back to basics: modeling the real world

So how do we fix this? The authors suggest going back to how the real world works. In reality, there is no such thing as “data” or “process” by themselves—there is only behavior. Behavior is how objects respond to events over time. And behavior includes change, which means time matters.

From this lens, we can model reality through four components:

1. Objects – the things that exist.
2. Relationships – how those objects interact.
3. Processes – relationships that involve change over time (e.g., baking a cookie).
4. Events – triggers that cause behavior to happen (e.g., pressing “start”).

Processes are special relationships that represent sequences in time. Events trigger those processes. All of these must be modeled properly if we want to capture how businesses behave in the real world.

Information, domains, and meaning

One of the most interesting and abstract parts of the chapter is about how meaning is expressed. The authors explain that meaning exists independent of space and time—it just is. But we experience and store that meaning through physical expression: text, numbers, formats, screens, files. That’s where we often mess up: we confuse the format with the meaning.

To make sense of this, the authors introduce the concept of domains—natural containers for meaning. A domain defines what kind of information something holds and how much information it carries. There are four kinds:

• Nominal domains – like gender. They classify things, but don’t carry order or quantity.
• Ordinal domains – like rankings. They show order, but not how big the gaps are.
• Difference-scaled domains – like temperature. They allow us to measure gaps, but not ratios.
• Ratio-scaled domains – like height or age. They allow all three: classification, ordering, and meaningful ratios.

Each domain needs to be expressed in a format (like numbers or text), and sometimes it needs a unit of measure (like meters or Celsius). Mixing this up or storing the same thing in different formats without coordination causes knowledge to become fragmented and unmanageable.

Mr. Domain’s secret

To make all of this less abstract, the chapter introduces a character—Mr. Domain—who walks us through examples (like temperature in jugs of milk or converting lengths across countries) to show how normalization of knowledge works in practice. Through his explanations, we begin to see how a structured “metamodel” could help standardize and reuse business knowledge, no matter how or where it’s stored.

Even something as simple as converting between inches and meters holds valuable lessons: we only need one rule per conversion, not every possible combination. That’s the power of normalization—and it’s what makes scalable, flexible systems possible.

This chapter lays the foundation for everything else in the book. It’s a philosophical and technical deep dive into how the real world structures knowledge—and how we can mirror that in our systems. The core idea is this: if we want business systems to be agile, we need to build them from reusable, normalized pieces of meaning—just like nature does. That starts with understanding behavior, domains, and the hidden patterns of how information works.

Chapter 2 – The Object at the Root of It All

What this chapter is about

This chapter builds the foundation for representing knowledge in business systems by focusing on one core idea: the object. The authors treat the object as the building block from which all knowledge flows. If we want systems to be agile and capable of adapting to real-world changes, we must start by understanding how objects behave, how their states change, and how we model that behavior over time. It’s not just about naming things—it’s about capturing their meaning, behavior, and evolution.

Why objects matter

Objects are more than nouns. In this book’s framework, an object is anything whose behavior is part of what we want to understand and model—people, things, events, even concepts. Each object carries state, attributes, and relationships, and responds to events. Its definition is dynamic and behavior-based, not static. This shift is critical: to make business systems reusable and adaptable, we must model how things behave—not just how they look at a given point in time.

Class and instance

The difference between an object class and an object instance is a recurring theme. A class groups objects by shared behaviors and properties. An instance is a specific version of an object, with its own identity and state. For example, “glass pane” is a class, while each actual piece of glass is an instance with its own thickness, color, and whether it’s whole or shattered.

This distinction becomes crucial when we want to reuse knowledge. Instead of duplicating rules and data for every instance, we store shared rules in the class—and only the specifics in the instance.

Behavior through state machines

To model how objects behave over time, the authors use state machines. A glass pane, for example, can be “whole” or “shattered.” A “hammer strike” is the event that moves it from one state to another. This idea is extended with state charts, where each object’s properties are visualized as partitions—helping to organize complex states and behaviors without chaos.

The magic here is how we represent effects—the result of events. For instance, hammer strikes have no effect on an already shattered pane. These rules are simple but powerful, and can be layered to represent rich behaviors—like cracked glass, broken glass, and even sub-states within those.

Objects as bags of meaning

Each object is like a “bag” holding its properties (attributes), relationships, and effects. This includes both what’s visible (like color or weight) and what’s invisible (like business rules). Over time, the object changes, moving through state space—a key concept introduced in this chapter.

State space

State space is the set of all possible conditions an object can be in. The more attributes we consider, the more complex this space becomes. If we add time, weight, color, and thickness to our glass pane, we move into multidimensional state space. This lets us track and understand the trajectory of an object over time.

State space helps us normalize knowledge by organizing what’s allowed (lawful states) versus what’s possible. It prevents us from creating messy, inconsistent representations of reality. For example, if a red glass can be shattered but a blue glass can’t, that restriction is part of the state space.

Default, unknown, and null values

A major insight in this chapter is the importance of distinguishing between:

• Unknown (we know the attribute exists, but we don’t know its value),
• Null (the attribute doesn’t exist at all for that instance),
• Default (a typical starting value when nothing else is specified).

Most systems fail to handle this distinction well, often treating all three the same. That leads to data errors, confusion, and poor decision-making. For example, if we confuse “no temperature reading” with “temperature is 0,” we might completely miscalculate a city’s average climate.

Identity and history

Every object must have a unique identifier that stays constant through all changes. This is how we track it over time. Even when the object changes state, we know it’s still the same thing. This is a simple but foundational idea—without it, we can’t model time, change, or history meaningfully.

The object’s history—its series of state changes—isn’t something separate. It’s part of what the object is. Systems need to reflect that.

Composite and aggregate objects

Objects can contain other objects. Think of an insurance policy class, which contains multiple individual policies. Or an inventory system made up of vendors, items, and rules. These are called aggregate objects. Each layer, each grouping, is still an object in itself, with its own properties and state.

This chapter introduces the core building block of the entire knowledge framework: the object. But not in the traditional programming sense. Here, objects are vessels of meaning, history, behavior, and transformation. When we understand them this way, we can finally build systems that represent how businesses truly work—and adapt when those businesses change.

Chapter 3 – The Nature of Attributes

What’s going on in this chapter

This chapter is one of the most detailed and conceptually rich so far. It focuses on attributes—how they work, why they matter, and how they connect objects to meaning, domains, and constraints. If objects are the “things” in a system, attributes are what tell us about them. But as the authors show, attributes are not just labels—they’re deeply structured components of knowledge, and getting them right is essential to building systems that can adapt, scale, and behave like the real world.

Attributes: the bridge between object and meaning

The authors start by defining an attribute as a special kind of object. It’s not just a property or a label; it’s the repository of an irreducible fact—a rule about an object class. Every object must have at least one attribute, and that one is its instance identifier (its unique ID). That identifier must always be nominally scaled, meaning it just asserts that the object exists.

Each attribute connects:

• A specific object (like a car)
• A type of property (like color)
• And a value (like red)

This trio—Object–Attribute–Value (OAV)—is foundational. It’s how the system knows what something is and what it currently looks like. It also provides the basis for modeling state, because an object’s state is simply the combination of all its attribute values at a moment in time.

Domains: where attributes get their meaning

Every attribute maps to a domain—a set of possible values and rules. For example, both a person’s height and a room’s width map to the length domain. Even if these values are used in different ways (e.g., with different units or limits), they still inherit the core rules from that domain.

Here’s the key idea: an attribute is like an intersection between a domain and an object class. It borrows meaning from the domain and combines it with specific constraints from the object. This allows attributes to be reused and understood consistently across different objects.

The state of an object = its attributes + their values

An object isn’t just a thing—it’s a bundle of attributes and values. The state space of an object is created by the Cartesian product of all its attributes. If you know all the attributes and their domains, you can map out every possible state the object could be in. This makes modeling behavior, history, and change possible.

For example, two rooms might both have attributes like length, width, and height. These are all drawn from the same domain (length), but they can each have different constraints and rules.

Types of attributes: qualitative vs quantitative

The book introduces two big categories of attributes:

• Qualitative attributes (like gender or status) come from nominal or ordinal domains and only need a format to be meaningful.
• Quantitative attributes (like weight or temperature) come from difference or ratio domains and require both format and unit of measure.

This matters because how an attribute is expressed—what units and formats we use—affects how we interpret and operate on it.

Constraints: how we define what’s allowed

Now things get deeper. The authors explain how attribute constraints shape what values are allowed and what aren’t. There are two major types:

1. Inclusion sets – Define which values are permitted.
2. Exclusion sets – Define which values are not permitted.

These sets act like rules for the attribute’s valid state space. For instance, a shipping container might only come in 20ft and 40ft lengths—that’s an inclusion set.

There’s a subtle but powerful distinction between:

• Unknown values (we know the attribute exists, but not its current value)
• Null values (the attribute doesn’t exist for this object)

This matters when designing systems: are we saying something doesn’t exist, or that we just don’t know yet?

Optionality and precision

The chapter also dives into the idea of optional attributes—attributes that may or may not have known values. The authors are precise here: optionality must distinguish between “we don’t know the value” and “this property doesn’t exist at all.” Most current systems blur this line, but the book argues that separating the two improves accuracy and flexibility.

Ordinal and quantitative constraints

For ordinal attributes (like preference rankings), we can use ranges—for example, “likes at least a little but not more than a lot.” These ranges can have upper and/or lower bounds. Similarly, quantitative attributes can be constrained with open or closed intervals, like “less than 2 feet” (open) versus “up to 2 feet” (closed).

Combining and merging constraints

The chapter ends by exploring how inclusion and exclusion sets behave when merged. Merging can get complex:

• Sets might overlap or conflict.
• Merging exhaustive sets (ones that claim to know all valid or invalid values) can cause contradictions.
• The authors introduce the idea of dormant value sets—older or inactive constraints that can be reactivated when needed.

The rules for merging constraints are detailed and precise. For example, if inclusion and exclusion sets overlap, the system can’t resolve the conflict unless it’s told which set takes precedence.

This chapter is a deep technical dive into how attributes structure meaning in a business system. Attributes aren’t just labels—they’re vessels of knowledge, tied to domains, values, and rules. Understanding their structure and behavior is critical to designing flexible, reusable systems. This isn’t about writing more code—it’s about building systems that reflect how the real world works, down to the smallest detail.

Chapter 4 – Domains and Their Expression

What this chapter explores

Chapter 4 is a deep dive into one of the most fundamental ideas in the book: how we give meaning to the world using domains. It’s a complex but beautifully structured chapter that walks us from simple concepts like measurements and formatting into abstract patterns of meaning and behavior. The goal? To show how we can build truly agile systems by grounding everything—objects, attributes, symbols, and their relationships—in domains of meaning.

From numbers to meaning

The chapter starts with a crucial observation: numbers by themselves don’t mean anything. Saying a room is 30 feet long only makes sense if we understand what “30” and “feet” actually refer to. These numbers are measures of meaning, and the unit of measure is a bridge between abstract meaning and numeric expression. When we say a room is 30 feet or 360 inches long, the room hasn’t changed—only the map from meaning to symbol has.

This distinction lays the foundation for the three types of domains introduced:

1. Domains of meaning – Where the abstract concepts live (like length, color, temperature).
2. Formatting domains – How we express those meanings with symbols (feet, inches, colors, etc.).
3. Domains of numbers – The raw number sets that we use to quantify things.

These three domains work together to make meaning visible, measurable, and computable. Every attribute and object we model in a system depends on these domains for its meaning and behavior.

The spectrum of domain types

Next, the authors break down how different types of domains carry different amounts of information:

• Nominal: Just tells us things are different. (E.g., male vs. female, red vs. blue.)
• Ordinal: Adds ranking. (E.g., first, second, third.)
• Difference scaled: Measures meaningful differences. (E.g., 20°C vs. 30°C.)
• Ratio scaled: Adds the ability to talk about proportions. (E.g., 10 kg is twice 5 kg.)

This is critical because the kind of domain we choose determines what operations we can perform. For example, we can’t meaningfully say that “male” is 2x “female,” but we can say 10 kg is 2x 5 kg. Systems often ignore these distinctions, which leads to misinterpretation and bad decisions.

Formats: Giving meaning physical form

Pure meanings are abstract. To be used in systems, they need to be formatted into symbols that can be perceived—by humans or machines. These formats must be sensed, which is why the authors define five fundamental formatting domains aligned with our five senses:

• Visual (e.g., text, images)
• Auditory (e.g., tones, speech)
• Tactile (e.g., vibrations, textures)
• Olfactory (e.g., smells)
• Taste

Most current tech systems only handle visual and auditory formats well. But as systems evolve, the ability to handle richer, more immersive formats (especially in virtual and augmented reality, biometrics, and robotics) will be essential.

Formats are more than outputs—they represent meanings. When a symbol represents another object, it becomes a format of that object. This makes formatting a subtype of representation. And when software represents a user and acts on their behalf, it becomes an agent—a central concept in automation and intelligent systems.

Patterns: The architecture of meaning

Now the chapter shifts gears. We move from domains to patterns—the most fundamental metaobject in the entire book. Everything we model, from concepts to user interfaces, is ultimately a pattern of information. The key idea here is that:

Meaning is a pattern. Symbols are patterns. And systems work by mapping between these patterns.

Patterns are defined by how symbols are arranged in space and time. These arrangements can be:

• Sequenced or unsequenced
• Ordered or unordered
• Bounded or infinite
• Delimited or continuous

The structure and rules that define a pattern determine its identity and meaning. For example, a sentence is a sequence of words (a pattern). If you change the order of the words, you might change the meaning. If the order doesn’t matter, like a shopping list, it’s an unsequenced pattern.

Patterns also have dimensions and degrees of freedom. A word is a one-dimensional visual pattern. A map is two-dimensional. A VR simulation might be three-dimensional. The more dimensions and degrees of freedom a pattern has, the more information it can carry.

Why degrees of freedom matter

The number of degrees of freedom a pattern has is a direct measure of how much information it can express. For example, a 3D model of a mountain can convey more than a 2D photo because it lets you explore different angles and perspectives.

Every symbol or pattern used in a system has a limited information-carrying capacity. Future business systems—especially those interacting directly with customers—must recognize this and optimize for it. Systems that ignore this will fail to scale, adapt, or meet modern expectations.

Boundaries and structure

Patterns can be finite or infinite, delimited or not. A paragraph has clear boundaries (periods, spaces). A musical pattern may be bounded by bars. But some patterns, like an image wrapped around a sphere, may be finite but undelimited—there’s no clear start or end. These nuances matter in pattern recognition, especially in systems dealing with multimedia, spatial information, or dynamic input.

Patterns can also be open or closed. An open pattern excludes certain symbols from touching the boundary (like an open interval in math). A closed pattern includes them. These constraints are important when modeling range, containment, and rules of association.

Similarity and proximity

One of the most powerful insights in this chapter is about similarity metrics—how we decide whether objects or symbols are part of the same pattern. Proximity isn’t always physical; it can be based on color, pitch, meaning, or even user behavior. These proximity metrics define clusters in state space—a conceptual space where each object’s state is defined by its attributes.

Different metrics apply in different kinds of spaces:

• In ratio-scaled space, we can use distances and ratios.
• In ordinal space, we can only compare rankings.
• In nominal space, we can just tell things apart—no ranking or distance is meaningful.

This leads to a profound realization: all patterns are clusters in state space. And the way we define the closeness of those clusters is the heart of meaning.

So what does all this mean for building agile, reusable systems?

We must:

• Carefully model domains of meaning to ensure clarity and precision.
• Use formats to express these meanings in ways humans and systems can perceive.
• Recognize and design for patterns—structured arrangements of information that define identity and behavior.
• Understand the degrees of freedom and similarity metrics that shape how information flows, clusters, and behaves.

This isn’t just about making systems work. It’s about making them understand the world they operate in. When we model meaning correctly—from attributes to domains to patterns—we build systems that can learn, adapt, and communicate with clarity.

4 Key Ideas from Creating Agile Business Systems with Reusable Knowledge

6 Main Lessons from Creating Agile Business Systems with Reusable Knowledge

My Book Highlights & Quotes

“… Agility and innovation are necessary to achieve global excellence and customer value in twenty-first-century business, yet most approaches to business process engineering sacrifice these in favour of operational efficiency and economics…”

“… Moreover, the IT systems used to automate and encapsulate business processes are unresponsive to the dynamic business environment. A modular approach to building business systems that parallels that of object-oriented software is presented…”

“… Agile Business Systems are designed to adapt to changing market conditions and customer demands, which results in increased efficiency and effectiveness…”

Conclusion

In the end, Creating Agile Business Systems with Reusable Knowledge isn’t just a book for architects or engineers—it’s a book for anyone who’s ever tried to change something and got stuck in the mess.

It gives you a new language, a new lens, and a new level of clarity. It’s not always an easy read, but it’s the kind of book that stays with you.

And if you care about building systems—or organizations—that can keep up with change, this might be one of the most important books you’ve never heard of.

I am incredibly grateful that you have taken the time to read this post.

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support and appreciation tangibly?

Creating these posts takes time, effort, and lots of coffee—but it’s totally worth it!

If you’d like to show some support and help keep me stay energized for the next one, buying me a virtual coffee is a simple (and friendly!) way to do it.

Do you want to get new content in your Email?

Do you want to explore more?

Check my main categories of content below:

• Book Notes
• Career Development
• Essays
• Explaining
• Leadership
• Lean and Agile
• Management
• Personal Development
• Project Management
• Reading Insights
• Technology

Navigate between the many topics covered in this website:

Agile Art Artificial Intelligence Blockchain Books Business Business Tales C-Suite Career Coaching Communication Creativity Culture Cybersecurity Decision Making Design DevOps Digital Transformation Economy Emotional Intelligence ESG Feedback Finance Flow Focus Gaming Generative AI Goals GPT Habits Harvard Health History Innovation Kanban Large Language Models Leadership Lean Learning LeSS Machine Learning Magazine Management Marketing McKinsey Mentorship Metaverse Metrics Mindset Minimalism MIT Motivation Negotiation Networking Neuroscience NFT Ownership Paper Parenting Planning PMBOK PMI PMO Politics Portfolio Management Productivity Products Program Management Project Management Readings Remote Work Risk Management Routines Scrum Self-Improvement Self-Management Sleep Social Media Startups Strategy Team Building Technology Time Management Volunteering Web3 Work

Do you want to check previous Book Notes? Check these from the last couple of weeks:

• Book Notes #126: Inevitable by Mike Colias2025-03-24
• Book Notes #125: Revenge of the Tipping Point by Malcolm Gladwell2025-03-21
• Book Notes #124: Radical Candor by Kim Scott2024-09-04
• Book Notes #123: The Personal MBA by Josh Kaufman2024-05-09
• Book Notes #122: The First 20 Hours by Josh Kaufman2024-05-02

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support tangibly? A virtual coffee is a small but nice way to show your appreciation and give me the extra energy to keep crafting valuable content! Pay me a coffee: