How often is an established Enterprise Architecture approach used to create a Target Operating Model?
If the answer is not often, then why not?
If the answer is yes all the time, then how should we go about creating one ?
Are traditional consultancy approaches to target operating models good enough?

What is an Operating Model?

The term Operating Model is a fuzzy one. What does it really mean? What is in an Operating Model?
It appears that often some consultants totally go out of their way to avoid mentioning Enterprise Architecture and instead focus solely on the term Operating Model.
This may well be a side effect of the misunderstanding of Enterprise Architecture as only concerned with IT Architecture. Or may be because those consultants want to invent new terminology to make their services sound unique?

Is a Target Operating Model just another name for the Target Enterprise Architecture?
And by Enterprise Architecture of course I don’t mean just the IT Architecture domains, but all the EA domains which now include:
  • Strategy & Motivation
  • Business Architecture
  • Information/Data Architecture
  • Application and Application Service Architecture
  • Technology & Infrastructure Architecture
  • Physical Architecture (I.e. Archimate 3 Physical Elements)
It seems to me that a target operating model is fundamentally just another name for the full target Enterprise Architecture model and in particular primarily represents the mapping between the Strategy and Business Architecture domains and the other EA domains.

Why do we need an Operating Model?

An Operating model at the very least represents the mapping between the strategic views and components, such as :
  • Business Model (BMC)
  • Business Motivation Model (BMM)
  • Wardley Model
  • Strategic Map/Balanced Score Card (SMBSC)
  • Business Capability Models
and the rest of the enterprise architecture models, views and components in the other remaining EA domains.
If we update the strategies then we will need to update how those strategies will be realised.
A strategic change / business transformation programme will be used to realise the new strategic changes and essentially change resulting operating model.
Many refer to a Target Operating Model in a simplistic fashion as consisting of People, Processes and Technology, but there is more to it than that.
According to POLISM, a definition that comes from Ashridge Business School, an operating model covers six component areas:
Processes
– The business processes that needs to be performed
Organisation and people
– The people and roles performing the processes and how they are grouped into organisation units
Locations, buildings and other assets
– The places where the work is done and the technology, infrastructure and physical equipment in those places needed to support the work
Information
– The Information, data and applications needed to support the work
Sourcing and partners
– External entities, people and organisations outside the enterprise also performing the work
Management
– the management processes for planning and managing the work
Missing from this list is an analysis and understanding of Customers, Risks, Assessments, Performance metrics and measures, and other influences.
A secondary question that I always ask myself is why don’t Business Masters (MBA) courses teach executives and management about Enterprise Architecture?
This may indeed be the source of the fuzziness and lack of preciseness of the term Target Operating Model?

Target Enterprise Architecture Model

For me a better approach is to use a complete Target Enterprise Architecture Model as the Target Operating Model.
The Target Enterprise Architecture Model will consist of a number of more specific models (viewpoints) grouped into a number of EA domains.
Each of the EA domains will typically address the needs of different stakeholders and
visualises their concerns. This is a bit like for the POLISM stakeholders above but in better detail.
Each of the specific models listed within an EA Domain below may well evolve and change over time independently. The specific models can be updated when necessary as the enterprise itself evolves and changes in reaction to changing business and customer environments.
There is traceability connection between each specific model, so creating or updating one model will inform and influence other models. The primary traceability connection are see in the diagram below.
As with any target enterprise architecture models, there can be a number of alternative future versions often aligned to different strategic themes,  business scenarios or intermediate transition architectures. There need not be a single view of the future.
The complete set of the following specific models makes up the whole target Enterprise Architecture model, grouped into the following EA Domains:

Strategic Architecture Domain

Business Model (BMC)
Wardley Model
Business Motivation Model (BMM)
Strategy Map / Balanced Score Card Model
Value Chain Model

Influences Domain

Influences model
Stakeholders model

Customer (Outside In) Domain

Business Value Network Model
Business Scenario Model
Customer Journey Model
Business Services  (value proposition) Model
Business Events Model
Business Service Flow Model

Risks Domain

Risks (RAID) Model
Assessment Model
Business Capability Domain
Business Capability Model
Capability Dependency Model
Component Business Model

Governance and Compliance Domain

Business Policy Model
Business Rules Model
Governance Model
Requirements Model

Organisation Domain

Business Context Model
Organisation Structure Model
Business Locations Model
Business Roles Model

Business Process Domain

Business Process Hierarchy Model
Business Process Flow (Value Streams) Model

Knowledge/ Information/ Data Domain

Knowledge Model
Business Information Flow Model
Business Information Object Model
Logical Data Object Model
Physical Message Model
Physical Data Storage Model

Applications Domain

Application Services Model
Application Landscape Model
Application Integration Model

Infrastructure Domain

Infrastructure Services Model
Infrastructure Model
Network Model
Physical Models

Roadmap Domain

Initiatives Model
EA Roadmap Model
Project Roadmap Model
Programmes and Project Portfolio Model
fullsizerender

Summary

In summary we should not be defining target operating models with yesterday’s approaches, but must instead use today’s better Enterprise Architecture techniques and models for defining the next Target Operating Model.
The models identified above are all fully defined and available in an Abacus model. Anyone who wants to follow this approach can contact me for more details.

Increasingly companies wanting to develop an Enterprise Architecture are also looking at a Service Oriented Architecture approach.

Consequentially one of the deliverables that needs to be defined in the Enterprise Architecture Framework is a Service Catalogue.
In fact there are two kinds of Service Catalogue that often get confused in casual conversation, an Application Service Catalogue and an Organisation Service Catalogue (or Business Service Catalogue).

Application Service Catalogue:
This is located in the Application Architecture column of the EA Framework and defines the Application Services (i.e. those Services that are performed by software applications, implemented as web services, and typically invoked in composite applications using a Process Orchestration).
These Application Services form part of a Service Oriented Architecture approach to building composite service based applications.
Generally I identify the Service Oriented Architecture as the main part of the target architecture vision.

Organisational Service Catalogue:
This is located in the Organisation Architecture column and defined those services that are provided by people or organisation units.
Often these are called ‘Business Service Catalogues’.
Organisations typically identify these Organisation Services as a result of decomposing their Functions into Business Units and then considering what those Business Units do.
If the Organisation Services are well defined, regarded as non-core commodity services, then they can often be outsourced.

In summary, Application Services belong to the Service Oriented Architecture and Organisation Services belong to a Service Based Business approach.

Of course a high level composite Service can include both an Organisation Service and a set of Application Services…

%d bloggers like this: