In a recent blog post titled “SOA without service-enabled applications?”, Joe McKendrick points to a big misconception in the I.T circles about achieving an enterprise-wide service oriented environment - that every providing system has to be ‘service enabled’ to achieve SOA. He is right, services that are built from the functions of the underlying applications need not be part of the applications themselves, in fact in many cases it should not be too, in my opinion.
Everybody (including those saying SOA is a dead cow; no more milk-able that is) accepts the importance of building a ‘business services network’ in enterprise I.T these days, and such a layer can be built as an isolated layer above the business applications, though I wouldn’t say we would need a ‘ commercial SOA stack’ to achieve the same. Taking this approach has many advantages, including composing coarse grained business services from multiple underlying system functions as well as achieving better loose coupling levels.
Another advantage that I see is that, as enterprise environments are consuming more and more externally hosted services(yes, I mean the SaaS, Cloud stuff), the business services layer will help provisioning these services to the enterprise consumers easily because all we have to do is to connect it through the business services layer. This kind of an approach I would say make one of the key enterprise I.T concerns today - how to replace internal systems with Cloud/SaaS services - addressed better as well because now there is a clear abstraction between the consuming systems and the providers, the consumers just have to point to the same end-point in the business services layer no matter whether that service is provided by an internal system or an external one.