The rise of Enterprise Architecture (EA) should be no surprise to any of us, and yet every day businesses either opt out of deploying enterprise architecture, or can't deploy it effectively. While the Industrial Age was characterized by process-based advances such as assembly lines and schematics, the Information Age isn't characterized by the rigors of engineering that richly founded the manufacturing surge in the early 1900's. As a result, nearly 40% of existing enterprise architecture programs will be stopped by 2010 because of poor execution, according to analysts at Gartner.

In the next few years, however, the surge toward enriching businesses with the value of information will create the need for long-term investments in enterprise architecture. This article will explore the ways that EA can positively impact businesses, and how IT managers can successfully deploy EA in their infrastructure.

Realizing the Impact of Enterprise Architecture on Business
To keep our parallel to manufacturing going, think of a plane flying through the air, a product of manufacturing. The process that produced the airplane requires detailed blueprints that will become the basis of an assembly line to create the aircraft. With Information Technology, this same principle applies to the creation of a 10K annual report. For those that run publicly held companies in the age of the Sarbanes-Oxley Act (SOX), this is an annual report that states the company's activity. This report is the product of the data warehouse manufacturing process. Does your corporation run this assembly of the report like the creation of an aircraft? Or is it like most companies that still leverage a string of spreadsheets and macros that five people in the accounting office call a financial report? It takes more than a simple order of data collection for large corporations like GE or 3M to create balance sheets so they've instituted systems to architect their Information Systems to assist in proving their compliance with SOX.

Architecture not only assists in creating valid reports, it also helps a business align its goals and strategies to the processes and systems. The rise of Business Process Modeling (BPM) in the 80's and 90's has evolved into Process Orchestration and now Service Oriented Architecture (SOA). This is a maturity cycle, much like how assembling an aircraft one piece at a time evolved, that has proven to business that IT can function in a manufacturing capacity for knowledge workers. Therefore, there's been a rapid improvement in the implementation of new business processes due to this mature loosely coupled service implementation provided by SOA.

Now it's time for the entire business to realize this level of maturity for all of its knowledge workers. This is one of the primary promises of Enterprise Architecture, the enablement of all aspects of the enterprise to participate in the creation of the architecture that runs the business.

Supporting Project Planning with EA
One of my favorite customer interviews recently led me down a path of discovery that proved to me that a good architecture group is worth its weight in gold. This customer was given the business objective of reducing the time customer service spent on the phone retrieving information about a shipment. The CRM process meant collecting data from four separate business units to get the current status, which could take minutes. Each of these business areas has mature information architectures and so when the executive team required a consistent customer face, they were ready with some answers.

It would take two more weeks of analysis before the application architectures could be sketched out on a white board to see where the commonalities in the units were to change the current retrieval process. What took hours for the information team took weeks for the application teams as a result of leveraging a structured architectural approach. Now that this process has resulted in a common customer repository for the business, the application teams are required to show how they interact with this system by communication diagrams that are linked to their activity diagrams in UML. This can be seen in Figure 1 at the lower-right corner linking to the center.

The real reason I wanted to cover this example was when the next business change came along. A new smaller company was acquired as part of its distribution network and it had to be integrated. Due to the efforts in customer modifications, the teams understood how to review architectures to look for the gaps, resulting in a project plan that effectively targeted the integration in a matter of weeks, rather than months. This result is all due to the enterprise architecture approach bringing information, application and business modeling efforts together with high-level communication diagrams.

Risk Management and EA
In any business, there's always an aversion to risk when it can be mitigated. This fundamental principal can be translated into project management in multiple ways, but with respect to Enterprise Architecture, there are more direct and tangible results.

In most architecture tools today, there's a level of metadata underneath all the artifacts that can be seen in the model. This metadata lets an architect quickly determine all of the objects that interact with this object. Note that I said architecture tool, since there is a rising demand in these tools for a layer of metadata underneath the objects they're drawing, providing links to other objects and models. In some circles this is called impact analysis, in others it's risk assessment, but both terms help us understand how to address risk in a changing system.

In Figure 2, there's a clear view of how to assess the impact of a change request on the capture order process. This impact view, which is generated from the metadata in the diagram, is a key output for assessing the risk of modifying that process. The different areas in the resulting diagram show high- and low-risk components, so an architect can scope a change that can avoid impacting areas of high risk, if possible. If it's not possible then another change assessment can be made to those other objects through an iterative process to determine the scope and complexity of the change request.

Within the past five years, there have been more decisions made not change a working system due to the risk that the change would pose to business operations. Now that enterprise architecture is capturing all of the relevant communication flows in the systems, it's easier to assess these changes more accurately.

EA Is a Natural Evolution
In 20 years, I have a hope that Information Systems managers will look back at our struggles and not be able to comprehend why we struggled to complete projects in a certain period of time at a specific tolerance for risk. They'll have the results of our labors, just as the automotive assembly line manager can't understand why Henry Ford built one car at a time. Once business embraces the need to structure its creation of information more rigorously, the people that manage the creation of the information better be ready to embrace Enterprise Architecture to save themselves from the folly of those that have struggled in the past.