My colleague John Rymer expects platform-as-a-service (PaaS) technology to “cross the chasm” into mainstream status over the next three years (2012-2014). Today, PaaS solutions, which provide application development and deployment tools abstracted from the underlying cloud infrastructure on which they run your apps, fall into four types: 1) Pure cloud integrated development environments (IDEs); 2) Traditional IDEs that offer the option of cloud deployment; 3) IDE-neutral cloud runtimes that can run apps built by multiple types of IDEs; and 4) PaaS solutions designed for use by business developers. John sees all four of these categories aiming to cross the chasm in this timeframe but doesn’t expect all four segments to succeed in making that transition.

Why does this matter? PaaS is one of the easiest and most productive ways to take advantage of cloud economics, and the elasticity of the cloud, by providing an easily consumable elastic app platform. Today, most apps for the cloud either lack the ability to automatically scale up or down in their use of cloud resources, based on demand, or else gain that ability through complex programming to low-level APIs and frameworks. PaaS provides access to the cloud without all the drama. Only through taking full advantage of these attributes of the cloud can your business realize the full benefits the cloud theoretically provides.

We are in a highly disruptive time in the world of commerce technology. Consumers are interacting in increasingly unique ways empowered with ubiquitous Internet connectivity with fun and easy to use interfaces and tools. Their expectations are impacting how companies market, manage their supply chains, organize, and measure the business. The needs of “the platform” seem to evolve from one week to the next. What we used to call eCommerce Platforms are now not only powering webistes, but also mobile sites, mobile apps, call centers, and in-store or in-branch interfaces that both customers and staff are using – sometimes together.

But there is an even more fundamental change about to occur – the agile commerce platform. The agile commerce platform will expose commerce as a service (CaaS) to support all touchpoints with customers. A services enabled platform which will enable eBusiness & Channel Strategy leaders to drive differentiation, respond to changing customer expectations, and enable creative business relationships to support business adaptation and facilitate growth*. Commerce solution providers from across the map are building CaaS solutions.

This is the topic of my latest report.

It was only about a year ago when Larry Ellison was confusing the OpenWorld audience with the “cloud in a box” approach, and only a very few CIOs managed to turn a large Oracle landscape into a real private cloud based on an opex model to their business units. But a lot has changed since last year.

An important prerequisite for a full cloud broker model is the technical capability of cloud bursting:

Cloud bursting is the dynamic relocation of workloads from private environments to cloud providers and vice versa. A workload can represent IT infrastructure or end-to-end business processes.

The initial meaning of cloud bursting was relatively simple. Consider this scenario: An enterprise with traditional, non-cloud infrastructure is running out of infrastructure and temporarily gets additional compute power from a cloud service provider. Many enterprises have now established private clouds, and cloud bursting fits even better here, with dynamic workload relocation between private clouds, public clouds, and the more private provider models in the middle; Forrester calls these virtual private clouds. The private cloud is literally bursting into the next cloud level at peak times.

An essential step before leveraging cloud bursting is properly classifying workloads. This involves describing the most public cloud level possible, based on technical restrictions and data privacy needs (including compliance concerns). A conservative enterprise could structure their workloads into three classes of cloud:

• Productive workloads of back-office data and processes, such as financial applications or customer-related transactions:These need to remain on-premises. An example is the trading system of an investment bank.