The cloud hype continues to spread into just about any IT category, whether it's computing infrastructures (IAAS), platforms (PAAS), storage (scaling on-demand), applications (software as a service [SaaS]/cloud software), and even newer categories, such as integration on the cloud (IAAS). The list goes on.
Cloud models are now presenting CIOs with new ways of dealing with the shrinking IT budgets by allowing them basically to move nondiscretionary activities to discretionary.
But how does that all ultimately affect the end user? What will be the changes (if any) in the way of consuming applications? What does this all mean to the business?
If we take a look at just the application category and try to peel away the hype factor, how does the cloud model help business applications?
To answer that question, let's first examine previous application delivery models and how it all evolved into current cloud models:
Application Service Provider (ASP)
ASP was about using an external package, including the hardware, database, and application, all bundled together as a package with maintenance services. But it was a "messy" deal; the hosting came from vendor A, the software from vendor B. Sometimes the client had to talk to both vendors; sometimes vendor A would buy the software from vendor B. Either way, pricing was not flexible.
The advantages with ASP were that you could outsource what you didn't need inside, and there was no need to manage hardware and maintain the application.
The drawbacks mainly related to timing (ASP came a bit too soon to the market). The core idea is good but inadequate security technologies and communication barriers (bandwidth) made it a risky choice for many organizations. Another drawback associated with ASP was that it was a single application that could be used by many -- no customization, no changes. It was a "vanilla," take-it-or-leave-it package.
Will ASP still have a place a few years from now? Yes, it will fill a need for a "service" (a single instance) that many people need to use. For example, a suppliers' portal that provides an exchange place for buyers and sellers. In this case, there will be no reason to customize the application for everyone; it's a generic application that everyone can use, no one needs to keep it inside its organization, and, in fact, it is even better off managed by an external party that can be the "translator" between all parties.
SaaS
SaaS had much better timing. Suddenly, everyone is now talking about it, and it actually makes a lot of sense. Many of the technological barriers are gone. As organizations embrace new architectures such as SOA, SaaS is becoming a more viable option. While SaaS is a multitenant configuration, it does allow organizations to make some changes and customization. They don't have their own specific application, but they can have a variation of their application, sharing the infrastructure, platform, and application layer with other tenants.
The main limitation to SaaS, however, is the lack of control. When you use SaaS, you don't control the application (the core processes that are managed within it), and you don't control the data. This limits the uses of SaaS to applications with the following characteristics:
Applications that have a "network effect" (much like Web 2.0 initiatives, these applications present more value when more people are using them). For example, travel management and social software.
Niche and loosely coupled processes. The "classic" process would be one that doesn't require (any or many) integration with other processes. HR-related processes are a good example (i.e., travel management systems, eployee performance management, incentives management, e-recruitment).
Noncore processes. When it comes to core processes that are at the heart of the organization, even if COTS software is used, the application must be customizable; there is no room for compromise. SaaS is not the answer in this case. The high sensitivity level in this type of application makes it all the more difficult to hand over the control of data to an external vendor.
New processes. Organizations will most likely look at SaaS for new things that are not currently managed with an existing application.
As a result, in a few years most organizations will have a mix of applications: legacy core applications will run internally (perhaps organizations will use cloud services to make these applications more efficient), and the other type of applications will indeed be SaaS -- these will be the newer applications, and usually the more innovative systems.
Organizations will need to address the integration issues of cloud-based applications with internal ones (not surprisingly, there are already quite a number of vendors developing these types of integration solutions to the cloud).
Cloud Software
Cloud software will be another development in this lifecycle. Cloud software brings the control back to the user organization; it can develop its own application from scratch (using platform as a service tools [PaaS]).
In previous models -- ASP and SaaS -- organizations have no or limited control of their data. In SaaS, they don't really control the data or the application; they are consuming services and don't really deal with the content of the services or how they are delivered.
Cloud software will not eliminate the need for SaaS, however. Both models will have a place: SaaS will become a model more suitable for commodity-type or lightweight processes, and cloud will enable organizations to run heavier, core processes.
IaaS (Integration as a Service)
IaaS is another piece of the architecture that will become more and more necessary as organizations adopt these solutions. They will need to integrate them with internal, legacy, on-premise applications.
There is a very high chance that this is not the final phase of the evolution.
את המאמר ניתן לקרוא באתר של Cutter - כאן.
אין תגובות:
הוסף רשומת תגובה