What is Enterprise Architecture ?

The term ‘Enterprise Architecture’ confuses people.  What does an ‘Enterprise Architect’ do ??

I was challenged recently to explain the difference between IT architecture and Enterprise Architecture.  My immediate answer was that Enterprise Architecture takes a broader view than IT but that answer was difficult to defend in a discussion with an IT architect that delivered architecture across a broad scope.

There would seem to be a common misapprehension that an Enterprise Architect is a business, application or technology architect that has a broad scope.  My definition of Enterprise Architecture, and Gartner’s, is that an Enterprise Architect defines the way in which an organisation operates, through models and abstractions, and uses those models to facilitate quick and efficient business change.  The models cover the business functions that exist in an enterprise and they’re not just from an IT or process or information perspective, but a holistic view of all three perspectives across the whole enterprise.

The definition of the way in which an organisation operates is often called an  ‘Operating Model’ so an activity for an “Enterprise Architect” is the documentation of operating models.

When Enterprise Architects have this view of an enterprise and the models to depict it then they can use them to support the refinement of strategy.  Many executives understand their part of the enterprise well and can manage it but don’t necessarily have the “helicopter view” necessary to make change because they don’t always understand how their function affects the rest of the enterprise.  Enterprise Architects are there to use their models to make sure that the impact of change is understood and to help executives refine their strategy.

Finally, I should answer the question of whether you need an Enterprise Architect.  If there is no change in your enterprise then the answer is ‘No’, you don’t.  Of course, the converse is true too – if you want your business to change quickly then you need more Enterprise Architects.  Now show me a enterprise that doesn’t want to change …..

Relating IT and Enterprise Architecture

IT Architects have a hard time.  It’s commonly perceived that the IT department is slow to deliver the whole solution, can’t keep up with the business and is too expensive.  In any solution discussion, there always seem to be a lot of IT architects, each espousing a different technology as the ‘silver bullet’ and often disagreeing with each other to the point of religious fervour.  Passionate yes, and misguided – maybe.

Those IT department traits, I believe, are symptoms of the stage at which IT Architects are included in any business discussion, but I’m not advocating bringing them in earlier either !  In the recent conversations about whether CIOs should be given a seat on the board, my position was that they should and deservedly so.  What I got wrong was what would happen next: CIOs  briefed their IT architects on the overall business strategy and the IT architects bullishly defined what was needed to deliver the strategy.  However, alongside the CIO on the board, were the other directors that ran operational departments and they needed to define their departmental strategy.  What happened next should have been predicted: when those operational directors went to IT to ask for support in developing their ideas, they were told that IT already had the answers.  When both solutions are analysed independently, IT had ignored business critical issues in developing their solutions and the business hadn’t (had the chance) to address IT concerns.  So what I got wrong in my support for CIOs joining the board, was that IT now viewed themselves as being the way to deliver strategy, rather than a supporting actor.

I have witnessed discussions in which an IT architect sets out how the business needs to change to accomodate a new peice of IT that’s the silver bullet to delivering the business strategy.  Those meetings never go well but there had clearly been hours of expensive IT architecture work put into the definition, so much so that the operational directors often wondered why those architects weren’t dealing with customer issues.  All of that IT architecture ignored one fundamental fact: IT don’t run the business and often don’t have the best view of how to move the business forward.  It’s also true that, all too often, IT architects want new technology, rather than improving what already exists or, heaven forbit, admitting that their last bright idea didn’t deliver the business benefits that were promised.

So what are IT architects responsible for ?  My list would be:

  • defining the the lifecycle for each of the applications and providing that information into as an ‘influence’; 
  • developing ideas on how to reduce the TCO for IT platforms;
  • defining IT principles, by decomposing the business vision;
  • setting IT standards;
  • governing the IT aspects of solution architectures; and
  • delivering IT solutions, hand-in-glove with the appropriate business unit.

However, in all other discussions on how strategy can be implemented, IT architecture should to defer to the business units and explain the impact of IT principals to the business units.  For example, moving to a cloud-based implementation model might form part of a principal. However, the move to cloud has an implication on how IT is paid for (i.e. OPEX vs CAPEX) so that too should be fed into the enterprise motivation model as an influence.

That approach ensures that IT Architects speak on the subject on which they are most knowledgeable – IT.  That IT Architecture is a specific activity in the TOGAF model for a reason – it takes knowledge of the existing IT landscape and knowledge of new technologies.  There are many IT Architects that understand the application landscape across the whole enterprise and they’re often called ‘Enterprise Architects’ which is a confusing term.  I believe that the Enterprise Architects perform their activity, in TOGAF terms, in the Vision and Opportunities and Solutions activities and then lead on through the rest of the ADM activities.

So when should IT architects ben involved ?  In my view, the ‘proper’ sequence of events, after strategy has been developed, is for the Enterprise Architects (EAs) to help the business executives develop the strategy to the next level of detail and update roadmaps documentation as appropriate.  The EAs develop a new ‘to-be’ operating model and communicate with the various architect specialisms on how that new operating model can be realised and then gain agreement on the order in which change should be implemented: essentially ‘Agile architecture’ or my definition of it anyway.  If an incremental enhancement requires a complete refit of IT platforms then the discussion becomes one of cost/benefit analysis, not one of who is best placed to refine strategy.

Business motivation

This post is part of the ‘Architecture Models’ series.

What makes an organisation do anything ?  What causes it to change ?  If the internal and external forces on an organisation were clearer, would it lead to simpler change ?  I’ll try to answer the first two questions in this article and maybe you can answer the third in the comments section below.  This article is about documenting the enterprise’s reasons for changing; their motivations.  Unsurpringly, there’s a model that can be used to document these motivations: the ‘business motivation model‘ from the Object Management Group.  I use this model frequently because it helps me to define wby an activity is happening, that leads me to understand the Critical Success Factors and so it’s simpler to make the activity a success.  I use the word ‘activity’ advisedly because this model is nicely particular about its definitions for words.  It correctly defines vision/mission, goals/strategy, objectives/tactics and those are terms that I find executives misuse and then sow confusion by misusing them in communications.  Using this model, in your head if not fully, helps to structure thoughts about the reasons for change and stops that confusion.

I encourage you you read the official OMG definition but I’ll introduce the fundamentals in my own words here. The basis of the model is the following structure:


Business Motivation Model Overview (v1.3)

Enterprises define the ‘End’ that they want to reach, which is called their ‘Vision’, considering assessments of external influences as part of the process.  The ‘Vision’ is decomposed into ‘Desired Results’ and those are delivered by ‘Means’.  ‘Means’ can either be transient, such as a strategy to be executed, or permanent, such as a new business rule.  The enterprise is supported by a common vocabulary (aka a glossary) and enacted by a parts of an operating model.  It’s quite simple really: ‘Means’ deliver ‘Ends’.

There’s no definition of how often ‘Ends’ should be updated but it’s quite clear that it’s necessary.  If an organisation doesn’t have a Vision then it doesn’t need Means and if the Vision doesn’t change then it isn’t taking account of influences.  As an aside, I find it odd that not every company has a clear vision.  Published or not, it’s such a fundamental building block of Enterprise Architecture, maybe a pre-requisite, that I’ve declined work in organisations that couldn’t articulate their vision.

An approach that I’ve found to work is to use the model iteratively: define the motivations at the highest level of the organisation, and the Means to deliver them, and then decompose the Goals into sub-goals that are distributed across the organisation and then define the Means to deliver those sub-goals.  The Enterprise Architect holds the relationship breakdown between the different goals and can show how a change in one affects the others.  There aren’t many organisations that define strategy and plans with this much rigour, possibly because the executives haven’t been taught the tools necessary to structure their thinking, but from an Enterprise Architecture perspective, it’s both vital and enlightening.  Just imagine being able to explain to anybody in the organisation, those that wanted to know anyway, how their activity was part of a bigger plan, exactly how they fitted into the organisation and who changes their work impacted.  It’s a powerful tool, when used correctly and when the model is maintained over time.

The business model canvas

This post is part of the ‘Architecture Models’ series.

The business model canvas is a very high-level view of en enterprise.  It lists what the enterprise does, its interactions, resources and partners / suppliers but no more detail than that.  It’s a sort of X-ray of the organisation that shows all of the working parts but not how they work together.  You might think that it’s worthless but, if you have some knowledge of the type of business, then it’s a way of documenting an overview that’s easily consumable by non-architects.


The lists of what the business does are just lists, often bullet-points.  There’s no correct or wrong way to write them just so long as they make sense to whoever reads the canvas.  The canvas has been used by many years (it was documented in 2010 by Osterwalder, Pigneur et al.) and so has become a standard template.  As such, the template headings provide a prompt of what needs to be documented.  There’s an strong overlap with parts of the Zachman framework but I prefer the business model canvas because it’s more consumable by non-architects.

If you were starting a new business then this diagram is a useful overview of your proposed enterprise.  If you’re starting to understand an existing enterprise or a department in an enterprise then the business model canvas gives you a place to write down the things that you find.  What it doesn’t do is explain how the different parts fit together; that takes an Operating Model.

What is an enterprise ?

This series is about the Enterprise Architecture models that I use day-to-day.  It takes a top-down look at the different models that describe business, application and techology architecture and my commentary on where and how I’ve found them useful.

This post is the starting point for the series so, to get started, I need to define an ‘enterprise’.  For the purposes of this series, I’m going to define an Enterprise as:

  • a balance sheet

delivered by

for a company that can be described by a

that operates as one or more

  • business verticals

and which is measured day-to-day by a

  • balanced scorecard

and wants to change according to set of

It is harsh to characterise an enterprise as being just a balance sheet.  However, in a capitalist economy, when viewed from the outside, companies are characterised by their balance sheet.  From a social perspective, they might provide employment for tens or tens of thousands but they exist to make money, even if it’s just sufficient money to pay those wages.

I’ll admit that architecturally, this definition is ‘clean’: starting with, for example, an ‘operating model’ makes the flow of words more difficult.

Series introduction

There are many different Enterprise Architecture models and it’s hard to know which ones to use in which situation.  This series (Architecture Models) that shows the Enterprise Architecture models that I use day-to-day and I will describe why I’ve selected a particular model and explain how I found it useful.

Many of the models inter-relate so I’ll explain how they link together and then how they can be used to decompose an architecture from the most generic to the specifics of your enterprise.  I’m not intending to create a new model but we shall see whether this series ends up creating a meta-model of models.

The series will start with business architecture and then move into technology and information architecture, as you’d expect from TOGAF.


What’s in an Operating Model ?

This post is part of the ‘Architecture Models’ series.

This started out as a brief note but I’ve come back to it time and time again because it’s a complicated topic.  Most of the definitions that I saw of an ‘operating model’ were an organogram, an organisation structure showing who works for who.  Many of the people that I interacted with agreed that there didn’t need to be any more content in an operating model and so ‘HR’ should own and create it.  In fact, the IT platform that stores names and managerial relationships could probably display it for me if I wanted to see it.  OK, I exaggerate, but only a little.

It’s a question that is still debated in blogs across the internet.  The WordPress blog at Ashridge On Operating Models suggests that an Operating Model can be described by defining the enterprise’s ‘POLISM’ (processes, organization, location, information, suppliers and management system).

Whilst I agree that those are fundamental parts of an operating model, my view is that there’s more to an Operating Model than just ‘POLISM’.  That seems too constrained and fundamentals of how the business works would need to be documented elsewhere.  If I include those other fundamentals then I think that there are three pillars for an Operating Model:

  • the Financial Model of an organisation
  • the future of the organisation, as defined by its strategies and its saleable products
  • the Operations of the organisation that shows how the enterprise functions

and that these pillars sit on two foundational building blocks:

  • the principles for how the enterprise approaches its vision
  • a glossary


As an aside, Enterprise Architecture would seem to be the next level of detail that shows how each of the pillars interacts; a little like 3D chess but with more dimensions !