Applied Information Management

Choosing an Enterprise Architecture Model

In Brief: The play between Information Technology and the rest of an organization is no longer one in which IT serves a supporting, "back room" role. The most inventive organizations are destined to be the most successful ones and much of the opportunity for innovation is buried in the data and the processes that occur in routine business functions.

It was only a matter of time before business strategists established a formal discipline to optimize this synthesis of information technology and daily business functions. Managers today call the management of these integrated systems "enterprise architecture" and assert that this deliberate structuring of the relationships between the processes and systems that an organization uses in its business is essential if an organization is to strategically align business processes and IT resources.

Graphic of Figure 1: Association of Models to Business Requirements.

Establishing a structure that brings IT and the rest of the organization into a synchronized, complementary relationship is of enormous value. But where should the enterprise architect begin? Such an assignment can be daunting. And while the value of the project is high, so is the cost. Once identified, the blueprints that express the most effective integration of business and technology require the commitment of human resources, time and capital.

Although there are a number of enterprise architecture models upon which to base the work, six are most commonly used and a combination of two or three models is often appropriate. Figure 1 documents the alignment of each of six common enterprise architecture models with selected business requirements. These six models tend to align with particular types of organizations. They are:

  1. Data Model: The most prevalent form of model across all levels of organization maturity. There are many variations of data models. Operational data models are useful in all organizations. Domain models are used in more mature organizations.
  2. Process Model: Frequently used in low to middle maturity organizations. Modeling efforts are focused on documenting and standardizing processes and many forms of process models can be used.
  3. Unified Modeling Language (UML) Class Diagram: The most popular model and most useful when used with the UML Sequence Diagram model. It is of greatest usefulness in low to medium maturity organizations.
  4. UML Sequence Diagram: Best used with the UML Class Diagram and of greatest usefulness in low to medium maturity organizations.
  5. Data Flow Diagram: A well-known form of process model that has been used for many years in organizations at all levels of maturity. This model is accepted as a communication tool only when used to model small processes or segments of processes.
Establishing a structure that brings IT and the rest of the organization into a synchronized, complementary relationship is of enormous value. But where should the enterprise architect begin?

Clearly, the choice of model is most dependent on an assessment of the organization's maturity as it relates to documented business process, system development life cycle, and data warehouse. Fortunately, judging the relative organizational maturity can be completed without the use of complex tools or lengthy checklists. Here's a shortcut: Organizations with reactive and day-to-day activities that focus on immediate concerns are fairly low in maturity. Those with proactive processes, well-established guidelines and standards, and both short and long term goals are much more mature.

In the end, with the model matched to the organizationís maturity and related characteristics, the aspiring organization will benefit by integrating technical and business components with strategic planning efforts, resulting ultimately in a more successful organization.


(Selected citations only)

  • Baker, David C. and Janiszewski, Michael (2005, June). Seven Essential Elements of EA. Enterprise Architect. [Online serial]. Retrieved September 15, 2005 from Fawcette Technical Publications.
  • Bloomberg, Jason (2003, September 18). Calling the Elusive Enterprise Architect: You're More Important than You Think. Zapthink [Online]. Retrieved September 30, 2005 from ZapThink.
  • Phillips, Mike (2004). CMMI V1.1 And Appraisal Tutorial. Software Engineering Institute, Carnegie Mellon University [Online presentation]. Retrieved October 7, 2005 from CMMI.
  • Waddington, David (2004, November). An Architected Approach to Integrated Information. Kalido [Online]. Retrieved September 2, 2005 from Kalido's website. Now available from website.

Research Paper Author: Linda Ballas—2005 AIM Graduate, Software Architect, Standard Insurance Company, Portland, Oregon

Abstract: Waddington (2004) and Bloomberg (2005) believe that organizational characteristics should help determine the choice of an enterprise architecture model. This paper examines key existing models and aligns these with variations in organizational maturity level, including business process definition, system development life cycle and enterprise data warehouse (Phillips, 2004). Outcomes are provided for enterprise architects and systems analysts who seek to model both technical and business components to support strategic planning efforts (Baker and Janiszewski, 2005).

Download the entire Capstone research project