I have been involved in a number of discussions recently on the topic of what it means for software to be service oriented vs. service enabled. As a software vendor that markets service oriented software that service enables existing infrastructure this distinction is clearly important to us, but why should you care? This distinction is relevant to anyone investigating or applying SOA business solutions, using SOA suites or ESB technologies because understanding this distinction will inform you of what you are getting into and what you can expect for short and long term TCO and ROI.

There is much discussion on the topic of what level of granularity or coarseness right-sizes your services. The reality is that to get the full benefit of service enabling an existing system one has to implement a pattern of services that are semantically related and scale from fine-grained to coarse-grained services many times over.

For example, if we look at the data access services, we should see a large collection of really fine grained services that operate at a resource or transaction level of scope. This builds the pattern for information access and defines what is available. Ideally, these services would deliver their payloads through composition with a Canonical Information Service, but that topic is for another blog post.

As we pull back to “zoom out” of the coarseness of services, we suddenly see that the set of services are semantically related but providing composite services such as BPM sub-processes, embedded data flows and higher level services that drive workflows assembled directly from the collection of finer grained services and composed with business rules, analytic models and other services.

Now we truly have the infrastructure of services required to power business process agility and compose composite applications that can draw on and mash together business information in a dynamic manner with business rules enforced at every level of service utilization.

Because the pattern is the same at every level of granularity, I call this Fractal SOA. You can use Fractal SOA as a test to determine if you are looking at something that is service oriented or just service enabled. You can also use Fractal SOA as a model for implementing your services when planning and deploying your SOA. Ideally you would use a technology that is service oriented and supports this architectural approach directly (here comes the shameless plug) such as our SOAppliance.

You expect your existing IT to get service enabled, but how will that be done? Here you want a technology set that is service oriented, not service enabled. When you peel back the veneer of that ESB or other SOA infrastructure suite your vendors are showing you, you should see a set of services, not a wrapper-ed EAI or a semi-proprietary publish/subscribe messaging infrastructure. If it doesn’t look SOA on the inside, its not Fractal and therefore is itself a service enabled technology that will ultimately limit the ability to truly service enable your information environment.