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 !