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
