The Enterprise Architecture Journey

As I talked about in last week’s post, I believe that Enterprise Architecture is all about getting organized and prepared, to help an organization reach its future goals. For those organizations who are just beginning their EA journey, this entails having an understanding of where you are currently, and what the effort will be to get you to your future state. Much like preparing to take a trip, you need to have a destination in mind. From there, you look at different areas of planning and ask various questions. How far am I going? What mode of transportation will I use? Where will I stay? How long do I expect to be gone? Will I need a map? How much will it cost me? Will I need a passport? What will the weather be like? What should I pack? All of these questions hopefully lead to the end goal of a pleasant trip.

Similarly, you need to ask these same questions when you begin to implement an EA:

  • Where are we right now? Or, what is our current state?
  • How are we structured? Or, what’s our charter?
  • What are our standards? Or, what are our business and technology guiding principles?
  • What’s our destination? Or, what will the future state look like?
  • How long do I expect to be gone? Or, what’s our timeline?
  • Will I need a map? Or, what does my roadmap look like?
  • How much will it cost? Or, what’s our budget target?
  • What equipment will we need? Or, what hardware and software and telephony will we need?
  • How will we stay on track? Or, how do we intend to govern/manage the project?

The success of an EA initiative depends on the answers to these questions. And much like a trip planner, a Common Requirements Vision bundles all these answers together. This information is then stored in someplace easily accessible, such as an online repository.

Of course, this analogy may seem a little simplistic, given the pace of business and the degree of complexity over the course of the initiative. Goals and priorities, and technology can change. This means keeping up a productive pace, and maintaining good governance. And much like a pleasant trip, the journey in the end is worth it – to the organization and its stakeholders.

Here’s to success in your individual and organizational journeys.


EA and Business Strategy

This week we wrap up the semester by reiterating the value of EA in regards to an organization’s strategy. As we’ve been discussing since our 871 Foundations class, the purpose of EA is to be the linkage between the business strategy, and how the rest of the organization executes against it. EA does this through providing an understanding the current state, and what is needed to be done to get to the future state. The future state should then be aligned with the business strategic goals. A favorite quote of mine begins with the phrase “organize yourselves, and prepare every needful thing…”. EA properly undertaken provides the organization and preparation needed to have a solid foundation for change. We talk a lot about the value of EA, and to me, this statement says it all.

When it comes to getting organized and prepared, a CRV is crucial. Here you’ll find the Strategy Statements, and the Business and IT requirements needed to implement them. I thought some of the example CRV’s provided by Gartner were a bit of overkill though, so I would simplify mine similar to a Fast Path CRV, with just enough information to provide context and a high level plan. In my experience, the business strategy is too seldom made available to the technical teams. Rarely do I have an understanding of how what I do in my role as a BA makes a difference to the overall picture. So I particularly liked the example matrix that was shown in this week’s lesson. It gives a simplified explanation of how the requirements tie back to the strategy, and I would find it very beneficial. If a requirement doesn’t tie back to the strategy, then it probably shouldn’t be a requirement.


What are your thoughts on CRV’s, Strategy Matrix, and EA in general? Are you using CRV’s or matrixes in your organizations? If not, what are you using to show the value of EA?


Doctrine and Covenants. (1982). Church of Jesus Christ of Latter-Day Saints.
Section 88 verse 119

Allega, P. (2006). Building a Fast Path Common Requirements Vision. Gartner. August

Bank XYZ Business Strategies to Change Requirements and IT Strategies Matrix [Gartner Strategy Matrix]. (n.d.).

Metrics – Avoiding the Pitfalls

This week’s course reading focuses on metrics, and how to introduce metrics to measure an organization’s foundation for execution. As I discussed in my last post, reports of how well you’re executing are only anecdotal if you don’t have metrics attached to them. Knowing the benefits of metrics, I was really interested in the Gartner article, “Why Enterprise Architecture Measurement Programs Fail: The Common Pitfalls”, by Deborah Weiss. In this article, she makes the argument that implementing a measurement program can lead to fear and mistrust of how the data is going to be used. I suppose there could be concern from the perspective of what it means when an organization fails to meet its targets. If those targets are not met, organizations are bound to add cost-cutting measures, which instill fear of looming layoffs and reorganizations. This is a very human concern, and one to which attention should be paid.

That said, there are other concerns that should be addressed before implementing a measurement program. Weiss points out some common causes of failure, such as failing to link metrics to business benefits, failure to link metrics to better decisions, focusing on too narrow of a scope, or conversely, making the scope too broad. However, from my reading of the article, there really weren’t any recommendations for how to avoid these pitfalls. Going back to our discussions of context, it seems to me that if you’re going to implement a measurement program, you also need to communicate the context for why you’re measuring the particular item. So my first recommendation would be to start with the “WHY”. From my personal experience, I’m more likely to buy into something if I have the context. If the context doesn’t make sense to me, that’s a clue that we’re either not addressing the issue correctly, or we’re addressing the wrong issue altogether.

Going back even further to our discussion of “Just Enough”, my next recommendation would be to not bite off more than you can chew. In a previous organization of mine, they prided themselves on “measuring everything”. That’s all well and good, but is it really necessary? Just because you can measure it, should you? Is the metric really going to provide value? It seems wiser that instead of measuring for the sake of measuring, we measure just enough, and only those things that correlate to value, and execution against strategy.

What about you? Any other recommendations for avoiding metrics pitfalls? I’d love to hear your thoughts.


Weiss, D. (2006). Why Enterprise Architecture Measurement Programs Fail: The Common Pitfalls. Gartner. December

Effective Leadership

Leadership has been much on my mind lately, especially having been on the receiving end of what can be politely described as “ineffective” leadership. So I was particularly tuned in to chapter 9 of “Enterprise Architecture as Strategy”, where it discusses Leadership, and the effect that leadership, or the lack thereof, has on a foundation for execution of EA.

There are several ideas that particularly hit a nerve with me in his chapter, and I will be focusing on the following: The need for Metrics, and the need for Positive Leadership.

One thing that particularly stuck with me was the need for measurement of execution. The idea being that you regularly review several potential factors for a foundation for execution. If your scores are on the low side, according to the metrics, there is a case for urgent action. Without measurement, all feelings one way or the other about an organizations ability to execute are only anecdotal. The truth is in the metrics.

The next idea that stuck with me was that leadership needs to be positive. Ineffective execution can be turned around when looked at as an opportunity to leverage existing capabilities. This means focusing on what the organization is good at, while using that as a starting point to identify where there is room for improvement. Included in the steps to improvement is investing in your people. Too many companies batten down the hatches and assume a defensive position, limiting training and education which could drive the necessary improvements. The thing is, it’s the employees who will be responsible for the foundation for execution. Without positive leadership and investment in your employees, the engagement necessary for driving improvement likely won’t be there.

I’d be interested in hearing your thoughts on chapter 9, and on leadership in general. Are metrics necessary? What about positive leadership?


Ross, J. W., Weill, P., & Robertson, D. C. (2006). Enterprise architecture as strategy: creating a foundation for business execution. Boston, MA: Harvard Business School Press.

Gap Analysis – The Rant

This week’s assignments centered around the topic of GAP ANALYSIS – which for me is a bit loaded. Frankly, performing a thorough gap analysis has never been a technique I particularly enjoyed. The term “slog” comes to mind. Personally, I’m one of those folks who likes to move on to the next idea, and move quickly, without wanting to tackle the details of how to get there (which I’m sure probably speaks volumes about my success or failure in my Business Analysis career). I’ve always been more about the “ideation” and less about the “implementation”. If I get too bogged down in the complexities, I’m less likely to move forward on something. All of which brings me back to the issue I’ve had from the very beginning of class, that of how to get to a future state (the ideation) in a timely manner, before the next idea is looming on the horizon.

Now, I realize that a gap analysis has its place in the process. And I am definitely on board with planning. But I think where we often err is when we try to get all of the minute details documented in triplicate. Take for example, buying a new car. Currently I drive a 2001 model light SUV. It’s working, and maintaining the status quo, but it has its issues. But I know that cars have changed a lot since then, engines becoming more efficient and the interiors having lots more comfort factor. So I decide to investigate getting something brand new. Now, I could approach the task by figuring out the exact specs of what I have now, and the exact specs of something new, reviewing various makes and models and price categories, to the point where I’m so overwhelmed with the research that I’ve talked myself out of the upgrade and decided I’m better off just sticking to the old reliable. This to me is why I struggle with the concept of current state and gap analysis. In effect we add more complexity and time to an already complex task, and the more we work on it, the more we discover, and the more expensive it’s going to be, etc., etc. The result being that the org finds itself unwilling to change because the change is too difficult and too frightening.

In class the other night, we discussed at some length the Kaizen Method, a technique which I find really appealing. The idea with Kaizen is that you complete your current state, future state, and gap analysis at a high level over the course of a few days. This gives the team “just enough” of an idea of what it’s going to take to get them there, when it might be delivered, and how much it will cost. Thereby providing the powers that be with enough information to make a decision and get started on the change. The key is that it’s timely, which saves the team from getting too bogged down. Ideally it also serves to keep the organization in a forward-thinking mindset.

I’d be interested to hear your thoughts. Do you face similar challenges with performing current state gap analysis? If not, why not? (And BTW – In case you’re wondering, yes, I still drive the Old Reliable.)

Standards, Strategy, and Value

Was part of a conversation this week where it was mentioned that the company has a goal of increasing membership to 1.5 million in the next few years (currently we’re at about 850,000). This shouldn’t seem like that big of a stretch, but it was also brought up that for a particular process, we did not have enough capacity to handle that increase. And, not for the first time, there was a concern expressed that we can’t plan for strategic goals if management doesn’t let us know what the strategy is. With his conversation in mind, the article I found most interesting in this week’s readings was Gartner’s “Making Technology Standards Work”.

The article points out that Enterprise Architects struggle to justify their position when there is not a link between EA and business benefits, and how this unfortunately is not at all uncommon. The article assures readers that goals are always documented somewhere, you just need to go look for them. It also quotes from a previous article entitled “Business Strategy Defines Architecture Value”, which claims that a strategy can be inferred by asking a series of simple questions:

  • What business is the company in?
  • What are the target markets for the goods and services that the company provides
  • What is the geographic scope of the strategy?
  • What is the time frame to accomplish these goals?
  • How does the company want to accomplish these goals?

Once you find the documented goals, or identify them from these questions, one approach is to opportunistically select projects that will tie in to the business goal, and insert EA into the equation.

All of which leads me back to the conversation I mentioned earlier. It occurs to me that this approach might be an opportunity to resolve the concern of not being sufficiently in the loop to plan for transformation projects. By paying attention to posted company goals, or asking the above questions, we could derive the company strategy. From there, we could use a particular process or capability to put together a gap analysis, perhaps using the Kaizen method for a more timely turnaround of the analysis, and to keep it at a high level. Then once the gaps are identified, begin planning for the future state.

I plan to approach a few people in the organization to see if there is enough interest and availability that we could kick something like this off, and see how valuable it would be.


James, G. (2006). Making Technology Standards Work. Gartner. February

Lapkin, A (2005). Business Strategy Defines Enterprise Architecture Value. Gartner. August



EA and Business Processes

For most of my life now, I’ve had an interest in processes, and how to make them more efficient. If you’ve ever read the old book “Cheaper by the Dozen”, and been inspired by “efficiency experts”, you know what I’m talking about. So of course, the topic I was most drawn to this week was the focus on understanding business processes. To me, processes are highly important for EA. First, process diagrams help us to understand the business context. But second, and for me just as important, is how understanding processes can help us get from the current to the future state.

Imagine yourself looking at a business process, and being able to see how to make it more efficient. Making the process more efficient could be as simple as a tweak to a business rule, or a user’s workflow. Or, you could find out that it will mean a code change. Or, it could mean a change in strategy and an accompanying change in technology infrastructure. You won’t know this without first understanding the process and pain points. As they say, a picture, or in this case, a process diagram, is worth a thousand words.

Several months ago, I sat in on a session where the Enterprise Architects demo’ed their business capability mapping – what capability was needed in order to keep the business operating, who the capability owners were, etc. I found this somewhat interesting, but the question that kept coming to my mind was, just because we had a capability, how did we know it was really the right capability? For example, my organization is a Health Insurer. One of the key capabilities of an insurance company is the ability to pay a claim. So yes, we can and do pay claims. But, are we paying claims efficiently, and in a timely manner, using the best methods? Because of the focus on current state documentation, that was something the Architects couldn’t really speak to. However, that is what I would have found more interesting, and for me, that is why understanding the process is so important to determining what the future state architecture will look like.

What are your thoughts on business processes, and their relation to EA?