There was a time not so long ago that conventional wisdom said all you really needed to get an SOA deployment off the ground was an enterprise service bus, or ESB. You could use an ESB to service-enable a couple of existing applications, build a couple of services from scratch, stitch them together and, viola, you had an SOA.
Interestingly, in the early days of the SOA movement, this scenario wasn't that far from reality. Enterprises were dealing with a relatively limited number of services and deploying them in a relatively limited manner. IT departments were in a phase of "SOA experimentation" and taking the time to learn what worked and what didn't work. With a few exceptions, SOA was being adopted at the divisional level and in applications that were not very likely to be considered mission-critical.
However, like the computing movements that came before, SOA is continuing to mature and evolve. Enterprises learned from their early experiments that SOA could help bring new life and generate new value from existing systems and applications. SOA could allow, more easily, the reuse of services, promoting greater developer productivity and cost reduction.
But to take real advantage of the benefits of SOA, organizations would need to abandon the ad hoc approach the defined most early SOA deployments and adopt a change in mindset that allowed for the introduction of new dynamics that would impact the organization and its processes.
Without a change in mindset that puts greater structure around the deployment of SOA, organizations run the very real risk of falling into a state of "SOA Anarchy." Unfortunately, the concept isn't all that far-fetched. The early experimentation with SOA created an ideal environment for the proliferation of "Independent SOAs" inside different operational areas or business units.
As SOA spreads through the enterprise, you're faced with the distinct possibility that services have been dupl
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
icated in multiple divisions, effectively scuttling one of the key benefits of SOA, that being reuse of services. Further, this scattered approach to SOA deployment creates an atmosphere ripe for ineffective management of existing services and the IT resources that support them, and for creating situations of overlapping responsibility (or worse yet, no responsibility) for services within the IT department.
What's needed to help usher SOA into its next phase of not only maturity, but also effectiveness, is a means to govern your SOA deployment with governance meaning defined organizational aspects, processes and roles needed to address and manage new SOA dynamics.
Governance sounds good, especially when you stop for a moment to really ponder the alternative, butut the path to governance isn't always clear. Some would say simply, "throw in a registry and you're good to go." Unfortunately "simply" is the operative word and anybody that has any experience with SOA deployments will tell you that "simply" is very rarely a word that can be used to describe the process.
That's not to say that registry capabilities aren't important. Knowing what services you have available in the enterprise and how to access them is a good first step in taming "SOA Anarchy," but there is much more that needs to be done to achieve real governance. Repository capabilities are really what should be considered the seed of good SOA governance.
Whereas your registry acts as an index or phone book where you can discover services, your SOA repository is a complete catalog of the services available for use throughout the enterprise. Instead of just knowing what you have and where they are, a repository helps organizations ensure the proper use of the services they have available. By collecting and storing all of the relevant information associated with your services – not only contracts, but also policies, implementation artifacts, dependencies, etc., and by providing different visibility to those services based on roles and responsibility within the organization – an effective repository strategy promotes greater reuse of services and greater control over how they are deployed and used as part of a comprehensive SOA strategy.
What makes an SOA repository unique is that it involves all aspects of the SOA lifecycle, from design and development through deployment and management. It can provide everything that you need effectively to provision a distributed network of services in a maturing SOA.
For example, a repository should be able store your service contracts, details on implementations, policies covering use of services and other more general information such as authorized users for each service. In short, the repository should contain all the information necessary to redeploy/re-provision an entire network of services. Having these capabilities at hand makes it significantly easier to validate what services are deployed in your SOA environment and to perform ongoing checks against the repository's view of what the SOA should look like.
The world of SOA is maturing and evolving and organizations must too evolve if their SOA deployments are to be successful. Where an ESB used to be enough to get up and running, real SOA success is going to take more. Companies need to be thinking now about their SOA governance strategies and the technologies that will help them achieve their goals. The right repository choice gives customers the means to enable service discovery, governance and lifecycle management across the enterprise.
With these capabilities at hand, organizations are better equipped to successfully reuse existing services, understand the relationships between various services, redeploy/reprovision services as the SOA evolves thus realizing the business agility and flexibility that are supposed to be the leading benefits of SOA deployments.
About the author
Steph Bacon joined Iona Technologies Inc. as vice president of product development in 2005. Prior to joining Iona, Mr. Bacon served as vice president of engineering for Avaki Corporation, a provider of enterprise information integration products, which was subsequently acquired by Sybase, Inc.. While with Avaki, Mr. Bacon was responsible for driving the product engineering, documentation and QA for the company's products. Mr. Bacon has also held senior product engineering positions and managed distributed engineering teams with companies including Broadvision, Object Design and Bachman Information Systems.
