The Value of Enterprise Architecture

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

Comments

• Anonymous
  October 03, 2009
  The comment has been removed

• Anonymous
  October 03, 2009
  The comment has been removed

• Anonymous
  October 04, 2009
  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?

• Anonymous
  October 04, 2009
  The comment has been removed

• Anonymous
  October 09, 2009
  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). Regards,

• Anonymous
  October 09, 2009
  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.

• Anonymous
  October 11, 2009
  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.

• Anonymous
  October 13, 2009
  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.

• Anonymous
  October 13, 2009
  The comment has been removed

• Anonymous
  October 20, 2009
  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. Regards The Enterprising Architect

• Anonymous
  October 21, 2009
  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

• Anonymous
  November 02, 2009
  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...

• Anonymous
  November 03, 2009
  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