“The wisdom of bridges comes from the fact that they know the both sides, they know the both shores!”
– Mehmet Murat Ildan
What is an operating model and how does it work with an organization’s business architecture? We will explore this topic and give you some straight talk on how you can look at things and move forward from a business architecture perspective. Fasten your seat belt.
First things first, what is an operating model?
A variety of definitions exist. Here are few key ones:
The Business Architecture Guild® defines an operating model as: “an abstract representation of how an organization operates across a range of domains in order to accomplish its function.”1
The Operating Model Canvas book2 defines an operating model as…
“…a visual representation (i.e., a model)
…in the form of a diagram or map or chart or collection of diagrams, maps, tables, and charts
…that show the elements of the organization, such as activities, people, decision processes, information systems, suppliers, locations, and assets,
…that are important for delivering the organization’s value proposition(s)
…and how these elements combine to successfully deliver the value proposition(s)”
Julie Choo, author of THE STRATEGY JOURNEY, articulated the idea of operating model in her Business Architecture and the Strategy Journey Fireside Chat3: “In its truest form, an operating model is what it takes to actually run a business…it is comprised of various components such as capabilities, functions, people, process, data, systems…. All these things exist in isolation. The operating model is how you actually put all of these things together and make them serve their purpose.”
So, here are a few takeaways to keep in mind, especially from a business architecture perspective:
- An organization’s operating model ≠ an organization’s business architecture.
- Operating models typically include different and additional components than we would capture as part of business architecture.
- Operating models are not just about creating pictures, rather they help organizations focus on putting the pieces together in a way that allows for the successful delivery of its value proposition(s).
Is there a standard template or set of principles for an operating model?
Second verse same as the first. The Operating Model Canvas is probably the closest to a de facto standard for representing an organization’s operating model, with some rigor behind it.
What components should be included in an operating model?
Third verse same as the first. The components included can vary quite a bit, depending on the source you are looking at and their perspectives and methods for operating model definition.
Here’s a snapshot of just a few operating model frameworks and the components they include. (This is not a complete list of frameworks or potential components.)
- Operating Model Canvas – Processes, organization, locations, information, suppliers, and management system.
- Deloitte – Organizational design, processes, information and technology, and physical assets
- Bain – Structure, accountabilities, governance, ways of working, and capabilities – people, processes, technology
- Strategy& – People and organization, processes, governance interactions, culture, measures, and motivators, tools and technology
- MIT CISR – A matrix that focuses on an organization’s degree of business process integration versus degree of business process standardization
So, if you are creating an operating model for your organization, consider the frameworks and templates that exist, but if they do not meet your needs, customize one or create your own. Consider that people, processes, technology, and assets or locations reliably show up in some form on most operating models. Most importantly, help your organization achieve its goals behind wanting to create an operating model in the first place.
How do business models and operating models relate?
The Operating Model Canvas book gives a straight-forward answer to this that makes sense conceptually: the operating model covers the left side of the Business Model Canvas4, specifically the building blocks of key activities, key resources, and key partners.
P.S. More on business models and business architecture here in Post No. 80.
Where does the business architecture come in?
Let’s go back to our strategy execution perspective to get some context. (See Posts No. 3, No. 50, No. 71 and No. 81 for more on how business architecture bridges strategy and execution.)
Very simply stated…
- An organization’s business model “describes the rationale of how [it] creates, delivers and captures value.”5
- An organization’s business architecture defines what it does at a high-level (through ten specific business perspectives)6 to deliver its value proposition(s). Business architecture is also used to translate strategies and any changes to the organization’s business model into action by pinpointing where changes are necessary to value streams, capabilities, and other business perspectives, and following them through to the operating model.
- An organization’s operating model defines how a typically more detailed set of elements combine to successfully deliver its value proposition(s). An organization’s operating model is framed by the scope of its business architecture and any changes to the operating model resulting from organizational strategies or business model changes should be translated through the business architecture.
So, business architecture is a very important middleman. It’s not just a bridge between strategy and execution, but a bridge between an organization’s business model and its operating model as well.
Here’s a snippet from BIZBOK® Guide Part 1 that provides some additional insights.
“Business architecture is typically used alongside other business and operating models to enable businesses to drive investments based on a shared view of the business. Too often, organizations establish priorities and investments on a fragmented business perspective based on the needs of individual business unit siloes…the operating model is process, people, and technology focused. While useful for improving efficiencies and costs as well as implementing detailed changes to the business and IT environments, the operating model lacks the value-driven, capability-based, ecosystem-wide perspective needed to deploy actionable strategies, ensure consistent policy compliance, and optimize initiative investments.”
That all makes sense, but how exactly do I use business architecture and operating models together then?
It’s not you. In practice, this is where it gets confusing. It makes sense to read it in black and white, but then in real life your organization has a business architecture knowledgebase and maybe an operating model view(s). It’s not clear exactly how they fit together and there seem to be some overlaps, so what do we do with these two things exactly?
We’re going to take a little sidestep here to remind ourselves about the essence of business architecture because this context might help you to better make sense of what is going on in your organization in order to reconcile things and move forward.
Okay, what’s the sidestep?
Let’s talk about content versus blueprints. In business architecture, a piece of content can be captured for any domain. For example, within the capability domain we can capture a specific capability (content) named Customer Information Management.
We can capture content for all ten of the business architecture domains in a (hopefully automated) knowledgebase, including capabilities, value streams, organization, information, stakeholders, products, policies, strategies, metrics, and initiatives. We can use those pieces of content on an infinite variety of blueprints or views. And, since the information comes from the business architecture knowledgebase, the pieces are unique and reusable. As a result, we create a common understanding of words and concepts. This is the power of business architecture.
On the other hand, if we just create blueprints, pictures or slides without using the knowledgebase content, we could feasibly call a capability Customer Information Management in one place and Client Data Management or whatever we wanted in another place. We lose our common language and ability to reuse.
Taking it one step further, business architecture can be cross-mapped to the domains of other disciplines. Here are some key related disciplines and their unique domain(s) which is cross-mapped to capabilities, value streams, and other business architecture perspectives:
- Business Process – Processes/process activities
- Organizational Effectiveness – Roles and potentially other domains
- IT Architecture – Applications and software services
- Business Analysis – Requirements
- Customer Experience Design – Customer journey/journey stages and touchpoints
You might be thinking back to your science days about now and remembering mixtures (e.g., a salad) and compounds (e.g., salt). A blueprint is just a mixture of pieces of reusable content from the business architecture knowledgebase.
Just for fun, let’s illustrate the concept with some food. Here we have some vegetables (reusable content) and they can be used for an infinite variety of meals (like blueprints). However, we always call a tomato a “tomato,” whether it is used in a salad, on a sandwich, or on a pizza.
In business architecture, it is the same. Here we see a business architecture knowledgebase that has content for all ten business architecture domains and content for the unique domains from other disciplines as well. (There would be relationships between the content as well.) These reusable, agreed upon pieces of business content can be pulled onto any blueprint. For example, our process of Make Payment (which is actually stewarded by the process team) can be used on a Value Stream/Process Cross-Mapping, the Operating Model Canvas, or a Service Blueprint. But, it’s the same unique piece. Remember the tomato.
So why does all this matter? The topic of business architecture versus operating models can be quite confusing because we are often thinking and talking salads, not tomatoes. People in our organizations sometimes ask us for a salad, an operating model, instead of just telling us that they are hungry, or in other words, what their business goals are. In addition, when we just draw pictures without capturing reusable content in a knowledgebase, we can end up with redundant and slightly different content in many different places and lose our ability to bring people together around a common language and vision, that best serves the customer and creates the most efficient organization.
Put it all together. Where do we go from here?
If you have been asked to create an operating model (or target operating model) for your organization or if you think your organization needs one, start with why. Don’t just select a template and start creating a picture. First, define what is intended to be achieved with this activity.
From there, decide if you actually need a cohesive operating model blueprint or not. Here’s a major takeaway: in many cases, you may not actually need an operating model view, but instead simply to capture the relevant set of content in your knowledgebase (e.g., the processes and systems for a certain scope) and use it any number of ways from there.
If it does make sense to create a cohesive operating model view, then:
- Select, customize, and/or create your operating model template with the components needed to achieve your goals.
- Where available, use actual content from your knowledgebase and make sure the names on the pictures match the names in the knowledgebase.* This applies to business architecture domains and any other domains.
* Of course, figuring out how things relate is not always entirely straightforward. For example, here’s how the Operating Model Canvas components would map to the BIZBOK® Guide business architecture perspectives, roughly:
- Processes on the canvas would relate to processes in the business architecture knowledgebase (stewarded by the process team)
- Organization on the canvas would relate to business units in the knowledgebase (or perhaps more detailed content stewarded by the organizational effectiveness team)
- Locations would not have an exact relationship in the knowledgebase as defined per the BIZBOK® Guide now, but location and asset content should be captured and stewarded by another team(s)
- Information would relate to the information concepts in the knowledgebase, at least at a high level, which can of course connect to more detailed data perspectives
- Suppliers on the canvas would relate to one or more business architecture stakeholders
- Management system would not directly relate other than possibly to some policies in the knowledgebase
Finally, if your organization is looking to translate its strategies or business model changes into action, don’t jump right from strategy into the execution with the operating model – always translate changes through the business architecture first for the enterprise perspective.
While there is not necessarily one easy answer or solution, as a business architect, the best thing you can do is to ask why and then use your knowledge, talents, and influence and to help you organization leverage the best possible approaches to achieve its goals. Happy modeling!
More Good Stuff...
Section 3.12 of the BIZBOK® Guide (Business Architecture Guild® membership required): This BIZBOK® Guide section describes the alignment of business architecture and operating models. (Section available from BIZBOK® Guide version 10.0 and onwards.) Make sure to check out the Guild white paper on Aligning Operating Models with Strategy Using Business Architecture, which describes the alignment and provides a useful overview of different operating models as well.
Operating Model Canvas (book Andrew Campbell, Mikel Gutierrez and Mark Lancelott): A highly recommended read on operating models.
Business Architecture and the Strategy Journey, Part 2: A Fireside Chat with Julie Choo (Biz Arch Mastery): Listen to Julie Choo, an expert on the topic, describe what an operating model is and what it should include during this Fireside chat. (Start listening at 07:17.)
The Strategy Journey (book by Julie Choo and Dr. Graham Christison): A must-read for every business architecture practitioner. This book provides the bigger picture strategy journey context for both business architecture and operating models.
What are the Components of a Target Operating Model (Quora): A useful compilation just to see a few different examples of operating models and their components in one place.
Operating Models: The Theory and Practice (Sergio Caredda): Another useful compilation.
Stunning Buildings Made From Raw, Imperfect Materials (TED Talk): Speaking of particles and architecture, here’s a fascinating TED Talk by Debora Mesa Molina on how she and her team reimagined the limits of architecture to be able to use imperfect materials that others did not want. Now this is ingenuity.
The Science of Macaroni Salad: What’s in a Mixture? (TEDEd): Just for fun, you can geek out for 4 minutes on mixtures.
- 1. See the Business Architecture Guild® white paper on “Aligning Operating Models with Strategy Using Business Architecture,” 2019. The Guild cites the definition of operating model to Marne de Vries, Alta van der Merwe, Paula Kotzé, and Aurona Gerber, “A Method for Identifying Process Reuse Opportunities to Enhance the Operating Model”, Proceedings of the 2011 IEEE IEEM, https://ieeexplore.ieee.org/document/6118067.
- 2. See Operating Model Canvas book by Andrew Campbell, Mikel Gutierrez, and Mark Lancelott, 2017.
- 3. From the Business Architecture and the Strategy Journey, Part 2: A Fireside Chat with Julie Choo, January 2021. Start listening at 07:17.
- 4. See the book Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers by Alexander Osterwalder and Yves Pigneur, 2010.
- 5. Definition of a business model from the Business Model Generation book by Osterwalder and Pigneur, 2010.
- 6. According to the Federation of Enterprise Architecture Professional Organizations (FEAPO), “Business Architecture represents holistic, multidimensional business views of: capabilities, end-to-end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders.”