A few weeks back I wrote about the benefits — and challenges — of a federated architecture. In that blog I wrote that such an approach helps the enterprise architect organize the efforts of disparate groups to avoid duplicate software project silos, but also that the approach won’t get far without buy-in and cooperation from business users, data owners and various other stakeholders. (For a more detailed refresher, see the original post here).

I mentioned there that I’d be following up the post with another to discuss a project I’ve been involved in to tie disparate financial systems into a federated portal, which included taking mobility into consideration early in the design process.  I know you’ve been waiting for it, so sit back and enjoy as I delve into the how of architecting that federated effort! I hope my experience will help prepare you for issues that may arise with federated systems in your own enterprise, regarding security, deployment coordination and user interfaces, which is where we’ll start.

Dressing for Success

The enterprise architect’s first challenge will be getting agreement on a unified presentation strategy. Without standardizing on a single presentation technology, you risk a user interface (UI) that looks disorganized and disjointed. Equally bad, you lose the ability to share design patterns and code across software projects, and developers remain in silos, jeopardizing the agility that can occur when they are free to share their talent with, or even move to, other development groups to create added value. Technical problems, such as OS resource competition and varying data refresh rates, are bound to arise as well.

The Web-based portal I’ve been focused on building is for a set of applications — involving multiple development groups — in the banking space. Being Web-based, HTML makes up most of the UI. But because the portal is to be a rich Internet application, we had to get agreement on which more complex UI elements we would leverage for displaying dynamic data (financial market data in this case). Ajax, Silverlight or Flash technologies were in the mix, but trying to combine them all adds up to a sloppy presentation. As the enterprise architect on the case, it was important to listen to the arguments on all counts, and in addition mobility features had to figure heavily into the final verdict. Flash is a good cross-platform, cross-browser choice for dynamic UI development, but even better, it’s turned out to be a real star in the world of mobile devices.

Just Log In

Another area of focus in federated architecture is user authentication. It’s absolutely necessary to build a single sign-on (SSO) solution—not necessarily one based on SAML (Security Assertion Markup Language), but one that’s web-proxy friendly—that unifies the login process for your internal applications. But it’s just as important to enable access from external domains, such as those of your customers and business partners, seamlessly and without sacrificing security.

Solutions such as those in CA’s Identity and Access Management suite, provide capabilities that can work in your enterprise, across the Web, and even extend to the cloud. A single sign-on product, such as CA SiteMinder®, is specifically built to solve this problem, as shown in Figure 1. 

Figure 1 - How Single Sign-on Works (Illustration credit: CA SiteMinder Product Brief)

Here’s how it works:

1. The user accesses a protected resource.
2. The user is challenged for credentials, which are passed to a secure SSO agent, such CA SiteMinder.
3. After passing through another layer of network security, the credentials are passed to a policy server.
4. The policy server securely authenticates the user against the correct data store.
5. Entitlements are passed back to the policy server where access is granted.
6. The user’s profile data is passed to the appropriate application(s).
7. Appropriate application content is provided to the authenticated user.

Remember, in a federated solution, all of your organization’s secure applications need to be unified within a single SSO solution, and all of your user authentication must be accessible within a single set of data stores. 

Deployment Demands

Another critical task facing the enterprise architect who drives a Web-based federated effort that runs well on mobile devices is the deployment and administration of services within the cloud. In my case, this involved a private cloud.

The main goals were to enable lifecycle and operational independence. The first mistake of some of the groups participating in the effort was that they placed their enterprise software components into the cloud as one large component. This quickly led to problems in the areas of scalability and ease of deployment.

As a result, I began an effort to break down all software components into sets of basic services with discrete tasks. We designed a way to easily deploy and dynamically execute these services across servers, both physical and virtual, according to a core set of capabilities and prerequisites. For example, information such as average transaction time, network bandwidth needs, dependencies on other services, and external resources and storage needs all are factors in deciding how many instances of each service are started, and where they’re located.

That’s why the system now can manage itself to a degree. However, administrators still can control individual services, migrate them across servers if problems arise, and roll out individual service updates without interrupting the entire federated system. In the end, the entire system and process is more agile, with limited dependency on specific developers’ expertise, or custom frameworks that duplicate deployment and administrative tasks. In summary, less human interaction equates to more efficiency, and reduced duplication equates to reduced costs and greater shared value.

Looking Ahead

If you’re interested in moving your enterprise toward a federated architecture, you must understand that you’ll need to constantly engage in forward-thinking and proactive planning, since unification efforts take a great deal of time and need to be flexible. That’s especially true as new development groups come on board and various databases need to be consolidated.

But as most enterprise architects learn early on, a good architecture is never complete. It just continues to evolve over time. We’d love to hear about any of your own evolutionary experiences as an architect.

You know it and I know it: Most large organizations suffer from silos, with duplicate software projects in active development. The reasons for this vary — a political power-play, an accident, a belief that it's easier to reinvent the wheel than drive someone else’s car.

But the results, as every enterprise architect knows, are the same: Duplication is costly, and ultimately it eats into the organization’s ability to function as an agile enterprise — that is, one that can freely and spontaneously exchange information as a whole, and where new initiatives are taken on by many people working collectively, instead of only a few working in isolation.

How to wrestle this problem to the ground? I suggest thinking in terms of the federated architecture pattern, an approach that focuses on software, processes and developer behavior. This approach leads to a more agile organization, as it fosters interoperability between lines of business and information sharing. John Zachman, creator of the Zachman Framework for Enterprise Architecture, has positioned this approach as a practical way to employ architectural concepts in complex, multi-unit enterprises. And he has noted that its success requires someone (YOU) figuring out and actually creating and managing what is to be federated — i.e., that which is to be centralized, optimized, integrated and reused by the overall enterprise. (You may want to read Smart Architect’s interview with John Zachman on recent changes to his framework here.)

Building on Zachman’s definition, federated architecture is more than a fancy term to describe an enterprise-wide approach to software. It's a model to share concerns across the enterprise, and to identify common business problems, infrastructure requirements, development efforts and data needs. It requires, in effect, that you build a system that encompasses the entire organization, so that the business is able to adapt to changes in the market more quickly and efficiently, and in a much more cost-effective manner.

As Fig. 1 shows, a federated architecture solution provides the platform to align disparate systems, data sets, other internal and external cloud-based systems, legacy systems, and infrastructure, all via an organization-wide taxonomy. From the purely organizational perspective, this is a difficult task: You need to align the business, the data owners and all stakeholders, the corporate IT strategy, and all of development. And if that weren't difficult enough, there are technical hurdles beyond the norm.

Indirectly related to this is a means to perform communication and integration across the components: Complex event processing (CEP). CEP involves designing your systems to respond to events that occur across all layers of the organization's IT systems. CEP, which in a federated architecture goes way beyond plain-vanilla middleware, becomes a driving force of systems integration and higher operational intelligence, and as such requires corporate wide buy-in and cooperation. Successfully accomplished, the result is a unified architecture, and a common development approach, for all of the systems in the enterprise — no more silos.

Integrating this into the cloud also ties into everything we’ve discussed here over the past year: further reducing costs, increasing efficiency, and raising overall system quality and uptime. (For more on those issues, see, for starters, Time to Revisit Your Cloud Strategy, Architecting the Cloud: Which Workloads Should Move First, or A Technical Perspective On Which Workloads Should Move to the Cloud.)  It also leads to that elusive agile enterprise, where individual components within the architecture — and the people involved — are part of a larger system, one where changes and improvements affect the organization as a whole, with benefits shared. 

Additionally, the federated approach helps to achieve operational independence: Developers for one part of the system can help (or even take over) when emergencies arise in other parts. Examples include software failures, architectural deficiencies and changing requirements that demand additional expertise. Being able to quickly find others within the organization to plug in and help in these situations is a big win. This is a key value that’s lost in the “silo approach.”

For the past year, I’ve been involved in a project where a set of disparate financial systems are being integrated into a single federated portal. As the system brings together elements of trade execution and supporting analytics, the problems have been wide and varied, from normalizing technology selections, to ensuring data-access rights, to meeting latency requirements.

In an upcoming blog, we’ll explore an architectural solution for a federated system based on this real-world experience. Your own federated systems will vary, and of course they don’t need to be a Web portal solution specifically for these lessons to apply. Regardless of what you’re building or integrating, you’ll face the struggles of coordinating numerous stakeholders across the organization, getting them to agree on an architectural direction, aligning their schedules and deployment plans to one another, and truly implementing the systems according to the agreed-upon plan.

In the meantime, let us know if you have an example of how you have implemented a federated architecture to drive agility – and how you did it.