The Value Proposition of Enterprise Architecture

The value of a documented enterprise architecture (EA) is to move an organization from complicated and ossified to complex and adaptive. It allows an organization to: · Respond to, or even better, anticipates changes in the environment (markets, economics, regulatory, labor, etc.) · Create new products and services that meet those environmental changes, · Develop…

The value of a documented enterprise architecture (EA) is to move an organization from complicated and ossified to complex and adaptive. It allows an organization to:

· Respond to, or even better, anticipates changes in the environment (markets, economics, regulatory, labor, etc.)

· Create new products and services that meet those environmental changes,

· Develop the processes to support those changes, and

· Build the information technology (IT) and data infrastructure to support those processes.

It is the reverse of how many organizations operate today, with the data and IT infrastructure driving the processes, which, with some serendipity, may only adapt to past changes in the environment, and are usually implemented far too late for the organization to capitalize on the environmental changes. More likely, the changes are discordant with the environmental changes, and at best, waste money and time, and at worst, make the company less likely to stay ahead of its competitors, and extremely, more likely to fail.

What are the factors that enterprise enterprise architecture? Over the last two decades, several models have evolved. John Zachman is generally credited as first addressing the need for EAs in 1987. The Zachman Framework provides a taxonomy for the artifacts that are needed to build the enterprise architecture by target audience (planners, owners, designers, builders, programmers, and users) and the issues that need to be addressed (data, business rules, governance, markets, etc.).

Zachman's model influenced subsequent approaches to enterprise architecture. At a basic level, most of the models, or more precisely, meta-models, address the following components:

· The environment: inputs, ie, markets, economic factors, and regulatory constraints.

· Business architecture: the organizational mission that responds to the environment, and the rules and processes for meeting that mission.

· Information systems architecture: specifies the overall IT model that supports the business architecture.

· Data architecture: supports the information systems architecture by eliminating the data required by the organization, the metadata that describes the data, the delivery and storage mechanisms, and analytics that evaluate the data.

· Data delivery system or IT infrastructure: defines the software, hardware, and communications that implement the data architecture.

· IT governance: assures that the investments in IT generate business value and mitigates the risks that are associated with IT.

There are other methods for articulating an EA along the Zachman Framework. These include the Department of Defense Architectural Framework (DoDAF), the Federal Enterprise Architecture Framework (FEAF), and The Open Group Architecture Framework (TOGAF), among them. How an organization decides to document its EA less important than simply doing it: as long as the selected methodology communicates effectively to the intended audience, it will work as a way to identify pain points in the organization, and allow for a way to design the changes to mitigate the problems the pain points create.

Recommendations and Conclusion

Articulating an enterprise architecture for an organization moves this notional construct to a pragmatic one that addresses the specific needs and business model of the organization is not trivial. First and foremost, change must be driven from the highest levels of the organization: the chief executive officer, chief information officer, and company board of directors. Without support from the top, the effort is doomed to failure: entrenched interests that are anathema to the goals of an EA will work to sabotage it, the initial exclusion will wear off, and the effort will wer, and the time and financial investment to develop the architecture can be discouraging. Further, many, if not most corporations, lack the expertise, time, and objective eye necessary to build an effective enterprise architecture. Bringing in outside expertise is often essential for success. Beside the technical and business knowledge required for building an enterprise architecture, experts can provide additional benefits:

· Providing and implementing a process for developing the enterprise architecture;

· Scaling the effort and developing an incremental approach to the enterprise architecture development;

· Bringing an unbiased eye to the existing enterprise and making tough recommendations for change

· Acting as a facilitator for managing competitiveness interests in the development of the architecture;

· Acting as a champion for the process and articulating the consequences of not moving forward;

· Assisting the organization implement the enterprise architecture;

· Help document and write the intensive number of artifacts necessary for the organization's enterprise architecture.

Without the effort to define an EA, businesses will continue to run the risk of increasing complication, ossifying their structure and inhibiting their ability to adapt to rapidly changing and hostile environments, with fickle and demanding consumers, aggressive and agile competitors, and constantly changing regulatory and financial environments. With an EA, a business can transform itself into a complex system, able to adapt its processes and systems to rapid and dramatic changes to its operating environment, and construct the tools to help anticipate and shape those changes to stay ahead of the competition.