Introduction

Federated architecture has emerged as one of the most commonly accepted patterns of enterprise architecture built on the principles of interoperability, but what does that really mean? For many, the term federated architecture likely evokes thoughts of government structure wherein a collection of states or provinces interact with (and ultimately adhere) to a national (federal) government structure. In this model, states have a semi-autonomous authority enacting legislation and guidelines on a localized level but are ultimately unified by shared national resources standards such as currency. From a technology standpoint, a federated architecture operates in a similar manner – allowing different systems and applications to solve for specific functions independently, ultimately backed by shared standards each individual system adheres to and utilizes.

This article explores the concept and benefits of federation. By its end, you will have a good understanding of the principles of federated architecture and be able to identify some real-world examples.

Autonomy and Interoperability

Extending the government analogy, having a monarch, or completely centralized authority often leads to an ineffective governing structure with the centralized authority being ill equipped to handle localized issues. Imagine if approval to fix every pothole needed sign-off from a national leader. . Interestingly, this concern transfers well to critiques of monolithic applications. Just like states, applications need some level of autonomy but ultimately aren’t built to solve every challenge and thus benefit shared resources and interoperability.

This article isn’t meant to be a civics lesson, but if you have a grasp on federated governments you in fact already have a pretty good understanding of federated architecture and its benefits.
Just like nations, enterprises choose a federation to deal with current and potential complexity without suppressing the autonomy of parts in the decentralized system. Let’s map this analogy onto a federated architecture and swap out some of the terminology in the next section.

Federated Architecture

Federated architecture is a pattern that unifies semi-autonomous applications, networks, or software systems. Each system (“state”) operates semi-autonomously. It can scale, process, experiment, and implement different technology. However, it complies with the rules that allow it to exist symbiotically with other related systems (“Union”).

Compliance in Federated Architecture

Two examples of interoperability that we can borrow from this government analogy are commerce and identity. The first example comes from all states accepting the same currency. Like currency, in a federated architecture system, there are some concepts that every semi-autonomous system adopts.

Identity is a different story. Each state has a verifiable—unique—ID card. Unlike currency this is not uniform but is often tied to a federally backed identifier like a social security number. . IDs are accepted across different states and often go through relaxed verification because there’s a separate authority establishing trust between the entities.

Holding the entities together is the central operating model. This model exists on a spectrum between two extremes: strong and weak1. Intuitively, an architect may design for more top-level control (strong) or give more power to the lower-level entities (weak).

The Benefit of Federated Architecture

One of the most popular stated benefits of choosing a federated architecture is allowing independent systems, teams, organizations, or entities to solve problems independently². The different kinds of independence include:

• Lifecycle
• Operational
• Platform

Sometimes, it helps to define a technology by its peers. What are the other options for large enterprises building complex applications? Federated architecture is typically used in larger enterprises or systems. It’s part of a category known as enterprise architecture.

What is Enterprise Architecture?

Enterprise architecture is the process and discipline that an enterprise takes to achieve its goals. Furthermore, it encompasses frameworks and a body of knowledge to guide architects in their approach to handling complex systems³.

Four examples of enterprise architecture frameworks include:

1. Zachman Framework
2. The Open Group Architectural Framework
3. Federal Enterprise Architecture 
4. The Gartner Methodology

It may be obvious that each system has a specialty and has been applied successfully in a number of situations. Describing each of the frameworks is beyond the scope of this article, but you can follow the links for each example to learn more!

Examples

Where can we look for examples of the federation? We have a nice real-world example in government, but let’s look at a few examples in technology.

RapidAPI Marketplace

The RapidAPI Marketplace supports the federation of APIs. The service eases the complexity of integrations by leveraging common API practices to promote interoperability. There is a level of compliance that each user or team must meet to join the group. However, once set up, they freely operate among other APIs.

Furthermore, each API product self-organizes and grows, increasing the value of the whole without restrictions from RapidAPI.

Users can build applications (creating a centralized operating model) from completely independent API vendors.

Email

Users can send Email messages across the network to each other regardless of their domain or email server⁴. There isn’t a central authority that controls the transfer of Email data, which is probably why spam is an issue. However, you could set up and manage your own email service, and after you complied with common protocols, you could send and receive messages to others.

Single Sign-On (SSO)

OpenID Connect, and other SSO protocols, can be referred to as federated⁵. OpenID Connect is “… an identity layer built on top of OAuth 2.0, with a large number of implementations from companies such as Google and Paypal. It enables client applications to receive valuable basic information about a user, such as a user’s identity, the user’s available attributes, and other authentication-related details.”

There is not one single identity provider that IDs have to verify with. The identity provider is simply a trusted party with the authority to authenticate.

Conclusion

As your business and technology stack grows, so too does their complexity, Adopting a federated architecture approach offers the benefit of individual systems being able to solve for specific challenges without having to solve for every challenge. Standardized agreements and resources enable each system to remain comparatively lightweight and ultimately benefit from one another exchanging data and functionality as needed.

FAQs

Footnotes

¹ “Comparison of Top Four Enterprise Architecture Frameworks” Free Essays – PhDessay.com, 4 May 2018, phdessay.com/comparison-of-top-four-enterprise-architecture-frameworks/. Accessed 29 Apr. 2021.

² “Federated Architecture.” Wikipedia, 10 Mar. 2021, en.wikipedia.org/wiki/Federated_architecture#Benefits. Accessed 29 Apr. 2021.

³ See (1) “Comparison of Top Four Enterprise Architecture Frameworks”

⁴ “Federated Architecture” YouTube, uploaded by Jeff Disher. 28 Dec. 2012, youtube.com/watch?v=uAtLhCJ3Tbg. Accessed 28 Apr. 2021.

⁵ Federated SSO, a Primer (SAML, OAuth 2.0, OpenID Connect). 18 Apr. 2017, www.mandsconsulting.com/federated-sso-a-primer-saml-oauth-2-0-openid-connect/. Accessed 29 Apr. 2021.

⁶ “Federated APIs across Ecosystems, WSO2 Webinar”. YouTube, uploaded by WSO2. 20 Apr. 2020, youtube.com/watch?v=6vEOtusyQ5U. Accessed 28 Apr. 2021.