High-level classification of Grid business models

The goal of this analysis is the classification of business models applicable to Grid solutions based on the business cases implemented in the BEinGRID project. They represent a number of different industries and their players. Their Business Models (BMs) largely differ and depend upon the industry characteristics that the Grid Services will be provided. Additionally, common business models for computing, such the Application Service Provider-driven models do not necessarily apply (at least with the same attributes) to industries such the automotive or film industries. Consequently, it becomes apparent that the horizontal application of grid computing business modelling principles to traditional and emerging future industries is a rather difficult and challenging task.

This classification of business models isn't based on traditional paradigms but rather it defines a framework to accommodate, describe and compare current and future models of the grid computing industry. We provide three distinct categories based on value propositions, their technological and economically associated incentives and trying to envision the future market of grid services so as to account for new business models. Then known business models are assigned to these three categories and, based on a comparison of their modelling elements and characteristics, we compare and deduct useful observations for trends, considerations, hindering factors, missing business elements etc.

A high-level classification of the Business Cases

The categories are the following:

• Category 1: "Grid Business Cases with a clear performance-associated benefit". This category of scenarios represents those cases that their implementations primarily aim at addressing one of the following problems/limitations:
•  additional CPU power needed for executing a demanding application (typical high-performance computing scenario)
• huge amount of data storage/memory is required
• access to heterogeneous, geographically distributed data resources is required.
• Category 2: "Grid Business Cases with a highly collaborative benefit" i.e. benefit arising from sharing complementary resources among participating organizations. In this case the resulting benefit from Grid adoption comes from sharing data, power and resources utilized for a common scope. Typical examples of this category are intra-organisational grids and Virtual Organisations and the expected economic benefit in this case could be shared among all participants in contrast to the first category where the main economic benefit is anticipated from the end-user where the service or application will be provided/sold. Also, the services of this category cannot be provided by a single provider since data or other resources are necessary to be obtained from other providers.
• Category 3: "Grid Business Cases exploiting the component-based software paradigm". This category comprising those business scenarios involving a service provider that offers applications on a pay-per-use basis rather than by means of licensing or long term static agreements and thus exploiting to the most the concepts of the next generation Service Oriented Architectures.

Generic Business Models for the Grid business cases categories

A number of different business models have been briefly described and proposed by the BEs that belongs under these three categories. Therefore we have decided to define a set of generic models for these categories aiming to emphasise on certain key aspects and characteristics and point out a number of associated interesting issues/problems for further analysis.

Category 1: "Grid Business Cases with a clear performance-associated benefit" - The Open Market Business Model

In this category we can include business models that fall under the general "Utility Business Model". Grid computing will ultimately present utility computing service providers with capacity planning issues similar to those faced by public utilities. Managing peak demand and the economical utilization of capacity will require incentives to modify usage patterns. This will favour the adoption of metered usage as a core element in the business model for utility computing. It is interesting to toy with the idea of what shape the utility computing business model might take in the future. The provision of computing services presents a matrix of opportunities that goes beyond any comparison to traditional public utilities, such as electricity.

Notwithstanding, it may be technically feasible to meter computing services, the question still remains, which services to meter and how to do it. We can envision the metered usage of CPU resources, for instance. At the application layer, there is already a move away from a pure license model toward subscription-based services. It is also conceivable that some kinds of applications could be adapted to a metered usage model, or a combination of subscription and metering.

However, trying to envision the future utility computing business models we will follow another approach by defining the concept of an "Open Market Business Model" as this has been also been proposed by EU project GridEcon (IST 033634). An open market in computing capacity is defined as a global or national marketplace where buyers and sellers of computing capacity meet. The market and pricing is transparent and regulated in order to ensure that both parties will honour contracts and agreements. The market resembles in some sense the stock market, with the difference that we envision it as a global marketplace rather than the national / pan national structure of stock exchanges.

Any company can buy capacity (provided they conform to the entry rules e.g. payment is guaranteed). Any company can sell capacity as long as they are certified (e.g. to guarantee delivery, quality and so on). We believe that brokers will intermediate between buyers and sellers. The added value of a broker is making sure that sufficient capacity is available and, especially in a forward market (where delivery takes place in the future), both parties honour the terms of the contract.

We believe that an open market can and will emerge from the consolidation of a number of Utility Service Providers (USP). This consolidation will only take place when the market for utility computing has matured, e.g. there a standard units of computing power, customers are used to buying their computing power from a third party vendor. A number of technical issues also need to be resolved in order make it possible.

An open market, on a national or global level, helps to increase transparency and has both benefits and drawbacks. One of the benefits is the possibility of a larger number of buyers. The drawback is that transparency makes vendors offerings comparable and puts a pressure on price (if all computing power is the same, price and guarantees are the only discriminating factors).

In short, the following needs to take place before an open market can come into place:

• Standardisation of computing units
• Companies are experienced in buying computing power in an ad hoc or planned fashion from a third party
• Technical delivery should be effortless and instant
• Jobs should be in a Grid enabled standard format that enables deployment on the spot without any additional work (e.g. in optimizing, parallelizing etcetera).
• Advanced decoupling between specific and general parts of computing

The benefits of an open market are:

• For buyers, a larger pool of resources
• For sellers, a larger pool of clients

The forward market helps companies to reduce their IT cost by selling off excess capacity and buying in case of (seasonal) peak demand. In the future, when an open market in computing cycles will exist, the USP can sell excess capacity on the open market, both spot and forward. A global market will increase the liquidity because of the time differences where a job in Europe can be run during daytime in Asia where it will be night-time and the capacity is cheaper.

The drawbacks of an open market are, for sellers, the increased competition.

A graphical representation of this market would accommodate a spot market, a forward market and a derivatives market:

• Spot market: instant computing capacity
• Forward market: capacity in the future
• Derivatives market : the right to buy or sell capacity at a given price

In theory, the sellers of capacity could be brokers that buy the actual capacity from other parties and add value by adding delivery guarantees and service level agreements. This could especially be the case when there are many potential suppliers of (small amounts) of computing capacity. The broker aggregates capacity.

Category 2: "Grid Business Cases with a highly collaborative benefit" - The Collaborative /VO Business Model

A generalised framework for the business models of this case could be a collaborative or Virtual Organisation utility computing model. Collaboration benefits could be gained both from an intra- or inter- company scenario. In both cases different organisations or departments combine the resources for a common benefit.

Examining in more depth the intra- VO model example, a company/organisation decides to internally adopt the Grid technology to more efficiently and economically manage their computing resources.

Their motives can be all or some of the following:

• High expenditure on IT
• Willingness to invest in leading-edge technology
• Large in-house IT teams
• High usage of internally developed software
• Willingness to pay to over-provision IT infrastructure rather than risk any service outage
•  Strong negotiating position with IT vendors

An example of such an organisation is the investment banks as these are the users who are actually facing up to many of the economic challenges. While the investment banks are working hard on many of the technical challenges in evolving their grid usage, the economic and business model challenges remain as challenging as for any other vertical market. Indeed, given the effective `competition' between departments in a bank, these challenges are often much harder than in other areas.

This initiative for them, typically led by a central architecture team, plans to offer compute resources across the bank. Over time, individual departments will no longer own their compute resources, but this will be provided by central architecture, using their global grid infrastructure.

Drivers for such an initiative include:

• Driving sustainable, long-term and linear cost savings and performance improvements
• Enabling a return to spending on innovation (instead of managing complexity)
• Providing utility, flexibility and agility
• Scalability - as "this year's exotic can easily become next year's flow."
• Fairer allocation of costs to business units
• Meeting ever greater data requirements - investment banks typically suggest a 50-100% annual growth driven by regulation, compliance and more advanced trading requirements
• Running out of datacenter space.

Further evolutions planned include:

• Self-service: users submitting a job directly to the global grid, without needing to go through the IT department
• SaaS and open source are cost-effective and additive, reducing software licensing costs
• Adding SLA monitoring, policy management, chargeback across heterogeneous resources.

What is clear is that the companies ready to move to the internal VO-model see an integration of SOA, virtualization and grids. Some make the distinction that SOA overcomes the challenges of legacy applications (redefining them as services) while new applications can be optimized for the grid (componentized, parallelizable and so on). Perhaps the key point is that the application, and indeed the user (probably not a computing expert), should be unaware of the underlying infrastructure, and this is where the integration of virtualization and grid computing can be seen.

There are clearly a broad range of technical challenges to such an ambitious project. Probably the largest single is data management, including such issues as storage, data movement, caching, replication, global namespaces and so on. As we seek to embrace non-HPC and more traditional software applications, software licensing becomes a major challenge. Open source software as always the preferred solution to overcome this issue.

Main concerns for moving to such a model are:

1. Security, both external and internal. Adopters would like tested standards or `best practices' to be in place for external communications. Furthermore, intra departments would like maximum security even from other departments for both compliance and competitive issues.
2. Forecasting IT needs. IT needs are typically rising rapidly. This creates two main problems from an economic perspective. Resource planning (again required technical expertise should not be assumed in all cases) and accounting and auditing i.e. matching internal budgets with actual usage, allocating IT spend, and ensuring that this conform to international accounting standards.
3. Metering, billing and chargeback. Departments would expect to be charged fairly and accurately for IT usage. The challenge becomes how to measure such resources, particularly as there is also an argument for reducing complexity. In order to efficiently measure IT usage you need to be aware the hardware, software, network and storage used. Of course, different jobs have very different requirements in terms of network and storage requirements. Arguably, there is also a fifth element, which relates to the management overhead, with some jobs requiring additional challenges in orchestration and data management. The definition of a "grid unit" is desirable in this case. However approached followed so far vary and do not conform to any standard.
4. Internal SLAs. The individual departments want to ensure that their IT needs are met, and consider a central architecture group to be comparable to an external supplier. Indeed, the use of a central architecture is encouraging individual departments to work with outsourcing providers to provide choice and potentially cost savings.
5. Resource and tasks prioritization and optimisation. Not all internal tasks require the full available computing power. Furthermore, there are tasks that will finish their jobs before the estimated time thus leaving an amount of resources already allocated wasted. It is important that these cases are avoided. Already computing power should be reselled back to the central architecture. There should be a well-defined relationship between the level of service required and the amount available to be spent for that.

Category 3: "Grid Business Cases exploiting the component-based software paradigm" - The software as a service Business Model

Software as a Service (SaaS) is a relatively recent model of software access. It builds on the latest advances in technology within the software industry in order to offer a radically different model for accessing and using software. As the name states, SaaS is a way of accessing software products as services. This is significantly different to the traditional means of accessing software and raises a number of problems, both technical and legal.

In this model a user can combine services or even software components (as in the service-oriented architecture paradigm) from different Grid providers and build his service. Providers on the other hand can provide their software in different packages and prices to meet the customer needs. Software can be accessed remotely and run over the grid infrastructure of the provider.

This is in contrast to the traditional software model where software would be purchased from a retailer, generally in a box with a manual and some storage media containing the software binaries. The software would be installed onto a server or an end-user's system and then accessed by one or more users as required.

Existing licensing models include:

• Indefinite, named licensee: The named individual is licensed to use the software. The license does not expire.
• Indefinite, floating license: Any individual may use the software although only one copy of the software may be run at any one time. The license does not expire.
• Fixed duration, named licensee: The named individual is licensed to use the software for a fixed period after which the license expires and must be renewed. Fixed duration licenses are generally valid for a year although other durations are not uncommon.
• Fixed duration, floating license: Any individual may use the software although only one copy of the software may be run at any one time. The license is valid for a fixed duration after which it must be renewed to continue using the software.
• Shareware: Software users are encouraged to pass the software to friends/contacts. Software can generally be used indefinitely but users are encouraged to make a donation to the software provider if they continue to use the software.
• Freeware: This is software that is made available on a closed-source basis, to any users, free of charge. Since the software is closed-source (the source code is not accessible), the main purpose of the license is to protect against users attempting to gain insight into any intellectual property encapsulated within the software through code decompilation or other methods.
• Open source:  Open source software is software where the source code is made publicly available. There are many different variations of open source license specifying how the code may be used and modified, how resulting modifications must be licensed, how components of the code may be utilized in other products etc.

SaaS makes software accessible according to a service/utility model. That is, users don't need to purchase, install and configure a software package just so that it's available on their system when they want to use it. They simply access the software that is pre-prepared and ready for end-users at some remote location. The user doesn't need to know where the software is running, what type of computer it is running on, who set it up etc. They just interact with it as per their requirements and then leave when they have finished.

The SaaS model allows a user at one location to interact with a software product at another. This means that the processing required to run the software is carried out at the remote location. It also means that the user does not need a computer that has the power to run the software itself; they simply need the connectivity to access the Internet or some other private network through which the software service is accessible.

The generic SaaS model can be further analysed in three different models:

1. The in-house hosting model which covers many of the current larger Software as a Service solutions that are available. In this model, the service provider develops their software service product and uses in house resources to host that product for access by external users. The provider may buy in significant quantities of resources in order to offer the processing power to support the external clients that are accessing the software service. This gives them the expense of managing the resources, something that can be quite significant in terms of power, cooling and space. However, if the provider has a large enough user base, predictable, steady demand, and is willing to take on the job of hosting, supporting and maintaining large quantities of high-performance computing resources, this can be a cheaper option than going to a third party computing provider.
2. The Application Service Provider (ASP) model where software is hosted on third-party resources that are operated by a business specializing in resource hosting. The offering may also include toolkits or libraries to assist in generating SaaS applications that are compatible with the ASPs hardware resources and operating environment. The software provider pays the ASP to provide a reliable, network-connected set of resources on which their software is made available to users. Since the software provider does not own the resources, they avoid the problems of hosting their own resources in-house, such as supporting and maintaining these resources. The ASP may have tiered hosting offerings that also include hardware and software support to end users of an application provider's software. Application providers can end up with a complete hosted solution where all they need to do is provide the software and keep it updated ­ this can also be a very expensive option for the application provider. ASPs can handle software with varying demand profiles since they can assign their resources across a pool of different applications that they are hosting. This provides better utilization of resources and the ability to pull in additional resources, within the bounds of their in-house capacity, if a particular provider's package is getting excessive numbers of users.
3. The True Grid model of SaaS which takes the Grid Computing paradigm of transparent access to almost unlimited quantities of geographically distributed resources and links this with the idea of software hosting. This is similar to an ASP model but the number of resources available is not limited by the quantity of in-house hardware as with an ASP. Also, when resources are not required, they are not paid for, since computing power is purchased on a utility basis with operators only paying for the power that they use. This is a highly technically complex model to build and there are currently no SaaS services that underpinned by a true Grid hardware platform. However this is seen as the next stage of development in the SaaS market. Since resources are not owned and only paid for when they are required, they may be in use by other Grid users at other times. When a resource is needed to run some software, it is provisioned on-the-fly with the necessary software package and the user is then connected to the software interface made available by the configured software that has been set up on the Grid resource. The full software transfer and configuration on the Grid resource takes place transparently to the user who interacts with the application exactly as they would in a standard in-house or ASP hosted model. The software setup and configuration is carried out by software known as a Grid middleware that is aware of the available Grid resources and can select a suitable resource to run the software for the end-user (e.g. a resource that is not overloaded running jobs for another user).