The Story of the Enterprise Architecture

People see the world as well as the activities and entities that occur and exist within it in different ways. The same applies to business. Enterprise architecture recognizes that different people involved with or impacted by an organization are interested in different aspects of its operation and development. Enterprise architecture recognizes this fact and leverages the opportunity that it presents. The opportunity to take the full story that details the operation and development of an organization in smaller portions, tailored to the interests of different groups of people.

Enterprise architecture, as a set of artifacts and deliverables, tells the story of:

  • The Current situation that the organization is in (current-state);
  • Where the organization would like to be (future-state);
  • What needs to change to get there (gaps); and
  • The orchestrated set of activities that must occur to get there (roadmap).

Imagine gathering together everyone involved with or impacted by the organization, sitting them down in an auditorium (or teleconference), telling them the full story in full detail, and attempting to elicit feedback.  One would likely find that much of the audience became disinterested as they listened to details that did not involve or impact them.  Each member of the audience would likely experience disinterest during a large portion of the entire story.  However, each might be more or less interested in different portions of the story.

Breaking down the Story

Enterprise architecture defines an approach to breaking down the full story into shorter stories.  The shorter stories are told from different perspectives to meet the needs of the various groups of people who may be involved with or impacted by the operation and development of an organization.  The approach enables enterprise architects to capture a great deal of detailed content and to present the content in meaningful and impactful ways.

This approach calls for the identification of stakeholders, concerns, and viewpoints and the development of views.  These terms may have different meanings in different contexts. These terms are defined (within this context) as follows for the sake of clarity.

  • Stakeholder: A stakeholder is an individual, team, or organization with concerns relative to the enterprise architecture.
  • Concerns: Concerns, in this context, are the key interests that are of crucial importance to a stakeholder and may pertain to any aspect of the enterprise architecture.
  • Viewpoint: A viewpoint is a vantage point (or perspective) from which the enterprise architecture can be described. Each viewpoint is intended to address specific concerns of specific stakeholders. Viewpoints are defined such that they can be applied to virtually any enterprise architecture.
  • View: A view is what is actually see when looking at a specific enterprise architecture (or subordinate architecture) from a specific viewpoint. To use an analogy, a viewpoint is to a view as a blueprint is to a building. Although a more accurate analogy would be to say that a viewpoint is more like a type of blueprint. Enterprise architects are familiar with the types of viewpoints that are typically used to describe enterprise architectures; just as engineers are familiar with the types of blueprints that are typically used to describe the design of cars.

Examples

There are a number of viewpoints defined by various enterprise architecture frameworks, many of which are designed to work together. However, enterprise architecture frameworks must be adapted to a specific organization. As a result, not all viewpoints defined within an enterprise architecture framework can be incorporated into the enterprise architecture of a specific organization. Perhaps more importantly, some viewpoints demonstrate value more quickly and easily than others.

The following viewpoints can demonstrate value quickly to business leaders, chief information (or innovation) officers (CIOs), IT managers, program managers, and directors of project portfolio management teams:

  • Business Anchor Model (using a Capability Model)
  • Project Viewpoint (based on DoDAF)

Business Anchor Model

A business anchor model helps tell the story of the enterprise architecture in a number of ways. The business anchor model can describe the current state of the enterprise, the future state of the enterprise, and can also help describe the allocation of resources and investments across the organization. A relatively new approach to crafting a business anchor model is to create a business capability model to represent the collections of people, processes, and tools that work together to deliver specific business outcomes.

Project Viewpoint

The project viewpoint helps tell the portion of the story of the enterprise architecture that describes the roadmap.  The project viewpoint describes projects being executed and planned and their relationships to one another and other elements of the enterprise architecture, including capabilities.  The project viewpoint is one of the many viewpoints defined by DoDAF that can be easily applied to virtually any kind of organization.  DoDAF describes the project viewpoint as a set of related viewpoints. However, it may be useful to produce views that incorporate several or all aspects of each of the DoDAF defined sub-viewpoints of the project viewpoint.

Each of these viewpoints will be described in more detail in future posts with hypothetical examples to help get business leaders, CIOs, and enterprise architects started.

One thought on “The Story of the Enterprise Architecture

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s