“Waiter, Waiter!”

The customer sat in the corner of the busy cafe, with a seaming bowl of soup, frantically waving to the retreating waiter who had just set the bowl down and hurried away.  Frustrated, he turned, but did not advance.

“What is it, sir?”

“Waiter, try this soup,” the customer replied.

Curious, he walked back to the table.  “What is wrong with it.”

“Just try the soup.”

“Sir, is there a problem?” the waiter impatiently insisted, looking over his shoulder at the other tables.

“Just try the soup,” the customer repeated.  A few seconds of silence passed.  The waiter considered his options. 

“OK, sir.  I’ll try it.”  The waiter looked around the table.  “Where’s the spoon?”

“A-haaaaaa” noted the customer. 

I spent about two hours yesterday in a conference call with the Enterprise Architecture team of a large financial institution, one of the many fringe benefits of this job.  I shared some details about our EA practices and they shared theirs.  It was an opportunity for me to speak with peers, share ideas, compare practices, and such.  (Special thanks to their Microsoft Account Manager for setting up the conference call). 

One question that came up, that in fact often comes up, is “how do you convince senior business leaders of the value of Enterprise Architecture?

My answer: I don’t.  Enterprise Architecture, the function, is not valuable by itself. 

Enterprise Architecture is valuable because of the data that EA collects, and the reports that EA makes available to senior leaders. Allow me to repeat, it’s all about the data.

Business leaders don’t need Enterprise Architects to stand around acting smart.  They need data, reports, and analysis.  The Enterprise Architect is essential to interpret that data, and help them to understand the value of the using the information to make decisions. 

So, if I have a business leader who does want data, I start there.  I collect a little data and show it to her, and whet her appetite.  I ask what questions she wants answered (“Which processes drive the most cost to my department?” or “How much of my budget, last year, was actually spent on going after my priority strategies?”).  Then, get the subset of EA data needed to answer that question.  Projects grow from projects, functions from functions.  Data maintenance is expensive, so the reports have to be valuable year after year.

When we see a business leader that doesn’t understand EA, we show the reports we created for other leaders.  It’s all about the data.

To be honest, I don’t want to ever sell the value of EA to a business leader.  I want one business leader to ask another, “where did you get that data,” and have the other reply, “From Enterprise Architecture, of course.”

The system should flow from it’s own success.

If the data is the food, EA is the spoon.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

13 thoughts on “The Value of Enterprise Architecture”
  1. Having right data/information at right time certainly helps business leaders with decision support.But in addition the business leader is helped many other different ways by proper enterprise architecture – productivity improvement, driving innovation, cutting costs, reducing time-to-market etc.

  2. I’m struggling with this one. You seem to be saying that enterprise architecture is all about producing reports on the status quo to allow the business to target areas for improvement. I would strongly disagree. Enterprise architecture is there to set the direction of travel – the destination if you like – once the future vision has been formulated.

    This is why we use the term architect… An architect produces the high level design for the building once the thought is there for a building to be required. The architect does not deal in measurements of the existing building in order to explain to the building which rooms are useful and which are not.

    I think this is a classic case of different areas referring to themselves as architecture when in fact they play a completely different (but equally valuable) role.

    Titles are important in distinguishing roles. For me this is a misuse of the term architect. Are you not describing business analysis here?


    The Enterprising Architect

  3. Hi Jon,

    I think you are struggling because you made an assumption, while reading my post, and then reacted negatively to the assumption.  I can’t do much to help you there.  

    I NEVER said that the data pertains only to the current state.  The fact that you made that assumption is troubling.  I’ve read your blog.  I would not have thought you, of all people, would go there.

    There are a great many enterprise architects (present company excluded?) who assume that the future state model is NOT data.  That we cannot model the future state in an accurate way, that we cannot DOCUMENT our decisions, and justify them.  That we cannot describe the future state and then measure the distance we have come and the distance we have yet to go.  

    Enterprise Architecture is an active role.  There is no way that we can add value by "pronouncing" the future, and then stepping back to watch as the organization either ignores it or makes earnest but ineffective choices.  We have to set the direction, but we also have to assist with the countless individual decisions.  That requires data.

    Enterprise Architecture documents the decisions, provides the measurables, measures success, and delivers value… all through data.  

    Does that alleviate your struggle a little?

  4. "In God we trust. All others, bring data!"

    I fail to see how a commitment to analysis, information, and fact-based decision making, (which is what I took away from this post), represents a vote for as-is architecture over the to-be.

    EA is in essence a decision-support discipline, not a decision-making one. Nothing helps a decision maker more than good reliable and transparent data. And data that accurately captures cause and effect is pure gold.

    I agree whole heartedly with Nick’s point. The only thing I would like to add is the concept of trust.

    By providing data to decision makers we gain their trust. But more importantly, providing them with good data provides us with a reason to trust them in return and have full confidence in the future state they require us to design.

    Data is the basis of trust in EA. If you don’t ‘bring data’ all else is lost.

  5. The way I see it NickMalik was emphasizing on HOW to make enterprise architecture visible to a business leader. It all comes down to data (from the as-is as well as from the to-be), but I really have to agree with Jon that your article leaves a feeling that Enterprise architecture is all about data when in fact reduces time to market, sets goals for the enterprise, changes the Business architecture, etc(again, all visible to the business leader as data).


  6. Thank you Julian.

    Perhaps the article didn’t clearly talk about the fact that as-is and to-be states are both represented in the notion of data.

    I make no claim to being the best author the world has ever seen.  But I do take it a bit harsh when someone reads an article, sees a gap, and rather than asking about it, opens up with whithering criticism.  

    Especially someone I respect.

  7. Of course! neither would I claim to be a good author yet.

    I have to say not so many people talk about what you did in this article…so many authors write about Enterprise Architecture, its benefits, and so on, but so few of them mention how difficult it is to sell to a business leader.

    It’s refreshing to see someone addressing these issues, and I have to say I find really interesting the data approach you mention.

  8. After your dismissal of Jon I’m a little hesitant, but I’ll chime in.

    I think in the original article you covered the future-state with the "business need" of "tasting the soup".  

    So in this example, EA is not only providing data on the current state (lack of spoon), but also restating the goal/mission for the stakeholder — and then making it clear what infrastructure/tools are missing to satisfy the goal.

  9. Hello st4rbux,

    Fair statement and I agree.  EA definitely takes the position of pointing out both the present state and the alignment requirements that drive towards the future state.

    How do you show the value of doing that to your business leadership?  

    When you make a non-controversial decision ("kill the legacy app that no one uses"), everyone applauds.  But what about when you make the controversial decision ("The project to implement a new CRM platform is ill-considered and not aligned to strategy.  Pull back hard and re-allocate 90% of your resources to other projects while you replan.")?

    How do you represent, in a systematic manner, that your controversial decision is better aligned to the goals and mission of the stakeholder than their pet project is?

    That is where data comes in.

    I don’t mean to be harsh, but if you state the future, but don’t prove it, and record it, and govern by it, it doesn’t make any difference.

    Isaac Asimov entertained us with his Foundation series, but he didn’t drive the creation of a new branch of Mathematics.  He may (yet) inspire that future, but inspiration is different than perspiration.  Enterprise Architecture has be involved in both.

  10. Hi Nick

    I have been remiss in not responding to your answer (spam swallowed the notification – sorry).

    Yes, your clarification did help greatly in my understanding, and my post was not intended as a "withering criticism". Apologies again for it appearing that way. I now understand your position, and agree with the sentiment that delivery of information is key to the value of EA (and perhaps information is a better term here as it encompasses a wider remit in most peoples minds).

    The value of this information may not be immediately apparant to the leadership however, and equally valuable recipients that are worth considering are the doers. It is hard to measure the amount of time projects spend getting answers to the same questions time and again (with limited success), but what is certain is that the cost of these questions adds up to a significant outlay.

    The information in an EA is of greatest value at this point in the organisation, as the potential savings (not to mention giving the same, right answer everytime) are enormous.


    The Enterprising Architect

  11. Hi Jon,

    Thank you for your kind response.  I agree that the word "information" would have made the point more clear than the word "data" did.  Alas, hindsight is 20/20 in this case.

    I also agree that the value of EA information may not be apparent to leadership, and that the value of that same information can be very valuable to the "doers" who have to drive changes to business processes, systems, information, and roles within an organization.  You correctly point out that the summative value of providing consistent answers to EA questions is substantial.  I couldn’t agree more.

    While I may not sign up for the notion that EA data is at it’s "greatest" value when directed at the doer, (I think the planning perspective has some extraordinary benefits as well), I do agree that the information stored in an enterprise architecture is of substantial value to the doers and that demonstrating that value can provide a much needed "win" in the long-running battle to get EA accepted as a business function.  

    Regards and respect,

    — Nick

  12. the key thing for me is getting data that’s consistent across the company. Many times, we have datapoints from different organisations within the company, but it’s not at the same level where discussion can happen. EA is about providing a structure & approach, i.e. a mean, to obtain the data, which is what the business leaders want, i.e. bottomline.

    I think that’s the value…

  13. Hi Jenkins,

    We have similar goals.  Consistent data is the first step toward useful data.  EA certainly provides that framework.  I would suggest that EA also provides people who know how to draw interesting conclusions from that data, but clearly consistency is a prerequisite to that conversation.

    Thank you for adding your comment.

    — N

Leave a Reply

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

seventeen + four =

This site uses Akismet to reduce spam. Learn how your comment data is processed.