John Schmidt recently wrapped up an insightful two-part series on the next “big thing” that will help bring data integration along. He notes that service-oriented architecture, which held a lot of promise, has certainly not turned out to be the silver bullet of integration that people had been hoping for. SOA may have disappointed to some extent on the integration front, and now, within the SOA community itself, there has been a raging debate as to whether the ultimate purpose of SOA even is integration. The question is whether the ultimate purpose of SOA should be to serve as a vehicle for application and data integration, or if it should be seen as an enabler of business process management and transformation.
Loraine Lawson has been tracking the ongoing architecture-versus-integration debate, which reveals a chasm between current SOA practices and its ultimate vision. There’s no question, for example, that the main justification for SOA in these past few years has been application and data integration. John Burke, principal research analyst with independent research firm Nemertes Research, has been tracking SOA adoption patterns, and found integration to be the most prominent reason for SOA. “The main reason that they had brought the architecture in was to integrate applications from a variety of sources,” he told Lawson in an interview last year.
Surveys I have been involved with – as well as others in the industry – consistently show that integration is the number-one driver of SOA projects. However, in this context, integration is often seen as a technical driver, versus a business requirement. For example, the most recent Evans Data SOA and Web Services survey of 400 companies, which I analyzed and authored, found that the leading technical driver of about a third of respondents report the main reason they are moving into SOA is to integrate new applications or front-ends with existing back-end applications. Many SOA proponents say by interfacing these applications with common front-ends or APIs, months of costly integration work can be avoided. The second-leading driver, cited by 15% of respondents, is to facilitate the movement of data between back-end systems.
The greatest business driver, on the other hand, was the ability to automate business process interactions between applications, followed by the ability to interoperate with customer and partner systems. Some commentators even say that SOA itself is not about integration, and that a better way to define the methodology may be as “service oriented integration,” or SOI. Todd Biske, a practicing enterprise architecture and author of SOA Governance, defines SOI as “the act of taking the same integration points that arise in a project and using Web services or some other XML over HTTP approach to integrate the systems.” While this could constitute a service-oriented application architecture, these approaches typically serve single applications, and there likely won’t be sharing of services, Biske says.
Burton Group analyst Anne Thomas Manes is even less kind to the concept of SOA as an integration strategy, wondering why money and resources would be poured into something that could be done at far less cost. “All this money is going into ESBs [enterprise service buses] and Web services, and they get a dozen or two integration projects going, but are they getting any business value out of that? I don’t see it,” Manes is quoted as saying. “I don’t think a bunch of integration projects are worth $20 million.” Instead, SOA should facilitate wider-reaching business process management (BPM) initiatives, Manes is also quoted as saying.
Done right, however, SOA begins to provide greater visibility of data sources across the enterprise – and this is an important step in the evolution toward frictionless data integration. As Nemertes’ Burke points out: “We did speak about data integration and sort of treating data as a service in that respect, and the topic mainly came up in the sense of, ‘This turned out to be a rock that we kicked over and found a lot of ugly things crawling underneath.’ Because when you start to roll out SOA-based integration of applications in house, or a third party, you start to break down barriers that existed in your infrastructure.”
There’s no question that SOA represents an important step toward sharing and linking resources across the enterprise – an advantage many organizations have not had up to this point. Other approaches, such as Integration Competency Centers and Lean Integration as John recommends, will take these capabilities to the next level to facilitate even greater alignment with the business.