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?
I understand exactly were you are coming from as I have been down this road also. You will probably go full circle and end up with the final conclusion that it gets you know where. At least that happened to me.
From stories I ended up questioning how stories were told and the key is language. Language is how these stories are communicated. Language can take many forms but they all have rules (grammar): VERBS are actions and tell the how , bpmn identifiea theae as Tasks – NOUNS (things) are the what , data objects – PRENOUNS (who), lanes – etc the big variable in all of this I found are the verbs and adjectives used to describe the story. Systems today are incapable of determining the enormous number of verbs and ways in which something can be done or to what extent something could be described. The more the variation in use of verbs and adjectives to tell a story the more complex the system. The resultant outcome is less standardization. We can either complexify the stories to the point of artificial intelligence or standardize to the point of something we can model.
I ended back at what I could describe and model. Which unfortunately looks more like a model and less like your theater. For me to tell a story I would be confined to keep it short and simple otherwise possibly loose my audience.
One more thing, the story in your theater will consistently tell the same story evey night the same show is on and all actors will all know what their part is in the acting. The process in you have in theaters are even probably more standardized than anywhere else.