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:

BMMOverview

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.