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.
BPM is your friend
BPM (business process management) tools are playing an increasingly important role in early SOA planning.
For years, IT has lacked insight into higher-level process. And ineffective tools for business analysts have stymied efforts to sync processes back to systems. But BPM tools have evolved, becoming increasingly standards-driven -- and because an SOA should be rooted in processes, BPM has become a great starting point for bridging the top-down and bottom-up approaches that SOA demands.
When companies roll out full BPM suites, they gain cycle integration benefits down the road through automation, monitoring, and more fluid control of assets in quickly changing business climates. Thanks to the componentization of services, business analysts can more quickly remodel applications without needing to hire a full IT construction team.
Can you get by without BPM? Of course you can. Smaller deployments and those without explicit requirements for higher-level orchestration, workflow, or the involvement of direct human interaction -- that is, primarily implementing system-to-system connections -- will find BPM to be overkill. But in large enterprise scenarios where applications span divisions and corporate boundaries, the inherent capabilities of a BPM engine benefit long-term processes effectiveness and, more importantly, cut costs for ongoing adaptability.
The bottom line is that no pat methodology for SOA modeling can apply across the board. But certain best practices are clear, beginning with a commitment to formally involve all stakeholders early on to analyze business functionality and build consensus on key areas where transformation will deliver the biggest strategic impact. And if from the starting gate you employ registry and repository frameworks with built-in tools for domain analysis and governance, you will vastly reduce the risk of losing control over your SOA initiative and will reduce costs over the total lifecycle.
With a holistic perspective and a real meeting of the minds during planning, effective modeling will create a solid foundation for next phases of SOA development.