Export (0) Print
Expand All
1 out of 1 rated this helpful - Rate this topic

Describing the Enterprise Architectural Space

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. Please see the patterns & practices guidance for the most current information.

 

patterns & practices Developer Center

patterns & practices Developer Center

Authors: David Trowbridge, Ward Cunningham, Matt Evans, Larry Brader, Microsoft Platform Architecture Guidance; Paul Slater, Wadeware.

Microsoft Corporation

June 2004

Summary: This document presents an organizing table that describes the enterprise architectural space, shows relationships among artifacts in the space, and demonstrates how different roles in your enterprise view enterprise architecture. This document also demonstrates how pattern authors can use the organizing table to organize existing patterns and to identify areas where patterns are not currently documented.

Contents

IntroductionEnterprise Architectural Space Organizing Table
Using the Organizing Table
Conclusion
References
Contributors
Key to Pattern Names in Figure 4

Introduction

Effective organization is critical to help us gain a full understanding of the complex world surrounding us. Standard and consistent organizing systems are used everywhere, from the Periodic Table of the Elements and the Biological Classification of Organisms, to the Dewey Decimal system in libraries. Such systems are also plentiful in the world of Information Technology. For example, the DNS system helps organize computers globally in a meaningful way, and file systems provide a directory structure to organize files in storage.

Enterprise-level software and system architecture are ripe for a similar organizing system. If you ask any group of technologists to describe the architecture of a system, you are likely to hear contradicting descriptions. Each person often has his or her own view of the system, which is accurate but different from the view of other technologists looking at the same system. A consolidated and consistent view of enterprise software-intensive systems could help technologists gain a shared understanding of the enterprise architectural space that is more complete and accurate.

This document presents an organizing table that the Microsoft patterns & practices team has used in pattern development for the past two years on releases such as Enterprise Solution Patterns Using Microsoft .NET. This paper exposes the early thinking about a dynamic way to organize and consume patterns. The authors anticipate that the structure of the organizing table will be refined over time and that the table will prove to be useful in many other efforts.

Enterprise Architectural Space Organizing Table

As enterprises respond to specific business initiatives, they produce many artifacts that capture architectural decisions, including: plans, notes, models, scripts, and code. Different roles in your enterprise use these artifacts to view the enterprise architecture in different ways. The potential for reuse increases if you have a meaningful way of organizing these artifacts.

Organizing the artifacts is a complex task, particularly as the enterprise and technologies change. Examining the space for all stable elements and cross-correlating all the relationships between elements would result in a multi-dimensional table that is not easy to display. A two-dimensional table allows you to analyze enterprise software-intensive systems in an intuitive way.

The Enterprise Architectural Space Organizing Table is such a two-dimensional table that captures and organizes business artifacts according to the decisions that produce them. The organizing table defines architectural viewpoints as rows, and interrogatives as columns. Figure 1 shows the basic structure of the organizing table. The particular rows and columns are discussed later in this paper.

Ff648192.f01entarch01(en-us,PandP.10).gif

Figure 1. Organizing table structure

As you will see later, the choice of rows for this organizing table provides a particular focus on the enterprise information space. The organizing table is intended to:

  • Provide a comprehensive view of the architecture space. The description is designed to organize architectural elements and demonstrate the relationships between them.
  • Be specific to enterprise software intensive systems. You may choose to extend the description to meet the needs of your enterprise.

The organizing table builds on four key pieces of work: The Zachman Framework for Enterprise Architecture [Zach], IEEE 1471 [IEEE], Andersen Consulting's Enterprise Information Architecture [Andersen], and test-driven development. Like the Zachman Framework, this table uses interrogatives as columns and roles as rows. This table, however, shows a higher degree of granularity in the rows and a higher degree of specificity in the artifacts contained in each cell. Also, based on the principles of test-driven development, this table includes an additional column that identifies the test of success for every row. Ideally, for any given row, the artifacts contained in the Test column should trace to the artifacts contained in the Purpose column for validation.

The organizing table groups rows together in levels of architecture, which shows the influence of the Enterprise Information Architecture framework. This grouping of rows exposes the overall alignment and traceability between business and technology. Within each row are discrete viewpoints, which are influenced by the IEEE 1471 architectural standard description. Together, these elements produce a highly granular map of the enterprise space that is organized by viewpoints and interrogatives.

One of the main strengths of the organizing table is that you can use it to store many different kinds of artifacts. By extracting, distilling, and abstracting the information contained in the traditional artifacts associated with enterprise software-intensive systems, you can produce patterns, practices, and guidance for your enterprise. You can then store these patterns in the organizing table. For more information about storing patterns in the table, see "Using the Table to Organize Patterns," later in this paper.

Architectural Viewpoints and Roles (Rows of the Organizing Table)

The organizing table divides enterprise architecture into five broad enterprise viewpoints. These views appear in the table as rows, which are organized from general to specific as you scan them from top to bottom. The viewpoints are:

  • Business architecture
  • Integration architecture
  • Application architecture
  • Operational architecture
  • Development Architecture

Although the viewpoints are a useful means of broadly categorizing architectural artifacts, the organizing table goes one step further by dividing the viewpoints according to specific roles that correspond to individuals with a particular skill set. As mentioned earlier, this additional detail allows you to trace the alignment of artifacts across the table.

Note   It is likely that the individuals in your enterprise do not map directly to the roles defined here. In a large enterprise, a role listed here might be assigned to a team (for example, architecture team). Conversely, one person may be responsible for many roles in a smaller enterprise. Nonetheless, most enterprise systems are viewed from the perspective of each of these roles at some point in time, and these roles can influence how you think about architectures as a whole.

The following paragraphs examine the viewpoints and the roles they contain in more detail.

Business Architecture Viewpoint

The business architecture viewpoint provides a basis for the other architectural viewpoints. Enterprise software exists to provide business value to your enterprise and must align with your business objectives. Without a well-defined business architecture in place, any attempts at enterprise architectures are likely to involve reactive, improvised technology decisions.

The business architecture viewpoint consists of the following roles:

  • CEO
  • General Manager
  • Process Owner
  • Process Worker

Integration Architecture Viewpoint

The integration architecture viewpoint is concerned with integrating systems that run in the enterprise inside and outside of the firewall. A simple enterprise may need only a few independent applications to run their business, but many enterprises need to integrate their applications both inside and outside the firewall. Inside the firewall, classic enterprise application integration (EAI) approaches are used to integrate systems at the data, function, API, and presentation levels. Often a message broker architecture is developed to perform intelligent routing, transformation, and business rule processing. Outside of the firewall, enterprises are connecting with other enterprises to create extended enterprise networks of trading partners that have cross-enterprise integration needs. This is the domain of business-to-business (B2B) integration servers (BizTalk) and Web services interoperability frameworks, which are designed to integrate multiple businesses at the process level.

The integration architecture viewpoint consists of the following roles:

  • Enterprise Architect
  • Designer
  • Developer

Application Architecture Viewpoint

The application architecture viewpoint contains all of the system and software elements necessary to run an executable application, such as databases, Web servers, application servers, networks, presentation frameworks, components (both infrastructure and custom), run-time frameworks, business logic, and the applications themselves. Any applications used to produce business value are really executable knowledge or executable business process. People interact with these applications through various interfaces and perform some portion, or all, of a business process using an automated, executable tool.

The application architecture viewpoint consists of the following roles:

  • Enterprise Architect
  • Architect
  • Designer
  • Developer

Operational Architecture Viewpoint

The operational architecture viewpoint is concerned with operating the production system in a stable, secure, scalable, predictable, and managed fashion. This category contains elements related to event, remote and performance management, user administration, backup, monitoring, and tuning.

The operational architecture viewpoint consists of the following roles:

  • Systems Architect
  • Systems Engineer

Development Architecture Viewpoint

The development architecture viewpoint is concerned with implementing the other architectures. Applications must be built and maintained in a systematic, efficient manner. The development architecture is composed of elements related to this effort, such as design and development tools, repositories, build master utilities, test suites, tracking tools, and other tools.

The development architecture viewpoint consists of the following roles:

  • Configuration Management Engineer
  • Buildmaster
  • Test Engineer
  • Developer

Architectural Space Interrogatives (Columns of the Organizing Table)

Although viewpoints and roles provide discrete perspectives into the architecture, you can provide further granularity in the architectural space by categorizing artifacts according to generalized questions that are related to the business initiatives that produce the artifacts. These questions, or interrogatives, form the following columns of the organizing table:

  • Purpose (Why). What is the reason for the architectural decision made in response to the initiative?
  • Data (What). What information is required by or will be produced as a result of the decision called for in the initiative?
  • Function (How). How do the architectural decisions made in response to the initiative work?
  • Timing (When). When do events or actions called for, or recognized by, the decision take place?
  • Network (Where). Where do the products of the initiative reside?
  • People (Who). Who benefits from, or is otherwise affected by, the initiative? What is the interface through which that effect happens?
  • Scorecard (Test). How do you know that the purpose of the initiative has been achieved?

The order of the columns is arbitrary, although it is useful to have the purpose column on the left, because it defines the reason for the architectural decision.

Combining the Viewpoints, Roles, and Interrogatives into the Organizing Table

Combining the viewpoints, roles, and interrogatives together produces an organizing table for enterprise software intensive systems. Figure 2 shows the organizing table, populated with descriptions of the artifacts it contains.

Click here for larger image

Figure 2. Enterprise Architectural Space Organizing Table
Note   For a larger version of this table, see the Organizing Table pdf file

Using the Organizing Table

The table provides a way of understanding the enterprise architectural requirements of an enterprise from multiple viewpoints and roles. You can use the table in a number of ways, including:

  • To understand the full extent of solutions in the enterprise. Few people grasp the full extent of solutions required in the enterprise. You can identify specific artifacts within the frame and explore nearby cells to broaden your understanding of enterprise architecture.
  • To identify relationships between artifacts. By examining subsections of the table, you can identify relationships between cells. Within cells, you can gain an understanding of artifacts that are related to one another. For example, an artifact that a particular roles uses may be related to another artifact that another role uses.
  • To cross-check elements in an enterprise for consistency and traceability. For example, you can use the test interrogative to check the validity of the purpose interrogative.

Using the Table to Organize Patterns

The organizing table organizes the artifacts of enterprise software-intensive systems, and therefore provides a view of the overall architecture. You can also use the traditional artifacts of the architecture to create patterns, practices, and guidance, as Figure 3 shows.

Ff648192.f01entarch03(en-us,PandP.10).gif

Figure 3. Typical uses of the organizing table

As the figure shows, you can extract important decisions and distill them into patterns, practices, and guidance that capture the collective learning of the enterprise. Placing this new learning in the organizing table provides particular benefits to pattern authors. As a pattern author, you can use the table in a number of ways, including:

  • To understand the context of patterns throughout the enterprise. You can identify specific patterns within the frame and explore nearby cells to broaden your understanding of the enterprise architecture.
  • To identify areas of the table that do not contain patterns. Areas of the table that do not currently contain patterns may reveal areas that the patterns community has not yet addressed.
  • To identify relationships between patterns. By examining subsections of the table, you can identify relationships between cells and patterns within the cells. For example, a pattern that a particular role uses may be related to another pattern that another role uses.
  • To move toward a more granular and consistent classification of patterns, according to their different characteristics and uses.

The Microsoft patterns & practices team uses the organizing table to categorize existing patterns and to identify areas where new patterns are emerging. Figure 4 shows the organizing table, with patterns from recent Microsoft patterns publications plotted on it. The abbreviation for each pattern name appears in the table as a hyperlink that leads to the published pattern elsewhere on MSDN. For a sortable list of these patterns, see "Key to Pattern Names in Figure 4" at the end of this paper.

 PurposeDataFunctionTimingNetworkPeopleScorecard
Business
Architecture
CEQ       
General
Manager
       
Process
Owner
       
Process
Worker
       
Integration
Architecture
Enterprise
Architect
 MDC AMDC MCD DaR
ETL Ent Dat SDa
 FiT
Pro Por Fun DOI
MOM SOI Pre
 TDC  
Designer MMR MSR MMRS
MSSR CTD MSTR
Nam DBr InBr MBr
MBu Pub Pip Gat
 MSCR  
Developer IMMRS IMSSR IMSTRIPro IMBr
IGat
    
Application
Architecture
Enterprise
Architect
       
Architect  LayA 3LayA Lay TiD 3TiD Dep
4TiD
  
Designer  MVC PCo FCo InF PCa
Obs Bro
DTO Sin SIf SGw AbF
Ada ApC Asm BDC Bri
Com Dec Fac  LayS
Map Med Mon  PAC
Prx ReF Spe Str TDG
TaM TeM
 SCl LBC FCl
SFar
  
Developer  IMVC IPCo IFCo IInF IPCa
IObs IBro
IBro IDTO IDTO ISin ISIf
ISGw IDTO PDC PFC UtC
    
Operational
Architecture
Systems
Architect
       
System
Engineer
       
Development
Architecture
Config
Mgmt
Engineer
       
Buildmaster       
Figure 4. Microsoft patterns plotted on the organizing table

Adding Patterns to the Organizing Table

In the future, the authors of this paper want to add patterns from key pattern authors. By sharing the organizing table with the broader patterns community, we believe we can provide an extensive and more coherent view of all available patterns. By combining efforts, the patterns community can increase pattern usage and better meet the needs of developers and architects who use them.

You can contribute to this effort, by adding your own existing patterns to the organizing table.

To add patterns to the organizing table

  1. Examine the problem and context of the pattern.
  2. Locate the most likely row and column where the pattern belongs.
  3. Read the contents of this and nearby cells and place the pattern in the cell with the best match.

Modifying the Table

In some cases, you will find it useful to modify the table, to meet your specific needs. For example, you may choose to increase the granularity of the table by adding additional rows or columns to more precisely define artifacts or patterns. Members of the patterns & practices team have themselves modified the table in this way in certain publications. For example, Enterprise Solution Patterns introduced a deployment column, as shown in the following subsection of the organizing table.

Ff648192.f01entarch05(en-us,PandP.10).gif

Figure 5. Enterprise Solution Patterns Organizing Table

This organizing table, which Enterprise Solution Patterns refers to as the Pattern Frame, is a subset of the Application Architecture row from the Enterprise Architectural Space Organizing Table. The Deployment column in Figure 5 added granularity to the Network column from the organizing table in Figure 2.

If you compare the Pattern Frame to the organizing table more carefully, you will notice that the column names were relabeled. The authors of Enterprise Solution Patterns customized the column names for the audience and to account for the constraints that they placed on this subset of the organizing table.

Conclusion

A comprehensive description of enterprise architecture artifacts helps you to reason and communicate about enterprise architectures. By using an organizing table containing viewpoints, roles, and interrogatives, you can help workers within your enterprise to understand the scope of enterprise software-intensive systems and improve business and technology alignment. You can also organize patterns, practices, and guidelines derived from these artifacts in the table. Organizing them allows you to categorize them, identify relationships between them, and determine areas where new patterns and practices may be appropriate.

References

[Andersen] Andersen Consulting, Goodyear, Mark. Enterprise System Architectures: Building Client/Server and Web-based Systems. CRC Press, 2000.

[IEEE] IEEE-Std-1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems.

[Zachman] Zachman, John. The Zachman Institiute for Framework Advancement, http://www.zifa.com.

Contributors

Many thanks to the following reviewers who provided invaluable assistance and feedback: Wojtek Kozaczynski, Microsoft Platform Architecture Guidance; Phil Teale, Microsoft Corporation; Richard Sears, Sears and Associates; Bill McDonald, Ascentium Corporation; Blaine Wastell, Ascentium Corporation; United Kingdom Architect Council–Patterns Working Group; Harry Pierson, Microsoft, Developer and Platform Evangelism Architecture Strategy Team.

Key to Pattern Names in Figure 4

The following sortable table lists the full name of each pattern that is shown in Figure 4. The table also indicates the location of each pattern in the organizing table, and the patterns & practices publication in which it appears—Enterprise Solution Patterns Using Microsoft .NET (ESP), Data Patterns (Data), or Integration Patterns (Integration).

Table 1: Key to Pattern Names in Figure 4 (click a column heading to change the sorting)

Viewpoint

Role

Interrogative

Abbreviation

Pattern name

Publication

Application Architecture

Designer

Function

AbF

Abstract Factory

ESP

Application Architecture

Designer

Function

Ada

Adapter

ESP

Application Architecture

Designer

Function

ApC

Application Controller

ESP

Integration Architecture

Enterprise Architect

Data

AMDC

Application-Managed Data Copies

Data

Application Architecture

Designer

Function

Asm

Assembler

ESP

Application Architecture

Designer

Function

BDC

Bound Data Control

ESP

Application Architecture

Designer

Function

Bri

Bridge

ESP

Application Architecture

Designer

Function

Bro

Broker

ESP

Integration Architecture

Designer

Data

CTD

Capture Transaction Details

Data

Application Architecture

Designer

Function

Com

Command(s)

ESP

Integration Architecture

Enterprise Architect

Data

Dat

Data Integration

Integration

Integration Architecture

Enterprise Architect

Data

DaR

Data Replication

Data

Application Architecture

Designer

Function

DTO

Data Transfer Object

ESP

Application Architecture

Designer

Function

Dec

Decorator

ESP

Application Architecture

Architect

Network

Dep

Deployment Plan

ESP

Integration Architecture

Designer

Function

DBr

Direct Broker

Integration

Integration Architecture

Enterprise Architect

Function

DOI

Distributed Object Integration

Integration

Integration Architecture

Enterprise Architect

Data

Ent

Entity Aggregation

Integration

Integration Architecture

Enterprise Architect

Data

ETL

Extract-Transform-Load (ETL)

Data

Application Architecture

Designer

Function

Fac

Facade

ESP

Application Architecture

Designer

Network

FCl

Failover Cluster

ESP

Integration Architecture

Enterprise Architect

Data

FiT

File Transfer

Integration

Application Architecture

Architect

Network

4TiD

Four-Tiered Distribution

ESP

Application Architecture

Designer

Function

FCo

Front Controller

ESP

Integration Architecture

Enterprise Architect

Function

Fun

Functional Integration

Integration

Integration Architecture

Designer

Function

Gat

Gateway

Integration

Application Architecture

Developer

Function

IBro

Implementing Broker with .NET Remoting Using Client-Activated Objects

ESP

Application Architecture

Developer

Function

IBro

Implementing Broker with .NET Remoting Using Server-Activated Objects

ESP

Application Architecture

Developer

Function

IDTO

Implementing Data Transfer Object in .NET with a DataSet

ESP

Application Architecture

Developer

Function

IDTO

Implementing Data Transfer Object in .NET with a Typed DataSet

ESP

Application Architecture

Developer

Function

IDTO

Implementing Data Transfer Object in .NET with Serialized Objects

ESP

Application Architecture

Developer

Function

IFCo

Implementing Front Controller in ASP.NET Using HTTP Handler

ESP

Integration Architecture

Developer

Function

IGat

Implementing Gateway with Host Integration Server 2004

Integration

Application Architecture

Developer

Function

IInF

Implementing Intercepting Filter in ASP.NET Using HTTP Module

ESP

Integration Architecture

Developer

Data

IMMRS

Implementing Master-Master Row-Level Synchronization Using SQL Server

Data

Integration Architecture

Developer

Data

IMSSR

Implementing Master-Subordinate Snapshot Replication Using SQL Server

Data

Integration Architecture

Developer

Data

IMSTR

Implementing Master-Subordinate Transactional Incremental Replication Using SQL Server

Data

Integration Architecture

Developer

Function

IMBr

Implementing Message Broker with BizTalk Server 2004

Integration

Application Architecture

Developer

Function

IMVC

Implementing Model-View-Controller in ASP.NET

ESP

Application Architecture

Developer

Function

IObs

Implementing Observer in .NET

ESP

Application Architecture

Developer

Function

IPCa

Implementing Page Cache in ASP.NET Using Absolute Expiration

ESP

Application Architecture

Developer

Function

IPCo

Implementing Page Controller in ASP.NET

ESP

Integration Architecture

Developer

Function

IPro

Implementing Process Integration with BizTalk Server 2004

Integration

Application Architecture

Developer

Function

ISGw

Implementing Service Gateway in .NET

ESP

Application Architecture

Developer

Function

ISIf

Implementing Service Interface in .NET

ESP

Application Architecture

Developer

Function

ISin

Implementing Singleton in C#

ESP

Integration Architecture

Designer

Function

InBr

Indirect Broker

Integration

Application Architecture

Designer

Function

InF

Intercepting Filter

ESP

Application Architecture

Designer

Function

LayS

Layer Supertype

ESP

Application Architecture

Architect

Function

LayA

Layered Application

ESP

Application Architecture

Architect

Function

Lay

Layers

ESP

Application Architecture

Designer

Network

LBC

Load-Balanced Cluster

ESP

Integration Architecture

Enterprise Architect

Data

MDC

Maintain Data Copies

Data

Application Architecture

Designer

Function

Map

Mapper

ESP

Integration Architecture

Designer

Data

MMR

Master-Master Replication

Data

Integration Architecture

Designer

Data

MMRS

Master-Master Row-Level Synchronization

Data

Integration Architecture

Designer

Network

MSCR

Master-Subordinate Cascading Replication

Data

Integration Architecture

Designer

Data

MSR

Master-Subordinate Replication

Data

Integration Architecture

Designer

Data

MSSR

Master-Subordinate Snapshot Replication

Data

Integration Architecture

Designer

Data

MSTR

Master-Subordinate Transactional Incremental Replication

Data

Application Architecture

Designer

Function

Med

Mediator

ESP

Integration Architecture

Designer

Function

MBr

Message Broker

Integration

Integration Architecture

Designer

Function

MBu

Message Bus

Integration

Integration Architecture

Enterprise Architect

Function

MOM

Message-Oriented-Middleware Integration

Integration

Application Architecture

Designer

Function

MVC

Model-View-Controller

ESP

Application Architecture

Designer

Function

Mon

MonoState

ESP

Integration Architecture

Enterprise Architect

Data

MCD

Move Copy of Data

Data

Integration Architecture

Designer

Function

Nam

Naming Service

ESP

Application Architecture

Designer

Function

Obs

Observer

ESP

Application Architecture

Designer

Function

PCa

Page Cache

ESP

Application Architecture

Designer

Function

PCo

Page Controller

ESP

Application Architecture

Developer

Function

PDC

Page Data Caching

ESP

Application Architecture

Developer

Function

PFC

Page Fragment Caching

ESP

Integration Architecture

Designer

Function

Pip

Pipes and Filters

Integration

Integration Architecture

Enterprise Architect

Function

Por

Portal Integration

Integration

Integration Architecture

Enterprise Architect

Function

Pre

Presentation Integration

Integration

Application Architecture

Designer

Function

PAC

Presentation-Abstraction-Controller

ESP

Integration Architecture

Enterprise Architect

Function

Pro

Process Integration

Integration

Application Architecture

Designer

Function

Prx

Proxy

ESP

Integration Architecture

Designer

Function

Pub

Publish/Subscribe

Integration

Application Architecture

Designer

Function

ReF

Remote Facade

ESP

Application Architecture

Designer

Network

SCl

Server Clustering

ESP

Application Architecture

Designer

Network

SFar

Server Farm

ESP

Application Architecture

Designer

Function

SGw

Service Gateway

ESP

Application Architecture

Designer

Function

SIf

Service Interface

ESP

Integration Architecture

Enterprise Architect

Function

SOI

Service-Oriented Integration

Integration

Integration Architecture

Enterprise Architect

Data

SDa

Shared Database

Integration

Application Architecture

Designer

Function

Sin

Singleton

ESP

Application Architecture

Designer

Function

Spe

Special Case

ESP

Application Architecture

Designer

Function

Str

Strategy

ESP

Application Architecture

Designer

Function

TDG

Table Data Gateway

ESP

Application Architecture

Designer

Function

TaM

Table Module

ESP

Application Architecture

Designer

Function

TeM

Template Method

ESP

Application Architecture

Architect

Function

3LayA

Three-Layered Services Application

ESP

Application Architecture

Architect

Network

3TiD

Three-Tiered Distribution

ESP

Application Architecture

Architect

Network

TiD

Tiered Distribution

ESP

Integration Architecture

Enterprise Architect

Network

TDC

Topologies for Data Copies

Data

Application Architecture

Developer

Function

UtC

Utility Component

ESP

patterns & practices Developer Center

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.