It’s time to make an end to the arguments that have plagued my professional-life and more for at least the past decade. And the simplest way to do that – to make that ending possible – is to reframe what I do, reframe the way that I work.
So here it is:
– I’m not an enterprise-architect.
Describing myself as an enterprise-architect was always going to be a cue for any number of arguments: there’s still no clarity at all as to what enterprise-architecture is, hence no chance for any kind of clarity about the real role of anyone as enterprise-architects. It’s true that I’ve done plenty of work in what most others in ‘the trade’ would accept as ‘enterprise-architecture’ – data-architecture, applications-architecture, business-architecture, that kind of stuff. Yet I’ve also done a lot more that I’d described as ‘enterprise-architecture’ but many others still wouldn’t. (Not yet, anyway.) And when the field we’re working in is riddled with uncertainties, right down to its own definition, and yet what our clients most want from us is some semblance of certainty? – well, yeah, cue the arguments indeed…
– Instead, I’m a maker of tools for change.
That’s a much more accurate label for what I actually do. To me, an enterprise-architecture is something that properly belongs to the people of that enterprise, and most of which should be done by the people of that enterprise. By contrast, what I mostly do these days is move between enterprises, helping people explore ways to get better at doing their own enterprise-architectures. I develop tools and techniques for enterprise-architecture and the like: a related discipline, certainly, and relevant to enterprise-architecture, too, yet not the same as enterprise-architecture itself – a somewhat crucial difference in (literal) practice?
This shift in focus helps in other ways too. For example, whilst it’s probable that my main work will still be around enterprise-architectures, this makes it clearer and more explicit that the same tools can also work well within any other domain that needs to cope with change. (Which is pretty much every domain these days, wouldn’t you say? )
We can illustrate this with one of the tools that’s part of the Enterprise Canvas suite – a view of the service-context that my Mexican colleague Michael Smith Castillo describes as the ‘holomap’. Here’s the basic version of the diagram that I’ve so far used most often here:
To me this illustrates the key relationships between an organisation – a business, for example – and the broader context within which it operates. That broader context, all the way out to what I’ve labelled as the ‘shared-enterprise’, is what I consider to be the natural scope of an enterprise-architecture: as I’ve put it in various posts here, “we develop an architecture for an organisation, but about its shared-enterprise”. Which means that that set of relations is kinda important, to say the least: hence, for example, some of the themes in recent posts such as ‘Organisation and enterprise‘ and ‘Services and Enterprise Canvas review – 2: Supplier and customer‘. All well and good, so far: a useful tool indeed, for that type of architecture-assessment and the like.
The catch is that it only works well if the terminology there matches up with the way people already think about enterprises, organisations and their enterprise-architectures. Yet that, it turns out, is a very big ‘if‘… – in fact it’s been a constant source of unwonted arguments, because most people in EA don’t yet see ‘the enterprise’ in those terms. (As I understand it, most still see ‘the enterprise’ and ‘the organisation’ as near-synonyms – which means that, to them, that diagram above simply cannot make sense.) Which, if I want this to work, I need to see as my problem – not theirs.
So let’s do a reframe here: change the level of abstraction, via a shift from framework to metaframework. We keep the same diagram, the same of relationships, but shift to a more abstract, pattern-type terminology.
Instead of ‘the organisation’, we go back to one of the core principles from Enterprise Canvas, the assertion that “everything is or represents or implies a service”.
(To avoid arguments, note that that assertion is actually an ‘as-if’, not a purported-absolute ‘is’ – and because some people tend to miss that point, we might perhaps need to rephrase it with the explicit qualifier “for the purposes here, we proceed as if everything is or represents or implies a service”. It’s true that other arguments do still tend to follow on from that assertion, but with the ‘as-if’ in place they tend more to be the useful learning-arguments, rather than the useless ‘true/not-true’ declarations-of-faith.)
If we make that change, then ‘the organisation’ in the diagram becomes ‘the service-in-focus‘ – the whatever-it-is that we’re exploring at the present time:
It’s just a service – any kind of service, at any scope and any level. So yes, it could be a whole business, a consortium, or something even larger than that – but it could just as well be something much smaller, maybe a single software-service provided by a single server in a data-centre rack. It’s a pattern, a metaframework: the principles remain exactly the same, wherever we choose to start.
If it’s a service, it probably provides services directly to others, and probably consumes services directly from others too – sometimes even the same entities on either side. These directly-connected providers and consumers denote the transaction-context for our service-in-focus:
If we were talking about a typical whole-of-business context, we might describe this as the nearest partners in the supply-chain – but again, the service-in-focus might well be on a larger or smaller scale than that, so let’s keep the terminology generic for now.
Those transactions take place within a yet broader context, that sets the rules for transactions, that provides a space in which prospects and competitors and recruiters and consultancy-services and the like all come together around a common aim. This conceptual space is what we might describe as the direct-context for the service-in-focus:
Again, if the service-in-focus here was the whole of a business, we’d typically describe this direct-context as a market – but we might well use different terms for this as we change the scope or scale.
Beyond that direct-context, there’s another kind of context yet again, a conceptual space where we find stakeholders that may be affected by our service-in-focus, or may affect it in turn, yet often without directly connecting with it in any way. Because of that distinction, we’d probably best describe this as the indirect-context for the service-in-focus:
Whilst the direct-context might set the rules for the overall market or its equivalent, out here in the indirect-context is where we’d find a much more general concept of ‘fairness’ and suchlike, around which those rules would be built. It’s also where we’d often find some significantly-different stakeholders – the context’s equivalents of investors and beneficiaries, who don’t transact with the service as such, and probably don’t interact directly with it either, but upon whom, in certain crucial ways, the service will definitely depend.
So that’s our ‘service-context model‘ pattern, from smallest-scope to largest:
- service-in-focus – the specific context for which we’re doing some kind of assessment
- transaction-context – other services that transact with this service, to support its main value-flow
- direct-context – sets the overall rules and interactions around which transactions may be built
- indirect-context – holds the overall ‘story’ that provides the service-in-focus with its ultimate reason to exist, and links together everything and all of the stakeholders within that ‘story’
From that first diagram with which we started here, we can see how this generic pattern applies at a whole-business-level, giving us an anchor-description of the organisation, the supply-chain, the market and the broader shared-enterprise. But how does it apply to other scopes, other scales? Ah, that’s where the useful-arguments come into play…
The trick, of course, is in preventing a collapse back the usual non-useful arguments. And the way we do that is by holding the core-terminology at the generic level, the pattern-level, and then let the context-specific terminology emerge from the conversation, in relation to that generic terminology. The generic-terminology also helps us when we want to compare like-for-like between different scopes at the same scale, or explore how things change yet also kinda stay the same, as we move between different levels of abstraction or relationship.
That’s the theory, but what about the practice? What’s the use of this ‘meta-‘ stuff? Fair enough: so let’s give this a concrete, tangible example that enterprise-architects could use straight away.
Think of that service-context pattern as a visual-checklist: and now apply it to the classic BDAT-stack, such as in the TOGAF ADM. What we’d start with is this:
And compare and contrast it to this:
At first glance, what we can see is that there’s a reasonable fit between the BDAT-stack and the service-context model, for Technology-Architecture at least: if Technology-Architecture represents our service-in-focus, then Data-Architecture and Application-Architecture are kind of a mix of transaction-context and direct-context, whilst Business-Architecture is sort of halfway between its direct-context and indirect-context.
Once we start to look closer with that pattern, though – using it as a visual-checklist – we might begin to notice some serious holes that could happen if we were to base our architecture-development solely on the current ADM…
The first is that we can’t run the pattern backwards. It might seem to work well-enough for Technology-Architecture, and perhaps also for the transaction-context and direct-context for Data-Architecture and Application-Architecture; when we get to Business-Architecture, we’ve got nothing at all. We can use the Business-Architecture part of ADM to help make sense of the ‘lower’, more technology-oriented layers of the overall architecture; but there’s almost nothing to help us make sense of the business-architecture itself, because it doesn’t tell us how to develop a description of the architecture of the business itself – its transaction-context, direct-context and indirect-context. Once we understand this point, though, we can use our experience of building technology-architectures to show us the kinds of things to look for at the other ‘layers’ – using the pattern’s core-terminology as a guide against which to cross-map the context-specific terminologies that we’ll meet along the way.
The next theme we might note is what we can here see as a kind of blurriness in the ADM’s descriptions, with its Data-Architecture and Application-Architecture as kind of halfway between transaction-context and direct-context for Technology-Architecture, and its Business-Architecture again a kind of halfway-house for Technology-Architecture’s direct-context and indirect-context. For example, in what ways do the applications act as the technology’s service-consumers (transaction-context), versus what aspects of the application-architecture itself providing the rules and suchlike that provide broader constraints on technology-provision (direct-context)? In what ways do those rules and constraints come from the business-architecture (direct-context), rather than overall principles that might have little directly to do with technology, but can have very real impacts upon it (indirect-context) – such as through financial controls or broader legislation? Using that visual-checklist really does help to tease this distinctions apart – and the often very different stakeholder-groups from whence they apply.
A final point that comes from using this visual-checklist concerns something that’s easily missed in an ADM-based technology-architecture assessment. The BDAT-stack correctly indicates that data and applications are, in effect, the service-consumers for the technology: but if so, what are its service-providers? – because the transaction-context won’t balance up unless we have an equivalent understanding for both sides of that relationship. What we’ll find is that a sweep for those service-providers will turn up some really important relationships, around power-supply, heating or cooling, physical facilities, physical maintenance, physical-security and more. Yes, they’re the kinds of things that too often get shoved over the fence to facilities-management or IT service-management – often dismissed as ‘ITIL territory’ and suchlike. Yet in reality these are an essential part of the overall technology-architecture: and once we do accept them as such, and include them in our assessments, it can be a real eye-opener – especially in terms of opportunities and risks that we simply wouldn’t otherwise be able to see.
(I perhaps need to emphasise again that the ADM isn’t ‘wrong’: let’s not have any arguments about that? All that I’m suggesting here is that it can be helpful to use it alongside other approaches – such as this service-context visual-checklist – to get the architectural-assessments that we actually need.)
So that’s a real, practical example of how I’m reframing my work from now on: a maker of meta-tools for change, and showing how to use them, not just for enterprise-architecture, but for strategy, for business-model development, for community and communication, and many other types of change.
Interested? Let me know, perhaps. Over to you for comment, anyway.