www.aspnews.com/analysis/analyst_cols/article.php/558411
By Phil Wainewright January 11, 2001 One of the primary benefits of the ASP model over traditional approaches is that customers can get new applications up and running in record time. Implementation cycles are cut from months to weeks for heavyweight applications, and from days to just a few minutes for more lightweight offerings. The main factor in achieving these speedier timescales is that the underlying systems on which the software runs have already been prepared by the ASP. In other words, the ASP has already done the systems integration. Unless there's a need to add integration with pre-existing systems and applications, all that remains is the business integration — setting up the application so that it reflects the business processes that are specific to each individual customer. The ability to separate business logic from the underlying software platforms in this way has only become possible in the past few years. Its emergence has been one of the principal enablers of the ASP model. Now it is beginning to sow the seeds of even more far-reaching changes in the way that computing is delivered to enterprises — with significant implications both for traditional integrators and for the first generation of ASPs. In the days when business logic was intermingled with systems logic, no-one had any choice but to design and build complete finished systems, test them, and then deliver them. Computing systems were delivered in what computer scientists would call batch mode — one complete project at a time. Constant evolution ASPs have discovered they don't have to deliver systems using this laborious, monolithic process. They can start off by implementing a small subset of basic functionality, and then add additional application features incrementally. That further speeds the time to implementation, as well as allowing the customer to manage user training in small, digestible steps. More radically, it allows customers to fine-tune their requirements over time. They can decide to introduce extra features they didn't think they would need when they started out, or remove functions that don't turn out as useful as they first thought. They can try out alternative approaches to the same problem, they can go back and rework individual business processes, or they can suddenly go off at a tangent after completely new business opportunities. This is the true nature of computing delivered as a service — no longer the immutable end-result of a predefined project, but a continually evolving resource that constantly adapts itself to changing business needs and conditions. Utility provision This is not what the first generation of ASPs envisaged when they started out. They saw themselves as utility providers of standardised applications, who would reduce the cost of delivering IT by mass-producing monolithic solutions. Although they would charge less for the upfront consulting, they aimed to reap their reward when they delivered the fixed result for a recurring monthly payment. Put to the test in the market, they have discovered that the customer's need for consulting never goes away. Instead of delivering a fixed result for months on end, they must constantly modify and rework the finished solution. Every morning they wake up once again to the groundhog day of business implementation, still behaving like consulting businesses instead of the utility providers they had set out to become. The survivors will be those who successfully hand over the business implementation role to companies who are set up to act as long-term consulting partners. The challenge will be to find consultants who can unlearn the traditional project-based, batch-mode method of delivering IT solutions, in favour of a more partnership-based, continuous-consumption model of service delivery. Only when they have done so wlll ASPs wake up to find they've left their consulting groundhog days behind them and are free to fulfil their original vision of becoming utility IT providers.
|