In almost all SOA initiatives, the most important initial steps have nothing to do with choosing or deploying software.
First and foremost, modeling an effective transformation demands a comprehensive understanding of existing business assets, processes, and the technical landscape already in place within your enterprise -- and frequently beyond its walls.
That may seem obvious, yet some companies lack an appreciation for the scope of true SOA adoption. Often, organizations familiar with benefits gleaned through early Web services point solutions anticipate quick returns that discount proper planning and allow projects to be commandeered by IT too early in the process.
SOA is really about process and integration. The goal here is to bring IT into alignment with business as well as to isolate redundancies, to fuse process overlap, and to consolidate siloed assets so that a foothold on efficiency may be gained.
Before you can begin to map processes and decompose applications into reusable services, however, a holistic view of operations is necessary to ensure proper and complete assessment. This also serves as a basis for identifying key areas where SOA transformation will offer the greatest impact.
At this planning stage you must gain an accurate understanding into the span of business components across the enterprise: processes, applications, people, and data.
Accomplish this by establishing a steering committee made of leaders from business units across the enterprise, whether affected directly or indirectly, and without regard to current organizational divisions. Plan to gather not only process engineers and IT but also everyone from finance and compliance agents to warehouse management and HR.
This may seem excessive, but a full-on mapping process is necessary to obtain a complete picture of how you're transacting business today. And that insight will provide the necessary data to map an accurate course for consolidation through SOA.
Tools of the trade
It would be fabulous if a comprehensive cradle-to-grave toolset for SOA existed, but there are as many approaches in play as there are scenarios to model. That being said, several bundles of tools are coalescing around common functionality and offer features your enterprise shouldn't be without. When selecting a modeling tool, demand the ability to export code that can be easily read by development tools. A close fit with your IDE and support for key SOA model-driven standards will be mandatory when you move to the real-world application-development process. Also ensure support for registries and federated repositories. Distributed development demands strict control of assets, particularly in an increasingly outsourced world, not to mention assurance of ready reusability.
For smaller companies, SOA is taking shape with simple MDA (model-driven architecture)-compliant UML tools that can read and write MOF (meta-object facility) metadata. UML tends to be too technical for business analysts, unless well-articulated through domain-specific language mappings, so integration with process modeling tools is important.
Large-scale enterprise SOA, however, will require sturdy tools for registry and repository modeling. And management must be able to reign in the varied and distributed services and assets during the entire lifecycle.
Plan to use registry and repository tools -- such as those from Flashline, Infravio, Logic Library, Systinet, and the like -- that are good at graphically abstracting the UDDI interface. Onboard modeling tools help establish asset metadata and taxonomies that can be mapped less technically by analysts, shortening the ramp up to productivity.
Although you might be able to get by with a registry-only product (say for internal services or a small number of partner-specific targets), use of a complete registry and repository combo is required in most cases for full governance capabilities later on.