This blog post was contributed by Amy Wohl. Amy Wohl has
been commenting on, writing about, and consulting to the information
technology community for more than 35 years. She is an industry
analyst and her current foci are cloud computing and the effects of
technology on society. She also has expertise in helping to create
new markets for new technologies. Read more blogs by Amy on Amy Wohl's Opinions and follow her on twitter @AmyWohl
As business life gets more complex, with a network of relationships with customers, partners, and suppliers and the pace increases with more and more acquisitions, mergers, and consolidations, we need a way to manage the complexity of achieving service reuse and business agility across departments and channels. Federation is a key to managing this complexity. SOA is the foundation for an environment where agility and reuse are central. It supports:
- A service – a repeatable business task such as “check customer credit.”
- Service Orientation – A way of integrating your business as a set of linked services and the outcomes they provide.
- Service Oriented Architecture (SOA) – An IT architectural style that supports service orientation.
The key is to manage the sharing of the right set of services between service domains—rather than everything being shared by default or nothing being shared at all. Service Federation offers a middle ground that enables true scaling of SOA by allowing service domains to evolve at their own pace and avoiding “sharing overload” to potential consumers, while managing the sharing of selected services according to service consumer needs and overall enterprise policies.
Sharing services requires a method for making the right services visible, providing service security, and offering service monitoring and governance. This may be done in both hierarchical (parent/child) and Peer-to-peer service relationships.
- In a hierarchical architecture, one service domain takes on a dual role as (a) a service domain for the specific community it represents and (b) a coordinator or broker or interactions between other service domains—it becomes the Parent for those Child service domains. This pattern is used if there is an enterprise entity that can play such a dominant role via governance authority, financial means etc. It makes it easy to establish federation-wide governance and monitoring of service sharing. In a centralized environment, this can be done at an early stage by having a parent service domain that only provides brokerage between child domains but does not yet have a service domain of its own.
- Peer-to-peer architectures are common in ad hoc federations (used early in the process where there are only a few service domains and none so large or so strong as to be the parent domain).
Governing a federation is similar to governing services in a single service domain. Someone (typically the service owner) should be able to “approve” the use of a service by another service domain.
In the Cloud, service federation may also be employed, following the use of SOA and the implementation of SaaS solutions made up of SOA services. The federation in that case may deploy services across data centers, private, and public clouds.
Read more by downloading this free white-paper PDF on Service Federation Management