Friday, December 15, 2006

The Fifth Utility

Utility computing, also often called, as the fifth utility seems to be positioned as the cool new model for enterprise computing. Note that the term computing must not be read as just related to computer as a processing box, but must be generally understood as the ‘business model’ of offering a service. The fifth utility is more about business model based on utility computing rather than the technology alone.

The idea of service provisioning for the clients based on similar grounds such as using electricity service or water, where in clients can consume as much of resources as needed and are only required to pay for what is being used, is considered as ‘Utility Computing’.

So then, utility computing is a “Service Provisioning” model.

Whenever an operation or a service becomes an absolute necessity for an enterprise to function, and the abundance and standardization of such services drives the ubiquity of such service, then, it will make the most sense for an organization to obtain such services from an utility source. (Ex: Electricity)

Any process or offer that can be commoditized as a service can be packaged as ‘probable’ contender for utility computing.

In my view, the utility computing model implies that majority of the services that are ubiquitous across general consumption (e-commerce or enterprise alike) can probable be serviced through a utility computing paradigm.

Such services can then be consumed on a pay-by-the-drink usage model.

Technology (IT) in general can be considered as a usecase for utility computing. IT as a utility is a very highly debatable topic. I do want to suggest that IT as a whole does not fit into the utility model. IT services can be broadly categorized into two systems.
  1. Systems that provide strategic benefits for an enterprise.
  2. Systems, which are ubiquitous across enterprises.

The utility computing model best fits the second category of services. In my view, the utility computing model implies that majority of the services that are ubiquitous across enterprises can be outsourced. Such outsourced services can be used based on a pay-by-the-drink usage model. The idea of paying for using applications or compute resources or storage, based on the pay-by-the-drink model sounds great in theory.

‘But does it really work in practice?’

To arrive at finding an answer to the stated question, we need to understand the concept of a generic utility computing model. Most importantly, we must try to find the candidate attributes of the model that best fit into the description of the model. Eventually, we can contemplate on the practicality of all the variables in the equation that can make the utility computing model usable.

If the fifth utility was to be considered a ‘simulacrum’ then the probable originals could be the following market models:

The current focus seems to be more towards virtualization of systems as the first step towards utility computing stack. Notice that decentralization of ‘data’ through the usage of torrents or similar P2P networks (Ex: Naptster) is a way towards virtualization of data. Also the emergence of Web 2.0 is pushing the industry further towards ‘Web as a platform’ for provisioning the service. Web 2.0 in general and probably semantic web in particular does and will have more relevance towards offering the services as utility to be consumed over the web. (More about this in later blogs).

There is also a general purpose architecture around utility computing being construed called the SOI. SOI or the Service Oriented Infrastructure is in effect an infrastructure solution to make the SOA happen (SOA: Service Oriented Architecture). SOA suggests that if a offering must be conceptualized as a ‘Service’, then the supporting SOI needs to be in place to allow both offering and consumption to happen.

Note that SOA is a technology architecture to enable LOB applications to work within a composite application framework...

Meanwhile, there is a business side of the SOA and the definition of a 'Service' in the business model is more important than the definition of the 'Service' as explained everywhere while preaching SOA. (Check webservices and SOA keywords while searching for technical definition on Google).

What then makes up a business definition of a Service ?

I will present an over simplified version of the key constituents of a ‘Service’. I will call this the first-set

  • Service Description
  • Service Costing and Pricing
  • Objectives of the Services (Also called Service Level Objectives)
  • Service Level Agreements
Also for a Service Portfolio
  • Service Usage and Consumption plan leading to a Service Offer
  • A Master Service Agreement for a Portfolio of Services
Notice that most of these are also common for service as a utility except that following critical ingredients must be added to the mix (Let me call this the second-set):
  • Service Metering (or monitoring)
  • Service Lease Agreement
  • Service Chargeback or Billing
  • Regulatory Compliance
It can be a long debate towards concluding whether all services that have the pre-defined drivers/attributes (both the first and second set) can be considered as utilities. I do not have a good theory of my own to present one case or another (will try in further blogs).

There are many frameworks such as ITIL, COBIT etc that deals with the concept of ‘IT as a service’. Most of these frameworks revolve around the first-set of drivers I have presented. The key theme of service provisioning is based on building a Service Catalog and a CMDB (Configuration Management DataBase). The ServiceCatalog and the CMDB in general is a dichotomy built around what they call as the “front office” and the “back office”.

Most of the front office activities are addressed by building a service catalog. This includes creating a service portal as a single pane of glass across functions such as:

  • Help Desk and Requisition
  • Self Service
  • Auditing (for compliance)
  • Financial Accounting
  • Relationship Management
  • Vendor Management (Service)
These can be well managed through the creation of a service catalog and then making the catalog actionable and orthogonal across the stated functions. Companies like newScale and Lontra are in the race to productize the service catalog (Though I must say that newScale has been more widely successful penetrating the market). These companies also have workflow and performer management stack built into the product to address IT service provisioning in particular. In contrast the back office activities such as:
  • Inventory Management
  • Service Configuration management (CMDB, Bill-of-Materials)
  • Capacity Management
  • Availability Management
  • Incident and Change Management
  • Resource Workflows and System Integrations
  • Vendor management (Configuration)
These are managed by a different breed of systems which are more asset centric and are focused towards system monitoring and event management. Companies such as CA, BMC, HP-Openview and IBM-Tivoli have product stacks around the back office.

This simplification of the service definition also helps us understand that utility definition will not be any significantly different from the functions and operations management of a service, except that not all services are utilities.

Maybe the service catalog can have services that are marked as utilities or maybe there is a different breed of management suite that is required for creating a utility computing model. More research on these thoughts can reveal the plausible theory to be adapted. But, for sure, it is obvious that a utility offering is not possible until the front office and the back office are both an established reality. Saying this, there are still no products that are providing the ‘second-set’ of requirements which are essential and critical for a utility offering to happen. In my opinion, a large vacuum exists in the market space where a product can emerge to satisfy the second-set.

In conclusion, the fifth utility as a simulacrum is still in the making, waiting for the Integration of front-office with the back office through the probable emergence of Web 2.0 based platforms which in turn makes the SOA and SOI to happen. In effect, for the pay-by-the-drink paradigm to work, the critical ingredients from the second-set to emerge as a product that best fits into the overall framework must become a reality.

Saying this, there are some successful emergence of utility based usage of Web Services demonstrated by Amazon on their AWS portal. These are some of the trends worth tracking for the simulacra to emerge.

No comments: