Architectural Patterns

Definition: Architectural patterns are a method of arranging blocks of functionality to address a need. Patterns can be used at the software, system, or enterprise levels. Good pattern expressions tell you how to use them, and when, why, and what trade-offs to make in doing so. Patterns can be characterized according to the type of solution they are addressing (e.g., structural or behavioral).

Keywords: architecture, architecture patterns, patterns

MITRE SE Roles & Expectations: MITRE systems engineers (SEs) are frequently the stewards of an enterprise, system, or software architecture over its life cycle. The MITRE SE is expected to understand how architecture patterns can simplify and expedite the development of the system, and to mandate and encourage their use when appropriate.


"A key aspect to enterprise architecting is the reuse of knowledge. In most organizations today, the experience gained while doing a similar endeavor in the past is rarely utilized, or grossly underutilized, while dealing with a need today. Through better utilization of experiences and knowledge from the past, one can obtain major strategic advantages [1]." Pattern usage is an excellent way to reuse knowledge to address various problems. Figure 1 shows the levels of pattern application and how mature the pattern practice currently is for each one.

Figure 1. Architectural Pattern Usage
Figure 1. Architectural Pattern Usage

The architecture of an object, system, or enterprise is recognizable from the organization of features that contribute either structurally or behaviorally to the subject. A "pattern" has been defined as "an idea that has been useful in one practical context and will probably be useful in others [2, 3]."

Complexity Management
A major problem facing MITRE's sponsors today is constructing large, complex "systems of systems." These initiatives attempt to integrate dozens of legacy applications into a "system of pre-existing systems" to solve new and unexpected problems. The use of patterns can make these systems more efficient and effective. For instance, a system might have a tightly coupled architecture to address low-latency performance needs. Likewise, loosely coupled architectures may provide more opportunities to flexibly combine existing functions. As an example, one pattern used to enable loose coupling is the facade pattern in software architecture. This structural pattern provides a simple interface easily understood by many customers, hiding the complexity of function it provides, and is typically used when a service is to be provided to many objects in the environment.

Pattern Expression
One of the reasons why "experience gained while doing a similar endeavor in the past is rarely utilized" is because problems and their solutions are not expressed in a form suitable for reuse. Patterns provide a form for expressing technical solutions in the context of business problems and capturing them as reusable corporate knowledge assets.

In 1979, the (building) architect Christopher Alexander published The Timeless Way of Building, which describes a way to organize common solutions to architectural problems using patterns. In the early 1990s, software engineers began applying these ideas to systems architectures. Here is an example of a layered enterprise architecture expressed in Alexander's format:

  • Name
    • Layering
  • Context (situation giving rise to a problem)
    • Systems need to evolve to accommodate changing user requirements and new technologies
    • Managing change in complex systems
  • Problem (set of forces repeatedly arising in the context)
    • Applications built as monolithic structures
    • Changing one part propagates costly changes everywhere
    • Migration timelines are long and expensive
  • Solution (configuration to balance the forces)
    • Structure a system into layers
    • Each layer is a "black box" with well-defined interfaces
    • Implementation details of each layer are hidden behind the interface

Figure 2 illustrates the Layering pattern.

Figure 2. Layering Pattern
Figure 2. Layering Pattern

A pattern can be expressed using both human language such as prose, and more formal representations such as Unified Modeling Language diagrams. Patterns may also provide fragments of code to illustrate a design solution; however, it is not the intent of a pattern to provide a fully coded implementation.

Applications of Patterns

As the value of patterns becomes recognized in the federal government, agencies are beginning to build pattern repositories in the context of the Federal Enterprise Architecture framework. For example, the Department of Veterans Affairs has established a Technical Reference Model that includes 18 patterns that address such issues as router configurations and email address conventions.

When problem spaces are pervasive in an enterprise, there is an opportunity to develop guidelines in the form of patterns to address and govern solutions to that problem. The Tactical Edge Characterization Framework [4] contains patterns that address solutions to problems that occur at the edge of an enterprise where the users do not have large-scale and robust infrastructures.

The Navy has successfully applied patterns for their surface combat systems software product line. They use a layered presentation approach and a catalog of pattern elements.

Another set of problems occurs in the security domain of enterprises. The use of different approaches and a lack of patterns in developing security solutions lead to interoperability problems.

Best Practices and Lessons Learned

To be effective, patterns need to be incorporated into the corporate culture and adopted by management, business, and technical organizations. As illustrated in Figure 3, the effective use of patterns involves activities across technical, organizational, and process dimensions:

Figure 3. Dimensions of Effective Pattern Use
Figure 3. Dimensions of Effective Pattern Use

In addition to internal corporate use, patterns can leverage collective solutions among partners across corporate, government, and national boundaries.

Pattern practices that MITRE engineers are encouraged to follow:

  • Seek out pattern sources. For systems you are the steward of, seek out sources of architectural patterns. Examples include Net-centric Enterprise Solutions for Interoperability (NESI) [5], and the Electronic Systems Center Strategic Technical Plan [6]. These two are particularly applicable to problems of enterprise-level net-centricity.
  • Be a pattern steward. Recognize and capture patterns for reuse by others. Base patterns on proven experience in a common form or expression that is amenable to capture as a corporate knowledge asset. This is one way to help our customers solve their hard problems.
  • Lead the way in pattern usage. Enable and stimulate the selection of technical solutions based on successful patterns by using them in key documents such as Technical Requirements Documents, Software Development Plans, Systems Engineering Management Plans, and other key architecture documents.
  • Patterns, patterns, everywhere! Adopt patterns not only in technology-based SE work but also organizationally and in the process arenas. Works such as the Mission Level Modeling done by Prem Jain [7] contain workflow patterns that can be reused in architecture modeling efforts.

References & Resources

  1. Jerome J. Peloquin, 2001, An Essay on Knowledge as a Corporate Asset: Building the Case for Human Capital.
  2. Fowler, M., 1997, Analysis Patterns—Reusable Object Models, Addison-Wesley, ISBN 0-201-89542-0.
  3. The Open Group, The Open Group Architecture Framework (TOGAF) version 8.1.1.
  4. Dandashi, F., et al., November 2007, Tactical Edge Characterization Framework—Volume 1: Common Vocabulary for Tactical Environments, The MITRE Corporation.
  5. Department of the Navy, SPAWAR Systems Center Pacific, "NESI Public Site—Net-Centric Enterprise Solutions for Interoperability," viewed February 25, 2010.
  6. "ESC Strategic Technical Plan," MITREpedia, viewed February 25, 2010.
  7. "Mission Level Modeling," MITREpedia, viewed February 25, 2010.

Additional References & Resources

Adams, Koushik, Vasudeva, and Galambos, Patterns for e-Business, IBM Press, ISBN 1-931182-027.

Buschmann, Meunier, and Rohnert, Pattern Oriented Software Architecture, A System of Patterns, ISBN 0-471958-697.

Gamma, Helm, Johnson, and Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, ISBN 0-201633-612.

Halley, Marc R. and Chris Bashioum, Enterprise Transformation to a Service Oriented Architecture: Successful Patterns, Proceedings of the IEEE International Conference on Web Services (ICWS'05).

Hohpe and Woolf, Enterprise Integration Patterns: Designing, Building and Deploying Messaging Solutions, ISBN 0-321-20068-3.

MITRE, Information Sharing, Biopedia, viewed February 1, 2011 (includes instructions to access the Sharing Among International Partners Initiative (SAIPI) wiki).

Lapkin, A., October 22, 2004, A User's Guide to Architectural Patterns, Gartner Research Note G00123049.

Leganza, Gene and John Meyer, April 13, 2001, Using Patterns in Enterprise Architecture: Part 1—Benefits and Drawbacks of the Patterns Methodology, Giga Information Group.

The Open Group, The Open Group Architecture Framework (TOGAF), version 8.1.1, Part IV (Resource Base), Architecture Patterns.

Navy PEO Integrated Warfare Systems, July 31, 2009, Surface Navy Combat Systems Architecture Description Document.

Schulman, J., October 19, 2004, Overcome Architecture Pattern Pitfalls and Problems, Gartner Research Note G00123461.

Schulman, J., October 20, 2004, Architecture Patterns Lead to Better Solutions, Gartner Research Note G00123458.


Download the SEG

MITRE's Systems Engineering Guide

Download for EPUB
Download for Amazon Kindle
Download a PDF

Contact the SEG Team