19 December 2020 / Company updatesRead more
Company > News & insights
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 and business architecture framework.
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 planning solutions 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 and enterprise architecture solutions, 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 Business Architecture tools 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 of 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 it’s 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:
- Outcomes are measurable, tangible, directly related to objectives and can be easily associated with performance targets;
- Outcomes precisely reflect the purpose of the business and what it is trying to achieve;
- Outcomes are unambiguous and concrete, there is no doubt over whether they have been achieved or not;
- Outcomes do not impose constraints over the manner in which they are achieved, facilitating business flexibility;
- Outcomes are modelled as state patterns, simple constructs that are far easier to understand than the complex notation of process models;
- 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:
The coordinated transformation of resources into desired outcomes.
(Coordinated by Governance, transformed by Courses of Action into outcomes – Desired Results)
The truth is that most organisations do not have a tangible and comprehensive explanation of their business model
Can that be true? How did we get to this state? Consider the recent history of corporate IT. The adoption of enterprise application adoption over the past two decades was characterised by competing views around the “Build vs Buy” schools of thought.
The buy approach, based on the philosophy of “industry best-practice”, relied on the vendor to deliver “best-practice” processes and services in their packaged applications. Customers bought into the promise of reduced costs and complexity of system implementation by re-engineering business processes to comply with those embedded in their application of choice. A key saving came from the fact that very little business analysis was required since the whole idea was to adopt the information, rules and process models built into the selected application. For these organisations their business model is implicit in the systems it is built on.
The build approach was premised on the belief that custom software could provide a more specialised solution that targeted specific business needs and that would not lock the organisation into a vendor strategy. Customers assumed responsibility for analysing, designing, documenting and maintaining their own applications. Key to the success of this approach was a highly competent team and very well documented solutions. In practice, this was rarely the case and these custom-built applications have mostly evolved well beyond the original designs, to the point that the only explanation of what they do is encoded into the system itself. Where it does exist, analysis and design documentation is generally poor in quality, disjointed and not up to date.
Inevitably, these aging enterprise systems are becoming legacy through the relentless pace of technology innovation. As enterprise systems age they soon become inhibitors rather than enablers of agility.
The only explanation of how many businesses operate is inaccessibly encoded in a myriad of technologies, stitched together in a rigid and brittle patchwork of duplicated, redundant, incompatible silos of information & logic
Where did we go wrong? For the past 20 years the most fundamental misconception of corporate IT has been to consider technology as a strategic asset, rather than a strategic enabler. By treating systems as an asset we have committed enormous resource and effort into burying the logic of the business into the technology platform, yet made very little commitment to articulating and preserving an understanding of what the systems do. When it comes time to change the platform we are faced with the tyranny of legacy. Many large organisations have hundreds or even thousands of systems and nothing to explain how they all work.
The enterprise architecture team at one large global financial institution took 18 months to produce a stocktake that simply listed the 4,000 systems in their application landscape and roughly what they do. They anticipated that it would take them at least 2 more years to assess the inevitable duplication and redundancy of information so that they could begin to identify opportunities for rationalisation.
How can an organisation in this state avoid digital disruption? The only possible way is to shift the prevailing view and recognise that systems are just means, not ends. We need to recognise that the system is not an asset, technology is a commodity.
Your most important strategic asset is your business model. Applications are simply current implementations of the business model.