Building your enterprise architecture program the right way

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.

As it turned out, the business process changed a lot, but it was all for the better. As we examined the business processes of the two departments, a senior manager asked, "Why do we have two separate departments doing basically the same business function?" Great question!

This simple question led to a simple and effective business process change that resulted in streamlined operations and more effective management and governance of the billing cycle. Through the discipline of business process architecture, we discovered duplication of work, and the application architecture function determined that new software and hardware were not needed.

The savings for this company were impressive and resulted from EA in action.

The data piece

I have also been involved in many data warehousing and data integration and migration activities that benefited tremendously from enterprise data architecture. Working as a data architect, I have been able to look across the data landscape in an enterprise and identify opportunities for data reuse and consolidation. These efforts resulted in hundreds of thousands of dollars in annual savings through the elimination of redundant data, databases and ETL processes. In addition to saving money, companies benefited from improved data quality simply by removing redundant data stores.

These examples may seem small, but they are not trivial. As I discussed with Jerry Davis of NASA, having an EA program is a necessity. It allows an organization to effectively manage current technology while planning for intelligent growth of future technology investments. It also allows a company to identify and eliminate unnecessary waste, thereby reducing costs.

If you are considering launching an EA initiative, take your time and plan well. Don't go it alone and reinvent the wheel. Others have charted these waters and can offer both inspiration and insight. Some of the resources available include the Zachman Enterprise Architecture Framework and The Open Group Architectural Framework (TOGAF). I have used both and highly recommend starting with either one when defining or enhancing your strategy. You may also need some outside help to jump-start the program or gain insight into the reasons why your EA effort is not producing the value it should.

Most importantly, however, is to remember that enterprise architecture is much more than just applications and technology. The primary disciplines of your program are business and data architectures. If you include these, you are sure to build on a strong foundation and give your EA program chance for success!

Ken Karacsony has over 16 years of professional and consulting experience in IT. He is an author and conference speaker on a range of IT-related subjects. He can be reached at

Copyright © 2009 IDG Communications, Inc.

Shop Tech Products at Amazon