Well, there you go. I promised you some controversial views on this blog and here’s one of them. I believe that processes are NOT part of a business architecture model and here’s why.
I strongly believe that business architecture models need to be as light weight as you can possibly make them while still achieving the objectives assigned to the business architecture team. There are two reasons for this belief:
- A lighter weight model facilitates faster responses to questions from the top table – almost by definition the fewer artifacts you have to impact the faster your response can be;
- A lighter weight model provides business architecture benefits at a lower TCO (Total Cost of Ownership) – the more detailed your architecture models are the more they cost to maintain their currency.
Including processes within your architecture adds disproportionate weight to your architecture models in comparison to the architectural value you gain, while at the same time slowing your response to questions from the top table. What causes the added “weight”?
- Processes are low level – they deal with all the sub-activities and all the decision points
- Processes are physical – they have multiple physical implementations in order to achieve a single logical outcome
- Processes change often – most businesses are achieving small incremental productivity improvements by changing processes almost continually
Dealing with the first point, do you need to know the detail of “how” the business does something or are you more focused on what it needs to do and the parameters within which it needs to operate? As an example, which question has the higher architectural value: how do we take orders? or, can we handle taking 1,000 orders per month per operator at a cost of less than 5 cents an order? In both cases we need to understand something of the process but we don’t need a full process flow to understand the second question.
The second point really compounds the problem of the first point. You will find multiple physical implementations of the same logical process for valid reasons – identifying a customer logging on to a web app will use a different process to identifying a customer who’s called you on the phone. Sometimes it’s valuable to recognise these differences in your architecture; sometimes not so much. If you are including processes in your architecture, you don’t have a choice – they all have to be recognised and modelled.
The final point comes back to the maintenance overheads of dealing with changing processes. I have seen one company whose philosophy is “If it can’t be done with SAP then we don’t do it” but I think this is the exception that proves the rule. In practice, most companies are continuously tweaking their processes to gain small incremental advantages and you will be hard-pressed even to keep a track of all these changes let alone maintain your models currency. By the way, this is also ignoring shadow organisation effects where the documented process may not change but the actual process sure does!
Convinced yet? “Well, sort of. But surely we still need to know what the business needs to be able to do?”. Sure we do, and this is the crucial distinction. As architects, we need to know what the business needs to be able to do, but we are less interested in how the business actually does it. This to me is one of the key benefits of business capabilities.
A business capability sets out, at various levels of granularity, what a business needs to be able to do. Some of those capabilities may be decomposed into sub-capabilities e.g. Send Communication may be comprised of Compose Communication and Fulfill Communication. For some of those capabilities it may also be useful to distinguish different physical implementations of the same logical capability, for some capabilities not so much. Some capabilities need to have parameters, goals or targets which map back to the strategic goals and each capability can be associated with target parameters.
However, at no time do these capabilities dig into the detail of how exactly those capabilities are delivered. This provides you as an architect with a rich framework within which to focus on what the business needs without having to worry about the in-depth detail of the how.
A challenge has been thrown at me that “Surely this doesn’t apply when the focus of the architecture effort is about process standardisation. Surely, then you need to know the detail of the how?” Even in this situation, my stance remains the same – from an architecture point of view you don’t need to know the how. In fact, focusing excessively on the how can actually detract from the bigger picture view of standardisation.
From an architecture point of view, your focus is to decompose the overall process components into a series of reusable, flexible, capability components that can then be individually standardised going only to the level of physicality that you need to. What is architecturally important is that you have a standard component – what that capability does inside the black box is a question for business analysis not business architecture.
I stand by my view, processes are NOT part of a business architecture; capabilities very definitely are.