Based on feedback from my last blog entry, “The Busy Executive’s Quick Cloud Computing Reference Guide” the consensus was that people found it very helpful as a means of gaining quick understanding of what Cloud Computing is without getting mired in heaps of technology jargon and hype. So, I decided that SOA needed something very similar. After all, there’s so much confusion and misunderstanding of SOA in the market right now.

Let’s start with a basic understanding of a service. There are lots of things that you can call services, which is where many of the problems arise for SOA. I believe that the use of the word service in context of “Service Oriented Architecture” connotes a particular meaning that filters out most of non-applicable definitions of services. To further illustrate this meaning, I will discuss services in the context of software services so as to clarify the differences between SOA and not-SOA.

First, SOA is an architectural approach designed to identify and delineate business functional boundaries within a particular domain. A domain can be a single organizational unit or an entire industry. Regardless of the domain, if there are interactions within the domain, then there is most likely more than one unique business functions used to complete those interactions.

Many times, and more often with larger domains, there is more than one way to accomplish a particular task or objective. When a domain is required to support multiple paths to a singular end, it has been identified that the redundancy has an associated cost. Removing that redundancy results in efficiencies and cost savings. Very simply, SOA is the initiative designed around identifying the domain goal, marking the necessary business functions boundaries required to reach that goal, consolidating these business functions so that there is no redundancy and then orchestrating the process to reach the goal against the resulting set of business functions. The identified business functions are your services. Note, without these business functions you cannot complete your mission and achieve your task.

Most people agree on the following regarding desirable attributes of a service. We use them to do work for us that we don’t want to do, we want them to be consistent and reliable, we want to pay a fair price to use them and we don’t want to own them, and we don’t expect to still be responsible for part of the job after hiring the service. If you hired a landscape service for your house that was supposed to prune your shrubs and you still had to go out on the weekends and clip the hedges, chances are you’d fire that service provider.

All the “chatter” in the media and on the Internet would have you believe SOA is very complex and requires expensive software and expensive resources when all we’re doing is looking at a particular domain and figuring out how we can chop it up into a group of services that work together. For example, a landscape service and a mulching service have particularly good synergy, would you agree? These are two distinct services, but they have what we call a loosely-coupled relationship. That is, they work together for the duration of a task and then go their separate ways.

Granted, the task of looking at a domain and breaking it down into a set of services is a strategic skill that requires an experienced practitioner, but formulating the boundaries and putting the governance around those boundaries in place can be done by current management.

Now that we have these critical elements defined, let’s compare three different topics of software that have all been associated or labeled SOA. Of the three, only one is truly SOA. These three topics are: Software-as-a-Service (SaaS), component-based software development and real SOA.

Why Isn’t Software-as-a-Service a Service? To answer this, let’s return to our agreed upon attributes of a service. SaaS meets one criteria we defined for a service—we want to pay a fair price to use them and we don’t want to own them. However, most SaaS is just rented software. You’re still responsible for integrating your data with the SaaS application after you rent it. You’re still responsible for configuration of the forms and workflows after you rent it. For me, SaaS fails to meet the other key attributes of a service.

When many technologists and IT specialists discuss SOA, what they most often really mean is component-based software development. Many people in the IT industry have used the label SOA to describe a way to build software systems. This is possible, if the software represents critical business functions as we will explore shortly in the discussion of real SOA. However, in these conversations you will also hear things like SOA platforms and utility services. These are sure-fire indicators that the discussion has degraded into software design methodology and has left the realm of SOA.

Here’s why there’s no such thing as a “utility” service and it’s just a software component. If the business itself would be less scalable or cease operation because the service is not available, then you have a service. If the mulching service doesn’t show up when the landscaper is there, the landscaper cannot complete their task.  Whereas, the utility service concept is a technological artifact of a software or solution design. The software providing the business service could exist without the existence of the utility service. The resulting solution may not be as modular of a design and, perhaps, not offer the service provider, the preferred level of agility and flexibility, but the service consumer would be no worse off than if you decided not to build a utility service, but instead, developed that business logic directly in to the software itself.

The last topic is SOA and real services that are comprised of software. The best way to describe this is to look at a couple examples of services that I have developed over the years.

The Alert Service – This is a software-based service that was used in data center management to notify personnel that a problem had occurred. A user or another piece of software could create an alert and it would send the notification via a number of mediums, such as pager, fax, phone, email and printed ticket. This software took care of the entire task, didn’t have to be built for each individual usage and delivered the one and only one way to perform the task goal.

Zero Bond Calculator Service – This is a software-based service that provided various zero-coupon traders with a consistent means of quoting a zero coupon price. The service happened to be accessible via Excel, but could have been offered via phone or other mediums if necessary. The trader provided the inputs and the calculator service provided the pricing. It consolidated the various approaches to pricing used by each different trader, thus minimizing the overhead of the trading desk. Again, it took care of the entire task, didn’t have to be built for each individual usage and delivered the one and only one way to perform the task goal.

In each of the aforementioned examples, the software represents a business function that was implemented using software because it was easily automated and reduced the need for human labor. However, because it was implemented in software, does not, in and of itself, make these services. It’s the role they represent. These services allowed the business to reduce complexity, consolidate around one way of achieving a goal and do so in a way that was agile and flexible. Moreover, while they are not dependent upon one another to provide value to the business, one could easily see how they could work together synergistically to ensure high-availability of the zero coupon pricing calculator for traders.

That’s SOA in a nutshell! Identify, consolidate, orchestrate and govern a set of business functions or capabilities.