Roughly half the group reported service-enabling mainframe assets, while roughly two thirds consumed assets from packaged apps like SAP or Oracle. For a run-time governance tool like AmberPoint’s, that means instrumenting a transaction flow that might begin with a SOAP request and tie with an Amdocs document management system API.

Agility was by far the biggest driver for SOA projects, cited by three quarters of the sample. After that, “stovepipes” (a code word for the need to integrate application or data silos) and long lead times were each cited by just under half of the respondents.

As to how far along this group was, nearly 60% stated their SOA projects were either in development or pilot. The early stage of SOA adoption was also evident in t he number of components that were involved in the implementations: 45% of respondents reported that their projects had 10 or less components, while another 27% reported only up to a couple dozen components.

But for the other 40% of the sample who reported their SOA implementations in production, the results buttressed the integration angle, with only 9% of the entire sample stating that their SOA projects were confined to a single department or business unit. By contrast, a third of the sample said their projects spanned multiple departments and/or involved external business partners.

So how successful were the projects? Somehow, we’re not too surprised that barely 1.5% reported that their projects did not meet their goals. Given that, as the data showed, SOA is still in preliminary stages for most of the sample, we’d take this low figure with a grain of salt. For instance, when client/server systems were rolled out, the initial perception was that they made end users more productive as the fat visual client apps made enterprise systems more accessible. Only later did the costs of maintaining all those fat clients, many of which were unique to each workstation, become apparent. On the SOA side, that phenomenon would be, as SOA blogger Joe McKendrick characterized it, JBOWS (Just a Bunch Of Web Services) – you spawn those services because they’re so easy to spawn, and wind up with a proliferation of redundant offerings that wind up costly to maintain.

---