In this article I want to share a simple, practical approach to describing parts of an organization — one that deliberately ignores the common division between business and IT, because that separation holds us back.
The guiding principle is that models should represent real things. A building blueprint works because it describes something concrete: an actual building, with actual dimensions, that will be built by actual people. A subway map works because, however simplified, every line and station corresponds to something you can physically travel to. The moment a model loses that connection to reality it stops being useful.
The same principle applies here. Every element in this approach represents something that either exists or is explicitly intended to exist — a team you can name, a system you can access, a person who is accountable. Abstract concepts have their place, but their connection to what is real must always be evident.
No prior knowledge about modeling is required. If you can make sense of real estate blueprints, that show the layout of rooms, then you can make sense of the illustrations in this writeup. If not, please contact me to let me know what I am not explaining well enough.
To make this concrete, we follow The Enterprise through a real change: a decision to improve employee morale that leads to a new system and a new team. We start with what the enterprise looks like before anything changes, then introduce the new system and the organizational unit built around it. From there we drill into the system’s composition and zoom out to show how that unit fits into the broader organizational landscape.
The Enterprise
) and systems (
). The notation used is PrimaryScape, where blue shapes represent structures, green shapes represent information, and yellow shapes represent behavior/functionality. 
For more information about the above representation, please take a look at the Reasoning Behind a Simple Enterprise Representation writeup.
The Goal
The Enterprise has set a goal to improve employee morale. A well-known international management consulting firm is hired for consulting advice and guidance. After significant research and extensive use of their experience, working with lots of other enterprises for decades, the consulting company determines that people with an active interest in their pets have 20% better morale. The recommendation to The Enterprise is to support their employees’ interest in their pets.
The Plan
One of the market leaders in pet-based employee engagement is Catnip Enterprises. Catnip Enterprises are the creators of the Curious Cat Collaborative Content Creation and Commenting Bulletin Board (C6BB) software product. The C6BB software product can be installed as an IT system in a customer’s data center. Catnip Enterprises has plans on offering their solution as a cloud-based software-as-a-service (SaaS) in the unforeseen future.
The Enterprise decides to buy and implement the C6BB software product sold by Catnip Enterprises. The objective of implementing the C6BB system is to achieve a 20% improvement in employee morale.
The C6BB system needs to be up and running all the time because The Enterprise has employees working across all time zones of the globe.
To handle the C6BB system, The Enterprise is setting up a new operational unit called the C6BB Operational Business Unit (or C6BB OpBit). The C6BB Operational Business Unit will run and operate the C6BB system.
The C6BB Operational Business Unit (OpBit) consists of:
- the C6BB system
- a leader
- a leadership team to do strategic planning for the C6BB OpBit
- an operational team to run the C6BB system
- a user support team that helps the users of the C6BB system with any questions
- a Customer Portal where information can be provided to the users
- a collaboration space where knowledge is captured
- a content management space where internal documents are kept
Note that every blue shape represents a structural thing that exists, or will exist if we are representing a future intended state. A leader is a person that is identifiable. A team is identifiable by its manager and its members, even if it is not common practice to uniquely identify teams within enterprises. Systems can be shown to exist because people, or other systems, can access the system. If a system is down then there are consequences. Content and collaboration spaces, such a SharePoint sites/libraries/folders or Confluence spaces, exists and access to them can be controlled. The point is that this diagram just represents things that exist. Even the C6BB Operational Business Unit exists and is defined by the parts that make it up.
We can now show The Enterprise before and after setting up the intended C6BB solution.
After C6BB
Before C6BB
The Context
In order to run the C6BB System, the C6BB Operational Business Unit must buy compute, storage, application, and data center resources from other organizational units within the enterprise. These other organizational units are providers of, in this case, technical services. Each relationship between C6BB Operational Business Unit and the other organizational business units should be managed by an agreement, where the division of responsibilities and service levels are agreed on.
The technical service providers are still operational business units. It is their business to provide technical services. The separation of business and IT is an outdated and inefficient way of thinking. Over the last 50 years information technology has to varying degrees become part of every business unit of the enterprise.
Let’s clarify the relationship between the C6BB Operational Business Unit and the other organizational business units, by going into a little more detail with the C6BB system. At the highest level of abstraction we have represented the C6BB system as a single structure with behavior and information.
The C6BB system is made up of several components. In this case we will assume a simple traditional approach using two virtual machines to run application and storage components.
Nginx runs the web server and proxy virtual server. Apache Tomcat runs the application where logic has been implemented. MinIO runs an object store bucket where the pictures will be stored. PostgreSQL runs the database where meta data and other application data is stored.
The above picture, which one can think of as a top-down view, can also be represented as a sideways view.
All of these components have been created and configured only to make up the C6BB system. The C6BB system exists as a thing only because there is an agreement and understanding that these components running together makes up a system. The parts by themselves do not make sense or serve any purpose, but together they do. We can say that the C6BB system is composed of several parts, which can be visualized using a composition relationship (
) or by showing the parts within the C6BB system rectangle.
Sideways View
Top Down View
The virtual machines do not exist independently. If we continue the sideways view further down we will see that the virtual machines are running on a virtualization platform system. This virtualization platform system is composed of multiple physical servers.
Going all the way down to the Virtualization Platform system is relevant because it identifies the dependency the C6BB System has with a different system. In turn the C6BB Operational Business Unit requires a relationship and agreement with the operational business unit that runs the Virtualization Platform. In the diagram below this operational business unit is identified as the VM Service Provider.
The name VM Service Provider works in the context of this story, but it is a really poor choice of a name. Service provider is a role one party has towards another. The VM Service Provider gets its hardware from a HW Service Provider, who in turn gets its space from a Facility Service Provider. The VM Service Provider is a service consumer relative to the HW Service Provider. It gets really confusing because service provider and service consumer are roles a party takes on relative to other parties. Instead use real names for operational business units, or any kind of a party, instead of names based on a contextual role.
We can build on the dependencies the C6BB Operational Business Unit has to other operational business units. The application and database components require technical operational support which can be provided by other service providers within The Enterprise.
Now that we understand what is going on at this detailed level, we can simplify the picture.
Simpler Perspective
Even Simpler Perspective
The Business Context
So far we have addressed the structural dependencies of the C6BB system. The structural dependencies are what is needed to run and operate the structural components of the C6BB system.
The VM Service Provider runs the virtual machines. The App Operations and DB Operations Service Providers take care of the application and database components respectively.
Now let’s focus on the behavior and information of the C6BB system.
But let’s switch to a more logical representation of the behavior and information of the C6BB system.
Who or what triggers functionality/behavior to occur in the C6BB system? Where does information come from, and where is information sent to? For example, where does the [Some Employee Data] come from?
The following logical system context diagram can help us understand.
[Some Employee Data] comes via an integration (1) from the HR Management System (HRMS). Employees are (2) using the functionality (
) built into the C6BB system.
The (a)(b)(c) data access arrows shows how information is either read by or written by the functionality. Bi-directional arrows means read and write.
The stronger emphasis of some of the information shapes (
) is meant to show system of record information. This is where the information is created and is the only place where it should be updated in order to avoid data integrity problems. This is a useful extension or variation to the PrimaryScape modeling notation.
HRADAR stands for HR Analytics Data Analysis Reporting (anything for a mnemonic acronym). The HRADAR system receives information from multiple sources (3), such as HRMS and the C6BB system. Those with a keen eye will notice that [Employee Survey Results] does not have any origin in this picture. Presumably that information came from some survey system, but its origin is not relevant in this representation. The [Employee Morale Analytics] functionality in the picture also does not have any explanation for what triggers it. This can be explained in text or one could introduce a different picture with different information which focuses on the HRADAR system. Possible explanations could be that the functionality is manually triggered by a user logging into the HRADAR system, or that it is an automatically scheduled job that runs every week or every month.
Systems are systems and cannot run in a vacuum. We have shown that the C6BB System is running in the context of an Operational Business Unit we call the C6BB OpBit. The HRMS and HRADAR system exists in their own operational context, and context matters. Below are two different options, A and B.
Option A with Systems
Option B with Systems
Option A describes an organizational setup where the HRADAR system and the HRMS system is operationally handled by two separate operational business units.
Option B describes an organizational setup where both the HRADAR system and the HRMS system is operationally handled by the same operational business unit.
Option A and Option B are both viable approaches and different enterprises could handle two such systems in different ways. There is no right or wrong approach. Background and maturity of the people and organization involved plays a significant role in why an enterprise currently is set up one way or the other.
When building the C6BB System and establishing the new Operational Business Unit then it makes a difference if one has to integrate with two independent operational business units, each running their own system, or one operational business unit running both systems. From a technical perspective it is the same systems integration work, but operationally agreements and ways of working have to be set up differently.
For the sake of this story, The Enterprise was running the HRMS and HRADAR systems in their own operational business units (option A). We can now show how the C6BB Operational Business Unit is dependent on other operational business units.
This view does not show all of dependencies that the C6BB Operational Business Unit has to other operational business units. It only shows those dependencies that exists because of the C6BB System. The C6BB System is the most important part of the C6BB Operational Business Unit for it to achieve its purpose, which is to enable employees to engage with each other around their shared interest in cats. Remove this system and the C6BB Operational Business Unit cannot accomplish its main purpose.
There are three operational business units, in the above representation, that have not been explicitly named and are instead identified by the type of service provider they are. In a real scenario, not a story about The Enterprise, these operational business units should be identified by their actual names. This is a key point to keep in mind when creating reality based models. One should, whenever it is possible, identify and reference real operation business units, organizational units, information systems, teams, or any other things that exist within the enterprise.
The Common Frame of Reference
The operational business unit concept gives us an approach to use a common frame of reference. In order for the C6BB Operational Business Unit to function effectively it uses other resources, such as document management, collaboration platforms, and email systems.
In the image above other operational business unit dependencies are shown. Even this representation does not complete the list of all dependencies for the C6BB Operational Business Unit. Common ones like the email system, personal computer delivery and support, finance, or HR process support are not included. If an operational business unit wants to create visualizations of all its dependencies and they think it is helpful in running their operational business unit as efficiently as possible, then they can invest in creating and maintaining such models. An alternative could just be maintaining a simple list in an internal wiki page, just to keep track of what other operational business units they work with. A model representing their reality does not have to be a visual diagram.
The Conclusion
We have now gone through the approach I wanted to show you, using a fictitious though tangible example. Teams and systems are not new concepts, even if Teams does not seem to be a primary concept usually tracked.
The new and important takeaway is the concept of an operational business unit. An operational business unit is the smallest grouping of parts, such as teams and systems, that together has a purpose. The concept of an operational business unit recognizes that neither systems nor teams run by themselves.
I am deliberate in calling it an operational business unit. Operational, because it should be clear what it does and what it operates. Business, because if you are part of an enterprise then you are doing business. From your perspective as an operational business unit you provide and consume products and services from and to other operational business units.
This is a generic approach that holds true no matter what kind of an enterprise we are talking about. It is also an approach that does not depend on everyone buying into it. You can use this approach just for yourself, to make sense of your operational context and run your operational business unit efficiently.
One significant challenge I predict is that using the operational business unit approach challenges the traditional IT vs Business mentality that still is prevalent in many organizations. We have outgrown that old division and it is holding us back.
The Cliff Hanger
The Enterprise failed in its goal of improving employee morale by 20%. The implementation of the C6BB System and establishing the C6BB Operational Business Unit only resulted in a 10% improvement in employee morale. The Enterprise called in the well-known international management consulting firm again and asked it to figure out why they did not get the 20% improvement in employee morale.
You will have to wait for the sequel to find out what went wrong and how they fixed it.