Business Maps as a Framework

The metamodel we propose for modeling most businesses. Inspired by Domain Driven Design and user interviews in which entrepreneurs described how they model their businesses

Business Context

We divide our business into Business Contexts, each of which is a bounded context meaning it's a semi-isolated (maybe even generic) piece of the business. There are no rules on how big or small a Business Context should be, it's up to each entrepreneur to choose how they would like to divide their business to make it manageable for them and their scaling ambitions.

Think of a Business Context as a mental room, in this room we only think about a specific part of the business, allowing us to focus instead of being dragged left and right by the noise of the rest of the business. This structure helps with context switching, because with Business Contexts you can offload your toughts at any point, switch to another context, then come back later and pick up where you left off.

Each Business Context can have any number and combination of: Things, Personas, Actions, Values, Workflows, and Interfaces.

Things

What are the things we talk about in a given context, what do they mean, how do they related to everything else? Here we define the concepts related to a specific Business Context; we give the concept a name, give it a definition, and "shape" the concept by specifying its Attributes.

Attributes describe those concepts and how they relate to each other. This effectively allows us to create a mini ontology of a given Business Context and steers us away from miscommunication and ambiguity.

For example, the word "bucket" can mean different things depending on the context. In one context, we could be talking about a physical container we're using to mix paint, and in another context, we could be talking about a service offered by a cloud provider that allows us to store digital information. In the first context, the Attributes of the bucket could be its color, the material it was made from, and whether it has a handle or not. And in the other context, the Attributes could be the name of the bucket, the account that owns it, and the policies that dictate who can access the data within the bucket.

Attributes

Each Thing can have different Attributes that represent aspects or properties of a Thing. Each Attribute has a name, an Attribute Type and an Attribute Shape. The Attribute Type is what helps us distinguish the Integer number 420, from the Time 4:20, from the String (text) 420, which is a cultural slang term.

The Attribute Shape is what tells us what values are allowed within that Attribute, for example we might have an Attribute called "age" with an Attribute Type: Integer, and the Attribute Shape says that the age must be greater than 0 and less than 150. This improves your data's integrity, and makes it easier for you to set rules on your data as you develop your business applications.

Some examples of Things are Lemonade, Pizza, Contract, Wallet, Location, Device, Session, etc...

Personas

Every Business Context serves and is managed by different actors, whether those are human customers of different kinds, employees, or an AI agent that's triggering some automations. Those actors, or more accurately, those kinds of actors, are called Personas. Within the Personas space rules are chosen to manage what Actions can be invoked, effectively forming the policies of a given Business Context.

Actions

The verbs used within a Business Context. For example a Persona might view, add, remove, update, book, share, send, sign... a Thing by interacting with its Interface

Actions can be further divided into: the goal behind it, the procedure of actually doing the action, and its effects on the Business Context.

Interfaces

Things are just data, in order to perform Actions on them, we need some Interface that represents them. An Interface might be VisualInterface such as a web page, or a MachineInterface such as a JSON-LD API which allows computers to interact with the data.

Workflows

A Workflow defines the functions within your business logic, and should represent your functional requirements of a Business Context. You can described workflows through a linear sequence of steps, parallel branches, loops, recursion, or conditional paths. It can be triggered either by an Action or at regular intervals. Workflows can trigger other workflows to react to data changes, or send notifications, or ask for human intervention.

Values

While Things describe the shape of the data within a Business Context and tend not to change often over time, Values describe actual data content not just its shape, and is meant to change over time, while keeping track of changes.

Values could be individual instances of Things, or their Attributes, aggregates of any combination of them, configuration variables that the Business Context needs to function, or a qualitative goal we're aiming at.

They are useful for us to measure how well a given Business Context is performing because they represent what we value. For example the number of orders or customer feedback could be Values.

Value Stream

We want to avoid building monolithic businesses, in which everything is mixed up with everything else, so we divide our business into Business Contexts. Those in turn are connected through Value Streams. Value Streams describe the movements of Values between contexts, think of them as conveyor belts moving through different stations. Value Streams help us identify bottlenecks, and opportunities across our business, as well as give us a holistic view of the health of the business.

On this page