Jul 022013
 

A recurring theme in enterprise architecture forums and debates is: “How do we demonstrate the value of EA or justify architectural overhead?” Some may view these discussions as academic, which compounds the problem, because it supports the idea that enterprise architects don’t really understand their role, that they don’t have a common definition of enterprise architecture, and that we consequently don’t need them!

By far the biggest problem is a mind-set that perpetuates certain misconceptions about EA. All too often the rewards from architecting are seen as long-term outcomes, EA is not regarded as an essential element in enterprise transformation, and the value from EA is not measured effectively.

The first myth is that EA is optional. The reality is that every enterprise has an enterprise architecture. What is optional is whether you choose to manage it proactively or not. And deciding to have a hands-on and positive approach to managing enterprise architecture is also not enough. You must manage EA well.

The second myth is that EA is no different than many other disciplines. The reality is that EA has three unique, distinguishing characteristics: (1) it provides a formal approach for documenting and transforming the foundational structures and behaviors of an enterprise; (2) it views the enterprise holistically; and (3) it manages change toward an emergent long-term vision in a series of incremental steps.

The third myth is that calling yourself an enterprise architect isn’t enough. The reality is that you have to think as an architect — otherwise you are simply duplicating some other role, such as IT manager or strategist.

The last myth is that EA only produces value when a new architectural state is implemented and operational. The reality is that a good EA team delivers value throughout the strategy to execution cycle; from the value of ideas, vision, and plans through the value of doing the right things; to the value of making the best of scarce resources and investments and seeing things through to completion.

avatar

Roger Evernden

Roger Evernden is a Senior Consultant with Cutter Consortium's Business & Enterprise Architecture practice. He specializes in the highly practical use of EA to manage organizational transformation.

Discussion

  15 Responses to “EA Myths”

  1. avatar

    Roger, I disagree with your statement EA is different than other disciplines. Yes EA is different than a Doctor, Dentist, Account or Consultant. However, from the research I’ve been doing the past 30 years. EA shares the same factors you list with all the other design disciplines as well as a the same discipline maturity lifecycle pattern: http://briankseitz.wordpress.com/2012/02/02/discipline-maturity-lifecycle-enterprsie-architecture-example/ –only the span of time and the media they work in are different.

    • Brian – thanks for the feedback. EA certainly shares characteristics with many other disciplines, but it is more difficult to demonstrate the value of EA when we only focus on its similarities with other areas.

      If EA is the same as other design disciplines, then it becomes much harder to demonstrate the unique contribution and value from EA! Emphasizing the distinctive characteristics of EA makes it easier to demonstrate the need for EA and the outcomes that we derive by using EA.

      To distinguish EA from other disciplines we need to highlight its differences, including the span of time and the media we work in, as you mention in your comment.

      • Thanks Roger. I certainly agree that good EA team will create successful proposition. Now the question is how to break the “Myth”? How do we ensure EA teams across organizations deliver value consistenly? Can a framework be created for the EAs which would align the thinking towards value creation?

        Life of an EA also becomes difficult when the EA has to recommend an option which will cost more than a shortcut development team wants to implement.

        Appreciate your thoughts on creating value proposition from a ‘pesky’ situation.

        Best Regards

      • avatar

        I don’t believe differentiation from other disciplines is the key. The real issue is demonstrating value to the enterprise in a manner that resonate with those stakeholders. Too often we expect our audience to understand our jargon and perspective. Next time try you explanation on your kids. See if it makes sense to them.

        For a while I was watching IT Execs and managers roll in to Executive meeting pumped up about their latest project, present and hi five themselves as they left the meeting for the group to decide on funding. They figured they nailed it. Back in the meeting I’d have Execs ask me what the hell was this guy talking about and why should I care. They hadn’t even gotten to do I believe this guy. Technically, all the information was correct; like a brain surgeon explain the details of a complex operation using all the technical terms.

        Think about it, its your life; in this case the corporation’s life. Would you give the go ahead based on such an explanation? Most likely not. You’d ask plain English questions like:

        Has this been done before successfully?
        What is the success rate?
        How many times have you done this and success rate?
        What’s the cost? Side effects? Benefits?

        –not one bit of tech-speak.

        That’s not to say these people would not understand, they don’t have the time to translate. Other disciplines have matured and learned how to explain the business benefits simply. Manufacturing doesn’t spent time telling the CEO about the latest and greatest features of a CNC machine, they talk about increased throughput, lower costs per unit produced, they’ve spent the time with the CFO to properly present the business case, rather than have the CFO argue why their numbers are wrong for the proposed project.

        • I couldn’t agree with you more!

          Differentiation from other disciplines is just one of the things that we can do to justify the EA overhead. It’s important to make the distinction, in the same way that the local builder is not going to have the same skills as an experienced building architect, or a burger chef compared with haute cuisine. Emphasizing characteristics that demonstrate the unique value of EA is one step towards making it easier to justify your role.

          Using visualizations, examples, anecdotes, and metrics that are relevant to each stakeholder is absolutely essential – as you rightly point out. The EA myths in this blog are from my recent Cutter Executive Report – “Value, Benefits, Outcomes, Results, Returns, and Options: Justifying Architectural Overheads”. Here you will find practical tips and guidelines for talking to stakeholders in their own language at each stage of the strategy-execution lifecycle.

          You might also find a recent two-part Update useful, as this lists improved ways to communicate with stakeholders: The New Techniques of Fifth-Generation EA”

  2. The failure of enterprise architects is that they don’t demonstrate value thru the implementation. Giving ideas alone is not sufficient. Also the implementation teams don’t easily connect the big picture with their actual solution and is source of disconnect

    • Thank you Dhaks. Certainly it is true that may enterprise architects fail because they don’t demonstrate the value produced by implementation. And few implementation teams are likely to acknowledge the connection between the big picture and their solutions.

      So enterprise architects can do two things to improve perceptions about their value!

      1. The need to close the gap between architecture and implementation. The two extreme positions are: that implementation matches the architecture, or that implementation doesn’t match the architecture. In between are partial matches. The architect must be proactively involved in governing the implementation and tracking any deviation or exceptions from the architecture. When they do this, then they can demonstrate the value through implementation.

      2. But they also need to be aware that they often add value way before implementation. For example, by advising against a high-cost solution and proposing a simpler and smarter architectural change. Or by exploring a number of alternative architectural options, and demonstrating the value of one option over the others. Here the value is in the quality of their arguments and ideas.

      Which is why I argue that “a good EA team delivers value throughout the strategy to execution cycle; from the value of ideas, vision, and plans through the value of doing the right things; to the value of making the best of scarce resources and investments and seeing things through to completion”.

    • avatar

      Dhaks, building onto what you’ve written I’d add that a portion of the problem is that the implementation team (who may often do the detailed design) do not themselves buy into the function of an EA team or even the architecture itself. Everyone thinks he / she can “architect” a solution. This is especially true with the implementation team who are the ones carrying the can for a failed implementation architected by someone else.

      An EA team sitting in an ivory tower will add less value than one which is fully integrated into the implementation team.

      Equally, an EA team which is not putting together pragmatic architectures is too adding less value than they could.

      • avatar

        I would have to say that I agree with the EA myths you’ve presented.

        EA is really a misunderstood discipline.

        The ability (or inability) to effectively engage to identify and communicate the problem being solved, solution options (business and technical) and the paths to the desired outcomes in the appropriate ways to the different audiences differentiates the good EA’s from the rest of the EA’s (and the ability to actually execute against a strategy).

        The thinking / perspective an EA needs to take is different. Most of the time the technology is the easy part. Technology without changing peoples behaviors (adoption, process, skill sets, etc.) doesn’t realize value (monetized or social).

  3. avatar

    I was confused by the third “myth.” I think you have the wording slightly wrong. You meant to write “… is enough” not “… isn’t enough.” But I get your point

    On the last “myth”, I agree with Dhaks. If the Enterprise Architecture function does not see the organization through to the implementation of a new state, then their value is questionable. Ideas are cheap and easy, while delivery is hard. I am confused by your writing on this point because you seem to contradict yourself. You indeed seem to understand the importance of completion when you write “…seeing things through to completion.” But then why do you say it is a myth that EA shows value by delivering a new state, which is to my mind, “seeing things through to completion”? If you have a point here, I don’t see it.

  4. David – thanks for your comment. Actually I did mean to say that it isn’t enough to call yourself an enterprise architect! I know of many people who are nominally performing the role of enterprise architect, but who actually don’t perform as enterprise architects. In other words, they have the job title, but they are actually doing the work of a solution architect or IT manager. So to really be an enterprise architect you have to think and act as one!

    As for the last myth let me explain further. Actually good EA ideas are not cheap and easy! Thinking of a range of architectural options for tricky problems is a big challenge. Being able to explain the costs, benefits, risks and options associated with each transitional state or enterprise pattern takes years of practical experience and skill. The point of the last myth is that architects should demonstrate the value they add throughout the cycle from strategy to execution. At every stage the EA should add value – it shouldn’t be left to implementation, although of course that is also important.

    Hope that clarifies!

  5. avatar

    Thanks, Roger. Yes, now I get it. You are saying a good enterprise architect adds value throughout the process, both before, during and at the delivery of a project. I agree with that, and I appreciate your earlier remarks to Dhaks. That helped a lot.

    One thing I don’t often hear about is the two-way nature of architectural standards. In addition to an architect ensuring a project complies with standards, Sometimes innovative developers have a new and better way to do things. If the architect is not open to improving the architectural standards, those standards can present an inertia to innovation that stifles the adopting of emerging ideas.

  6. “How to break the myths??

    Breaking the myths is partly a question of changing current ways of thinking – for example, changing the discussion from “do we need enterprise architecture” to “do we need to manage the enterprise architecture”.

    It’s also a case of putting better metrics in place, or using techniques that actively recognize the type of positive results and outcomes that EA delivers.

    These myths are an extract from my recent Executive Report – “Value, Benefits, Outcomes, Results, Returns, and Options: Justifying Architectural Overheads”, by Roger Evernden, which has a lot more to say on this subject!

  7. Two Way Communication

    David – yes: some architects are not open to ideas from other areas! Which is a shame, as that is a great source of practical and often innovative ideas.

    Enterprise architects need to engage in two-way communication with all relevant stakeholder groups. There are various ways to do this, but one option is to initiate a wiki that allows anyone to post concerns, suggestions and innovations related to key architectural subjects, such as software applications, business processes, or infrastructural technologies.

 Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>