C3. Prefer the most abstracted service delivery model that meets the application’s needs

In the context of service delivery models, we first ask the question "do we need to run this at all?" which can be answered in the negative if there is a cost effective Software as a Service (SaaS) solution that satisfies the requirements, and the loss of control and cost downsides associated with the solution are acceptable. If we do need to run something, then it makes sense to ask the question of whether there are managed services that can ease part of the operations burden or perform tasks we’d rather not do ourselves. Thus, Platform as a Service (PaaS) should be the next most preferred service delivery model, and within that, there are different services available that manage various components for us to varying degrees. In the event that PaaS managed components are unsuitable for an application, and the choice comes down to managing all components of an application, down to the operating system, via Infrastructure as a Service (IaaS), vs doing so on-premises, consider whether the scalability advantages of the public cloud offer a meaningful advantage over what we can do on our own infrastructure. In practical terms, this sort of thinking proceeds as a “flowchart” of sorts, from SaaS, to PaaS, to IaaS, defaulting to on-premises.

There are, of course, exceptions to this. Each stage of decreasing abstraction comes with the potential and/or necessity for rearchitecting. There is a cost/benefit to doing this, and it might not be worth it in terms of cost/time/established internal expertise/etc. A DoIT unit faced with a cloud adoption decision may, in fact have a need or desire to directly manage lower levels of abstraction (things like integration with on-premises databases, specialized virtual networking, latency, past history with / considerable expertise in a particular component of the application stack that is situated BELOW their core competency).