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.