Digging to China - Just Because You Can Doesn't Mean You Should

Imagine it - there you are, armed with a shinny, expensive, new architecture tool that your boss has just gone way out on a limb  for. You got the training, a bit of organizational momentum and a ton of great ideas about how this tool is going to enable some great architecture work. What should you do first? Current state is a mess and future state is not even a twinkle in management's eye. Following the logic that you can't build a new house until your current house is clean you do the sensible, pragmatic thing by taking on the architectural equivalent of house cleaning - documenting the current state.

Along the way, you conclude that one can't really have a clean house unless the foundation is inspected; up comes the floor, in goes the shovel. After a  month you're staring at a huge hole and a few of your coworkers, either by osmosis or coercion, have chosen to dig alongside you. You gain a bit of organizational recognition for your current state analysis / hole digging. Someone asks, do we really need a big hole? "Shut up and keep digging" you and your crew respond.

After a few months, it dawns on you that there is no foundation. With blistered hands, a huge pile of dirt in your once cleaned house and being no closer to "China", your teammates crawl up out of the hole, dust their britches off and find better things to do; mumbling about the damn tool that got them digging in the first place. Next thing you know, organizational priorities shift, people wince at the mere mention of the T-O-O-L. Annual maintenance is not renewed in the name of fiscal responsibility; you can forget about all that great architecture work.

This mostly true story has three points - 1) Doing current state first, then spending too much time on it is a trap [note 1] 2) it takes maturity in your EA practice to be able to successfully leverage a tool, and  3) acquiring a tool before you are ready makes the trap that much more tempting.

Simply put, Enterprise Architecture is about executing architecture analysis  on the enterprise to define a future state and roadmap to it.  The roadmap requires current state analysis, the questions are when and how much? Having an EA Tool, like System Architect, ARIS or Troux [note 2], makes it possible to dig deep into your current state defining the complex relationships between business processes, applications and technologies. But how much current state is needed and when should you do it? The opening story illustrates with tongue-in-cheek, a very real, and painful personal experience. Given a sophisticated architecture tool and the option to use it for current state or future state analysis, current state is very tempting.

Current state analysis is straight forward - you know at some point you have to do it anyway. You've wanted to "clean the house" for a while because architects hate dirty living. Future state analysis requires creativity, organizational politics and commitment that takes along time to build. Because of these factors, I'd venture to guess that many EA teams go for current state first, then, finding they have the tools, begin the journey to China. The trap comes when the complexity of detail available in the current state analysis tests the resolve of your team and the value of the effort. By the time you decide to stop digging, the diggers are soured to the tool (EA tools are complex and unwieldy still) and organizational infatuation has moved on to something else. Your opportunity to achieve your real objective, defining the future state and roadmap, is gone.

My first recommendation from this diatribe is to protect yourself with some principles (EAs like principles) , for example - just enough current state and after the future. When you are considering what to do about road-mapping, with or without a tool, focus on future state. Its hard, but its also the point of EA.

Current state is only useful in so far as it enables a roadmap and the business case investment in achieving the future state. While there is merit to documenting every conceivable relationship between technology, applications and the business , its not the primary benefit of EA. EA is about moving to the future, not configuration managing the present.

This brings me to my next thought about EA tools - don't forget basic EA truisms, like, "its about people, process AND technology". Truth is, EA tools are still emerging; none where conceived from the beginning as "EA" tools in the broader sense. It takes a significant amount of maturity in an EA practice to 1) avoid spending too much time on current state and 2) deal with tool quirkiness for the benefits offered. Make sure that your path to tool acquisition accounts for the people and process aspects of your EA practice and that you are really ready for the power and the pain an EA tool can provide.

My second recommendation for budding EA teams is that you stick with Visio, Powerpoint and Excel for a while. This will force you away from complexity because the tools don't support complex analysis and data management. In EA, simpler is often better because your non-EA executive audience wants a simple picture of the new house you are architecting for them not a hole in the ground.

Once your client (the business) is excited about the future state, then create detailed technical blue prints and conduct just enough current state analysis to justify the investment. By this time, you'll probably need that tool.
_________________________________________________
Note 1 - See pitfall number 5 from Gartner's top 10 EA pitfalls.
Note 2 - See Enterprise Architect Tool Selection Guide from the Institute for EA Development