Building your enterprise architecture program the right way

Computerworld - As a guest on the Federal News Radio program in Washington, I was being asked about my experiences in reducing IT costs. Joining me on the program was Jerry Davis, the deputy CIO at NASA, who mentioned that implementing enterprise architecture had really helped his agency develop a mature IT organization and control IT-related costs.

I had to agree, but the topic of EA is far more complex than that brief interchange suggests, and far more difficult to properly implement than most IT professionals realize. Yes, a properly defined and implemented enterprise architecture initiative can result in greater efficiency and lowered IT cost of ownership. But just like anything else in IT, there can be a huge gap between a great idea and the final implementation. Too often with EA, IT organizations miss the mark.

How so? I'll try to explain, and I hope you'll find my advice useful, whether you're only planning to implement an EA or you have already developed one that has been a disappointment.

The first thing to realize is that there are four main areas of EA, covering business processes, data, applications and technology. All four need to be adequately represented if your EA is going to be robust. Unfortunately, I have seen far too many EA implementations with non-existent business process architecture and practically no data architecture. The application and technology architectures are well worked out, but those are secondary architectures that support the business processes and data used by the business. It's the business process and data architectures that are foundational. Failing to adequately develop them will leave your EA effort flat.

Let me give you an example of what I am talking about. I was recently working for a client who wanted to streamline the billing process. I worked with the company to define the requirements and develop a vendor request for proposals for a billing system package. As part of the RFP process, the architecture group submitted various technology requirements and standards.

This technology architecture provided value in governing the technologies that would be considered. But that alone doesn't constitute an EA. Digging into business processes, I poked around the company and learned that a billing system was already being used in another part of the organization. I found that the application covered about 85% of the business requirements and that we could expand its use with no new licenses or hardware required.

When I presented these findings to the client, we determined that the business process would have to be changed a little, but the change was amply justified considering the cost savings at hand.