The theory of enterprise-architecture

(This 'from the archives' article provides supplementary information for the YouTube video 'Balancing theory and practice in enterprise-architecture - Episode 23, Tetradian on Architectures', released on 05 July 2018. The post was originally published on the Tetradian weblog on 16 September 2012 as 'The theory of enterprise-architecture'.)

---

What is the theory underlying enterprise-architecture?

This was a question that came up in a group email-discussion earlier today, and it’s probably worth bringing out into a more public arena so that other people can come and play with it too.

My own view is that an awful lot depends on what’s meant by ‘theory’, or ‘underlying’, or even the use there of the word ‘the’. And that’s before we even get close to The Dreaded Definitional Problem of defining what we mean by ‘enterprise-architecture’… 

What worries me is that implicit in the question “What is the theory underlying EA?’ is an assumption that in terms of how we use theory, we’re still operating solely within the linear-paradigm: for example, that there must somehow be an identifiable linear or ‘deterministic’ chain between theory-as-cause and practice-as-effect.

Reality is that that just ain’t how it works here.

What we see instead is the use of a variously-disciplined mash-up of ideas and experiences from a wide range of different domains, always somewhat personal, always somewhat contextual. It’s very much dependent on personal skill and experience – and personal history, too. And if we think for more than just a moment or two about the nature of the problem-space – or context-in-view, rather – then it should be clear that that’s not only what we would expect, but to a large extent that’s how it should be. In fact if we don’t get that kind of disciplined mash-up (with a definite emphasis on that word ‘discipline’), well, that’s when we’ll find ourselves “gettin’ into a whole heap o’ trouble”…

Sure, the specific items-of-content (the ‘content’ being theory, in this case) in the space are always relevant. To me, though, what’s far more important is how theory-items are selected for use in each context: theory-as-belief-as-tool. Gooch’s Paradox applies here: “things not only have to be seen to believed, but also have to believed to be seen“. Hence what matters most here is the discipline in working with meta-theory and meta-methodology – in other words, how theories and ideas can be recombined in line with the dynamic needs of context – and also a willingness to accept and work with the nature of the context-space.

Probably the bane of our entire profession is that it’s riddled with attempts to repackage complexity or uniqueness in ways that ‘make sense’ in terms of the linear-paradigm. The big-consultancies do this all the time, not least because it makes it easier to ‘sell’ – even though they know that it doesn’t work… Perhaps for much the same sort of reasons, we also see a heck of lot of claims that such-and-such is ‘scientific’, when in reality the respective ‘science’ consists of someone-or-other’s empirical experience, or a lot of reading of so-called ‘science’ which again turns out at root to be little more than someone’s opinion.

And in the sciences themselves, the classic example would be how people latched on to the belief (or hope?) that chaos-mathematics makes chaos predictable. It doesn’t: it can make the nature and type and extent of unpredictability somewhat-predictable, but it never changes the fact that inherent-unpredictability itself always remains unpredictable – and hence not amenable to linear-paradigm notions of cause-and-effect.

[One guide I return to regularly on this – on how science really works, rather than what so many people think of as ‘scientific’ – is Beveridge’s ‘The Art of Scientific Investigation‘: see in particular his chapters on strategy, chance, intuition, and the hazards and limitations of reason.]

The catch for us in enterprise-architecture is that the linear-paradigm works just fine much of the time in IT and IT-related architectures, in fact we’d usually need its emphasis on consistency and linearity in order to work well in those contexts. Yet because it works well in that type of architecture, for that class of problems, people often make the mistake of thinking that that’s ‘thetheory’ of architecture or systems-thinking or whatever. But the linear-paradigm does not work well in any context that includes self-feedback or wicked-problems (‘complex’) or inherent-uniqueness (‘chaotic’) – and the contexts we work with will almost always contain some aspects of those types. Which means that linear-paradigm notions of ‘the theory underlying’ are likewise inherently problematic in these contexts.

We saw much the same in that previous post on recursion in definitions of ‘process’: none of this is straightforward, and there’s always a strong subjective and contextual element here. Theory in a complex context is inherently as complex as the context itself; and likewise theory in a unique or ‘chaotic’ context is inherently somewhat chaotic. The moment we forget that, we’d be in deep trouble in terms of theory and its application in practice.

Another comment that came up from the conversation: “Surely a theory must testable, and remains unproven until it is tested?” Sure, that sounds straightforward enough, but in an enterprise-architecture it’s rare that we can test anything in that way that most people seem to expect. The reality is that just about all we can do is try something out, and see what happens: the act of changing something changes the context itself – which means there’s no way we could wind the clock to try again with exact same factors in place.

Every context is different, in often-subtle yet inescapable ways: that’s why ‘best practice’ is so problematic, for example, and ‘worst-practice’ – the study of known anti-patterns, in order to understand what doesn’t work – is often more useful in practice. To be blunt, people who demand ‘proof’ that something will work in an enterprise-architecture are merely demonstrating that they don’t understand how things actually work in enterprise-architecture – nor in the real-world, for that matter. The only action in an enterprise-architecture that has anything resembling predictable or testable results consists of doing nothing at all: and even that rarely works as well as anyone would hope. In short, it’s tricky…

A lot more to say on this, of course – especially around what kind of meta-theory approaches do work for this – and I’ll explore that in future posts. But I’ll stop here for now: any comments so far?