6 October 2016
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?
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)
Why do we need an Operating Model?
- Business Model (BMC)
- Business Motivation Model (BMM)
- Wardley Model
- Strategic Map/Balanced Score Card (SMBSC)
- Business Capability Models
– 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
– 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
– the management processes for planning and managing the work
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
Strategic Architecture Domain
Business Model (BMC)
Business Motivation Model (BMM)
Strategy Map / Balanced Score Card Model
Value Chain Model
Customer (Outside In) Domain
Business Scenario Model
Customer Journey Model
Business Services (value proposition) Model
Business Events Model
Business Service Flow Model
Business Capability Model
Capability Dependency Model
Component Business Model
Governance and Compliance Domain
Business Rules Model
Organisation Structure Model
Business Locations Model
Business Roles Model
Business Process Domain
Business Process Flow (Value Streams) Model
Knowledge/ Information/ Data Domain
Business Information Flow Model
Business Information Object Model
Logical Data Object Model
Physical Message Model
Physical Data Storage Model
Application Landscape Model
Application Integration Model
EA Roadmap Model
Project Roadmap Model
Programmes and Project Portfolio Model
23 March 2013
Tom Graves recently participated in an Open Group TweetJam on Business Architecture. You can read about the results of this at http://weblog.tetradian.com/2013/03/20/opengroup-on-bizarch/
Unfortunately I didn’t hear about this in time to participate but I thought I’d record my own thoughts here.
The questions were:
- How do you define Business Architecture?
- What is the role of the business architect? What real world business problems does Business Architecture solve?
- How is the role of the business architect changing? What are the drivers of this change?
- How does Business Architecture differ from Enterprise Architecture?
- How can business architects and enterprise architects work together?
- What’s in store for Business Architecture in the future?
How do you define Business Architecture?
Business Architecture is one of the primary domains within Enterprise Architecture. It deals with the architecture of the business, ideally from a business perspective and is expressed in business terminology.
It should not really be considered a separate discipline from Enterprise Architecture but often is by those who persist in misunderstanding that Enterprise Architecture is only about IT and not about the whole of the enterprise.
Business Architecture deals with the structure and design of how an enterprise operates, makes money or delivers value, how it organises itself in order to provide products and business services to its customers, clients and consumers. It should be expressed independently of how the business architecture will be mapped to the underlying application architecture and infrastructure architecture, but is more connected to the business/contextual view of the information/data architecture and will include the organisation architecture.
Business Architecture is centred on the business and the business strategy, not on IT or on the IT Strategy and should not be considered just a source of requirements for IT projects (which is the impression that TOGAF gives of Business Architecture).
In general Business Architecture includes the following deliverables:
What is the role of the business architect?
As a specialised type of Enterprise Architect, they are in a leadership role, close to business management working for the CxOs to evaluate and elaborate possible future strategic scenarios.
They have a responsibility to guide, recommend and oversee the realisation of the business strategies identified by the CxOs, but they don’t control the business strategy or make the actual investment and strategic change decisions.
What real world business problems does Business Architecture solve?
As a type of Enterprise Architect, a Business Architect deals with strategic change, business transformation activities concerning topics such as:
- Ecommerce changes
- Cost reduction
- Process improvement and efficiency
- New organisation design
- Mergers & Acquisitions
- Reuse of shared services
- New markets
- Regulatory and legal changes
One should not forget that, by definition, an Enterprise Architecture model covers everything about the enterprise including the environment and market which it operates in, its Business Strategies, its Business Architecture as well as the rest of the Enterprise Architect domains.
How is the role of the business architect changing? What are the drivers of this change?
The role of a Business Architect is becoming much more distinct than it has been. many organisations are maturing their enterprise architecture functions that were previously just centred on IT architecture and are now specifically introducing a Business Architect role.
How the Business Architect role differs from other roles such as a Business Analyst, Business Change manager, Business Transformation Manager etc. is still playing out. I discussed this to some extent in a previous blog post – The difference between a Business Architect and a Business Analyst.
Another current difference is that a Business Architect is often closely associated with the Business units (and perhaps reports to a business line manager of sorts) and therefore is seen as being on the ‘Demand’ side of a business, whereas the rest of the Enterprise Architects (including IT Architects) are often lumped into the IT department and therefore are seen as being on the ‘Supply’ side. In theory, the Enterprise Architects, including Business Architects, should only ever be on the ‘Demand’side and not seen as part of IT. They should report to the CxOs, ideally seen as part of a CEO Office.
How does Business Architecture differ from Enterprise Architecture?
A Business Architect is a type of (a ‘real’) Enterprise Architect. Business Architecture is a sub domain of Enterprise Architecture.
How can business architects and enterprise architects work together?
Of course they can. The distinction in the question is artificial anyway, since a Business Architect is just a type of Enterprise Architect that specialises in the Business Architecture domain.
But in reality many organisations do have an unfortunate tendency to make up their own interpretation of what these roles actually are.
What’s in store for Business Architecture in the future?
We will see more and more Business Architecture roles in the future as organisations mature their enterprise architecture strategy and capabilities, and they realise that they need to get to grips with their business model and how it is realised. They will need Business Architects to help them do that.
For most enterprises embarking on large scale strategic planning and business transformation programmes it is all about staying robust, viable and efficient, continuing to deliver good outcomes and value to their customers/consumers/clients in the future. Enterprises should be wanting to stay competitive and efficient and beat the competition.
If the enterprise is to succeed, it must make strategic decisions and investments in change based on a thorough architectural gap analysis/impact analysis that is only possible with business architecture as a key part of their enterprise architecture function.
24 May 2010
Jeanne W. Ross recently proposed the following.
“Let me propose the following hypothesis: Although EA was initially a function within the IT organization, we will soon find IT to be a function within EA. This is actually not a wild theory; it’s a trend.”
– Jeanne W. Ross, Foreword, The SIM Guide to Enterprise Architecture, CRC Press, 2010, p. xli.
This is a great proposal.
Making the IS/IT function part of the Enterprise Architecture (EA) function makes much more sense than having the Enterprise Architecture function as part of IT.
Unfortunately the latter situation is far too common as organisations make the mistake that EA is somehow a more specialised version of Solution Architecture and Technical Architecture.
From the business perspective, the IS and IT functions are often seen as part of the problem and if the Enterprise Architecture (EA) function reports to IS/IT then by association it can also seen as part of the problem.
Since EA is very close to the business by definition (i.e. the ‘Enterprise’) this make life for an Enterprise Architect very difficult. Their natural and main business stakeholders will be wary of sharing their discussions on strategy and business ideas with EA.
The EA function should ideally report to the executive board and be a peer with the business functions.
Often the EA function reports to the CIO. If the CIO is the head of IS and IT functions, then this can be a problem.
Ideally the Chief Enterprise Architect (i.e. the CEA) should be a new ‘C’ level executive position and a peer of the CIO and not report to the CIO.
This would instantly give the Enterprise Architecture function the level of authority and position with the organisation hierarchy that it needs to do its job properly.
See also the discussion on this topics started by Birgitt Hartje