What’s the minimum that we need as a base for a viable business-architecture?
That’s a shorter summary for a multi-part question recently sent to me by Chilean business-architect Richard Moira Lupin:
What should a company have, what maturity, what capacity, what purposes, so that a business architect can, at least partially, exercise and execute business architecture projects?
For various practical reasons, as you’ll see, it’s probably most useful if I address each of those parts of that question in sort-of the opposite order:
What’s the purpose of business-architecture?
To me, the role of business-architecture is to build and maintain a clear picture of the structure(s) and story(ies) that the organisation will need, in order to do its business. Or, in short, to maintain the architecture of ‘the business of the business’, in context of the organisation’s market(s) and the respective broader shared-enterprise(s) – and then help others use that picture to guide the implementation of that organisation’s structures, services and operations, from a business perspective.
In functional terms, business-architecture sits as a bridge between strategy, product- and/or service-design, organisation-design, marketing and change-management, and also some aspects of operations-design and knowledge-management.
The services that business-architecture would provide relate mainly to guidance for and arbitration between each of those organisational-functions above (strategy, product-design etc) for which it acts as a bridge, in relation to any questions about ‘the business of the business’ as a unified whole.
The key effect of the absence of a distinct business-architecture is that business-analysts and others would be forced to make often-arbitrary guesses about what ‘the business of the business’ actually is. Such guesses are rarely consistent with each other, are often too easily influenced by vendors’ ‘solutioneering’, and may well be just plain wrong.
What capacity for business-architecture will an organisation need?
It’s probable that the only honest answer would be ‘It depends…‘. The most common key factor here is organisational size and complexity.
For a small organisation addressing only a single market, the business-architecture is likely to be simple enough that it can be addressed as just one more minor task for the CEO or equivalent. (By definition, all architectures are ultimately the responsibility of the CEO, though this responsibility is likely to be delegated to others in anything but the smallest of organisations.)
As the business grows in scale and complexity, the need for a dedicated business-architecture role, and, later, a dedicated team, will likewise increase. Probably the closest parallel would be the organisation’s business-strategy function: a business-architecture team is likely to need to be roughly the same size as the strategy-team – though unlike strategists, business-architects are more likely to be a distributed-team working more directly with and between other business-functions.
What maturity will an organisation need before it can gain real value from business-architecture?
I’d argue that the correct answer is ‘any maturity at all’ – for example, one of the times we most need a business-architecture is right at the start, when we technically have no organisational-maturity at all. What differs at different levels of maturity is the emphases and priorities for the types of activities we need to undertake – and we can use an explicit maturity-model to guide us in this. My own examples, as described in some depth in my book ‘Doing EA‘, come more from enterprise-architecture than business-architecture, but the principles are still essentially the same:
The ‘Step 0’ bit – “Prepare and maintain foundations for architecture” – is what I’ll come back to for the answer to the last part of Richard Moira’s question. A crucial point here, though, is that this isn’t a simple step-by-step process: we may well find ourselves doing bits of work from what is nominally Step 3 or even Step 5 when we still haven’t really cleaned up on Step 1. Yet all that doing activities that are nominally ‘too early’ would mean is that we may be creating further work for ourselves at those nominally ‘earlier’ levels – and we need to be aware of that fact, as leaving that work not-done would create new risks and potential business-instabilities for the future. The Step 2 work of ‘Clean up the mess’, for example, is not a one-off ‘fit-and-forget’, but something we need to get good at, all of the time – otherwise our business will eventually grind to a halt from drowning in its own literally ‘unfinished business’. Maturity means that we’ve reached a level of mastery at doing something that we don’t even notice it as an issue any more – we just do it anyway, as ‘unconscious competence’:
There are also some important crosslinks between this kind of maturity and other business-concerns, such as the crucial mindshift that’s needed for a business to successfully support a transition to ‘pull-marketing’ and the like:
Another set of crosslinks help to indicate the probable types of complexity that the organisation would be able to successfully address at each of the respective levels of maturity:
…and, from there, the probable types of product and service that the organisation could successfully provide and support at that respective stage.
Again, though, remember that this ‘maturity-map’ isn’t just a linear step-by-step sequence: we can do things ‘out-of-sequence’ if we need to do so. It’s just that it becomes harder to do, and almost certainly harder to maintain, if the respective maturity-level isn’t already well-established throughout the organisation.
What must a company have in place to support a successful and useful business-architecture?
I’ll presume that what’s meant by ‘have’ here is the set of artefacts – documents, diagrams, models and suchlike – that will be used to guide conversations on business-architecture and its use, dependent on the architecture purpose, capacity and maturity as above.
For the absolute top-level for the business-architecture, a useful starting-point here would be the overview in the ‘Implications for mainstream enterprise-architecture’ section in the post ‘EA in miniature – Part 2: First steps‘. (For some useful notes on the relationships between architecture and design, see the matching ‘Implications’ section in the next post in that series, ‘EA in miniature – Part 3: Getting real‘.
The single most important part of this top-level is the ‘enterprise-vision‘ – a very brief summary, often no more than half a dozen words, about the ‘what’, ‘how’ and ‘why’ that holds the entire enterprise together. For this context, the term ‘the enterprise’ is not the same as ‘the organisation’: it relates to the shared-enterprise that the organisation serves, and within which the organisation does its business. This is much broader in scope – not just broader than the organisation or even its market, but a scope bounded by a shared-story that would always continue to exist even if the organisation and market did not:
Values, success-criteria, standards, laws and regulations all devolve from that enterprise-vision – it’s that important. The organisation then positions itself in relation to that enterprise, via its own mission and vision, which are necessarily subordinate to the enterprise-vision itself – and not the other way round…
For details on how to derive and use an enterprise-vision, see the video ‘Introduction to visioning – Tetradian on Tools For Change‘ and the post ‘A structure for enterprise vision‘.
For more on how to link the organisation to the shared-enterprise – and also on what happens if we get it wrong – see the post ‘Vision, role, mission, goal‘ and the slidedeck ‘Vision, Role, Mission, Goal: a framework for business motivation‘.
The enterprise-vision provides the anchor for looking ‘outward’ from the organisation, towards its customers, suppliers, investors and other partners. We then need to link to that outward enterprise by looking ‘inward’ into the organisation itself:
Hence the other essential business-architecture artefact, to aid with this, is the capability-model (sometimes known by other terms such as ‘Functional Business Model’). This describes what the organisation does, in a deliberately abstract way – the capabilities or functions that are needed for the organisation to do its business, as distinct how those capabilities or functions are implemented at the present time. At its simplest possible level (‘Tier 1’), almost every business-organisation would have a capability that looks somewhat like this:
At the next level of detail (‘Tier 2’), there’s more differentiation, though organisations in the same industry would share a similar capability-map, to which industry-wide standards are often associated:
In business-architecture, we would typically develop our capability-model to at least ‘Tier-3’, a more organisation-specific level – at which point it becomes hugely useful to the organisation. For more on just how useful and important capability-maps are, see the videos ‘The usefulness of capability-maps‘ and ‘More uses of capability-maps‘, and the slidedeck ‘Unpacking TOGAF’s Phase B: Business Transformation, Business Architecture and Business Buy-in‘.
For more on how to develop a capability-model, see my books ‘Doing Enterprise-Architecture‘ and ‘The Service-Oriented Enterprise‘. For free resources, there are basic instructions in the section ‘Step 1: Know your business’ in the free-download sample-PDF for ‘Doing EA‘, and more-detailed instructions and an old but perhaps-still-usable Visio-template in a free-download file there (the latter link points to a web-page for ‘Doing EA‘ from which you can download the ZIP).
Another useful business-architecture tactic is to use abstract context-neutral templates that can be adapted to context-specific needs. For example, the service-based Enterprise Canvas frame can be used as simple yet useful capability-model in its own right, that also – as per my book ‘Mapping The Enterprise‘ – also helps to map out how a given service would link to the broader shared-enterprise:
Yet the same frame also has many other business-architecture uses, such as a service-completeness checklist, and as a guide to real-world implementation – including customer-facing and back-office elements – for business-model designs developed in other well-known tools such as Business Model Canvas.
There are plenty more items we could add, even at the starter-level – see the slidedeck ‘Business-Architecture: Upwards, Downwards, Sideways, Back‘ for some other suggestions. But just with the items above, you should you have the minimum you’d need, to start developing a useful business-architecture.
There’s one important proviso related to all of the above: the concept of ‘business-architecture’ described above is not the same as the so-called ‘business-architecture’ in certain current ‘enterprise’-architecture frameworks such as TOGAF.
In both approaches, ‘business-architecture’ is regarded as a somewhat specialist sub-domain of a broader ‘enterprise-architecture’. But that is almost the only equivalence between the two approaches.
In the approach described here, ‘business-architecture’ is a literal ‘the architecture of the organisation’s business’, in context of ‘enterprise-architecture’ as a literal ‘the architecture of the enterprise’. The focus of attention in each architecture is always ‘people-first’, not ‘technology-first’: technologies may be important, but only ever as an enabler in context of the business and the enterprise itself.
However, in TOGAF and other IT-centric ‘enterprise’-architecture frameworks, the emphasis is the other way round: ‘technology-first’, not ‘people-first’. Any people-concerns subordinate to those of the technology, and the effective definition of ‘enterprise-architecture’ there is not ‘the architecture of the enterprise’, but actually ‘the architecture of enterprise-IT‘. (Or, rather, ‘the architecture of the organisation’s IT’, since there is a strong tendency to regard ‘organisation’ and ‘enterprise’ as exact synonyms – which in turn makes it all but impossible to support the mindshift needed to make the Step-3 to Step-4 maturity-transition described above, or even to make much sense of any interactions from beyond the organisation itself.) Given this, their effective concept of ‘business-architecture’ is best summarised as ‘anything not-IT that might affect IT’ – which might perhaps be valid if our sole interest is the IT, but is a classic ‘cart-before-horse’ misframing if our real concern is the architecture of the business itself.
In short, those two concepts of ‘business-architecture’ are fundamentally different: Don’t Mix Them Up!
Related posts:
- Uniqueness and serendipity in enterprise-architecture
- Solution-space: Beyond Cynefin?
- More on meta-methodology (‘Beyond-Cynefin’ series)
- Models as decision-records (Enterprise Canvas)
- Towards a whole-enterprise architecture standard – 2: Core
转：Building-blocks for a viable business-architecture
http://weblog.tetradian.com/2020/01/03/building-blocks-for-viable-bizarch/
