The purpose of IT is to enable the seamless flow of information to achieve business outcomes.
Everything else is secondary and in service to the above goal.
- Applications only exist to manage data.
- Servers only exist to host applications, data, and integration
- Security only exists to protect information at rest and in transit
- And so on…
Therefore, it makes sense to explicitly model the information lifecycle, showing what information is created, consumed, and exchanged. Operating model diagrams are arguably the core business requirements, as they provide the top-level reference against which projects/programs/products should be shaped and against which IT strategy should be aligned.
Operating model diagrams can exist at multiple nested layers, usually as follows:
- Enterprise contextual, in which you seek to identify information exchange between the Enterprise and other actors, e.g. B2B, B2C, B2B2C, regulatory, or any other information exchange.
- Information exchanges between domains within the Enterprise.
- Information exchanges within a domain.
The modelling approach is the same regardless of the level.
There are some excellent references available on this topic.
- Enterprise Architecture as Strategy covers level 1 and provides several valuable frameworks for getting this level right, including how to identify which is the four primary operating model types most closely match your organisation based on the required degree of business process integration (low or high) and standardisation (low or high). The four types are Diversification (low, low), Coordination (high, low), Replication (low, high), or Unification (high, high).
- Designed for Digital covers mostly level 2 and follows from the above guide. It emphasizes the importance of identifying Enterprise components/domains that should be treated as coherent building blocks. You should seek to identify this as part of defining an operating model diagram based on the affinity of functions and information.
Modelling should identify business processes and modelling what information is read, written, and exchanged (via the dashed Flow connector)
In the following example, we can see three Business Functions, each connected by a Triggering connector to show the sequence of events.
We’ve coloured the connectors related to the information lifecycle in blue: a Flow connector and two Access connectors.
The information lifecycle diagram is shown in blue, with information read/written/exchanged.
This tiny diagram fragment explains the principal elements and how they are connected.
In practice, there are usually two phases to developing these diagrams, at any of the levels 1, 2 or 3 as defined above.
- Phase 1 – creating what usually amounts to a ‘shock and awe’ diagram where the primary purpose is to fully complete the discovery of all the processes and how they fit together. It would be best if you did not usually attempt to lay out the diagram too neatly in this phase; only seek to ensure that the diagram ‘compiles’, e.g.
- All processes have an actor defined.
- All functions have at least one information input and output, using Flow and Access connectors.
- You can trace the diagram from end to end and see where various business milestones and outcomes are achieved along the way.
- Phase 2 – scenario extraction in which you break the ‘shock and awe’ diagram into smaller building blocks. For example, a customer placing an order and establishing a contract might be one building block, followed by the ordering and shipping processes, and so on. In moving from Phase 1 to Phase 2, you will also need to define which parts of the business are core versus being plug-n-play.
This process of developing operating model diagrams at various levels is similar to the creation of swimlane diagrams. If you want to copy how a typical swimlane diagram looks, the diagram above can be rearranged, as shown below.
Most swimlane diagrams do an excellent job of showing the actions performed but do a poor job of showing the lifecycle of information (the blue lines)