Todd Biske: Outside the Box

Back in October, I attended the Shared Insights EA Conference. I had never been to an Enterprise Architecture conference before, so I didn’t quite know what to expect. I’d been to various SOA conferences, which obviously have a lot to do with Enterprise Architecture, but there is a difference. David Linthicum has blogged in the past about the differences between the EA camp and the SOA camp, so if you’re interested in that, you can read some of his entries as that’s not the point of this discussion. The real point of this entry is strategic planning, which is important to both EA and SOA. The question is why is it so hard?

When I started looking into the EA discipline, I initially found Architecture and Governance magazine. I was surprised to see advertisements for Troux until I found out that the editor-in-chief works for them. The real reason for my surprise was that I had only known Troux as a vendor of a configuration management database. My first thought was what does CMDB have to do with EA? Then, at the Shared Insights EA Conference, nearly all of the vendors there also were CMDB vendors. Guaranteed, they had tailored products toward EA, but I’d venture a bet that they all started out in the CMDB space, so what gives?

I’m of the opinion that the EA discipline grew out of a desire to get some arms around the spaghetti bowl of technology that constituted the typical large enterprise. Note that the word “strategic” didn’t appear anywhere in that sentence. Hence, there is a connection to CMDB. Another word for what was going on was current state analysis, with the CMDB being a place where the results could be captured. This is actually a key first step for entering into a strategic planning effort, however, which is where EA should be headed.

As an analogy, let’s look at MapQuest. If my memory of the early days of the web serve me correctly, it started out as a pure mapping solution, and only later added driving directions. I could get a map of my current location, which would the equivalent of populating my CMDB. I could also get a map of some other location that I’d like to visit. This would represent some future state. Whether or not that could be represented in the CMDB is debatable, but also besides the point. If all I had was this map, however, I still may be no better off. If the map of my town and the place I want to go don’t overlap, I have, at best, only a general idea of how to get from point A to point B. What is needed is point A, point B, and the directions in between. Any practicing enterprise architect should understand that current state documentation, future state definition, and a roadmap to get between the two is what they are responsible for. Architects that are stuck in current state definition may help quantify the current problem, but not much more. Architects that are focused only on the future state wind up in an ivory tower, and architects who start throwing together an action plan without a future state in mind, well, who knows where that will take you, but it’s probably safe to say it is short-sighted.

So what are the challenges associated with this? Well, here are two. First off, people who excel at big picture thinking are normally poor at details. Likewise, people who are very detail-oriented are very poor at seeing the big picture. The tasks I described include both big picture thinking for the future state definition, as well as execution details for the action plan. The architect that can define the big picture may struggle in the finer details of the executable plan. That’s one. The other problem is that a strategic plan has many dimensions to it, as well as dependencies. Here’s an overly simplistic example, but it gets the point across. Let’s suppose that the engineering or infrastructure guys decide they’re going to stop buying infrastructure as projects demand, and instead develop a strategic plan for the technology infrastructure. Great, right? Well, it’s not that easy. While the organization may be able to define the current state of the technology, what happens when they try to define the future state? The infrastructure guys can probably get pretty far based on industry trends, but as soon as an attempt is made to turn that into an executable plan and assign some priorities, the applications that will utilize the infrastructure come into play. At this point, pressure is now placed on the application organization to think strategically. Again, there’s a certain amount of work that can be done based on industry trends and imitating others, but to be really strategic, it has to be driven by the business strategy. So, now the problem leaves the realm of IT and enters the world of the business. What’s the current state of the business, the future state of the business, and the plan to get there? That’s certainly not a question that a technology architect may be able to address.

At this point, the most mature companies for EA are now including a business architecture practice, whether it has that name or not. The strategic planning process is not an IT thing or a business thing, it’s an enterprise thing. While organizations may be able to achieve some limited success by simply following the paths of those before them as reported by the analysts, sooner or later, they’ll find that the barriers must be broken down to be successful.