The Architecture of Purpose

From the title you’d be forgiven for assuming that this is yet another crack at the meaning of life, but no, you’re not in the wrong room and the answer is not going to be “42” or anything nearly as elegant or concise. My level of abstract thinking isn’t quite that refined yet.

Nope, this is a discussion about why the “architecture of business” has to start with the “architecture of purpose” and my favourite topic, why outcome-based business models are better than process-based ones.

Purpose is noble, an admirable characteristic, something we aspire to and want our children to have a sense of. Many of us spent a good part of our early lives searching for one. We pride ourselves on having a clear one and our emotional state of mind is quite positively correlated with how successful we are in achieving ours.

Human idiosyncrasies however are far too unpredictable and prosaic for me; organisations are my fetish. Whilst it may not be true of all humans, organisations usually exist for a reason. Their motivation for being is to pursue an articulated purpose. This “business purpose” is the thing that business strategists set straight in their corporate mission statements and elaborate in their strategic business plans.

A sense of purpose is about having direction; aligning people and deploying resources effectively. Purpose reduces uncertainty, the one thing that all business administrators will most certainly want to control. Uncertainty is bad, wasteful, the cause of failure, missed targets and undesired detours on the path to purpose. Reducing uncertainty clearly foreshadows success.

Uncertainty can be reduced by improving the predictability of outcomes. Predictable outcomes are good; investors don’t place bets on serendipity and the probability of an outcome occurring is not arbitrary. Outcomes succeed actions and in business, the actions that achieve outcomes are intentional. In other words, we have a far greater chance of achieving an outcome if we specifically set out to do so. Which is why strategic planners will always define desired results first and then set the courses of action to achieve them.

As a business architect focused on making strategic plans operational, two questions spring to mind:

• Why then is it that when a strategic plan is translated into an operational plan, we do exactly the opposite and shift all of our focus to modelling processes?
• Why do our process modelling notations converge around activities (courses of action) and have no constructs whatsoever for defining outcomes (desired results)?

We put all of that effort into setting our business objectives in our strategic plans, but our operational plans jump straight into modelling the detailed flow logic coordinating the actions and procedures that people should follow, without even a thought given to modelling the outcomes they should be pursuing. No wonder it’s so hard to track how well we are actually doing. We haven’t built into our models what we are trying to measure! This is exactly where it all goes wrong.

Let’s step back and take a deeper look at the structure of purpose. The concept of purpose has actually been decomposed quite thoughtfully by the OMG Business Motivation Model, which organises the constructs of a business plan into Desired Results, Courses of Action and Directives (by which I think they really meant Governance). We could consider these three constructs as the Pillars of Purpose since they provide a useful scaffold for conceptualising an organisation as a state-of-affairs.

Consider this interpretation of the core BMM constructs:

• Desired Results define Goals (broad statements of direction) and Objectives (specific and measurable end states), which are the target states-of-affairs for the business domain.
• Courses of Action describe Strategies and Tactics that the organisation will pursue to effect transitions to states-of-affairs by way of some value-producing behaviour.
• Governance articulates Policies and Controls that govern the achievement of target states-of-affairs and the execution of state-transitions.

Why would we want to conceptualise an organisation as a state-of-affairs? Well because an outcome is a pattern for a state-of-affairs. We can think an outcome as a “desired state” that can be very precisely described by an identifiable case where a particular set of states exist for properties of things in the domain, at a point in time. In a business process a thing can only exist in one of its possible outcome states.

When we envisage an organisation as a state-of-affairs, we imagine an interconnected collection of things with a particular set of outcome states. What happens next in a business process will be inevitably predictable (although not necessarily desirable) from the current state since we have a finite set of possible outcome states for each thing and each possible state-transition is also known.

An outcome-driven model of business architecture has numerous advantages over process driven models. Here are a few that come to mind:

An outcome-driven model of business architecture has numerous advantages over process driven models. Here are a few that come to mind:

1. Outcomes are measurable, tangible, directly related to objectives and can be easily associated with performance targets;
2. Outcomes precisely reflect the purpose of the business and what it is trying to achieve;
3. Outcomes are unambiguous and concrete, there is no doubt over whether they have been achieved or not;
4. Outcomes do not impose constraints over the manner in which they are achieved, facilitating business flexibility;
5. Outcomes are modelled as state patterns, simple constructs that are far easier to understand than the complex notation of process models;
6. Outcome state patterns don’t incorporate flow and sequencing logic so that rules are decoupled from their implementation and far more accessible for change than when they are buried in a process notation.

So, what does an Outcome-based model look like and how do we “fix” all our process-models? That’s a subject for the next entry Decomposing Process Models.

Meanwhile back to the topic, here is my definition of Purpose:

Purpose: The coordinated transformation of resources into desired outcomes.

• Coordinated by Governance,
• Transformed by Courses of Action
• Into outcomes: Desired Results