Packaging SOA: What serves the customer?

January 30, 2008

Packaging SOA: What serves the customer?

I was talking to a CIO the other day about the whole area of Service Oriented Architectures. It was one of those interesting probing discussions around key players, emerging technologies and the like. One of the interesting topics that came up was around packaged software. This CIO was confused about a major issue. What is the benefit and danger of implementing a package software offering that has all the industry best practices, business process, and middleware integrated together. What are the opportunities and risks of this approach? Likewise, what are the risks of buying piece parts and integrating them together?

This is an important question and one that I have obvious opinions about. I think that it can be dangerous for companies to buy a too well integrated SOA environment from a single vendor. While it might seem like the path of least resistance might be to just buy an entire software suite from a company like SAP or Oracle and be done with it. While this may seem like a pretty straight forward question it actually is much more complicated. On the plus side, a customer could get a head start by using a SOA model where everything is designed to work together. On the other hand, I would submit that this approach is antithetical to the reason companies are approaching SOA in the first place. Companies are moving to SOA in order to create a flexible, modular environment where it is easier to add or subtract components based on either a new business initiative or a new innovative technology. If the SOA platform is too well integrated, change becomes hard.

So, what did I suggest to my CIO friend? I told him that it is better to look at packaged software as components in an overall SOA strategy rather than the lynch pin of that strategy. It is better to begin with the overall business strategy and an Enterprise Architecture and select technologies that are designed with standardized interfaces. The foundation should be based on loose coupling of services.

A packaged offering can work if customers finds a package that is standards based and extensible does not lock them into one perspective on the world. I think we’d all like to have a world where you just buy what you need off the shelf and life is good. But unless you are buying a commodity, I think the world is still too complicated for packaged SOA. Are there SOA commodities? Of course, for example, a set of best practices that are well understood across a broad spectrum of customers can be packaged as a business service and used broadly. Even a large service such as those offered by ADP is an example of a service offering that is well understood and not differentiated. Who would want to write their own service for managing payroll.

I do think that there will be a time when the SOA software market has matured to the point where building blocks are mature and well structured enough to be able to link together services smoothly and easily. But I don’t think we are there yet…do you? Let me know what you think.

About Judith Hurwitz

Judith Hurwitz is an author, speaker and business technology consultant with decades of experience.

One Comment
  1. […] Hurwitz raises some of the pros and cons of SOA buy versus build in a recent post, and talked about the understandable confusion a CIO was feeling toward moving to SOA via packaged […]

Leave a Reply

Your email address will not be published.