Yesterday we hinted at the confusion between Software-as-a-Service (Saas) and Service Oriented Architecture (SOA). Dovetail Software from its beginning has had a vital interest in the delivery and reuse of services in conjunction with the Clarify legacy install, through its APIs and now also through Dovetail Web Services. Unlike Saas however, these are employed within an on-premise deployment, completely within the control of IT.
Despite being the ugly duckling of today’s acronyms, SaaS holds tremendous promise for enterprise evolution, but perhaps only when deployed in conformance with ongoing architectural development.
Jason Bloomberg, senior analyst with ZapThink, has illustrated in a compact way the chasm of misunderstanding that lies between the architectural model of SOA, which determines how software is structured, and the delivery model of SaaS, which determines how software is used.
”’Let’s say you offer a Web service via SaaS and you have many customers consuming it. Now, say it’s time to update that service. What happens to all the consumers? Do they break? Do they have to manually update their software? Either option exposes tight coupling between service consumers and providers—an SOA anti-pattern in this case.
“An SOA approach to SaaS solves this problem, Bloomberg said because SOA can provide ‘a predefined versioning policy in place that states that consumers must take a specific action every month to ensure they are on the latest version, for example, by automatically downloading an update and that the services will change versions one day after the consumers update. Now, it’s possible for the consumers to automatically remain in synch with services as either or both change versions. That’s loose coupling in action and an illustration of the power of SOA.’” – SOA and SaaS: Where do the twain meet?
Indeed the engineering of reuse is a labyrinthine project, the horizon of SOA and the terrain of enterprise architecture (EA). EA consultant John Wu over at ITtoolbox has written a long and detailed, summary specification for just such a task. He presents a surprising notion:
“Engineering of reuse is business oriented by learning the solution from the similar line of business. Again, there is nothing under the sun, it is not necessary to reinvent wheel. The best way to learn experience of others is to leverage on the solution patterns from the similar line of business. The engineering of reuse must be business oriented rather than technical driven.” – The Engineering of Reuse
Burton Group has recently released a report that cautions enterprise architects not to get carried away with the speed of SaaS deployments, and not to let the overarching architectural considerations fall away.
“SaaS as well as SOA and agile development principles have all come about because of the business demand that IT be more nimble in dealing with changing business requirements, Creese notes. But he cautions that architects should not get carried away by the need for speed.
”’The risk is in letting the speed of technological change override business prudence,’ he writes. ‘Just because an enterprise can quickly change system behavior doesn’t mean it should. A “simple, quick change” can wreak havoc if the company doesn’t think it through—if, in the rush to make the change, the enterprise doesn’t consult the affected divisions or check the appropriate regulations.’” – Burton cautions architects on SaaS
None of this is to say that SaaS is a poor model. To the contrary, SaaS is booming precisely because it fills gaps that the longer range evolution of the cross-enterprise strategic vision can’t always fill in time. But it becomes apparent that deploying SaaS as a strategic move instead of a tactical (or the reverse) can result in failure.
“Then there are those companies that are completely embracing SaaS throughout the enterprise, using it to support more complex CRM processes. Examples might include real time integration of a SaaS application into an enterprise’s back-end or cross-departmental processes.
“For such firms, projections that Gartner released last year may be particularly dismal: Through 2010, 75 percent of complex CRM SaaS deployments will fail to meet enterprise expectations.” – SaaS Best Practices, Part 1: Implementation Checklist