OAD Consulting, Inc.

Modeling Enterprise Architecture

Enterprise Architecture (EA) is a means to support the business through the use of IT. EA modeling is a holistic approach to capturing not just all of the areas within IT but also the alignment of IT to the business. The purpose of EA is to ensure that IT provides tangible benefit to and keeps pace with the business. EA provides information necessary to help make tactical and strategic business decisions. To do this, it must address the needs of all stakeholders.

In order to address the concerns of each stakeholder, we must take a divide and conquer approach. There are several architectural standards today that prescribe various aspects of capturing Enterprise Architecture. Standards like the Open Group Architecture Framework (TOGAF), the International Standards Organization’s Reference Model for Open Distributed Processing (RM-ODP) and the Rational Unified Process (RUP) prescribe a process for capturing your architecture. Each also provides a set of architectural views, but leaves it up to the architectural implementation team to fully determine what they should be.

Another standard, Model Driven Architecture (MDA) by the Object Management Group (OMG), also provides a separation of concerns, in this case into three levels; the Computational Independent Model that describes the business environment in completely technology free terms, the Platform Independent Model (PIM) that provides a design solution that is not tied to a particular technology base, and a Platform Specific Model (PSM) that puts the solution in terms of the chosen technology base.

Excerpt from: TOGAF Version 9, Enterprise Edition, Part I - Introduction | Core Concepts | Using TOGAF with Other Frameworks

Because TOGAF is a generic framework and intended to be used in a wide variety of environments, it provides a flexible and extensible content framework that underpins a set of generic architecture deliverables.

As a result, TOGAF may be used either in its own right, with the generic deliverables that it describes; or else these deliverables may be replaced or extended by a more specific set, defined in any other framework that the architect considers relevant.

In all cases, it is expected that the architect will adapt and build on the TOGAF framework in order to define a tailored method that is integrated into the processes and organization structures of the enterprise. This architecture tailoring may include adopting elements from other architecture frameworks, or integrating TOGAF methods with other standard frameworks, such as ITIL, CMMI, COBIT, PRINCE2, PMBOK, and MSP.

After extensive work with numerous large companies in the insurance, financial, pharmaceutical, publishing, and automobile distributorship sectors in adopting the concepts of the above standards, I have found that the following architectural views provide a good representation of the needs of the various stakeholders and a good starting point for my clients. These views are for companies that have business information systems with multiple business domains in a distributed environment. A company with other development modes, e.g., real-time applications, will have a much different structure to their architecture. Learn more about each of the architectural views by following the links below.

Business Architecture

The Business Architecture captures information about the structure, purpose, and operation of your business. Creating a formal model of the business allows for critical review of the problem space before designing the solution space. Read more on the (EA)2 Online User's Guide section on Business Architecture.

Application Architecture

Application Architecture deals with how applications are built and interact with each other. Building a suite of applications that communicate across your intranet with a service oriented approach to distributing core business logic and information will utilize a different Application Architecture than a suite of applications that run on the same PC and share common functionality. In either case it makes sense to look at the Application Architecture from two perspectives, namely the functional and integration views. The level of detail you want in either view depends on the type of IT shop you have. If you develop applications in house, then you will want to explore the underlying components of your applications. If you are mostly an integration shop that purchases off-the-shelf software and provide some “integration glue” to allow them to communicate, then you may only need to deal with the applications as “black boxes.” Read more on the (EA)2 Online User's Guide section on Application Architecture.

Data Architecture

The Data Architecture describes the DB Schemas, logical DB Interfaces used by the applications, and ETL Jobs that transform and move data from DB Schema to DB Schema. Read more on the (EA)2 Online User's Guide section on Data Architecture.

Infrastructure Architecture

The Infrastructure Architecture includes all of the elements needed by the business software and databases in order to run. This includes IT software and IT hardware and other types of elements to fully describe the underlying infrastructure of the enterprise. The Server, Server Model, and Server Metamodel links provide an in-depth discussion that applies to the other node types Read more on the (EA)2 Online User's Guide section on Infrastructure Architecture.