Architecture is theory

Those who denigrate architecture as ‘only theory’ are seriously missing the point, because the role of architecture is theory – theory to guide the practice of design. Without theory to guide practice, all that we’d have is design that’s built on untested assumptions. Not A Good Idea…

Where this started was a snarky putdown the other day from someone who purported to work as an IT-architect. He was “giggling”, he said, because he regarded my work on whole-enterprise architecture as ‘all theory’, with no relevance to anything, And added, with another free gift of sneer, that a big investment company such as Berkshire-Hathaway – big in terms of the funds it manages, though not in number of employees or partners – would have no need for whole-enterprise architecture. Hence, he asserted, that one purported exception proved that no organisation would need it, therefore what I’d described was ‘all theory’, and therefore irrelevant to everything.

Sigh.

And yeah, I’ve had fifteen years of that kind of – let’s be blunt here – clueless inanity shoved in my face, day after day, month after month, year after year. If you wonder why I’m giving up on so-called ‘enterprise’-architecture, that’s one of the core reasons.

But one more try, though, in the hope that it might perhaps help others to avoid falling into the same traps as that sneerer…

There are two parts to this: the role of architecture as theory, and the specific role of whole-enterprise architecture.

First, on architecture and theory.

A quick one-liner: theory informs practice, practice re-informs theory. It’s a loop (sometimes known as a praxis-pragma loop) via which we can improve effectiveness in reaching iteratively towards a desired outcome.

For the ‘architecture’ context in business and elsewhere, architecture is theory, design is practice. In context of the ‘realisation-stack’ – such as in the sequence of layers in the Zachman model – we use design to move ‘down’ the stack towards real-world implementation, and use architecture to move back ‘up’ the stack to review and re-acquire guidance for that design. In visual form, the relationship looks like this:

…and:

Yes, in working our way downward towards making something real, we mostly work on design. Yet the moment we need to rethink our options, at any stage in the development-sequence, we need to go back to architecture. Architecture is the theory that guides the practice of design.

(By the way, this is exactly the same structure as in ISO9000 quality-management: whenever we need to rewrite a work-instruction, we go back ‘up’ to the guiding-theory of the respective procedure; when we need to rewrite the procedure, we go ‘up’ to the guiding-theory of policy, and so on.)

Without architecture, design literally has no guidance. That’s exactly what happens when Agile goes wrong: it fails because it has no guiding architecture.

And likewise, without design, architecture cannot deliver anything tangibly-useful in the real-world. When that happens, that’s when architecture seems to be ‘only theory’.

(That latter problem is an almost-inevitable outcome of any architecture-framework that covers only a subset of the ‘realisation-stack’, and/or that describe higher/more-abstract layers as ‘architecture’ and lower/more-concrete layers as ‘design’. Those fundamental errors are a direct cause of the too-common perception that its version of ‘enterprise’-architecture is ‘all theory’.)

One of the major causes for the abysmal quality of much (most?) ‘enterprise’-architecture is that it fails (refuses?) to apply architecture to itself, as metatheory to guide the design of a useful architecture. Which, yes, will give those “it’s all theory!” critics even more reason to sneer at us – but all that sneering does is, again, illustrate the clueless inanity of such critiques. Architecture is the theory that guides the practice of design: in which case, by definition, we’ll need an architecture to guide the design of an architecture. The only problem with architecture is if we fail to take that theory into useful practice, as design for useful implementation.

The second part here is about organisation and enterprise. That aspect of that sneering put-down about whole-enterprise architecture arises – to again be blunt – from a redoubled cluelessness about the nature of enterprise itself, and also about the content needed for an enterprise-architecture.

In that Berkshire-Hathaway example, it seems almost certain that the sneerer made two fundamental mistakes: failing to understand the crucial distinctions between organisation and enterprise, and making arbitrary assumptions about size of organisation in relation to applicability of architecture. (There’s also almost certainly some mistaken assumptions about content for enterprise-architecture, but that’s a separate topic for another time.)

For organisation versus enterprise, one of the common assumptions is that the two terms are synonyms for each other: that the organisation is the enterprise, that the enterprise is the organisation. In reality, ‘organisation’ and ‘enterprise’ denote two different scope-entities (in essence, ‘how’ versus ‘why’) whose boundaries may coincide – but that special-case is basically useless and dangerously misleading, because it represents a context in which the sole reason for the organisation’s existence is to talk only with itself. The simplest summary here is that the enterprise represents the context, purpose and guiding-story for the respective organisation (or ‘service-in-focus’, to use a more appropriate context-neutral term): we develop an architecture for the organisation, about the enterprise that provides its context. In practice, the scope of enterprise we’d typically need to explore for an enterprise-architecture would be three steps ‘larger’ than the scope for the organisation – the organisation plus its transactions, direct-interactions and indirect-interactions – and also looking ‘inward’ to perhaps the same depth:

For example, we’d need this to identify typical RACI-type mutual-responsibility relationships:

…and also much, much more, such as modelling the organisation’s options for positioning itself within that broader enterprise.

In short, an ‘enterprise’-architecture that allows us to assume that organisation and enterprise are synonyms is Not A Good Idea…

The other mistake was the assumption that enterprise-architecture is only relevant to organisation of a certain type or size. That may be true for IT-architecture: but it should be obvious from the above points about organisation and enterprise that it is not true for a literal ‘the architecture of the enterprise’. Every organisation, or every size and type, will need to understand the enterprise within which it operates – and this would perhaps especially apply to an investment-organisation such as Berkshire-Hathaway that would need not only to understand the architecture of its own enterprise, but also of every organisation in which it invests.

There’s one other useful lesson that we might gain from that sadly pointless putdown-attack, and that’s a reminder that emotion applied to theory can be a warning that we’re at risk of falling into the Seven Sins of Dubious Discipline – in particular, going ‘overcooked’ in Sin #4, ‘The Meaning Mistake’. In this example, an emotion such as ‘giggling’ is a classic indicator that someone’s being both arrogant and clueless in applying ‘policy-based evidence‘ to some context they don’t actually understand – and that if we’re giggling about someone’s view of theory, the one who’s being arrogant and clueless may well be us. Not A Good Idea…