Enterprise Architecture and Target Operating Models

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

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.

Enterprise Architecture as the Office of the CEO

We are used to the idea of a Programme/Project Management Office (PMO) but often organisations fail to understand (or perhaps deliberately misunderstand) what the Enterprise Architecture function does. I propose that the Enterprise Architecture function is, in effect, an Office of the CEO, or an Office of the CEO and Strategic Change Management.

The book ‘Enterprise Architect as Strategy’ (http://www.architectureasstrategy.com/book/eas/ ) gives us the right way of thinking and talking about what enterprise architecture is for – creating a foundation for the execution of the Business Strategy.

This book is an essential read for senior executives, business leaders and enterprise architects.

Many people within an organisation will understand the big picture view of the business strategy, such as the CEO of course, but perhaps only at a shallow level of detail.

Would the C-level executives understand all the potential nuances and wrinkles that come with that business strategy? Perhaps not unless they were a ‘details’ person.

What does the CEO do? They will spend time in evaluating ideas, formulating the mission and vision of their orgnaisation, innovating the business model to ensure the company remains competive in their market, looks for future opportunities for expansion and carving out a niche market.

It is the Enterprise Architect who has the job of maintaining the big picture on the behalf of the CEO, in sufficient detail to ensure that it becomes a knowledge base to support the executive’s decision making and help them to realise the business strategy and govern the implementation of that strategy.

In this way the Enterprise Architecture function is effectively the Office of the CEO,  providing strategic support to the CEO and the other C-level executives. It’s also worth stating here that effective companies focus on enterprise architecture and don’t jump straight into IT architecture. Enterprise Architecture is not the same discipline as IT Architecture.

We can look at the the Enterprise Architecture function in terms of Deming’s Plan-Act-Do-Check process improvement process:

PLAN

The CEO and other C-level executives will stablish the mission, vision, goals, objectives, principles and metrics to identify the main outcomes of the business strategy.

The Enterprise Architect will help executives, business leaders and strategic planners to develop the business model, operating model, and other enterprise architecture models supporting business model innovation

DO

The CEO and other C-level executives will evolve and innovate the Business Model.

The Enterprise Architect will take the business strategy and business model and support the development of the target operating model,  communicate the business strategy, model the target and interim enterprise architecture models, plan an EA roadmap of strategic initiatives, identify and define the required capabilities, define the mandates for the investment programmes and key projects, define standards and process improvements. They will usually define the IT strategy to ensure that it fits with the business strategy rather than being developed in isolation (as unfortunately often happens).

CHECK

The Enterprise Architect will perform EA governance, compliance and design assurance against those programes & projects implementing the strategic changes and new capabilities. They will perform gap analysis and impact analysis, measuring the performance and compare the results against the expected outcomes.

ACT

All the while the Enterprise Architect will report to the CEO and act as their trusted advisor. They will analyze the gaps, risks, costs, issues, assumptions and dynamics to determine their cause and determine where to apply further strategic changes in the next iteration of the cycle and improve the overall maturity level of the enterprise.

The mission of Enterprise Architecture is to improve the implementation and excecution of the business strategy, ensuring that the enterprise will survive, continue to develop and remain profitable in the future.

An interesting example to look at is the US Department of Health and Human Services which has established an Office of Enterprise Architecture as part of the Office of the CIO.  http://www.hhs.gov/ocio/ea/index.html

Activities of the Office of Enterprise Architecture

As the the book ‘Enterprise Architect as Strategy’ says – ‘When it comes to executing your Business Strategy your Enterprise Architecture may matter more than your strategy itself… ’

Enterprise Architecture Strategies

I recommend you read Chris Curran’s excellent blog entry on 16 Enterprise Architecture Strategies Learned The Hard Way

http://tinyurl.com/32hfj8s

I’ve included his list below with my views and comments following that.

1. An exhaustive enterprise level blueprint is virtually impossible to build – it’s too big and no one will buy-in

2. The best strategy blends a direction-setting enterprise blueprint and business unit and domain blueprints

3. Centralized accountability for the EA function is a predictor of success

4. A centralized team of architects is critical in driving EA standards and approaches

5. Architects must be assigned to projects as core team members (60%+ of total EA FTEs) rather than “advisors”

6. EA should be measured in 2 ways: business capabilities delivered and costs of core services

7. Measure EA as an asset – what does it cost to provide the service and what return does the business get from the business capabilities delivered?

8. Architecture leadership requires strong management, business operations and technology skills, most likely in 3 different types of people; don’t expect your chief architect to run the EA function

9. Methods and governance must be integrated into existing work processes (eg, project approvals, SDLC) rather than a new overlay

10. Enterprise Architecture is not always the best name for communicating; maybe Strategy & Planning or Enterprise Transformation is better

11. The best large companies have “business architecture” teams reporting to the business (or dual reporting to business and IT)

12. Leading companies have reference architectures in place for 90% of the technical domains

13. Your senior enterprise architects must have the right cultural skills and awareness to integrate well with upstream business partners and downstream technical users

14. High performance groups maintain consistent, formalized EA involvement in the SDLC to translate blueprints into sufficiently detailed starting architectures for each project as well as accurate cost and resource estimates

15. Mature organizations target 40% EA resource time for strategic planning and 60% on SDLC tasks, and typically err on spending more time on SDLC tasks

16. Strong credibility and trust amongst Business and IT partners is a predictor of EA success. Credibility has typically been gained via joint strategic planning efforts, one project at a time.

My Views

These are my comments on Chris’s list.

1. The enterprise architecture blueprint (i.e. the enterprise architecture content) needs to be developed in iterations, and treated as a living document/model that will never be complete. Aim for each iteration to provide value in it’s own right, to both the business and the rest of the organisation.

2. I agree that there needs to be different aspects to the business and IS strategies that address different segments of the enterprise. They shouldn’t conflict with each other though. Enterprise Architecture is all about aligning the IS strategy to the Business strategy and target business [operating] model.

3. The EA function needs an executive sponsor such as the COO that is accountable for the success of EA. I’m increasingly of the opinion that the EA function should not report to a CIO that is only focused on IT. This sends out the wrong message to the organisation as a whole. The COO should be focused on the success of the business and how it operates as a whole and not just the success of IT. In some cases success for the business may mean less IT as business capabilities in the cloud are used instead of local IT capabilities.

I’ve seen some suggestions that a new C-level post is needed to manage Strategic Change and Enterprise Architecture , that of a Chief Strategic Officer (CSO). This new role makes sense if the COO is only responsible for service delivery operations & support activities.

4. I agree – A centralized team of enterprise architects is critical in driving EA standards and approaches. There is also room for federated EA teams in large global organisations where centralised control is not feasible or even possible with local regional and country based regulatory environments.

5. Its the Solution Architects that should be assigned to projects as core team members. Enterprise Architects will be involved from a governance, compliance and design assurance perspective in quality gates/steering group meetings, and as an advisor. There are usually not that many enterprise architects and too many projects for them to be core members of every project.

Being a ‘Core’ member of a project team implies that they are managed by the project manager, whereas the relationship should be the other way around – the project manager needs to heed the advise and direction coming from the enterprise architects who have a governance sign off at the end of each project phase in project steering group meetings.

6. I agree that EA should be measured in terms of business capabilities delivered, but also in terms of value delivered. Cost of services is just one of many ways of measuring value. The value of EA is indirect though and value is only realised by solutions that deliver the business capabilities in the future many months away. To measure EA properly though means that there need to be a good record of decisions that are made by EA and the eventual outcome of these decisions in the future. This doesn’t happen much in my experience at the moment.

7. EA is a core business function in the same way that Finance Management or Sales & Marketing are core business functions. We should treat the Enterprise Architecture content as a knowledge management asset. The value is the return on knowledge (ROK) that is used in supporting decision making.

8. The EA function does need strong leadership. Doesn’t always get it though. In all the EA teams I have encountered, the Chief Enterprise Architect does also run the EA function. Within a larger EA team, there are often specific managers for the Business Architecture, Information Architecture, Application Architecture, Infrastructure Architecture aspects.

9. I partially agree. Aspects of EA Governance, Compliance and Design Assurance processes should be integrated into existing Strategic Planning, Portfolio Management, Programme and Project Management, Software Development and Service Delivery processes, but the Enterprise Architecture Development process (i.e. TOGAF ADM) will be a new overlay.

10. The name ‘Enterprise Architecture’ is all too easily confused with ‘Solution Architecture’, ‘IT Architecture’ which is a source of confusion so there are often suggestions for new names for ‘real’ Enterprise Architecture. I’ve not yet found a new name I like though it is becoming common to include Enterprise Architecture within a Strategic Change Management team.

11. Business Architecture is just one of the domains of Enterprise Architecture. All of Enterprise Architecture should be reporting to the business (i.e. the COO) rather than to IT (i.e. the CIO).

12. A Reference Architecture is a key component of the target Enterprise Architecture as a whole. In some cases these are provided by industry reference architectures.

13. I agree in general although I’d say that Enterprise Architects probably need to be much more business focused than IT focused. IT is often seen as part of the ‘problem’ and EA needs to be in alignment with the business.

14. This is more the responsibility of the Solution Architects who need to liaise with the Enterprise Architects to translate the Enterprise Building blocks into Solution Building Blocks. The Solution Architects should ideally form part of a ‘virtual’ EA team.

15. The 40% EA resource time on strategic planning and 60% on SDLC tasks mainly reflects the current overemphasis on IT Architecture being done by Enterprise Architects. I think the ideal percentages should be the other way around i.e. 60% strategic planning and 40% project related work.

16. I agree that the credibility of the Enterprise Architects and their trust relationships is critical. Building that credibility and trust starts with working closely with the business on strategic change programmes

Before all else, be armed – with a budget

Being an Enterprise Architect is a role I enjoy but I recognise the scenario described by Rik Laurens at http://www.capgemini.com/technology-blog/2010/01/enterprise_architecture_the_on.php

I think the main underlying issue is that the Enterprise Architect doesn’t, in any organisation I have engaged with, actually ever command a budget.

With money comes the power to spend it and influence others who will come to rely on that money being spent in their direction on their project etc.

Without the money weapon, an enterprise architect must rely on their powers of influence and persuasion with the C-level executives, and their governance sign off power at end of project phases and giving approval at project board meetings.

As the enterprise architecture discipline has not yet reached the tipping point where the majority of organisations realise its key importance and give respect to the Enterprise Architect, this influence and persuasion is still often overruled by JFDI thinking when the going gets tough.

Enterprise Architects do always have to continually demonstrate value and ROI, even if it is indirectly achieved by the delivery projects months away when they implement what you have defined in the EA roadmap.

However I think that Enterprise Architects do need to closely align themselves with the C-level decision makers (CIO, Business management etc.) in an organisation rather than with the project teams to achieve the necessary power and influence.

I know this sounds a bit Machiavellian, but if you are aligned too much with delivery then you’ll be seen as a [project level] solution architect and not as an [strategic] enterprise architect which is where you want to be in the first place.

It’s a fine line to walk.

Before all else, be armed [with a budget].

EA supporting rapid corporate decision making

What does agile mean?

Mostly the interpretation is that it means doing the work in an iterative and incremental fashion, so that each new iteration can be flexible enough to rapidly react to constant change.

This is a good approach that should be taken regardless of whether one is doing enterprise architecture or solution development.

Other interpretations is that agile means development without architecture or analysis, where the design only meets the current set of known requirements and the solution being developed must be refactored when the requirements change.

This is good for development but not so good for long term strategic planning of enterprise architecture.

Terry Blevins has made some important insights in at the Briefings Direct blog

Enterprise Architecture exists to support the decisions that are made every day in an organisation.
Enterprise Architecture helps to really understand the decisions that need to be made and to ensure that the decisions are made based on the facts.
Each iteration of the enterprise architecture processes needs to be aligned to the speed at which an organisation needs to make decisions.

In this way enterprise architecture be made agile. At the enterprise level, it’s not about agile development but agile decision making.