Federation is a key to SOA
People used to talk about centralizing everything to make an SOA work (centralized ESB, centralized registry, centralized policy enforcement, etc). Although centralizing a team to manage an overall SOA effort is still a very popular and successful strategy, the centralization of the supporting technologies isn’t necessary (or practical) in many large organizations. For example, SunGard used to think in terms of maturity steps leading components towards a complete compliant stack, centralized server architecture). We’ve learned that by identifying what each component is and certifying certain attributes (but leaving it where it is) is far more useful to emphasize. This is a federated approach of sorts.
Leaving things where they are, but certifying the definition of key attributes (and organizing their availability to business needs, resulting in composite solutions) is an important step in the federation model. If you have familiarity with SunGard’s CSA Levels (the centralized approach), the maturity model was recently superseded by a federated approach to attribute definition. The following structure identifies the method of consumption of a business service, and serves as a certifications federation model for the compliance of any software artifact indexed for consumption:
- Service Interface Certification: complies with standards associated with encapsulation or service interfaces and message protocols (such as WSDL/SOAP, FIX, etc.), replaces Level 1.
- User Authentication Certification: complies with authentication standards, (single sign-on), replaces 1/3 Level 2.
- User Interface Certification: complies with UI standards, (Sphinx), replaces 1/3 Level 2.
- User Authorization Certification: complies with authorization standards, (entitlements), replaces 1/3 Level 2.
- Data Model Certification: complies with one of the standard data models, replaces Level 3.
- Reference Implementation Certification: relies on full reference implementation stack, replaces Level 4.
Another important step in federation enabling SOA is ditching the notion that a centralized service registry contains all your artifacts available to the SOA (at least in terms of how most service registries are defined today). Instead, the concept of solutions organized through a federation of registries is far more SOA-friendly, and with a federated certifications model, such as the one above, indexing assets across an organization begins to make the federation gel.
SunGard established the concept of a Solution Registry to differentiate the idea from service registries. Solution Registries manage a federated network of service registries (where low-level service components may be found), and create collections of services as solutions (which are things a business individual could actually make use of). SunGard’s Infinity offering provides the solutions umbrella linking services to business needs through a federation model of software artifacts wherever they may reside.
ESB’s and other parts of the SOA infrastructure stack are yet another area people have tried to centralize in the past. At least in large organizations, many are finding that too requires a federated approach to be successful. As it turns out, mandating a central broker implies that a central support team would have to understand the details of every component and application. Instead, the delegation model of distributing the knowledge load to others (keeping expertise where it is, with the software) fosters the right kind of ownership that thrives in a successful SOA.
Last week, in a conversation with group of analysts who cover the SOA space, it was clear that some of them see a central ESB as a hindrance in some large companies, as opposed to an enabler because of the fragmentation of the messaging layer. No two ESB’s look the same, and software intended for reuse often runs into incompatibilities due to the lack of agnosticism between vendors with messaging. A federated model can ensure the mess is organized, but federation needs to be implemented with a number of other things in order to work well (such as those mentioned above, i.e. registry, certifications, etc).