This is the theme of an article by Ephraim Schwartz on SaaS. Ephraim and I agree on an essential point: “My biggest rap against SaaS has been that the multi-tenant architecture demands a great deal of standardization in business processes. It does not allow a company to address processes specific to its industry segment. In other words it does not easily allow for competitive differentiation through customization.” But Ephraim argues that this weakness is also a strength in certain situations – most notably compliance and collaboration with suppliers and other stakeholders. In the case of compliance for example – “there is no competitive differentiation here, either you comply and can prove it or you cant”.
Ditto in other areas of industry standards and collaboration. SaaS can act as an honest, neutral broker of standard collaboration practices for exchange of information that goes well beyond the WSI and other Web Services (and sometimes SaaS even employs these same standards). But this assumption is based on a relatively stable data and operational models with associated stable APIs. Heretofore, the SaaL-Software as a License model has done the opposite.
SaaL has said to clients and users: you are totally dependent on us the software maker through the EULA you have signed. This is a total dependency to us the software provider for whatever maintenance, support, service and schedule and scope of updates we deem appropriate. Now some software vendors have taken this to an extreme and have effectively said to customers: in cases of conflict customer requirements versus our need for attaining 90%++ market share, our need for attaining 90%++ market share wins conclusively everytime.
For example, in the move from Visual Basic 6 to Visual Basic.NET Microsoft said unilaterally to its developers and customers here is how the new VB-Visual Basic will work – take it or leave it. And if you take it we will provide a utility which will get your thousands of programs 60-90% of the way to VB.NET but then you are responsible for getting the rest of the way there. It looks Vista will provide Microsoft users several of these painful “options”. But this is not a Microsoft-only phenomena. Home and corporates have surrendered much to their SaaL providers. Apple has taken its user base and developer pool through some gut wrenching changes with its MacOS and hardware platforms in the past 25 years. Ditto for Macromedia and its Flash users and developers in just 10 years.
One of the attractions of Open Source and SaaS is that they start to redress the balance. Each promises to provide users with better support, service, maintenance and … uhh, well on the scope and schedule of updates … well, uhhhhh we will see. Well SaaS is now saying one of the advantages of using us is our stable and standard (as well as secure and performant) APIs. Trust us – we will make changes to them with great discretion. Well this party is from Missouri – and with two good reasons.
First, in both Web Services and n-tier, heterogeneous development all three software layers: Presentation, Persistence/Storage, Communications/ Messaging are up in the air in terms of best models, design structures, and solution frameworks depending on the specific requirements and problem set. This means despite the best of intentions, solving some n-tier problems may force the issue and require major API changes.
Second, software dvelopers, whatever their ilk, are strongly disposed towards benevolent dictatorships as far as the scope and schedule of updates and improvements to their software. A huge No-Prize will wing its way to the reader who came name 3 OpenSource, SaaS, and SaaL developers that allow their users to determine the schedule and scope of software updates.
The closest to this type of privilege appears to be some scope and schedule to its developers by Sun in the Java Community Process, some scope to its users by SAS and IWay, and some scope to developers by Apache, Eclipse and other communal Open Source. However, do not underestimate the attraction of stable APIs. Whole communities of 3rd party developers tend to be drawn to stable and useful APIs. This is the attraction of SalesForce.coms AppExchange, ditto for Visual Basics COM, and the relational databases SQL. Stable APIs mean the ability to self-configure and customize at the periphery while leaving the core software performance, reliability, security and functionality to the original vendor.
With breakneck change in the underlying practice of software development, it has been difficult for software vendors to extend this offer. Times have changed according to Microsofts David Vaskevich. Will SaaS vendors be the first to broaden their reach – and allow developers and customers to have a say in the schedule and scope of API changes ?
(c)JBSurveyer 2006