How To Avoid EA Failure

by Jeff Tash, ITscout

I’ve been a long-time critic of enterprise architecture gurus -- people like John Zachman and META Group’s George Paras -- because of their insistence that EA be approached, literally from the get-go, as a comprehensive, top-down, long-term endeavor. I believe EA projects can significantly improve their likelihood of success if approached incrementally, where value increases and risk decreases at each stage of development.

I well understand where Zachman and Paras are coming from. I recognize their desire to tie technology implementation and usage to critical business drivers. I fully appreciate the importance of trying to maximize the value of IT utilization while at the same time minimizing IT costs. However, I’ve seen way too many cases where EA initiatives fall into the trap of becoming massive, expensive, high risk efforts because of the complexity involved in trying to comprehensively account for all technology implementation and usage within an organization.

I’ve repeatedly asked for an opportunity to present my dissenting opinion at ZIFA and EAC -- conferences chaired by John Zachman and George Paras, respectively. Unfortunately, every time I’ve submitted a presentation abstract, my request has been declined. I’ve been told by both of these conference chairmen that their audiences don’t want to hear from any speaker who disagrees with the position that EA must be firmly and exclusively rooted in knowledge of business strategy in support of IT initiatives.

Let me restate my position clearly and unambiguously. I think it’s a huge mistake to ask people to embark on a long complex ambitious quest that promises little, if any, tangible reward prior to completion. I believe that’s the primary reason why over 60% of Global 2000 IT organizations have yet to pony up sufficient investment funding to implement successful EA programs. It’s like dieting, or quitting smoking. People are more likely to begin a process, and stick with it, when they can move forward slowly, gaining confidence and building on success one step at a time.

What’s my advice? Avoid undertaking a full-blown EA effort before you’re ready. Start, instead, by making your initial EA objectives simple, short-term, inexpensive, and low risk. Initially, your primary goal should be to produce targeted results quickly. EA need not be an “all or nothing” proposition.

Rather than approaching EA from the traditional, top-down, business-oriented focus, I recommend starting from a technology perspective. IT needs to first get its own house in order before trying to tackle the larger issues of aligning itself with business strategies.

Many, if not most, IT organizations do a horrible job of communicating with the people inside their own enterprise who build and/or run application software solutions. Look at your own company. How well does your IT group describe, communicate, and explain its own standards, architectures, and strategies?

Don’t worry about getting everything defined up-front. Your overall enterprise architecture will emerge over time, evolving to fulfill new requirements and take advantage of new technologies as appropriate. Just do enough to get your team going. You don’t need to model every single detail. You don’t need to be perfect. You certainly don’t need to be complete. Iterate, iterate, iterate. Constantly solicit feedback. Listen to your users. Document, but don’t over-document. Move forward judiciously. Gain trust.

I can’t stress strongly enough the importance of trust. I worry that too many business executives have already lost confidence in their IT organizations. There’s a prevailing attitude in many a corporate boardroom nowadays that the best way to succeed with IT is to appoint a “business person” as CIO -- not a “technologist.” After all, in their mind, solving the really tough technology problems is not the CIO’s job. Rather, those technological issues are seen as the responsibility of their firm’s strategic software partner -- whether it be SAP, PeopleSoft, Oracle, Siebel, or whomever. I wonder how well these business-savvy decision-makers truly understand how these software vendors, whose coattails they’ve latched themselves onto, are dedicated to keeping their products complex and expensive in order to hold their customers hostage to their own self-serving business models.

I also don’t see how IT execs are going to regain trust through today’s latest management fad -- offshore outsourcing. Sending IT jobs overseas is a cost-cutting measure intended mainly to impress financial bosses. Employing workers in foreign countries who will work for dirt cheap wages will save money in the short-term. But unless IT significantly improves the way in which it communicates and explains standards, architectures and strategies to the people staffing these new overseas IT centers, then those workers aren’t going to be any more successful than their stateside peers.

So, what’s the answer? Start slowly. Begin by leveraging the “terrain” upon which your EA foundation must be built. Focus on the “people side” of existing technology investments. Most IT organizations have a wealth of valuable knowledge that goes underappreciated and underutilized because it’s not well communicated or understood by a larger audience. Harness your existing knowledgebase that currently exists only in pockets inside the enterprise -- either by key individuals or small groups of technology teams. Pull together the many pieces of disjointed information that already exists throughout your organization in a variety of different formats, and make this valuable knowledge, derived from experience, readily and widely available in an easily accessible manner.