The deliverables of enterprise architecture

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?

Tagged with: , , , , ,
11 comments on “The deliverables of enterprise architecture
  1. Ron Parker says:

    If you have innovation as a part of EA there is something else to consider. The innovation team can truly help cultivate ideas into value in a consistent manner. Any innovation should be changing the people, processes, technologies or data. In order to bring innovation into production you need to document and incorporate the new behaviors or tools. This process can take place with the help of EA Practice area. They own this process and can help develop the standards and the guidance necessary for the implementation of innovation. So there are real EA deliverables there that have real value.

    EA cannot only be involved in direct deliverables but they can also guide the processes around how those deliverables are made valuable.

    • Tom G says:

      @Ron: “EA cannot only be involved in direct deliverables but they can also guide the processes around how those deliverables are made valuable.”

      Yes, exactly.

      You’re also right about the need for EA (or at least some equivalent body) to hold ownership of core shared-reference items such as standards: those would definitely be deliverables for EA, regardless of the scope of that EA.

  2. Ivo says:

    Tom,

    “most of the deliverables of whole-enterprise architecture appear only in the outcomes of other people’s work.”

    Not necessarily. W-o-E should be able to directly propose or even provide solution or dissolution of present or future problems and support strategy and management of strategic risk. I see it as much more ‘walk’ than ‘talk’.

    “even explain exactly what it is that we do”

    We are in trouble if we can’t explain what we do, and do it in such a way so that it’s understood.

    “They want definite deliverables from us, to prove that they’ve done their job of monitoring our job as consultants or whatever.”
    When that is the case, the problem is what they call ‘monitoring’ is something else, probably the blame-structure notion of ‘control’ (which is neither monitoring nor control)

    “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”

    I would rather say that the real value is in finding meaningful scores that make feed-backs work and helping in fixing the structure where loops are open or have opposite direction or don’t link the right dots.

  3. Tom G says:

    @Ivo – yes, agreed, all good points, and I do sort-of sit corrected on those aspects.

    “W-o-E should be able to directly propose or even provide solution or dissolution of present or future problems and support strategy and management of strategic risk.”

    In practice – not least for political reasons – I see it far more as the latter (‘support strategy’ etc) rather than the former (‘provide solution’ etc). If we purport to ‘provide solutions’ at the high-end strategic level, we are going to get shot at, big-time. To me the only time when we’re likely to be allowed to present anything that resembles a ‘solution’ at this level will be for the purpose of giving people something to argue against, and say that it’s ‘wrong’ etc, in the process of working towards something that is right.

    “We are in trouble if we can’t explain what we do” – that’s exactly why many of us are in trouble. 🙁 The real problem is that, as I explained in the ‘No jobs for generalists’ posts, there’s almost no way to describe in Taylorist-style terms what it is that a cross-function generalist does: it’s like (in fact is) trying to explain three-dimensional structures to someone who lives only in a flat world – they simple do not have the concepts in place in which the ‘between-spaces’ of multi-dimensionality of the enterprise can make sense. That is a very real problem – and I for one haven’t found a good way around it as yet.

    “probably the blame-structure notion of ‘control’ ” – with mid-level managers who live in the imaginary-world of ‘performance-reports’, that’s exactly what it usually is. In English, this is termed ‘CYA’, aka, ‘Cover Your Ass’…

    “finding meaningful scores that make feed-backs work” – that’s what those two metrics are designed to do. However, mid-level managers usually focus on the score itself, rather than on how to score can be used. That’s really the point there.

  4. Benjamin says:

    Hi Tom,

    I’ve seen it many times that providing a common ground or language to get people talk about their maybe very different business context in a cohsesive way, is what they say they valued the most about EA. On the other side without proper communication of EA with a destinctive portfolio of what you offer and what value it will provide, is something you probably cannot miss doing.

    Other quotes have been around seeing certain things through having the 20.000 foot view, that most others don’t. Often thought of being obvious, but not many have it seen actually.

    By the end of the day: Know your most important EA stakeholders and what information to provide when and in which way. There will be no debate about the value if you get this right.

    • Tom G says:

      Benjamin – “providing a common ground or language” – yes! To me a large part of the EA role is acting as ‘translator’ between different sub-cultures, and helping people move towards a common shared-language through which they can then continue to communicate on their own, without needing an external ‘translator’. (There’s also the point of helping those sub-cultures to understand that they do need to communicate with others in order to get the work done… 🙂 )

      “Often thought of being obvious, but not many have it seen actually.” – very often turns out that things that to one person or group are considered ‘obvious’ aren’t obvious to anyone else at all. Hence the importance of that part of the EA role about surfacing ‘the obvious’, and making it visible enough for people to discuss.

      “Know your most important EA stakeholders and what information to provide when and in which way.” – yes, very much so. In fact it’s obvious, isn’t it? 🙂 – which is why we, uh, often need a little nudge to remind us that it should be obvious to us in terms of our own actions too… 😐 🙂

  5. Gavin B says:

    Tom, have been enjoying your recent series of posts – you are right on the money in so many ways. From my recent direct experience in leading an EA team out from EITA into Whole of Enterprise Architecture, there are a couple of really key success factors (and you never fully succeed, you’ve just not failed yet…!)

    1) a leader immediately above you who really gets EA, and who fully sponsors your work, and is highly credible with his/her peers and the top team. (not seen themselves as ivory tower)

    2) the opportunity opened up by this leader to work with the top team, and gain credibility with them – so that you can put your own skills to work, and have the valuable conversations that you describe in this post.

    Completely agree that the value is in the conversation as much or more than the deliverable. We’ve just completed an initial enterprise wide Target Operating Model/future state architecture, and although there is a product, we’ve worked hard to position it as not “our” deliverable but simply presenting back something that is owned by the top team, a record of their conversations and agreements (with maybe a little structure and a few choices of wording from us). 🙂

    For us, part of the solution to middle managers not getting it has been to lift the engagement up above them, to work with and for the directors and senior leaders, at their level. We end up helping to set the context for the middle managers, and avoid some (but not all) of the need to deliver hard products. Again, this was only possible because we had established the right relationships through the personal sponsorship of a credible leader.

    • Tom G says:

      Gavin – your ‘really key success factors’ – yes, definitely, to both of them.

      On “we’ve worked hard to position it as not ‘our’ deliverable but simply presenting back something that is owned by the top team” – yes, absolutely essential. The moment we present something at whole-enterprise scope as being ‘our design’ is the moment we’re likely to lose all credibility with anyone else.

      On “a record of their conversations and agreements”, I did a post on this some while back: ‘Models as decision-records (Enterprise Canvas)’: http://weblog.tetradian.com/2011/01/23/models-as-decisionrecords/ – might be worthwhile rescuing that one from the archives, perhaps?

      Thanks again, anyway – much appreciated! 🙂

  6. @Tom
    ‘whilst enterprise-architects may well deliver models of various kinds..’

    Enterprise Architects do create plenty of EA models but these are often not seen as our primary deliverables these days. The EA model will have many specific views and viewpoints of interest to our stakeholders but the stakeholders will probably value the resulting insights rather than the views themselves. Both views and value will depend very much on each individual stakeholder’s perspective and their ability or inclination to spend the time engaging with the enterprise architect who produces them. Communication is key to producing the appropriate views.

    Of course it doesn’t help when the stakeholder doesn’t ‘get’ enterprise architecture at all, and doesn’t want to communicate with the enterprise architect.

    Very often an EA roadmap and resulting programme/project plans will be the deliverables seen as having the most value. This is especially true for people focused on delivery, and not focused on strategic thought. In other words a deliverable for many people has to be actionable to gain anyone’s attention.

    Any deliverable that end up as shelf-ware will have failed.

    • Tom G says:

      @Adrian: “Enterprise Architects do create plenty of EA models but these are often not seen as our primary deliverables these days.”

      Yes, exactly. (If they are seen as the ‘primary deliverables’, that’s when they usually end up as shelfware…)

      “Both views and value will depend very much on each individual stakeholder’s perspective and their ability or inclination to spend the time engaging with the enterprise architect who produces them.”

      Yeah, that’s the hard part. And that’s where the notion of selling ‘solutions’ is such a darn nuisance – ‘solutions’ are nicely prepackaged components for a Taylorist machine, but within the EA process (and others like it) the whole point is that we’re not in the Taylorist machine, we’re in the ‘between’-spaces that it can’t see and doesn’t know how to deal with, yet without which the machine doesn’t work.

      “In other words a deliverable for many people has to be actionable to gain anyone’s attention.”

      Yes, though actionable by whom? – that’s another area where this gets, uh, interesting… As they move further ‘upward’ into strategic space, EAs and other generalists become less and less likely to actualise a plan, not least because the specialist are far better / more experienced than they are at the ‘doing of things. (That detail-level experience is why the specialists are specialists, after all. 🙂 ) As in Gavin Beckett’s comment above, the work has to be ‘owned’ by the top team, and/or whoever actually puts it into action; yet if it’s ‘owned’ primarily by those people, then the work of the generalists in pulling that deliverable together can easily get forgotten, precisely because they don’t actualise it themselves. For an EA, it’s a real sign of success when other people say “we did it!”; but can also be kinda tricky if saying “we did it!” also becomes an assumption that the EA did nothing to make it happen… :wry-grin:

      In short, a lot of people seem unable to tell the difference between ‘doing no-thing’ (in the Taoist sense) and ‘doing nothing’: and since much of an EA’s work revolves around ‘doing no-thing’, this can easily land us in a whole heap of trouble. :sigh:

  7. In my experience many architecture deliverables are what I would call “architectural waste”, meaning they are not valuable because they are not consumed by the next step in the IT Value Chain.

    I prefer talking about architecture consumables
    http://architecturalthinking.net/2012/11/22/not-deliverables-but-architecture-consumables/

    Ultimately, to be successful, an architecture practice needs to provide to its stakeholders (within and outside IT) what they need, cost effectively.

Leave a Reply

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

*