All growed up

The title of this blog post doesn't have a typo. All Growed Up is the animated movie of Rugrats, a popular American television show that portrays lives of a group of toddlers. In this episode of Rugrats, the babies attempt to tackle real issues as if they are much older and ponder major life decisions. Its like Rugrats 2.0.

Mainstream SOA adoption
We are at an inflection point with Service Oriented Architecture (SOA) maturity. For several years, businesses have moved to an architecture that is oriented towards services to give them increased flexibility. For over ten years, applying SOA principles has been a very effective way for organizations to achieve both business agility and cost optimization. SOA has primarily been about the services that allow an organizaton to achieve its business goals, and both service reuse and flexibility have been key factors in the success of SOA. Across the world, thousands of IT organizations have embraced SOA to really simplify their application integration environments and enterprise architecture, by addressing and increasing service reuse as well as securely integrating across a heterogenous set of service consumers and service providers. Each of these organizations started with a specific business problem or process or application and a set of services. These SOA pilot projects focused on specific business problems that tackled aspects of the SOA lifecycle. By using the SOA paradigm and applying best practices they were able to see real business benefit. SOA is more mainstream now and often as the "only way that IT approaches and solves business problems".

SOA is "all growed up"
Many enterprises are moving beyond SOA projects that focused on specific, departmental business problems to more complex SOA installations extending the reach of SOA and making it ubiquitous, supporting end-to-end business transactions across departmental or business unit boundaries. Most modern enterprises are not single entities, but have multiple business units. These are different departments or lines of businesses, that are sometimes even across country boundaries. And each business unit has services reused within the business unit boundaries via its own connectivity infrastructure. Each domain has their own ESB and registry. These domains or business units are often unconnected and autonomous - they are effectively "islands of SOA", or service domains. There has been a growing requirement to share services between these independent domains. These may be a result of a merger or acquisition, or the creation of inter-enterprise hosted services, or as a result of multi-enterprise collaboration. Connecting isolated services can optimize business performance and improve flexibility.

What if this cost can be reduced by bridging connectivity "across" domain boundaries? A non-technical analogy is - a government structure where a "federation model is used to address unity out of a number of separate entities so that each member retains the management of its internal affairs."

In the SOA context, this poses several questions:

• Heterogeneity : How does one maximize service reuse across heterogeneous enterprise domains?
• Share: How can one share services between domains, instead of federating the underlying connectivity infrastructure?
• Visibility: Can an enterprise architect discover and manage those services that span the multiple SOA boundaries?
• Effort: Sharing services on a case-by-case basis is possible, but can be complex and costly.What code has to be written by the IT middleware team to accomplish the federation?
• Autonomy: Can each domain still run their own SOA based on how they like it, or same as how they did it before participating in the federation?

In other words, there is a strong need to manage service visibility and reuse across the enterprise, across divisions and across boundaries of SOA domains. As Tommy would say to Angelica from Rugrats in his nasally voice, "what are we going to do Angelica? we are all growed up!!"