I viewed a webinar today featuring a senior integration architect at Bank of America talking about how they use webMethods to facilitate their massive integration efforts, apparently with some degree of success. I liked the admission by both the customer and vendor that SOA is an architectural design approach of loosely-coupled components, not a particular technology or product, although products can obviously help you to build a service-oriented architecture faster, cheaper and in a more standardized manner.
This definitely put me in mind of a recent engagement where I spent a year as the acting application architect for one business silo within a financial institution, facing many of the same business and technology challenges as BofA. I also sat on the architectural review board, so had a view of the common challenges across the entire organization and the technology infrastructure being deployed to address them. Almost all large financial institutions got big through a combination of acquisition and growth, and both of those growth methods can lead to disparate systems in the back office — even within one silo — that don’t intercommunicate well (if at all), which in turn leads to a lot of internal inefficiencies and a less-than-optimal customer experience. Furthermore, most organizations are not set up to share across the business silos, so attempts to create common infrastructure such as those that support SOA can be tricky unless an architect is empowered to work across the silos.
As you move up the services stack, the focus changes from the base services and registry layers (where webMethods plays) to orchestration, where services are assembled into processes that relate to actual business processes (you knew that I’d get around to process eventually, right?): the task flow and BPM layers in the integration stack that I referenced previously, although the lower levels of that particular stack are MOM (“first generation SOA”) rather than XML-based web services (“second generation SOA”). As you bring these concepts together, and especially when you start looking at the technology stacks, it becomes obvious that you can’t have an effective BPM strategy without SOA. You can implement BPM without SOA, but it won’t have the ability to become the strategic orchestration layer that’s required to pull together disparate systems and provide new integration functionality in the future.