Clarifying Cloud Part 3: 4 Delivery Models

There are traditionally 3 delivery models for consuming the cloud.   Coming from a service background, I add in a 4th, to clarify the value of service and how it is different when delivered via the Cloud.
Infrastructure as a Service (IaaS):
Generally known as the bottom layer, essentially servers, switches, firewalls, routers, cabling etc.  An example offering would be from a provider that enables on demand provisioning of servers without any of their interaction.  There are no AEC only pure plays that I am aware of.  My company comes close, but we are not soley focused on IaaS, and due to some limitations of vendors, and value propositions, we do not meet all five characteristics of cloud.  We have some co-opetition, that is similar.
Platform as a Service (PaaS):
Generally known as the middle layer.  An example would be a vendor that allows you to run applications of your choice, on top of IaaS, without their interaction.  Again, there are no AEC pure plays that I am aware of.  My company and some co-opetition come close here as well, for similar reasons as IaaS.  There are several that may utilize PaaS themselves, but generally limited.  Some generic examples could be Facebook Apps of Salesforce Apps.
Software as a Service (SaaS):
Generally confused with “being the cloud”.  SaaS is not the cloud, and being a SaaS provider does not make you a Cloud computing company.  The SaaS model is however the easiest to understand, typically licensed per user per month, although it could be in some other variations which I’ll discuss in the future.  AEC examples are e-Builder, Constructware, Buzzsaw, Aconex, and a gaggle of others fit this model.  There are some great & not so great (for reasons not so obvious) SaaS options on the market.  My company and a wave of other veterans prefer the Microsoft model of Software Plus Services.  This idea produces the same result from the end users perspective, but is also able to clearly define the difference between the software and the service.  I’ll discuss this idea at length in the future, and why it will likely prevail as the Cloud market evolves.
Resources as a Service (RaaS):
Although not traditionally noted in the “as a Service” group, I like to use this, because the “S” in “aaS” gets highly abused, as if there are no humans involved.  The AEC industry is by default, labor intensive and as a result understands resource leveling, beyond outsourcing or subcontracting or generic bundling.  It’s important to delineate that there can be and are humans involved in Cloud.  More technically, people have told me RaaS is the same as Business Process Outsourcing (BPO) and Knowledge Process Outsourcing (KPO).  I argue those are typically based on term agreements where a resource is on premise or dedicated to one Customer and not necessarily working on Cloud solutions, leveraging the Cloud, or enabled by the Cloud.  RaaS would have to be a multi-tenant, scalable, on-demand resource which would meet certain criteria not required for traditional outsourcing or subcontracting.  This model is a major are for cost benefits, which I will expand upon in the future.
If all human resources could be eliminated from Non-Tactile processes & Technology initiatives, other elements being equal, technology would provide the purest form of efficiency, and buildings would would be better.  Although my company’s philosophy strives to achieve this, it’s not likely, so we do the next best thing, by applying the definitions of the Cloud Characteristics and Delivery Methods to the use of Human Resources, which today are required to some degree to run any of the available Cloud services on the market.  I’m not holding my breath that this will change during my lifetime.