I have encountered numerous people that, when I mention Software-as-a-Service, they say “ah, yes, SOA”, at which point I go into a well rehearsed speech about what SaaS is, as a business model and how different it is from SOA, being a technology trend.
But are these concepts so far removed? Is there a reason why so many professionals confuse the two? So, giving it some thought I realized that there are many points of similarity and interaction between the two concepts.
First, both have been around for a long time. SOA has its roots in the term ‘Software Engineering’. We all know how far apart are the disciplines of writing software and assembling pieces of hardware, but that was the guiding principle. Object Oriented programming, arriving in the late 60’s, promised to change all that with the concept of component programming. Then came CORBA, which was supposed to do the same at the system level, but never really took off.
Software-as-a-Service has even older roots if you consider the Timesharing-Multitasking model that allowed running the same software from a mainframe, on multiple terminals, and all of its subsequent versions. And then, the ASP model which basically evaporated with the dot.com bust.
It seems now, that both concepts have arrived at a point of general acceptance. They just make sense, and the adoption rate is growing, albeit, implementing a good SOA solution is more an art than a science. I believe we will see a higher adoption rate of SaaS than SOA in the near future.
SOA is also a venue enabling SaaS. Many SaaS offerings are now using Web Services as a means to integrate with the backend legacy software and other vendor offerings.
SOA and SaaS are both disruptive (perhaps destructive) technologies. They are changing the way CIOs think about their businesses, and both serve to help IT manage their service easier and more cost effectively. And of course, both are generating a lot of hype.
But think of this: SOA is, after all, software as a service, albeit a different kind of software and a different kind of service. When we think of the Software in SaaS, it is a full, stand-alone application, whereas in SOA the chunks of code are smaller, performing a single business process. And of course the term Service is used differently; in SaaS it is referred to as a business service, not a system service, like in SOA.
Granularity is one of the arts needed to be mastered in SOA. One would like to write a service that is small enough to cater for all applications, but big enough to provide as much functionality as possible. Sounds like the similar dilemma one finds in SaaS; the old 20/80 rule. One would like to write an application with as much functionality as possible, but on the other hand it should be general enough to provide for all consumers.
Now, let’s fast-forward to the future and play the ‘Zoom-In/Zoom-Out” game. Imagine SaaS vendors writing chunks of code that are big enough to accommodate a business process but not a whole application. An example would be code validating a credit card purchase. These modules will provide an interface (standardized) to interact with other modules engineered by the same or different software vendors. Imagine the IT purchasing these modules and assembling their application in-house, from these Leggo service blocks.
These services could reside on-premise or at a service provider. It should not matter nor change the model.
In that perfect world, where SOA has become a reality in IT, the subject of ‘Build vs. Buy’ becomes a non-issue. The need for external applications, provided by ISVs is reduced significantly, whether installed on-premise or delivered as a service. When that happens, the whole ISV landscape will drastically change, and many of the software application vendors will either disappear or transition into providing the service widgets to be consumed by the enterprise.
And in that futuristic world, where software components from different vendors will talk to each other via a standard interface, elephants will be fluttering their butterfly wings on their way to the grand ballroom…
No comments:
Post a Comment