And what about the ever-present, existential question: To build or to buy? "You build it if you have to, not because it's fun," says Bill Conroy, enterprise architecture senior business executive for Bank of America. According to Conroy, Charlotte, N.C.-based Bank of America ($1.2 trillion in assets) has a well-defined set of rules for its SOA-enabling technology. "Partnership, purchase, then build if you have to," he says. As a rule of thumb, anything that's commoditized, the bank will buy. But if the technology is differentiating, is intellectual property or is of strategic value, then the bank will be more prone to build, Conroy notes.
For its SOA project, Wachovia required that all its technology be componentized and capable of being extracted -- nothing could be hardwired, the bank's Bishop says. Wachovia didn't want any technology built to a specific language or a specific format. "This is where a lot of SOA strategies fall short," Bishop asserts. "A lot of people in the past would build business logic and need to inherit that it was running on a Java container. We didn't want that. We wanted to reuse so that it could be moved about in different ways."
Bishop distinguishes service-oriented architecture -- SOA -- from service-oriented infrastructure, or SOI. "Think of it like you're building a house," he says. "SOA, the set of services, would be the rooms. But the actual foundation -- the plumbing, the wiring, the heating and cooling -- would be the SOI, what you need to run and operate [your SOA]."
According to Bishop, he bought a lot of best-of-breed technologies that are open standards-based and pluggable. "On the client side, we just leveraged the .NET framework from Microsoft, so that was really more of a leverage of the development tools," he says. On the server side, Wachovia's CIB division leveraged open source from JBoss (Raleigh, N.C.) and grid server and fabric server from DataSynapse (New York). It also used Tibco messaging, IBM (Armonk, N.Y.) data power and data caching technologies from Tangosol (Somerville, Mass.) on the data side. "We married those into hardened versions -- almost like solutions stacks -- so that the application developers don't have to think about how they combine them all," Bishop says.
Governance From the Top
But without the right governance, even the best SOA technology plans can go awry. "Left unmanaged, services can rapidly degenerate into a tangled mess," warns The Butler Group in a recent report, "Planning and Implementing SOA."
To manage business components and services along with infrastructure services and components, Wachovia's Bishop relates, the bank's CIB division created a portfolio management function, in terms of personnel and tools, to govern the project and track the usage of those elements. The first step was to create an open source community, which set specific rules in terms of what the CIB's business units could contribute or use, according to Bishop. The second step was to establish peer groups across the various applications to understand who built what, how it was being used, who reused what and how it was reused, he adds. The third part of the governance plan included mandates that each development team contribute and/or reuse various components of the SOA as part of their annual objectives. And finally, Bishop notes, the CIB division created a steering committee that prioritized projects.