What's PaaS?

One of the models used to explain the cloud computing service offerings - derived from the NIST model -  shows the service models arranged as a stack. Implicit in this model is a usage hierarchy (explicitly shown in the diagram below) , that is BPaaS will use SaaS, SaaS uses PaaS to provide an abstraction from underlying computing resources and IaaS provides the basic resources. This seems to make a lot of sense to software architects who recognise a familiar pattern.  

  However, one of the problems I face when talking about PaaS is that many have different preconceptions as to what it is, usually derived from what is currently being provided by various cloud vendors. These range from:

Provided PaaS Services	Example Provider
A set of services for resource allocation in a IaaS service model.	Amazon EC2, Rackspace
Basic middleware and data storage services.	Amazon Web Services (AWS)
A set of application services.	Goggle App Engine (GAE)
Model driven development platforms in the cloud.	force.com
Application development framework for cloud computing.	vFabric, Heroku
A process development framework in the cloud.	Cordys Process Factory, IBM Blueworks Live
Platforms that provide a set of business functionality that can be built upon.	CRM functionality, platforms that provide document management and process automation etc..  PaaS at this level seems to be a underdeveloped model.

Looking at this suggests that the simple model as proposed by the NIST is, in fact too simplistic. So what should the model look like?  

One possibility I like, is to place the PaaS service model to the side of the others and show that they are used by two different roles, i.e.:

PaaS is then a set of functionality that can cover the development needs for the complete spectrum from IaaS to BPaaS, but in practice each cloud service provider will only cover a limited set.

(Update: I've been having some problems with the images displaying. Reloaded them so hopefully it works now.)  

Architectural Decisions

If you are trying to implement any kind of architecture management you have to start documenting the architectural decisions you have made to keep future developers aware of the problems that were faced and why they where solved that way. But what information should be kept? One model I have used in the past is the Tyree-Akermann model (published in IEEE Software March/April 2005). This captures the issue, the alternative solutions considered and, of course, the decision itself. In addition, the model is extended with information that supports the decision (e.g. architectural principles, business factors).

This isn’t the only model that can be used. IBM have developed one in some detail and the ARC42 project has, as part of a software documentation template, developed an implicit model (only in German).

Now, one way to go, would be to consolidate the models to derive a "universal" architectural decision. However, since reading "Architectural Design Decisions as Reusable Design Assets” by Olaf Zimmermann (originally published in IEEE Software Jan/Feb 2001, but now available here), my thinking has been pushed into concentrating on using the decisions to provide a knowledge base for other architects, i.e. reference architectures.

Zimmermann’s paper proposes, that when creating a reference architecture, not only the component, connector, patterns etc. are documented, but also the issues that the architect has to solve together with the design alternatives available in applying the reference architecture to a real situation. These issues - complete with alternatives and recommendations - form a guidance model. This guidance model is then tailored to the project situation to produce a decision model and extended with the actual outcomes.The beauty of this simple scheme is that the guidance and decision models have the same structure making it easier to extract best practices from completed architectural documentation. Zimmermann goes into a lot of detail about this, but I have tried to summarize it with the following two diagrams:

1. The structure of the models. Although Zimmerman uses a SOA reference architecture as an example, the principle can be applied to any reference architecture as I’ve tried to show in the diagram.

2. A (simplified) process showing how the guidance and decision models are used in architectural design.

Two main challenges still remain though - getting your architects to document their decisions and setting up an organisation and processes that can actually extract and propagate architectural best practices.

Quantum computers - a commercially viable option?

Way back at the beginning of 2007 I posted a minimalist comment expressing some incredulity that a company - D-Wave - had been founded to develop and sell quantum computers. I've now just seen that they have sold one to Lockheed Martin for undisclosed purposes.

So when can we expect a quantum computing service in the cloud (a.k.a. QaaS)?