Todd Biske: Outside the Box

While doing my thinking outside the box, I ran across Joe McKendrick’s post discussing whether SOA can be boxed. Joe provided commentary on a blog entry from Jack van Hoof who called out that the major ERP-vendors could potentially deliver “SOA in a box.” He points out:

SAP offers a service bus, service registry, events registry, canonical data management, business processes, services deployments (!), business monitoring, business process management, security… out-of-the-box. Yes, of course the implementation must be tuned and configured. But it’s all there, out-of-the-box.

There’s a certain amount of truth to this statement. It’s probably better stated as services in a box, because after all, it’s a box. We have no idea what the underlying architecture of SAP is. While it may be the case that SAP or any other large ERP system could constitute the bulk of your infrastructure, that doesn’t mean that you’re suddenly purchasing an SOA. If new business needs come along, it’s now up to your ERP system to provide those capabilities. If they’re new, then it’s the ERP vendor who must figure out how to quickly make the changes necessary, if they even choose to do so, since it would have to be something with broad customer applicability to make financial sense for them. It’s certainly possible to build custom code on top of the ERP system, but you’re always going to have that dependency. That’s not necessarily a bad thing, you just have to choose wisely on where to leverage the ERP system.

I’d like to pick on one comment Joe made in his commentary. He stated:

…the idea of buying all SOA from one vendor flies in the face of the ultimate meaning and purpose of SOA — the ability to pick and choose tools, applications and services from any and all vendors. SOA is supposed to mean the end of vendor lock-in.

I don’t agree with this opinion. While services can be used to create an abstraction layer from vendor products, I don’t think it needs to be a goal. The factors that influence whether an organization leverages one vendor, lots of vendors, or no vendors really doesn’t come into play at all. What SOA should do is assist you in making appropriate vendor decisions. Just as I commented some time ago that SOA should neither increase nor decrease outsourcing, but instead ensure increase the chance that outsourcing efforts are successful, the same holds true for choosing vendors. By breaking the problem domain down to a finer-grained level (services rather than applications), I can make better decisions on the vendor products I choose. If they don’t expose services for the capabilities I need, I’m going to look elsewhere. The only thing that could start leading toward better insulation from vendor lock-in will be more standards in the vertical domains. There’s plenty of standards out there, but there’s probably far more spaces that are not standardized.

So, what’s my advice? I don’t think you can buy “SOA in a box,” you can only buy “services in a box.” Your enterprise architects need to be the ones defining the architecture, and then leveraging the architecture to ensure that not only your home grown systems, but also your vendor systems, whether from one or many, adhere to it.

One Response to “Services in a box”