In an article published on Tuesday, February 12, 2013 in the Wall Street Journal, “Send in the Tech Reinforcements” the authors, Arthur Hermann and John Scott make the case that an ISV like Amazon can ” . . . make over 30 changes a week to its portal, from adding simple code changes to new complex features, without a major glitch.” (quoted from the print edition of the Wall Street Journal. This article is available online. A subscription to the online Wall Street Journal is required to read this article). In contrast, the authors note that “[b]y treating software as if it were a product instead of a process, our military services are shutting themselves off from the kind of cost-efficient innovation that rules in the commercial software and IT industries.” (ibid).
While we do not necessarily agree with Messrs Hermann and Scott’s observations, we do find their mention of Amazon to be one of the best examples of why it makes sense for organizations to seriously consider cloud software offers. We absolutely agree that when an ISV has an opportunity to service an entire customer base with one set of software updates, and, further, when that same customer base is completely unaffected by the changes that accompany completed software updates, then the process is very beneficial to ISV and customer, alike.
Of course, there is nothing very sophisticated about the Amazon example in this article. In fact, the Amazon portal is the same point of access for any/all customers. Certainly, different browsers will expose the content differently, but the source code for the site is still the same. The economies of portal development, maintenance, and ease of access for customers are all very good reasons for ISVs to pursue this approach to systems development and for customers to purchase it.
The question for both ISV and customer then becomes whether the type of rapid development and implementation methods that cloud software systems are capable of supporting is likely to be used with the level of frequency that ISVs should deem worth the effort to build these systems, and, in turn for their customers to justify purchasing them for their use.
Certainly we can imagine scenarios where the speed at which cloud systems can be renovated and implemented makes sense, but, conversely, we can also imagine scenarios where this feature will neither be meaningful, nor worth the trade off with regards to the security of data that we still feel is a serious issue for cloud software services.
In the next post to this blog we will look at some other points made in Messrs Hermann and Scott’s article. Specifically, the cost overruns they mention and our own take on the general poor performance of IT projects, as delivered, when compared to their original objectives.
© IMB Enterprises, Inc. & Ira Michael Blonder, 2013 All Rights Reserved