In the response to my most recent post on Enterprise Architecture, Brenda Michelson posted a very interesting question:
I think the number one question Enterprise Architects and Enterprise Architecture Practices need to answer is “What do we contribute to the business”. What is the ultimate outcome of Enterprise Architecture? And therefore, what would be missing (or more difficult) without Enterprise Architecture – Brenda Michelson
Nothing will focus your mind on a process better than considering the output. I’ve been focused on that notion quite a bit lately. In meeting after meeting, in discussion after discussion, I’ve been thinking about the output of EA. I am in “violent agreement” with Brenda on this point: we must focus on the results, and more importantly, we must focus on what would be different in the absence of Enterprise Architecture.
- If we provide alignment, does that mean that without EA, there is no alignment? Or is there bad alignment? Or is there random alignment?
- If we provide information for good decision making, does that mean that without EA, there is no information for good decision making? Bad information? Incomplete information?
Business people care about the health of their business. Answering the questions above in the wrong way will produce a declaration about the value of EA that is condescending at best, and downright insulting at worst. “What do you mean, our information is not good enough! Who the heck are you, anyway!” Not a fun conversation.
The Mission of Enterprise Architecture
In order to understand the difference we make, let’s create a mission for Enterprise Architecture. Let’s answer the question: “why are we here?”
In my experience, EA exists to do two things:
- to Envision an organization that includes the strategic and operational changes that leaders require and demand, and
- to Guide changes to the structure of the organization, and the actions of the business units themselves, so that the vision becomes reality.
To Envision and to Guide. Sounds easier than it is.
- First, the business leaders have to be clear about the changes that they are demanding. EA has an effect in this space by helping business leaders to describe their business goals in an accurate and actionable manner. Without EA, business leaders may not have an internal team with the charter of insuring actionable strategy.
- Second, you have to have a good understanding of the organization, so you can focus resources on the changes that are actually needed. We have an effect by helping to identify the areas of the business that need change in order to fulfill strategic desires. There may be a long list of “problems” in a business. EA is there to assist in selecting the right ones to go after. Without EA, business leaders may not have an internal team with the charter of finding the specific areas for change that are needed to meet the needs of a strategy. The result would be the frequent loss of energy, time, and money as key dependencies go unaddressed.
- Third, you have to have a good system of governance to insure that approved business plans are not thwarted by the currents of time, conflicting initiatives, and poor communication. Without EA, business leaders may not have a consistent and clear mechanism for reporting progress in changing the organization to meet the needs of business strategy.
- Fourth, you have to have a grasp on the potential for innovative application of processes, enterprise relationships, new business models, and new technology trends. This is a serious source of insight for the formation of new business strategies, both at the high level (new business models) and at the detailed level (new efficiencies through the application of technology). Without EA, business leaders may not have an internal team with the charter of evaluating new ideas and business models with the goal of bringing new approaches to the table.
- Fifth, you have to have the ability to provide repeatable process guidance and standard methods designed to insure that specific actions by individual contributors are likely to produce the intended outcomes. (Keeping the devil out of the details). Without EA, business leaders may not have a dedicated internal team focused on providing “instructions for change” to the individual contributors in the organization where their lives are most impacted.
Now comes the fun part… you will notice that I underlined the word “may” in each of the statements above. Each of these needs may already exist, in some form or another, in your organization. Those needs could be distributed in different places, and can be inconsistently performed. Consulting agencies make a great deal of money filling in these roles on an occasional basis for large companies. Business leaders may have a single person or a small team whose job is to solve for a specific set of problems that looks an awful lot like a collection of these needs.
So when EA comes on the scene, there is a great deal of gentle negotiation. EA team members cannot simply “jump in” and take on strategic roles that are being filled by another trusted advisor. They have to provide value, often to the effect of strengthening those other advisors. We can often be most effective by making other people more effective. We can be more valuable by making other people more valuable. Over time, if we have earned the right to be direct players, instead of indirect players, we will be trusted to do the work that so many folks describe as Enterprise Architecture.
That takes time, patience, and careful awareness of how the “lines of influence” work. It is not a job for the novice.
Brenda made a specific proposal in her response that I’d like to address in context of this blog post:
I propose we think of EA as a business and work backwards from the desired outcomes — ease of change, reduction of complexity, and better technology investment return. To achieve those outcomes, what capabilities, policies, people and tools are required. And then, how would we describe (classify) that? — Brenda Michelson
With as much respect as I can muster, I find that I must disagree with Brenda here. I would not frame the value of EA as “ease of change, reduction of complexity, and better technology investment return.” Those are each “operational strategies.” They are NOT universally applicable to all companies. Some companies will not be focused on reduction of complexity. I agree that there are persistent underlying problems that need to be addressed, and that EA impacts them, but I would not use that impact to justify EA.
Even within a company, many business leaders would not find these underlying problems compelling. If I was to ask a business leader (outside the COO) about the relative importance of an operational strategy like “reduction in complexity” compared to “increase our market share in Asia", I can easily predict their response. If I was to ask the COO about these strategies, he or she would probably L
OVE them, but would put them below “increasing market share in Asia” in priority. It is not enough to be a supporting function for a supporting function.
On the other hand, I could say “to increase market share in Asia, we must provide a mechanism that encourages our partners to move more of our products, and the root cause of partner resistance is the price and difficulty of using our sales model. W can address these concerns by leveraging consistent information across channels and, through process simplification, reducing the cost of our products to suppliers. The resulting efficiencies, passed on to the partners, would reduce costs and improve partner experience, thereby producing a greater market share.”
What I did was use the business strategy (market share) as a “compelling event” for addressing the persistent underlying problems of ineffectiveness, inefficiency, complexity, and resistance to change.
Talking about the persistent underlying problems is useful when we speak to our peers. It is simply not compelling when justifying the existence of EA to the people who decide our fate: executives.
The Key Capabilities of Enterprise Architecture
Back to the list above, let’s pull aside those effects that I outlined, and as Brenda asked, let’s look at the capabilities demanded by them.
1. Capability: Strategy Formation – EA will perform a key role in advising business leaders on the formation of actionable strategy. That requires EA to
- (a) be able to define what an actionable strategy looks like,
- (b) have trained resources able to assist with reviewing business goals and offering insight and guidance on making them more actionable, and
- (c) have the positioning within the organization to play a role in strategy development.
2. Capability: Comprehensive knowledge of the opportunity areas of the business – EA will leverage a rich base of understanding of the functions and structures of the business in order to focus business strategies on the key problem areas that need to be improved. That requires EA to
- (a) maintain a rich base of business knowledge including information about business units, processes, technologies, locations, business products, partnerships, etc,
- (b) have a process for quickly connecting business strategies and goals to the areas of the business needing improvement,
- (c) have people trained to collect the needed information for the production of strategic roadmaps indicating the order, timing, and scope of specific initiatives, and
- (d) have the positioning within the organization to insure that the resulting roadmaps can influence the process of approving and funding those roadmaps.
3. Capability: Governance processes – EA will influence the performance of business governance to insure that the projects that are performed reflect the strategic roadmaps identified in earlier stages. That requires EA to
- (a) have direct contribution to, and accountability for, the development of a corporate governance process,
- (b) the resources able to evaluate progress by various teams and to determine if their progress meets the requirements of the roadmaps, and
- (c) the positioning within the company to point out the flaws and impacts that may result when a team misses its goals.
4. Capability: Innovation generation – EA will be part of the system of thought leaders that assist with the generation of new business strategies, especially as it applies to the application of technology-focused innovations in the marketplace. That requires EA to
- (a) have a regular process for collecting and examining ideas from both external and internal sources with the ability to produce an estimate of the impact to the business if that idea is adopted,
- (b) a mechanism for funding the deeper examination of promising ideas through proof-of-concept development and business projections to validate the feasibility of new ideas, and
- (c) the positioning needed to expose new ideas to strategic leaders on a regular basis.
5. Capability: Standard and Policy Governance – EA will be part of the system of change agents that develop specific instructions for changing the behavior of individual contributors and reviewing their behaviors over time to insure that changes have taken hold. EA will be accountable for guiding changes needed for strategic projects, a subset of all change projects and will likely represent only one source of policy and standard changes. This requires EA to
- (a) have reasonable and comprehensive knowledge base of company standards and policies that they can work with,
- (b) have a process for examining strategic needs and developing standards necessary to ensure that strategic decisions produce long-term desired outcomes across a wide array of roles, behaviors, and systematic activities.
- (c) have the necessary position to provide feedback to teams and business groups on their performance of business policies and standards in a manner that produces better compliance in the long run.
How to use this post
In this post, I describe the capabilities needed by an EA team in order to fulfill the mission that I outlined above. Clearly, if you disagree with the mission statement, you will expect to see different capabilities highlighted. I would be surprised if any EA team adopts the mission statement above without tailoring it to your own organization. I want to be clear: our own internal Microsoft EA mission statement is different from the generic statement above.
However, this can be useful analysis in producing your own mission statement and statement of capabilities. Your list of capabilities will be different than mine! That’s OK. Once you have produced that statement of capabilities, you can set out to measure yourself. You can look at each capability and determine if that capability is mature in your organization.
By determining the capabilities you need, and evaluating the capabilities you have, you can produce your own roadmap to a more mature EA organization. In doing so, you will develop your own business model illustrating the situations where you can (or must) be indirect, supporting other business units or business functions, in order to have the desired impact. That is your business model.
Your value proposition, for your EA team, will be unique, especially at first. Until your organization takes a dependency on Enterprise Architecture, and begins to establish trust, and your team develops the position needed to have the influence you should have, your value proposition will not be “ideal.” Your value proposition will evolve, probably on a frequent basis, until you hit the “sweet spot” that is specific to your organization, business culture, and leadership climate.
If you do decide to use this kind of analysis for developing the value proposition of your EA team, I’d love to hear about it! Please share.
8 thoughts on “The Mission, Capabilities, and Business Output of Enterprise Architecture”
Allow me to be devil's advocate here and attempt to boil down these capabilities to their essence:
Capability 1 – Governing/reviewing other people's strategy
Capability 2 – Gathering information
Capability 3 – Do some governance
Capability 4 – Capture other people's ideas, look into them a bit
Capability 5 – Do some more governance
If you take a step back and look at it, do you really believe this is a great value proposition to start selling with?
For me it feels like EA creating things for its own ends more than anything else. How does any of this really add value? What can I point at and say 'EA made this happen' ?
Nick.. great post.. I will be pondering over the days to come..
Mike, interesting perspective.. let me see if I can add some fuel.. (I am not trying to put words in Nicks mouth.. just adding my thoughts)..
Capability 1 – I agree that it seems a bit vague.. but I think the key is the term "Actionable". My org tends to think a bit too high level when it comes to building a strategy. Typically, their strategy is a whitepaper that some business partner has written to describe a problem and a very, very broad recommendation. What I interpret Nick to be saying is that the EA deliverable is the HOW around the WHAT that is described in that whitepaper. Who else could do that and make sure that not only is that WHAT made actionable, but that plan doesn't interfere with the larger set of initiatives happening all around us.
Capability 2 – Gather Information – This one seems a bit more clear. Identifying the real problems plaguing an organization is one of the HARDEST things I have to do. How many times have I sat on a call and asked "why" do you want this specific requirement, only to be finally informed that the business partner asking for that specific thing really doesn't even understand the business process they are trying to create/improve. The EA deliverable here is more input to the final deliverables associated with the HOW described above. Not only that, we are "the keepers of the tradeoff list". This is where we will say "Mr. Businessman, this is WHY we solved this problem, this way".
Capability 3 – I think governance is easy. Who else can do it? Is there a specific organization charted to perform this role? I personally believe the EA group is the owner of this charter. I bet I am simplifying too much, but I feel like the deliverable here is the definition of the governance process, and when that is complete, performance of that process.
Capability 4 – This one is less ambiguous to me as well, probably only because I am currently doing some new capability development work. The EA deliverable here is the capability definition and roadmap (I think). We are the ones that see the opportunities for improvement. We are the ones that can identify the change needed to enable the execution of business strategies. It is our responsibility to take that information and generate the ideas (in a repeatable way) that will be made clear to the business through our "thought leadership" (whatever that means). All kidding aside, our deliverable is information and insight that our business partners can't get from the 50000 foot level. Who else is going to do that?
Capability 5 – we have all said it.. but RTFM. The challenge is never going to be reading the manual. It is, and always has been.. writhing the manual. EAs are the only group (in my experience) that isn't bounded by a specific project or a specific business unit, such that they can actually have the knowledge needed to generate the policies and standards that will bind those groups without the same level of visibility. Who is going to define the principles and reference architectures that ensure all of the projects being generated to implement a specific business goal will both align technically and strategically if the EAs aren't there?
I hope I didn't sound completely stupid here.. I just thought Nicks post was a good one and Mike brought up an interesting viewpoint. Take it for what it is worth..
Dang, now my coffee is cold again..
@Mike: Mitch did such a fine job of responding, I'm not sure what to add. (Kudos to Mitch).
How odd that you look at the list of capabilities and then question the value proposition. They are different animals.
The value proposition is a core part of the business model. (See the Enterprise Business Motivation Model). Required capabilities are distinct from the value proposition. You need the required capabilities to deliver the value proposition.
To answer your question: I would not justify EA on the basis of the capabilities. I would look to the value proposition. In this post, I used the meme of a "mission statement" to describe that value prop (an inexact parallel at best, but I'm doing my best to respond to your question).
We are here to consider all of the relevant information, in a rigorous manner, to produce a realistic, attainable, and valuable vision for the future structure and capabilities necessary to meet the strategic goals of the enterprise, and then to guide the organization in the necessary manner to make it real.
Without the EA role and without EA rigor, success in that endeavor is hap-hazard. Fits and starts. Other folks can and do fill that role and we MUST respect and support them. Where no one fills that role, we need to perform. EA is NOT necessary for success but we are necessary for timely and effective execution. EA speeds the delivery of a successful corporate structure and in a highly competitive marketplace, speed matters.
As far as the capabilities go, Mitch did a fine job. No need to repeat or correct. (Hey, Mitch… if I ever get a chance to meet you, I'll buy you a nice hot coffee :-).
No capability for architecture development? Hmmm
What about Risk?
@Bill, The EA team is part of a larger organization. In most companies, including ours, Solution Architecture is a function primarily associated with another organization. Our Enterprise Architects arose through Information and Solution Architecture ranks, and are familiar with the required skills. That said, does EA need a capability for developing a solution architecture, or would it be reasonable for EA to take a dependency on another org for the solution architecture? I think there are many opinions, and from an industry standpoint, it is not clear that there is a single winner. I did not include solution architecture as an EA function because I'm assuming the existence of solution architectural functions outside of EA that will take the primary onus of responsibility for that capability.
What about Risk? Should there be a risk management capability within EA? I would think that capability is similar to solution architectural development in that EA could develop risk models and perform risk evaluations, using those models… or EA could participate in risk models created by other teams, where EA is simply evaluating those systems on the basis of their compliance with specific enterprise standards designed to reduce risk. In that second context, MSIT EA plays a role as part of the larger organization. We modeled this after other companies who were successful in integrating their EA and Project Management risk review practices into a single "light" process. In that context, EA doesn't, of itself, have a risk management capability. We simply have a part to play in another team's risk management capability.
These are points of negotiation, of course. As I mentioned, EA has to "fit" into an organization's existing socio-political environment. If, in your company, EA includes a core team responsible for solution architecture, then in your company, Architecture Development is a key capability of EA. It is part of the larger mission. That much is clear. And you are correct to point out the lack of clarity in my post.
Obviously, my question wasn’t hard enough as you provided a thorough and insightful response seemingly within moments of my submitting the comment. Consider me jealous.
On our “disagreement”, I admit to abstracting up without showing my work. I (attempted to) call out common outcomes of enterprise architecture practices. I completely agree that outcomes will vary by situation.
As well, if I were selling an EA Practice, I would package those outcomes in the context of business priorities as you suggest: “increasing market share in Asia”.
However, if the outcomes of EA are tied too closely to a given business priority, there is risk of being perceived as transient. Executives might question the need for an EA organization, especially if the capabilities can be provided by individuals on their staffs (your “may”) or by consulting organizations.
So, this brings me to my next question. Do organizations need Enterprise Architecture Teams? Or, only access to (internal and/or external) enterprise architecture capabilities?
I realize this one might be best discussed in a bar.
Thanks again for the conversation,
I like to say our EA mission is to maximize business value, minimize business risk, and speed business change. I think that we do this through three major EA capabilities: inform, influence, and innovate. Just my 2 cents without writing a book.
Hard to disagree with the goals of maximizing business value, etc. In my team, we sometimes refer to a statement like that as "Mom and Apple Pie." To disagree with those goals would be like saying we don't like Mom and Apple Pie.
That said, your statement reads to me as a list of goals. I disagree that a mission statement is the same as a set of business goals.
You also generalize the "required capabilities" of EA to three words: inform, influence, and innovate. So, how mature is your EA team in the "inform" capability? How important is the "influence" capability to business strategy? To answer specific questions, you may need to refine that list of required capabilities a bit. Who are you informing, and who are you influencing? Why do they care about innovation, and what kind of innovation are you accountable for?
It helps to be more specific. I don't disagree with your generalizations (like I said, they are Mom and Apple Pie), but I cannot use them either. If I cannot use them, they are not practical. One goal of my blog posts is to share practical, useful information and ideas with my friends in the world of EA. Hence, my somewhat longer, somewhat more specific, level of detail.