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.

SOA brings many promises to the Enterprise. Chief among these is the ability for IT to respond to ever-shifting business needs. In the current SOA landscape the answers to accessing Enterprise data are the same as they were pre-SOA; namely: SOAP, WS-*, proprietary APIs, etc… Time and experience have told us that these technologies do not in fact really free Enterprise data. This is not a new or hidden concept, yet the technology landscape (driven by SOA), is not changing to adopt to this reality.Right now there are legions of Enterprise IT developers that are either writing custom code to consume complex non-standard Web Services APIs or they themselves are writing their own complex non-standard Web Services APIs. Meanwhile, we are in the midst of a revolution in the human-web. Concepts such as mash-ups, Web 2.0, etc…, are transforming the web into a user-driven, world-wide, application platform. This is a world in which users can mesh and extend data in ways that the shepherds of these data could never have imagined. All of this is possible because the human-web is simple: HTTP, URIs, and (X)HTML documents.

In the computer-web, especially in the Enterprise, there is no unified way to access data. Every data access service, web or not, has its own proprietary access mechanism. Or at best one of thousands of competing “standards” are used. This prevents the computer-web from experiencing the revolution that the human-web is undergoing. The development of novel, user-driven applications and IT’s ability to respond to inevitable business shifts is greatly hampered as a result. The good news is that the tools for solving these problems are already here: HTTP, URI, XML and they are already ubiquitous. Also we already have a set of design criteria (REST) that help usher in this new age of true SOA data access. We can now make the data accessible to users; give developers a unified interface to operate on the data; give Business Analysts common (canonical) representations of the data; and more. Finally, we can leverage all of the lessons learnt (scalability, reliability, security, etc…) by the human-web.

I propose that we call these SOA data access services Resource Services. Resource, since that is a fundamental concept in REST; and Service, well because they are to be services, web services in particular.

As an example, imagine letting a Google Search Appliance loose on a set of corporate data exposed as Resource Services. The resulting index could cross all data silos and harness the power of the Google search algorithms to give (the appropriate) users a wealth of information about their data. Clearly this raises all sorts of security and governance concerns, but that is a topic for another day. This is just a simple example, the key is that we can not possibly think up all the ways that this data might be harnessed, if it were easily accessible via a standard mechanism. It is time to stop imagining this brave new world and to start enabling it.