Demystifying Enterprise Cloudification

Publish date:

Moving to the cloud is easy, right? Wrong. There are many obstacles to overcome – only 6% of all global workload is sitting in a public cloud and many companies struggle to use a cloud approach for “serious applications”. For some reason many believe moving to the cloud means reducing the rigour of design, ignoring […]

Moving to the cloud is easy, right? Wrong. There are many obstacles to overcome – only 6% of all global workload is sitting in a public cloud and many companies struggle to use a cloud approach for “serious applications”.

For some reason many believe moving to the cloud means reducing the rigour of design, ignoring crafts developed over many years and to save on testing capabilities. This short blog will build on my previous post “To Cloud, or not to Cloud” (see here) and will focus on the “what areas to focus on to lift / update existing highly critical applications to the cloud”.

Many organisations have adopted (public, private) cloud capabilities for some non-production related aspects like development, unit testing or training environment. However most are not yet ready to adopt cloud based services and for the ones who did embrace cloud there was a realisation that the design approach is similar to previous patterns, including the typical pitfalls and issues; a realisation that moving to the cloud is “just” another delivery method requiring the same rigour as with previous approaches.

In particular to design or to transform “highly critical applications” 3 main aspects have to be considered:

Rg 1) As part of the “Business insight” there is a need to fully to understand what this application actually means to the business. By that I don’t just mean uptime or return to operations only; I mean how critical is this application (or better service) to the business, what availability characteristics are required, how reliable the service has to be, how responsive, what is the expected demand profile, what are the reporting characteristics and whether the service is regulated or unregulated.

Each of these 7 key service characteristics have different levels. For instance “constant availability” means 7 days 24h. But can also move to Extended Weekend Office meaning 06:00am through 7:00pm Monday to Saturday etc. Changing the characteristics of the service covering the 7 main areas will have an affect on the overall service characteristic. Many organisation have mission critical, critical, vital and supportive applications, however not always is it clear to all what sits behind each. Also a good approach is to categorise these into platinum, gold silver and bronze services and to align the characteristics accordingly.

These characteristics are important to understand the overall criticality of the service. Particularly when designing to transform a highly critical application one has to understand :

  1. What business process do I have to secure?
  2. What applications are supporting the business process and how long can the business cope without having access to the applications? (the RTO)
  3. What is the longest period of time we can lose data? (the RPO)
  4. What infrastructure related components are hosting the applications that supports the business process and
  5. What data storage devices are involved?

The infrastructure related solutions are – and must be – a direct response to the application and business related requirements. There is a need to understand what infrastructure component supports what application in the context of an end 2 end business process.

Many organisations have a number of platforms that supports one end 2 end business process. Lets take a Bank – most of the UI (user interface) is now implemented using Web Servers running Linux or Windows. The application logic is sometimes hosted on large UNIX systems and the backend is a large mainframe. Deploying an active/active dual Data Centre solution for the Mainframe will ensure that the backend will be available if the first Data Centre fails.  But the overall business process will not be available as the X86 and UNIX platforms are not active/active.

When designing highly available solutions the Lead Architect has to understand the entire business context and not “just” the infrastructure related aspects:

Key is to understand both grey and blue boxes – regardless if on premise on traditional technology or “somewhere” in the cloud. And of course this goes with the non-functional requirements including security; Finding, defining, agreeing non-functional requirements and ensuring that the delivered solution complies with the derived SLAs (Service Level Agreement) and KPIs (Key Performance Indicator) are critical to any solution delivery process.

The responsibility for ensuring appropriate non-functional requirements have been agreed and during design, these non-functional requirements are being used alongside the functional requirements is down to the “Architect”.Non-functional requirements are all requirements that deal with the so-called “-ilities”:

  • Scalability: Ensure the solution supports the current and projected business volumes
  • Reliability: Ensure the solution provides an appropriate level of robustness in support of business processes.
  • Manageability: Ensure the solution can be managed and maintained efficiently and effectively.
  • Availability : Ensure the solution provides the required levels of service as well as performance characteristics and
  • Security : Ensure that the solution provides all security related measures and controls to minimise any security related risks (critical for cloud based solutions) 

rg 2) Something “we” have perfected over the years. There are plenty of HA (High Availability), DR (Disaster Recovery)   and BCP (Business Continuity Process) Solution Patterns available. Key is though that there is a clear understanding of the points I made in 1 – proper business insight is needed. Also here should come the decision how and where to deploy the solution incl deciding if fully private on premise, only non-production in a public cloud whilst production is in a dedicated DC or all in the cloud.

Below an example of a potential pattern (for a warehouse management system deployed on SAP and Oracle) .

Point is that the “Top in class Solution Architecture” is related to the Business insight. No Business Insight, no solution; regardless if you use Cloud or not.

rg 3) Over the past weeks and month I noted a number of key build2run related DevOps aspects. See here Part 6 of my DevOps posts – all of these aspects apply equally for cloud / non-cloud deployments. One thing to add though is the ability to fully test for failure. Highly critical applications must be tested for all outage scenarios (example):

Key elements to successfully design and deploy highly critical applications in a cloud or non-cloud context:

  1. Business insight
  2. Top in Class Solution Architecture and
  3. DevOps

Each project / solution has to be assessed on its own merits and whether to move part or all components into the cloud is something that must be decided during the design phase – see [1].

Thanks for reading

[1] “To Cloud, or not to Cloud” (see here

Related Posts


The Distribution Transformation Voyage: Leveraging the Open Insurer Architecture

Chad Hersh
Date icon December 17, 2020

As insurers look at their overall strategy for a digital transformation, they will need to...


Two considerations when migrating analytics platforms to the cloud

Date icon December 10, 2020

When migrating to the cloud, AWS provides an extensive library of services that encourages...