Architectures Federation

Definition: Architecture federation is a framework for enterprise architecture development, maintenance, and use that aligns, locates, and links separate but related architectures and architecture information to deliver a seamless outward appearance to users.

Keywords: enterprise architecture, federated architecture, fit for federation, semantic alignment, tiered accountability, touch point

MITRE SE Roles & Expectations: MITRE works with a variety of government customers to help them build enterprise architectures, often in the context of supporting their overall enterprise modernization or transformation programs. Many customers are facing the complex problem of sharing their business processes, information stores, technical systems, and human resources in a cohesive and secure way to accomplish a common mission. MITRE systems engineers are expected to understand and apply the principles of architectures federation to enable local innovation, enterprise integration, and evolution across major portions of an enterprise architecture or multi-agency enterprise architectures. By helping them build their respective products to meet common prescriptive direction, MITRE's customers will be able to reuse component architectures by "snapping them together" like LEGO® bricks to build complex architectures of wider scope and applicability.


In recent years, MITRE has been supporting architecture efforts across the federal government spectrum. In fact, the federal government now mandates the use of Enterprise Architectures (EAs) by agencies seeking to obtain funding for any significant information technology investment. Customers use architectures to improve warfighting and business capabilities by enhancing the interoperability and integration of U.S. enterprises (e.g., the Air Force Enterprise) with Joint and Coalition forces, other Services, and national agencies.

To accomplish the above efforts, MITRE systems engineers are expected to understand and apply the principles of federated architectures to account for architecture interrelationships and to express how architectures connect to one another. Federated architectures enable local innovation, enterprise integration, and evolution across major portions of an enterprise – many of which may be enterprises in their own right. Principles of architectures federation in practice require merging, integrating, and federating a large number of diverse organization architectures such as the Federal Aviation Administration, DoD, DHS, CBP, and the Federal Emergency Management Agency, as well as contributions from industry players like the airlines, airports, IT industry, weather bureaus, and others. This article explores the basic concepts of architectures federation and offers lessons learned to help MITRE systems engineers understand how the principles of federation can help practitioners build architectures more efficiently and effectively.

What is enterprise architecture?

Architecture relates to the structure of components, their relationships to each other and to the environment, and the principles guiding the design and evolution of the entity they describe [1], whether that entity is an organization (e.g., federal department or agency), a system (e.g., Joint Surveillance Target Attack Radar System), or a functional or mission area (e.g., financial management, homeland security). Architecture products and artifacts can take a variety of forms, including models of structured data stored in an architecture tool or database repository, graphical depictions of the information in hard copy or electronic format, or unstructured data or text.

A good working definition of "enterprise" is any organization or group of organizations that has a common set of goals or principles, or a single bottom line (e.g., a corporation, a single department, a government entity, a network of geographically remote organizations). An enterprise architecture provides a clear and comprehensive picture of an enterprise. It consists of snapshots of the current operational and technological environment, the target environment, and a capital investment roadmap for transitioning from the "as is" to the "to be" environment. In other words, it acts as a roadmap for the way ahead. The snapshots are further comprised of "views," each of which consists of one or more architecture products that provide conceptual or logical representations of some part of the enterprise of interest to a particular group of stakeholders [2].

What does federated architecture mean?

The historical approach of developing monolithic, integrated architectures has not worked well, as these products generally become too complex and unwieldy. By contrast, a federated architecture is a framework for enterprise architecture development, maintenance, and use that aligns, locates, and links separate but related architectures and architecture information to deliver a seamless outward appearance to users. It enables a complex architecture to be built in a piecemeal fashion from component architectures. In this way, a federated architecture approach recognizes the uniqueness and specific purpose of individual architectures, and allows for their autonomy and local governance, while enabling the enterprise to benefit from their collective content.

Federation provides the means to organize an enterprise's body of knowledge (architecture) about its activities (processes), people, and things within a defined context and current/future environment. Federated architectures support decision making by linking architectures across the enterprise, providing a holistic enterprise view that allows for the assessment of such matters as interoperability, identification of duplication and gaps, and determination of reusability [1].

Why develop architectures that support federation?

The ability to integrate and/or federate architectures is essential for addressing enterprise issues across a broad domain such as a federal department or agency. Federation enables multiple groups to develop architectures with the focus that best meets their immediate needs, while providing a means for linking and relating those architectures to address issues that cross multiple areas. A single architecture may not be able to address the entire enterprise sufficiently to support the kind of analyses needed in a large organization with a diversity of missions. The ability to federate multiple architectures leads to a more robust construct for understanding the enterprise in smaller, bite-size chunks.

Architecture federation serves, in part, as a process for relating subordinate and parent architectures via finding overlaps and establishing mappings between their common architecture information. Federal departments and agencies are also pursuing another use of an architectures federation strategy that divides the enterprise into manageable, right-sized components, each of which can be described by the communities that are most closely associated with them [3]. A small set of rules, common terms, and standards are used by everyone to maintain consistency so that the component parts can be "snapped together" as needed. For example, department architectures depict department-wide rules and constraints, component architectures depict mission-specific services and capabilities, and solution architectures depict solutions that conform to higher rules and constraints.

The concept of federation also plays an important role in the development of the environment and the sharing of information. For example, as federal department and agency enterprises become increasingly networked, federated architectures are proving essential in organizing the array of information and complex relationships. Federated architecture metadata is also useful for evaluating portfolios of existing systems and programs to make decisions about changes or additions necessary to achieve desired capabilities.

So then, what is federated enterprise architecture?

As defined by the enterprise scope, federated enterprise architecture is a collective set of architectures with the following attributes:

  • It operates collaboratively, where governance is divided between a central authority and constituent units, balancing organizational autonomy with enterprise needs.
  • The central authority's architecture can focus on the dynamics of economies of scale, standards, and the well-being of the enterprise.
  • Constituent units' architectures have the flexibility to pursue autonomous strategies and independent processes [4].

What are the central elements that support architectures federation?

In a federated approach, responsibility for architecture development is shared at different echelons within the enterprise. To bring these separate but related efforts together requires:

  • Tiered accountability: Establish a hierarchy of architectures whereby architectures lower in the hierarchy inherit characteristics from higher-level architectures. Use touch points to relate architectures across the levels or tiers.
  • Categorization: Relate and group "like" architectures and artifacts.
  • Semantic alignment: Use common vocabulary and mapping relationships to establish shared understanding.
  • Reference architectures: Provide parent taxonomies for other architectures to use.
  • Search and discovery: Allow authorized users to find and access relevant architecture for information and reuse [3].

What are some key constructs for architectures federation?

The key constructs for architectures federation are graphically depicted in Figure 1. Each construct comprises of a collection of architecture products of interest to a particular group of stakeholders.

Supported Architecture

Figure 1. Key constructs for architectures federation

The subject architecture is the architecture that drives solutions for a specific purpose. It addresses all the business, information, business services, and technology components needed to deliver capabilities. The architectures of those solutions upon which the subject architecture relies are called supporting architectures; whereas the architectures of those solutions that rely on the subject architecture are called supported architectures.

Each architecture interface point (also called touch point) is an abstract representation of a purposeful connection between two architectures. These architecture interface points are abstractions of real-world interfaces that will be embodied in the solutions that implement the corresponding architectures. In simple terms, the interface points are the places where architectures can be joined into a larger federated architecture, so they are key to purposeful federation from an operational perspective [5].

What is the role of compliance in federation?

It is important for an architecture to comply with a set of standards, if it will be shared and used to support federation with other architectures (e.g., guiding the development of other architectures or programs). These standards come in the form of prescriptive direction called compliance criteria. Compliance criteria include business rules and processes such as information, service, and technology standards. A program or other architecture must adhere to these for it to comply with a given structure. Compliance criteria are augmented with descriptions of the ways in which these criteria will be verified. Therefore, the compliance criteria explicitly states what a program or architecture must demonstrate in terms of functionality and in terms of adhering to standards and meeting specific qualitative requirements.

An organization can start by creating architectures that meet a minimum set of standards, making it easier to share the architectures and positioning them for use in building a federation of architectures to support the construction of a federation of interoperable solutions.

What are some examples of compliance criteria?

Fit for Federation is an example of a specific compliance assessment that might be applied to any architecture that will become part of an architectures federation. Fit for Federation is determined by the following compliance criteria:

  • The architecture's purpose has been documented and verified by users and usages.
  • Input has been verified as coming from authoritative source, and the authoritative source is recorded.
  • The architecture and/or analysis (output) have been verified as fit for purpose.
  • Supported architecture interface points and associated standards are identified, documented, and verified.
  • Supporting architecture interface points are identified, documented, and negotiated with the provider.
  • Other compliance criteria (e.g., enterprise-wide standards and/or qualitative requirements) are established, documented, and verified.

Some examples of qualitative requirements that might be applied while assessing conformance to compliance criteria are affordability, dependability, extensibility, performance, and trust.

For a service-oriented environment, specific compliance criteria would be packaged as Service-Level Agreements (SLAs). A single compliance criterion can distribute to multiple SLAs. For example, supporting a given vocabulary would apply to all services that deal with the subject (domain) vocabulary.

Lessons Learned

To federate architectures, there must be semantic agreement so that pertinent information can be related appropriately. MITRE systems engineers can recommend that their customers achieve semantic agreement by:

  • Adhering to a common framework, which includes the use of common data element definitions, semantics, and data structures for all architecture description entities or objects
  • Conforming to common or shared architecture standards
  • Using enterprise taxonomies and authoritative reference data.

In general, conforming to common or shared architecture standards increases interoperability and makes it easier to federate. MITRE systems engineers should encourage their customers to choose standards appropriate to their purposes and help them establish the means to enforce compliance. For example, agreed enterprise taxonomies establish the context for aligning mission area activities and associated reference models, and for categorizing and organizing component architectures, thereby facilitating semantic understanding across the various architectures in the federation.

The federation of architectures is facilitated by an environment that enables information sharing. MITRE systems engineers first must recognize that an architecture-sharing environment requires sound governance and enterprise architecture services. They must help their customers establish sound governance structures to apply accountability to the development and maintenance of architectures toward set objectives, which will ultimately facilitate their ability to federate. This approach places responsibility around processes such as configuration management and quality assurance. MITRE systems engineers also must encourage their customers to establish enterprise architecture services to allow for the visibility, accessibility, and understandability of architecture information in a consistent and efficient manner.

The success of a federation effort also depends on exposing architectures and architecture metadata for potential linkage and reuse by analysts, planners, and decision-makers at every level. Sharing architectures and services that already exist helps expedite architecture development and federation. Registry capabilities [6] provide for registration and linking of architecture metadata to enable the creation of navigable and searchable federated enterprise architectures. Enterprise enforcement policies and governance for architectures reinforce robust interfaces and data relationships [1]. MITRE systems engineers should assist their customers to actively engage in these architecture-sharing venues by reusing artifacts before reinventing them and by posting their own metadata and products for reuse by others.

MITRE systems engineers should promote and foster the development of federated architectures within customer organizations to help improve the reliability and efficiency of decisions. This will occur as organizations align semantic and structural data across their boundaries so they can ensure that the right information is being used to answer key decision-makers' questions. MITRE systems engineers should continue to use federated architecture opportunities and improve the flow of information among stakeholder nodes and consequently decision-makers.


MITRE is working with a wide variety of government customers to help them build their EAs, most often in the context of supporting their overall enterprise modernization or transformation programs. A key skill that MITRE systems engineers need to bring is an understanding of how business needs, information technology, and people come together in well-constructed architectures.

Many of MITRE's customers are facing the complex problem of multi-agency enterprise architecture. How can different government entities share their business processes, information stores, technical systems, and human resources in a cohesive, secure way to accomplish a common mission? Architectures federation can foster this kind of sharing. By helping them to build their respective products to meet common prescriptive direction, MITRE's customers will be able to reuse component architectures by "snapping them together" like LEGO® bricks to build complex architectures of wider scope and applicability.

References & Resources

  1. Department of Defense, April 23, 2007, DoD Architecture Framework Version 1.5, Volume I: Definitions and Guidelines.
  2. Hite, R. C. and G. D. Kutz, March 28, 2003, DoD's Draft Architecture, GAO-03-571R.
  3. Frey, B., July-September 2008, "Department of the Navy Architecture Federation Pilot," CHIPS, p. 41-43.
  4. Air Force Chief Architect's Office, December 2007, Air Force Architecture Framework.
  5. COLAB—Collaborative Work Environment,, accessed January 20, 2010.
  6. Department of Defense, DoD Architecture Registry System,accessed January 20, 2010.

Additional References & Resources

Business Transformation Agency, BEA 6.2 Informational Release, accessed January 20, 2010.

Federal Chief Information Officer Council, February 2001, A Practical Guide to Federal Enterprise Architecture, Version 1.0.

"System Architecture," The MITRE Corporation, Project Leadership Handbook, viewed January 2010.


Download the SEG

MITRE's Systems Engineering Guide

Download for EPUB
Download for Amazon Kindle
Download a PDF

Contact the SEG Team