Describing the Enterprise Architectural Space

Describing the Enterprise Architectural Space

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.


Click here to download the PDF version of this guide from Microsoft Download Center.

Click here to download the Organizing Table pdf which is the larger version of Figure 2 in this guide.



Enterprise Architectural Space Organizing Table

Using the Organizing Table





Key to Pattern Names for Table 1


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.

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:

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:

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:

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:

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:

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:

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:

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:

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.

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:

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.

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:

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 recent Microsoft patterns releases plotted on it. Each pattern appears as a number. To see patterns these numbers refer to, and the publications in which they appear, see "Key to Pattern Names in Figure 4" at the end of this paper.

Figure 4. Microsoft patterns releases 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.

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.


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.


Questions? Comments? Suggestions? The authors of this paper urge you to join the Enterprise Architecture Space community on the Channel 9 Web site ( You can use this community forum to provide feedback on this paper and to contribute to the Enterprise Architecture Space Organizing Table.


[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,


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 table shows the patterns that Figure 4 refers to by number. The table indicates the names of the patterns, and the patterns & practices publications in which they appear—Enterprise Solution Patterns Using Microsoft .NET (ESP), Data Patterns (Data), or Integration Patterns (Integration).

Table 1: Key to Pattern Names in Figure 4

Pattern # Pattern Name Publication
2 Model-View-Controller ESP
3 Implementing Model-View-Controller in ASP.NET ESP
4 Page Controller ESP
5 Implementing Page Controller in ASP.NET ESP
6 Front Controller ESP
7 Implementing Front Controller in ASP.NET Using HTTP Handler ESP
8 Intercepting Filter ESP
9 Implementing Intercepting Filter in ASP.NET Using HTTP Module ESP
10 Page Cache ESP
11 Implementing Page Cache in ASP.NET Using Absolute Expiration ESP
12 Observer ESP
13 Implementing Observer in .NET ESP
14 Layered Application ESP
15 Three-Layered Services Application ESP
16 Tiered Distribution ESP
17 Three-Tiered Distribution ESP
18 Deployment Plan ESP
19 Broker ESP
20 Implementing Broker with .NET Remoting Using Server-Activated Objects ESP
21 Implementing Broker with .NET Remoting Using Client-Activated Objects ESP
22 Data Transfer Object ESP
23 Implementing Data Transfer Object in .NET with a DataSet ESP
24 Implementing Data Transfer Object in .NET with a Typed DataSet ESP
25 Singleton ESP
26 Implementing Singleton in C# ESP
27 Service Interface ESP
28 Implementing Service Interface in .NET ESP
29 Service Gateway ESP
30 Implementing Service Gateway in .NET ESP
31 Server Clustering ESP
32 Load-Balanced Cluster ESP
33 Failover Cluster ESP
34 Four-Tiered Distribution ESP
35 Abstract Factory ESP
36 Adapter ESP
37 Application Controller ESP
38 Assembler ESP
39 Bound Data Control ESP
40 Bridge ESP
41 Command(s) ESP
42 Decorator ESP
43 Facade ESP
44 Gateway Integration
45 Implementing Data Transfer Object in .NET with Serialized Objects ESP
46 Layer Supertype ESP
47 Layers ESP
48 Mapper ESP
49 Mediator ESP
50 MonoState ESP
51 Observer ESP
52 Naming Service ESP
53 Page Data Caching ESP
54 Page Fragment Caching ESP
55 Presentation-Abstraction-Controller ESP
56 Proxy ESP
57 Remote Facade ESP
58 Server Farm ESP
59 Special Case ESP
60 Strategy ESP
61 Table Data Gateway ESP
62 Table Module ESP
63 Template Method ESP
64 Utility Component ESP
65 Maintain Data Copies Data
66 Application-Managed Data Copies Data
67 Move Copy of Data Data
68 Data Replication Data
69 Extract-Transform-Load (ETL) Data
70 Master-Master Replication Data
71 Master-Slave Replication Data
72 Master-Master Row-Level Synchronization Data
73 Master-Slave Snapshot Replication Data
74 Capture Transaction Details Data
75 Master-Slave Transactional Incremental Replication Data
76 Implementing Master-Master Row-Level Synchronization Using SQL Server Data
77 Implementing Master-Slave Snapshot Replication Using SQL Server Data
78 Implementing Master-Slave Transactional Incremental Replication Using SQL Server Data
79 Topologies for Data Copies Data
80 Master-Slave Cascading Replication Data
81 Entity Aggregation Integration
82 Process Integration Integration
83 Implementing Process Integration with BizTalk Server 2004 Integration
84 Portal Integration Integration
85 Data Integration Integration
86 Shared Database Integration
87 Maintain Data Copies Integration
88 File Transfer Integration
89 Functional Integration Integration
90 Distributed Object Integration Integration
91 Message-Oriented-Middleware Integration Integration
92 Service-Oriented Integration Integration
93 Presentation Integration Integration
94 Broker Integration
95 Direct Broker Integration
96 Indirect Broker Integration
97 Message Broker Integration
98 Implementing Message Broker with BizTalk Server 2004 Integration
99 Message Bus Integration
100 Broadcast Message Bus Integration
101 Switch-Based Message Bus Integration
102 Publish/Subscribe Message Bus Integration
103 Publish/Subscribe Integration
104 Publish/Subscribe with BizTalk Server 2004 Integration
105 Pipes and Filters Integration
106 Pipes and Filters with BizTalk Server 2004 Integration
107 Gateway Integration
108 Implementing Gateway with Host Integration Server 2004 Integration
109 Content-Based Routing Integration
110 Content-Based Routing with BizTalk Server 2004 Integration

Patterns and Practices home