NOTES – an alternative approach for EA

If – as we’re often told – business-design is about the relationships between people, process and technology, what is it that links all of themes together? Answer: a story.

Okay, yes, this is a theme I’ve explored a lot here on this blog and elsewhere over the past few years. To date, though, I’d have to admit it’s been bit scrappy – various ideas here and there, but not that much to hold it all together. What I want to do is collate all those ideas together into a more explicit and systematic framework for enterprise-architecture and the like – one that wouldn’t replace any of the existing frameworks as such, but would complement them to provide a richer view across the whole enterprise space.

Perhaps think of it more as a style of architecture, an orientation of view, in much the same way that SOA – Service-Oriented Architecture – provides a way to view the context of the architecture.

A narrative-oriented architecture.

Except that – given the known antipathy of business-folk to the ‘A’-word – probably best to avoid using the word ‘architecture’ itself.

So for now, let’s call it NOTES – Narrative-Oriented Transformation of Enterprise (and) Services. (Or NT for short: Narrative Transformation – otherwise known as changing the story, in a business sense.)

Why do this? What’s the connection to enterprise-architecture?

Point is that the stories are the architecture – or an expression of the architecture-in-practice, anyway. Whenever we change the strategy, the people, the process, the technology or just about anything else within a business or whatever, we’re also, by definition, changing the business-story.

And since that’s happening anyway, probably a good idea to ‘surface’ the underlying story (or, more often, stories), and the changes in those stories. Doing so not only gives us a better understanding of past and present, but also gives us some modicum of choice about how those stories continue onward into the future. Which is probably a wise move, yes?

And why story? – why not something else?

The real reason comes back to the meaning of enterprise, as an essentially human endeavour. There’s a common tendency in EA and the like to describe the enterprise mostly in terms of things or information, with people almost as a kind of afterthought – which, in an all too literal sense, risks losing contact with the enterprise of‘the enterprise’. To keep connection with the whole-as-whole, we can perhaps see this as three distinct views or ‘worlds’:

• the physical-world is made of atoms
• the information-world is made of bits
• the human-world is made of stories

All three of these ‘worlds’ need to be considered ‘equal citizens’ in our overall view of the enterprise as a whole.

One of the reasons why this is important is that whilst the physical-world and information-world both expect things to remain the same – to follow ‘the rules’ – the human-world doesn’t. The algorithms of the information-world give us an illusion of certainty; the the stories of the human-world tell us more about what actually happens in the physical-world, which is that it’s full of exceptions – ifs and buts and sometimes and perhapses and I-really-don’t-knows. Messy; confusing; uncertain.

To illustrate the point, look at a typical taxonomy, a typical database-schema: it’s full of ‘is-a’ relations, ‘has-a’ relations, simple certain many-to-one or one-to-many relations. By contrast, when we look at the world through a story-lens, a narrative-oriented lens, we’re much more likely to be able to pick out the real-world items that refuse to fit into that nice, safe, certain schema: the ‘is-sometimes-a’ relations, the ‘was-once-a-but-isn’t-now’ relations, the ‘could-perhaps-be-any-one-of’ relations – the kind of real-world mess we’d need to expect for any reference-architecture, for example, or any Bring-Your-Own-Device policy.

Or, to give another real-world example, consider the case of the environmental-activist who’d been invited as the lead speaker for an international conference in Britain, but who was blocked from entering the country by the UK Border staff. Why was he was refused entry? – answer: because the biometric-data record in his passport was incomplete – the fingerprint-data were missing. Yet the reason why the biometric-data record was incomplete – and also the reason why he’d become an environmental activist – was that as a result of industrial pollution he’d been born without hands. Hence no fingerprints…

Describing that passport-problem as a story, it’s obvious that the main-path assumptions wouldn’t make sense in his case: and the system needs to be able to handle that kind of exception – because it’s literally not his fault that he doesn’t fit the system’s assumptions. (Likewise for the case of Abby and Brittany Hensel: one ticket, one seat, but two passengers, two passports; and they can’t do the passport-inspection one-at-a-time, either…)

Yet most of our systems are designed on the basis of an information-oriented world: certain, safe, sensible – and often just plain wrong. Yes, we need the consistency and conformity that good information-oriented design can deliver; yet we also need to be able to acknowledge and work with all of these real-world ‘oddities’ too – because reality is that whatever assumptions we make, there’s always something that just won’t fit.

Hence why story – and why story matters.

So how do we make this work? What does ‘narrative-oriented architecture’ and suchlike really look like in practice? One suggestion to start with is that instead of assuming that we should always build our architecture models to look like this:

— we need to remember that at the same time, what those so-certain seeming models might well describe in real-world practice is actually something more like this:

And when we look at the enterprise (and our organisation’s place in that shared-enterprise) more in terms of that latter view, it also gives us an alternative way to reframe that classic yet somehow incomplete concept of ‘people, process, technology’:

• people: actors and audience
• process: layers of story, from big-picture theme to throughline to story-beat to scene to scene-element
• technology: the stage

Some kinds of technology can also be ‘actors’, of course. Yet note that in story, technology-as-actor tends to be anthropomorphised – assigned humanlike characteristics, such as helpful (like R2D2 and C3PO) or malevolent (like the Terminator). That’s a big contrast to the conventional Taylorist model, with its literally robotic view of people – actor-as-technology, with no place for humanness at all…

So, to give a quick summary of what a narrative-oriented view of the enterprise would provide:

• a focus on service rather than solely on self
• a focus more on people than on machines
• from working only with the pseudo-certainty of automation to working with the full real-world complexities that only people can resolve
• from ‘people / process / technology’ to ‘actor / story / stage’
• from a focus on ‘what’ and ‘how’ to a focus more on ‘why’

I’ll expand on each of these, and other practical implications of NOTES for enterprise-architecture and the like, in subsequent posts in this series. See you there, perhaps?