Link: http://weblog.tetradian.com/2012/09/09/deliverables-of-ea/
Just what are the deliverables of whole-enterprise architecture?
In part this is a follow-on to the previous post ‘Ending the shoot-out at the EA Corral‘, about finding ways to end the seemingly ceaseless battles between those enterprise-architects who focus only on IT and the like, versus those who work at a broader whole-enterprise scope. Yet it’s also an important question in its own right – because it often is hard to see what it is that whole-enterprise architects actually deliver.
What sparked this off was a couple of Tweets from Roger Sessions, an IT-architect whose work I definitely do admire. I’d guess he’d been annoyed about some note or article from a whole-enterprise guy, because this was what came up in his Twitterstream:
#entarch must be revamped so that its purpose is no longer delivering useless paperwork, but facilitating high value IT projects.
At first glance, from a whole-enterprise perspective, that comment not only sounds snarky, but just plain wrong – after all, there’s a lot more to an enterprise than just its IT!
Yet remember that clash between Engineers and Scientists that I described back in the ‘Unbreaking‘ post – because that remark is entirely reasonable from an Engineer-style perspective. And that’s where Roger sits within the enterprise-architecture space: he’s a ‘big-picture’ thinker and practitioner, but that big-picture itself is always centred around IT. In that sense, he’s an Engineer: and as we saw at that research-laboratory, Engineers tend to dismiss Scientists as doing nothing but sit up in their ivory towers all day, churning out “useless paperwork” to waste Engineers’ time…
The next Tweet that comes up from Roger is clearly a reply to someone else who hadn’t been happy about that first remark:
I don’t know what “planning support” means. It doesn’t sound like #entarch has much in the way of deliverables.
Again, at first glance that sounds really snarky – but it’s actually quite accurate, especially from an Engineer-style perspective, or from the perspective of any solution-architect.
IT-architects and process-architects would expect to deliver strategic road-maps, application-portfolio maps and suchlike, often encompassing their entire domain; whilst solution-architects would be expected to deliver detailed and fully-documented solution-designs. But whole-enterprise-architects? – to any outsider, often all we’d seem to do is talk…
Yet when I look at my own work, in actuality that is indeed true: my main deliverable really is that I talk with people. I’m a generalist: I connect things, concepts, ideas, perspectives, in often-unexpected ways – and that really is where I deliver most of my value. I don’t have much in the way of tangible ‘deliverables’: most of the deliverables of whole-enterprise architecture appear only in the outcomes of other people’s work. Which can be quite tricky when we have to explain our ROI and the like to Engineer-types – or even explain exactly what it is that we do.
Likewise with Taylorist-type managers. They want definite deliverables from us, to prove that they’ve done their job of monitoring our job as consultants or whatever. But the reality is that most of what they’d think of as ‘deliverables’ is, to us, a waste of time on pointless paperwork – exactly the kind of ‘shelfware’ about which Roger rightly complained. In practice, to keep bureaucrats happy, we often have to, uh, bend things a bit… Here’s a real (though mildly-edited) example from a current client:
Maturity-assessment of existing methods, models and frameworks
Assessment of EA and enterprise effectiveness
Recommendations for EA presentation within the company
Possible scenarios including roadmaps for further development to enhance models and contribute to company effectiveness and agility
The maturity-assessment and effectiveness-assessment are both developed against documented processes, and they do both deliver a documented score that has some definite meaning for the organisation. To a manager or other ‘outsider’, the score is usually seen as a valid ‘deliverable’ in its own right: we’ve done something, and the score is the tangible result of that item of work. Yet the reality is that the score itself is often all but irrelevant: the real value is in the conversation that develops around what the score means, in terms of what it suggests about what the organisation can do to enhance its EA-maturity and overall effectiveness. The catch, of course, is that in Taylorist terms a conversation isn’t a ‘deliverable’: it’s a between-thing, a before-things-happen-thing, and hence doesn’t really exist – even if though it is actually needed in order for things to happen. Which is where things get tricky… and why we’re often forced to rely on ‘useless paperwork’ to prove that we’ve done anything at all.
The records of the conversation itself are often of definite value: which is why I usually take at least one camera to any consultancy-session, to record whiteboards and the like – and often also a video- and/or audio-recorder as well, to capture those serendipitous yet all-too-fleeting comments that didn’t make it onto the whiteboard or into anyone’s notebook.
[Although most of my EA-clients do value such records, many have been explicit that they don’t want them listed amongst the session’s official ‘deliverables’. Again, probably too much first-hand experience of worldview-clashes when trying to explain to managers just what it is that enterprise-architects actually do… 
]
Anyway, to summarise all of the above:
- whilst enterprise-architects may well deliver models of various kinds, often the most important deliverable of enterprise-architecture is the conversations that connect between people, or between people and other ideas and information
- most of the outcomes of enterprise-architecture will only be visible and measurable in the deliverables of other people’s work
That’s my view and experience, anyway: what’s yours? Comments or suggestions, anyone?
