Enterprise-architecture is all about story. The enterprise itself is a story; but the practice of enterprise-architecture is all about stories too. Let me tell you a story…
There once was this half-crazed guy who used to go on about an even crazier idea that there might be a bit more to enterprise-architecture than just, well, IT-boxes and suchlike. That there was a bit more to the story than that.
It starts, like most good stories, a long time ago. Turns out that whilst, yes, like so many other EAs, he’d come up through the usual IT-journey, from years of assembly-language through to database-design through to data-architecture and information and the rest, that wasn’t where he really came from. [I don't think he's the long-lost Prince of Multigravia, though - it's not that kind of story. Sorry.] He’d actually started out in graphic design, getting sidetracked into software and stuff to try to get typesetting-systems to work better. And he hadn’t forgotten the designer’s way of thinking about things (which these days goes by the fancy term of ‘design-thinking’, but it wasn’t called anything much back then). It was always about thinking about the big-picture at the same time as looking at the small-picture, and keeping the tension in balance whilst going in deeper and smaller and smaller and smaller, whilst still keeping the big-picture and the bigger-picture and the really-really-big-picture all in view at the same time. Kinda crazy-making, but that’s designers for you, of course.
And then something happened. [Yep, that's a phrase that comes a lot in stories.] He was working on enterprise-architecture by then, with a bunch of people who really in some cases really did think the the business-world began and ended with IT – that IT really was the centre of everything. He’d spent a fair few months documenting all the tiddy little Access databases and Excel spreadsheets that were being used way outside of their scope in business-critical areas, with no documentation and no backup, with no-one thinking that this might be a real business problem. And one of the areas he was asked to look at was quality-management. Which brought up a really simple yet surprisingly scary question: what is quality, anyway?
Quality is very tricky indeed: not a popular topic with many business-folks. [Boo! Hiss!] So unpopular, in this case, that the quality-manager for the organisation had actually committed suicide. [And no, I'm sorry to say, that's not a made-up story. 
No magical mentor in this story, unfortunately.] So how are they going to manage quality? We know how to it, they said – we’ll do it all with software! Buy a quality-management package off the shelf from one of the big vendors, so plug it in, roll it out to the whole workforce – there, problem solved! Easy! Sure it’s a fair few million bucks and ongoing but so what, it’s just ‘fit and forget’, isn’t it…?
Um. No. Even our half-crazed not-hero could see that that wouldn’t work. The problem was that lots of people wanted to believe that it would. Lots of serious business people with serious career-ambitions, and with serious access to lots of other people’s money. [Are these the villains of the story? Perhaps - but we'd better not say so in public if we want to keep our jobs...] A tricky enterprise-architecture problem, that one… But with a lot of hunting around, amongst the few mostly hidden backroom-boys still holding out the flag for the not-quite-lost quality cause, we found an in-house team who’d developed a quality-system that really did work. All done on little pieces of paper. No IT at all.
Sure, they were moving some parts onto software, but it was a ‘knowledge-management’ system for which we already had a site-wide licence, and which almost no-one else seemed to be using anyway: straight away a serious saving of several million dollars. But the main point was that it worked. And it was all about stories. Making sense, through stories.
Getting people to work together, to get the work together and make it work better.
Finding the best way to do the work, in whatever combination of people, machines and IT would be the best fit to that particular context.
Exploring, enquiring, endless seeking, ceaselessly improving. A commitment to quality; an enterprise in itself.
All through stories.
Which is itself a story.
So where are those stories in our usual narratives about enterprise-architecture? Uh… nowhere to be seen? Oops…
Perhaps this usual story of enterprise-architecture needs a different ending…?
Let’s step back a moment.
A few posts back, I wrote about a really great quote I’d found on two different views of architecture. One view said that it was all about structure; the other, all about narrative. But it we look at most of the EA tools that we have, and EA methods that we have, they’re all about structure. They’re very good on structure – no doubt about that. But unfortunately, they’re not good on narrative. There are a few notable exceptions (such as Nigel Green’s majestic VPEC-T), but for the others…? – well, we’d have to say that most are worse than useless on narrative… not so much ‘no-story’ as a negation of story itself.
Oh.
Which is a much more serious problem than it looks, because most EA work is actually about stories. Stories upon stories: lots of them.
Think about it. Every strategy tells a story. Every merger or demerger or restructure or re-this-that-and-the-other is a story. On the smaller scale, a business-scenario is a story. A use-case is a story. From as-is to to-be is a story. A typical application-consolidation effort is a story too, about how to clean up the tangle of this-doesn’t-go-with-that, and change it to a story of and-they-all-lived-happily-ever-after (until the next consolidation, anyway 
). It’s all stories.
Every requirement is a story. The work of an Agile team is all about co-creating a shared story. Getting people to work together is a story in itself, and one that in itself is so often made up of people sharing their different perspectives on what should end up as a shared story – perhaps across the whole enterprise.
And enterprise-architecture, in this sense, is all about supporting those stories. Every model tells a story, a record of decisions, options, choices. We can use each model to elicit further stories: people disagree with the choice, perhaps give us their story of why the choice needs to change; perhaps they agree, and the story helps to reaffirm and reinforce that choice, that story.
Yet at the moment, none of that’s in the models. Or, for that matter, the methods. We’re somehow supposed to know it’s all about story – but somehow pretend it’s all about the IT instead. Odd…
And when we stop to think about, EAs don’t actually do much other than tell stories, or get others to tell stories. We don’t do much development-work, perhaps not any: that’s the solution-architects’ job, and they’ll often get annoyed if we tread too much on their turf, their story. We don’t have much authority – especially beyond the borders of our own organisation. In most cases all we can do is influence, cajole, guide. And the way we do that is by creating a story.
It’s all about stories.
And that’s actually why I rant and rage so much about IT-centrism, and about the inadequacies of existing toolsets and the like: it’s not that it’s somehow ‘wrong’ or whatever, it’s because it stifles the story. Some of the toolsets are so constrained and so clunky that it’s like being a captive in kindergarten again, where the only permissible poems must be modelled on ‘Mary Had A Little Lamb’. The obsessive IT-centrism in so much architecture is like the self-centred bar-room bore, who insists that they have to be the hero of everyone’s else story. (The business-centrism of so many business-architecture tools is no better, by the way.) And a half-assed, half-complete story is no story at all. No fun for anyone else, anyway.
As enterprise-architects, we need to engage people in change, in a vision of something that works better than they have at present. And that’s why we need toolsets and methods that can cover the whole scope, the whole story of the enterprise, and support us in our storytelling of that story – because we need them to engage themselves in that broader story.
Enterprise-architecture: it’s all about stories. So it might help to remember that from time to time – by telling a story or two, perhaps?
[Post-script: if you're interested in story, you might like this Summary of story-structure models [PDF]. Among other things, it shows why so many Hollywood movies – from Avatar to Wall-E, to give just two relatively recent examples – have the hero apparently die and then recover, just before the end… ]