The terms “Software-as-a-Service” and “Service-Oriented Architecture” get thrown around a lot when it comes to discussions about business computing. And much too often, people use these terms in an improper context. Although they might seem similar, they could not be more different.
Explaining the difference can be a bit hard, since some of the concepts involved are a bit difficult to understand. But the most important thing to know is that:
- SaaS is a software delivery method, and that’s all
- SOA is a methodology for designing and automating business processes
- One is tactical, and the other is strategic
Software as a Service
This is the one that everyone should be familiar with by now. SaaS simply describes a business system where everything – or almost everything – is hosted remotely on the provider’s server. This can be a public cloud where you pay a monthly fee to access an application on a service provider’s system. Or it can be a private cloud where employees do all of their work on a primary server through remote terminals.
Each one of us has used a SaaS application at some point. Most of us have web based email, web hosting accounts, and we probably also manage our taxes online as well.
I won’t go into too much detail, since this concept is fairly easy to understand.
This one right here is the hard part.
SOA is a fairly difficult to grasp, and many people have required months of education just to get their heads around it. In order to touch on some of the core concepts behind SOA, I’d like to present a short story that illustrates some of its more practical applications.
Bill’s Clothing has been in business for over 5 years, and they’ve grown to the point where they can no longer operate efficiently as a single business unit. So Bill splits the company into 4 subsidiaries.
- Bill’s Clothing Group Of Companies (Head office)
- Bill’s Shirts
- Bill’s Pants
- Bill’s Hats
When it was just one company, all customers were treated the same regardless of what they were purchasing. So the company only needed a single invoicing and shipping system. But, after the company had split up, the nature of the work in each division changed drastically. And these changes became more pronounced as the company continued to grow faster.
In order to work more efficiently, each division adapted their invoicing/billing systems to suit their new business processes. Although this created efficiencies and cost-savings across each division, it also caused a lot of problems between the different business units.
Because there was a lack of standardization, similar transactions were given different names, treated differently, and recorded differently to the financial systems. As a result, errors were common and the companies wasted a lot of money performing duplicate tasks.
This also made budgeting and strategic planning difficult, since the company had a hard time understanding where they stood financially.
With Service-Oriented Architecture, each division could develop and adhere to their own processes, while also sharing a common invoicing and shipping system with the rest of the company. Instead of giving each division their own systems to modify, “invoicing and shipping” becomes a “service” which can be made accessible to developers.
A service is similar to a “class” or “function” that a programmer would use. Except that a service is not a block of computer code. Instead, it’s a business process that has been computerized.
All of the business units share the same service on the corporate system, but they modify it to suit their purposes. If one business unit needs to make a change to the shared service, this change is applied to the service itself. The end-user does not get their own isolated custom-application.
Because everyone shares the same service, any new features must be added based on a set of principles that apply across all units, and all similar information is treated in the same manner.
Business rules can be applied and enforced more effectively, the company runs more efficiently, and applications can be deployed and modified much more quickly.
This example gives a very rough overview of how SOA works.
The main thing that should stick out is that SOA makes no reference to whether or not these services are deployed over the web. You could deliver it via the Internet if you wanted to, but that would have nothing to do with whether or not it’s a true Service-Oriented Architecture.
Also, the invoicing and shipping system mentioned at the beginning of this story could very well be hosted through a SaaS provider. But because this isn’t true SOA, individual units could modify these systems themselves and define data differently without adhering to any agreed-upon standards. For this reason, you can’t call it SOA. It’s just a web-based application.
I know I’ve gone into a lot of detail over this article. So I’ll cut it short for now.
But if you have any other questions relating to these concepts, please leave a note in the comments below and I’ll gladly try to answer them to the best of my abilities.
EDIT: The comments are temporaroly disabled due to spam/time constraints. Please feel free to contact me directly with your questions. I will try to respond in a timely manner.
Image Credit: http://www.flickr.com/photos/ethnocentrics/213327033/sizes/s/