There are many ways for an insurance provider to approach cloud computing, depending on what problem it’s trying to solve.  Certainly, the cloud computing delivery model is well-suited for technology infrastructure (i.e., IaaS), such as compute, storage and networking services.  For the most part, these infrastructure assets are commodities that are straightforward to economically value and align well with the cloud’s promise of on-demand scalability.    But is the cloud well suited for IaaS’ brethren:  development environments (i.e., platform-as-a-service) and business services (i.e., software-as-a-service)?

Unfortunately, evaluating PaaS and SaaS assets is more ambiguous than assessing IaaS resources.  For example, there’s no “algorithm” that determines whether or not a business service should be delivered via on-premise, cloud or a hybrid combination.  And, like many things in an insurance CIO’s life, this lack of algorithm acts to ‘cloud’ decision making when it comes to PaaS and SaaS assets.

Indeed, according to Gartner, “the adoption of cloud computing remains very low in the insurance industry, especially when it comes to core insurance applications such as policy administration or claims management. For example, only 10 percent of carriers use software-as-a-service for billing applications.”  [http://www.insurancetech.com/architecture-infrastructure/225800122]

Fortunately, a ray of hope exists to confront this challenge.  A cloud computing assessment framework can significantly help in “framing” the decision set in a consistent manner allowing insurance CIOs and their executive management peers to weigh the benefits and risks associated with a cloud-oriented service. A framework considers cloud computing service models from a variety of perspectives:

  • Strategic (i.e., does the cloud service fit within our enterprise architecture strategy)
  • Business (i.e., does the service meet our business’ functional requirements)
  • Financial (i.e., does the cloud service help to optimize our IT financing strategy)
  • Architectural (i.e., does the cloud computing service meet the relevant non-functional requirements)
  • Risk (i.e., are the associated risks tolerable)

Within each lens, one would need to detail specific questions to help evaluate that perspective. For example, sample questions concerning business functionality and architecture are listed below.  In my recent experience at a top-20 insurance carrier, a comprehensive set of questions is on the order of 200. And, although the adoption rate of core insurance applications might not increase due to common insurance related constraints (e.g., legacy, data security, compliance, etc…), at least a CIO can be confident in explaining to their executive peers as to why, or why not, they are leveraging cloud assets.

Cloud Computing Evaluation Framework:

Business Impact (Out-of-the-Cloud Functionality):

  • Is the cloud solution’s user interface (UI) acceptable?
  • Is the cloud solution’s set of business processes a good fit for the required business processes?
  • Is the cloud solution’s set of business rules a good fit with the required business rules?
  • Is the cloud solution’s set of data elements a good fit with the required data elements?
  • Is the workload associated with this project highly variable, such that the cloud can provide an outlet for spikes in demand?
  • Is the cloud solution compatible with all company-approved mobile devices?
  • Is the cloud solution compatible with all company-approved web browsers (e.g., Explorer)?
  • Has your team created a business continuity risk mitigation plan should the SaaS provider go out of business?
  • Is the gap between the cloud solution’s functionality and the defined business requirements acceptable?
  • Etc…

Architecture Impact: Availability (Uptime):

  • Does the service provider publish or offer online access to its uptime records?
  • Is promised availability (uptime) at least 99.5%?
  • Does the vendor provide data that demonstrates the consistency of uptime over the past several years?
  • Has the vendor provided past outage data?
  • Etc…