We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

Has SOA delivered on integration?

Vote 0 Votes
An excellent question brought up by Loraine Lawson in this blog, Did SOA Deliver on Integration Promises?

8 Replies

| Add a Reply
  • If you look at SOA as 'point-to-point-integration-using-web-services', then it provides little value, primarily improved technical interoperability. Frankly, point-to-point-integration-using-web-services is not SOA at all.

    Adopting SOA changes the way we think of app integration. SOA first focuses on creating repeatable business capabilities. If creation of a business capability requires multiple systems to work together, then they have to be integrated 'behind' the service that delivers the capability. Then, as these business capabilities get consumed, they connect the integrated apps to others apps and processes in a repeatable but loosely coupled fashion.

    In other words, app integration becomes a 'by product' of creating and consuming business capabilities.

    We have now seen many examples of how the SOA approach is much better than the point-to-point approach of connecting systems.

  • SOA isn't responsible for delivering integrated applications to your business any more than your copy of The Joy of Cooking is responsible for delivering Stuffed Boar's Head (yes, the "treasured Christmas tradition") to your dinner table. Each is responsible for presenting the general approach, but it's up to you to execute.

    People still seem to think that SOA promised them something. (Vendors, yes. SOA, no.) SOA has succeeded for some and failed for others, but don't blame the cookbook if you didn't follow the recipe.

  • If SOA means breaking up silos, and Integration means making silos talk to each other but keeping them around as silos, then delivering on integration promises means not delivering on SOA promises.

  • Loraine is correct in her article that I didn't mention SOA's integration benefits, and that this tends not to come up very often. If anything, SOA acknowledges that there is a lack of integration under the hood (or in silos) of enterprises, and seeks to surface only those bits of functionality, as common shared services, that the business needs.

  • Integration taxnomy includes a variety of integration scenarios including Basic Middleware (e.g. Database to Database integration), Integration Middleware (e.g. ESB, BPM) and Integration Applications (e.g. Application Adapters, BAM). SOA deluevers Integration promise as far as Integration Middleware is concerned. ESB's Standard based Service Integration is easier more flexible and cheaper than former ways of integration.

  • I like Marc's response to this question. It was certainly the first thing that came to mind for me when reading the question. The goal of SOA was to provide a paradigm for service orientation, not integration. All too often people consider SOA to be EAI 2.0, but it's not.

  • Much of what SOA was related to in the early days were the Web Services standards that enabled much quicker, cost effective integration of data and business logic.

    One of the goals of 'SOA' was the concept of using best of breed technologies that integrate together. The idea that you could pick the best technology for the job whether it was from vendor a, b or c and it would work with the best of what vendors x, y and z delivered was a very attractive one.

    Yet abother goal of 'SOA' is reuse of services which comes down to the core of the question here. If the SOA stack is proprietary, it makes integration with other technologies and thus reuse from them as difficult and expensive as it ever was.

    However, the larger vendors have sadly dumbed down what was promised by insisting on buying 'their' SOA stack of software and provided some integration possibilities using standards on the outside but with proprietary internals with dependencies on their particular stacks.

    If SOA only promised that we would have services, any well run IT organization has been building 'services' for many years that are still reused on a regular basis today.

    From my perspective, the promise of SOA was to allow better, more cost effective integration between best of breed technologies that could then deliver the services that the business required throughout the enterprise. The easier integration facilitates a level of reuse not possible with proprietary stacks. If people believe SOA is simply a fuzzy conceptual thing, then we have nothing new as we have been implementing SOAs for years.

Add a Reply

Recently Commented On

Monthly Archives