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 Attribute
s, 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.