Organisations embarking on large-scale, company-wide service-oriented architecture initiatives should consider a federated approach to minimise costs and risks, while balancing flexibility at a local and organisation level, writes Massimo Pezzini, vice-president and Gartner fellow.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Although the industry has been discussing federated service-oriented architecture (SOA) for at least four or five years as a way to "divide and conquer" common problems across an organisation, practical experience is limited, and proven best practices are only now emerging. Initial experience shows that the issues organisations will face in the course of most federated SOA initiatives are not limited to integrating multiple enterprise service buses or federating diverse registry/repositories, but also include organisational and governance challenges.
To provide guidance for organisations considering a federated SOA initiative, Gartner has identified seven key issues to consider:
1. Determine whether to adopt a reactive or proactive approach
Some organisations see federated SOA as a fix for technical problems stemming from a lack of coordination or narrow-minded parochialism. Others embrace it as the best compromise between control and flexibility.
In the first case, federated SOA is adopted reactively, and multiple initiatives have spontaneously blossomed with little or no coordination. Inter-domain interoperability is pursued opportunistically, and when such a need becomes a recurring issue - for example, to support multi-company B2B or software as a service (SaaS) integration - a formal SOA federation process is initiated.
When federated SOA is recognised early as a strategic enabler, organisations often adopt a proactive approach. New SOA initiatives are encouraged, but are framed in well-defined domain structures. They proceed semi-independently, but are coordinated through common technical, organisational and governance principles.
Although the benefits (lower costs and risks) of a proactive approach are self-explanatory, in some cases this approach may face political and organisational obstacles. As a result, a proactive federated SOA can be practically pursued across only a limited number of domains, while the rest of the organisation, at least initially, acts reactively.
2. Appoint the federated SOA leadership team
Federated SOA requires a leadership team. This is an organisation that collects business and technical requirements, defines an SOA federation plan and makes recommendations about the supporting technical architecture, organisational models and governance processes. A supporting "SWAT team" (composed of architects, middleware engineers and developers) often includes individuals from an established and experienced SOA centre of excellence (COE), or may be a task force of individuals from the SOA COEs of multiple domains.
3. Design the SOA domains topology
The federated SOA leadership team must define the domain topology for the organisation by determining how many and which domains must be supported and integrated. Often, some de facto domains already exist, and just need to be formalized. But at times, the domain membership of a given service is not so obvious, and the federated SOA leadership team may decide to take over these borderline services. In general, the full topology naturally stems from the organisational structure of the company, and from legal and regulatory requirements.
4. Establish the Organisational Model
It is vital that each SOA COE coordinates during the federation process. This is usually achieved by mirroring the organisational setting and the governance model of the organisation. Gartner has identified three basic organisational models, although they can also be combined:
• Virtual Model: The individual domain SOA COEs are peers and autonomous; however, under the supervision of the federated SOA leadership, they meet periodically to agree on common standards, technologies and processes, and to address emerging issues.
• Hierarchical Model: The SOA COE in charge of a given domain acts as the "uber-SOA COE." It centrally defines standards, selects technologies and establishes governance processes that are then inherited by subordinate SOA COEs in the other domains.
• Mediator Model: Different from the uber-SOA COE, the mediator SOA COE is not in charge of an individual domain. It only acts as the centre of mediation and service for the individual operational SOA COEs by proposing standards, technologies and processes.
5. Draft federal governance processes
Much of the success of a federated SOA initiative results from the quality of the governance processes. Establishing common federal SOA governance processes is critical to enabling cross-domain application and service life cycle management; to establishing fair, cross-domain cost allocations; to defining clear accountability policies; to minimizing duplication of effort; and, ultimately, to enabling cross-domain interoperability and service sharing.
6. Establish interdomain interoperability standards
Cross-domain interoperability has two dimensions:
• Technical: This entails setting up infrastructure-enabling SOA endpoints (that is, services and applications) to communicate across domains by providing the appropriate security, management and quality of service. Technical interoperability can be achieved via a common protocol supported by all the domains. However, in some cases this is not possible; therefore, users need to deploy combinations of managed file transfer systems, point-to-point adapters, ESBs and integration appliances to link domain SOA backplanes.
• Semantic: This implies agreement on the representation of cross-domain business entities (such as customers, products, suppliers, payments, clinical data and other industry-specific entities). It means defining "canonical message formats" (also called "standardized" or "common" business objects), which should be used when transferring data among endpoints belonging to different domains. Although expensive and organisationally complex, setting up canonical message formats is vital.
7. Set out key performance indicators
Individual SOA projects are justified and evaluated on specific business goals. However, an SOA initiative is also expected to deliver IT benefits such as reuse of services, improved time to deployment for new applications, reduced application maintenance costs and more. To understand whether an SOA initiative is progressing coherently with these goals, SOA COEs should establish and measure a set of key performance indicators (KPIs).
The choice of which KPIs to be monitored varies across different SOA initiatives, but the federated SOA leadership team must establish a reasonable number of federal KPIs to have a sense of how the entire initiative is progressing. Therefore, each domain should instrument its SOA backplane to collect and report the data needed to monitor the domain-specific KPIs, as well as those required to populate the federal KPIs.