The science of enterprise-architecture (short version)

(The previous post, ‘The science of enterprise-architecture‘, covered a lot of ground, but ended up kinda long – again… So for those with tendencies towards TL;DR, here’s a somewhat shorter version. ūüôā )

How much is enterprise-architecture a science? To put it the other way round, how much does science even apply in enterprise-architecture?

The honest short-answer is ‘Not much‘.

We do see a lot of what¬†claims¬†to be ‘science’ in enterprise-architectures – but to be blunt, not much of it matches up to any real-world test. To make sense of this, it’s best to start by going back to first-principles:¬†what¬†is¬†‘science’, anyway?

The key distinction is between what most people think of as ‘science’ – ‘science as portrayed’, the¬†end-results¬†of science – versus real ‘science as practised’, the¬†processes and practices¬†via which those end-results are achieved. For science-as-portrayed, there are explicit rules and principles:

  • reproducibility¬†– the same results must be reproducible by others, following the same methods under the same conditions
  • predictive¬†– the results may be used to predict the behaviours of phenomena in the future
  • consistent¬†– the assertions and outcomes are consistent, both internally within and in relation to itself, and externally in relation to other scientific laws and themes
  • simplicity¬†–¬†Occam’s Razor¬†should apply
  • completeness¬†– the results should cover all phenomena within the context
  • peer-review¬†– establish consensus about what is true and what is not

Which suggests the possibility of¬†certainty¬†and¬†control¬†over what happens. Hence ‘scientific management‘ and the like.

But there’s a huge catch, around “following the same methods under the same conditions”. In enterprise-architecture – especially for high inherent-uniqueness, such as in healthcare,¬†customer-service,¬†clothing, fashion,¬†sales, market-design,¬†information-search,¬†farming or city-planning – what we¬†actually¬†see is more like this:

  • reproducibility?¬†– even with so-called ‘best-practices‘, it’s never quite the same methods or conditions (and often the key point is that the results should¬†not¬†be reproducible by others!)
  • predictive?¬†– where the context itself is undergoing almost continual and accelerating change, any prediction is always going to be uncertain
  • consistent?¬†– creating even a consistent terminology across an enterprise is often a nightmare, let alone anything larger in scope or scale
  • simplicity?¬†– rather than¬†Occam’s Razor, we’ll often struggle instead with our equivalent of¬†Hickam’s Dictum, that “patients can have as many diseases as they damn well pleases!”
  • completeness?¬†– across a large, complex, dynamically-changing context, ‘completeness’ is a fantasy of wishful-thinking…
  • peer-review?¬†– whenever we’re dealing with something new or unique, who¬†are¬†our peers anyway?

If we¬†don’t¬†have exactly the same methods or conditions, we¬†can’t¬†have reproducibility, consistency, simplicity, completeness or predictability – which also places tight constraints on how much we can use ‘science-as-portrayed’. And there’s no way to get round those facts, either.

We can describe this with the horizontal-axis of the SCAN framework, from certainty on the far-left, versus uncertainty and uniqueness extending towards infinity on the far-right:

In SCAN’s terms, absolute-control and absolute-predictability exist as an infinitely narrow line on the far-left. Yet by definition, an enterprise-architecture must cover the entire context-space covered by the SCAN frame. Hence, in practice:

  • the public perception of ‘science’ – as certainty and control – can be dangerously misleading¬†in any¬†real-world¬†business context
  • whatever science enterprise-architecture might use, it will¬†and must¬†be different from that myth of ‘certainty’
  • no matter how much our clients may desire ‘control’ and ‘scientific’ management, there’s no way any real science of enterprise-architecture could deliver it

To use science in enterprise-architecture, we depend on two crucial understandings:

  • the way that science¬†actually¬†works – the process and practice of scientific¬†enquiry¬†– is itself not ‘scientific’ as per that public-perception above
  • whilst¬†absolute-certainty may never be possible,¬†effective-certainty may well be achievable

Effective-certainty is what we might describe as ‘good-enough’-certainty: it isn’t¬†actually¬†certain, but it’s certain-enough for the organisation to be able to deliver its required outcomes.

In SCAN, the boundary of effective-certainty is indicated by the vertical red dotted-line. Once we go past that line, what happens becomes inherently uncertain: and the further we go to the right of that line Рmetaphorically speaking Рthe more uncertain it gets.

Yet that’s exactly what we¬†should¬†expect, for a true ‘science of enterprise-architecture’. Texts that describe the actual¬†process¬†of science – such as William Beveridge’s¬†The Art of Scientific Investigation¬†– show that it’s decidedly messy and uncertain. It also has to be able to let go of beliefs that it may currently think of¬†as¬†science – an¬†interesting¬†bootstrap-challenge…

One option is to view the process of enquiry as a set of distinct paradigm-modes Рeach with their own distinct disciplines Рthat we could summarise in SCAN-like form as follows:

We then use explicit¬†tactics¬†to¬†switch between disciplines, as required – a literal ‘path of discovery’ around the context-space.

Whilst we’re¬†tasked¬†with bringing things toward that left-hand side of the SCAN frame, most of¬†our¬†work occurs over on the right-hand side. For example:

  • where managers and solution-designers need frameworks, we need¬†metaframeworks¬†– frameworks to help us design context-specific frameworks
  • where they need methods and methodologies, we need¬†metamethods¬†and¬†metamethodologies¬†– tools and techniques to define context-specific methods and methodologies
  • where they need schemas ¬†and metamodels for data, we need¬†metametamodels¬†and¬†metametametamodels¬†– tools and techniques to create a context-specific metamodel for any scope or level
  • where they need toolsets with distinct notations to tackle distinct business-questions,¬†we need tools¬†that can cover¬†every scope¬†at¬†every level of detail¬†across¬†the entire toolset spectrum

Hence it looks like the most useful key to an answer is in three parts:

  • other than for some aspects of IT and machines, it’s probably best almost to¬†forget about ‘science-as-portrayed’¬†– the ‘science’ of certainty and suchlike
  • instead,¬†focus on ‘science-as-practised’¬†– the processes of ideation, experimentation, sensemaking and decisioning that underpin real science
  • always remember that¬†logic and the like have real limitations¬†– they¬†are¬†useful, but they’re not the only tool in the toolbox

Enterprise-architects should¬†learn and maintain the disciplines¬†of ‘science-as-practised’. For example, Beveridge’s¬†The Art of Scientific Investigation¬†describes the role of chance, the use of intuition, the importance of strategy and politics, and the hazards and limitations of reason. There are distinct disciplines around each of those themes – and¬†those are the disciplines of science that we need most in enterprise-architecture.

Our work is not about the would-be ‘completeness’ of science, but more about ‘just enough’ –¬†just enough detail, just enough scope, just enough science – coupled with an awareness of ‘it depends‘, that everything depends on everything else, and that there’s always a larger, more ambiguous scope.

And that’s why¬†the real answer to “Is enterprise-architecture a science?”¬†must¬†be “Not much”¬†– and always will be.

Ultimately, too, we need to remember that we’re enterprise-architects, not scientists. Science and its ‘truths’ are not the reason we’re here:¬†value¬†is. We need to keep the focus on¬†usefulness, on¬†real value, not imaginary ‘truth’¬†– delivering real business-value for our real business-clients with their real business-questions. Everything else is merely a possibly-useful means towards that end.

1 Comment on “The science of enterprise-architecture (short version)

Leave a Reply

Your email address will not be published. Required fields are marked *