Issue 2

The Enterprise Architecture Planning (EAP™) methodology and model are a seminal part of the common body of EA knowledge that remain relevant in their own right and which have influenced a number of other current frameworks, methodologies, and best practices in the public and private sector. However foundational, the EAP™ approach has become, according to some EA practitioners, somewhat dated in its content, presentation, technological examples utilized, and in its relationship to some aspects of how EA is being practiced today. The intent of this article is to refresh one part of the EAP™ approach, the famous EAP™ model (also known as the wedding cake™) and to provide explanations of each part of the updated model.

The main lesson that results from looking at Enterprise Architecture (EA) through the lens of classical architecture is that EA development should be executed in two sequential stages: an architectural stage followed be an engineering stage. The architectural stage begins with a general need and synthesizes distant to-be alternatives, one of which is chosen by the “client.” This selected to-be architecture provides a stable specification for engineering development. The engineering stage begins with the chosen to-be architecture and produces an optimized to-be enterprise design along with a staged transition plan. The transition plan migrates between as-is and to-be enterprise design states (not architectures). A robust to-be architecture does not change during the EA life and requirements creep. Staging EA development in this manner enables early management buy-in and reduces risk by providing stable intermediate milestones. While the best architecture stage is a low cost effort, its success demands quality execution and is best executed with special expert teams. In addition to the main lesson, private sector experience suggests that EA’s greatest value to the enterprise will come from Information Technology (IT) enabling the elimination of unnecessary processes. High value process-driven architecture should be initiated by the organization’s strategic planning function.

Enterprise Architecture (EA) is a still-emerging discipline. As such, it faces significant challenges despite numerous federal mandates for its implementation across all government agencies. EA is bolstered by an emerging presence in academia, but it suffers from setback in the practical world of management. In some cases, organizations have tried multiple approaches to EA implementation with mixed results. The significant challenge facing anyone tasked with implementing EA is not technological, but rather one of understanding organizational dynamics at the macro level and human nature at the micro level. For successful implementation, the people that make up an organization must take ownership of EA, rather than have it thrust upon them. This article explains how this may be accomplished, as exemplified by the EA effort in the Federal Aviation Administration’s Air Traffic Organization.

The existence of patterns is almost universal, and their se is evident in many domains. The human mind seems to perceive patterns without conscious thought – we notice an individual’s personal habits because they form patterns. Patterns are also used in a number of engineering disciplines – software engineering, requirements engineering and mechanical engineering to name a few. Some of these disciplines have used pattern for over 20 years. Today’s enterprise systems have become extremely complex. It is difficult, if not impossible for a system architect to mentally juggle all of the details of a modern complex multi-functional and distributed system. Patterns may provide the enterprise architect an approach to managing this complexity. This article reviews some of the relevant research and application related to the use of patterns, reviews how other disciplines are using patterns, and discusses research that has been done on applying patterns to the practice of architecting complex system (enterprise) architectures. Examples of architecture patterns are presented and discussed, and a methodology and rationale for documenting architecture patterns is presented.