Enterprise Cloud Transformation – A recipe for successful strategies

Recipe

Any great food requires a great recipe and great execution, through multiple transitions. The recipe might need adjustment if available local ingredients are different and in fact, local ingredients may be preferred by locals, but ultimately everyone expecting the same outcome, which is great food!

Similarly, for a successful Cloud transformation, it requires a great recipe with all required ingredients including local ingredients each with the right portion. As you know just like food, any mistake we make in getting the right recipe leads to complete failure and that’s no different in Cloud transformation.

Background

Each organisation is different in terms of the business model, technology strategy, customer expectations, industrial obligations and cooperate compliances.

Most of these organisations are facing challenges around digital transformation and IT modernisation, which become a by-product of Cloud Transformation.

This paper explores whether a recipe could help here if so how to come up with an enterprise cloud strategy that would abstractly fit with each organisation.

What’s in Recipe

• Your business domain(s) and business model
• Your technology domain(s) and technology operations
• Your people and process
• Your compliance requirements

These four are not an exhaustive list of everything in a recipe, but without these, the recipe would not be considered complete.

Recipe Item One — Your Business Domain(s) and business model

There are three aspects of the business domain that need to be understood.

1) The current state of the business domain and how it’s related to customers, partners, and suppliers.
Furthermore, if there are any contractual obligations associated with any of the above parties, industrial regulations, regional jurisdiction and global laws such as data privacy acts.

2) What’s the business strategy look like in 6 months, 1-year, 2-year and 5-year timeframes?
This is probably the hardest and one must engage from C-level managers all the way down to business SMEs to get a consolidated view of business strategy.

3) Understand current business problems, inefficiencies, and data quality issues.
The business operations people would be the right people to provide insight into this, approaching the right person, asking the right ‘why’ questions while showing appreciation would help to get a better outcome.

Recipe two — Your Technology Domain and Technology Operations

1) The current state of the technology domain and what infrastructures and applications are forming the critical part of the workload.
This is a static view of the current state to understand the critical part of the IT landscape as a minimum requirement.

2) How the technology strategy looks in terms of infrastructure, application, delivery approach and cloud.
This needs to have details on each technology choices for long-term use, otherwise, it needs to be established. The delivery approaches such as agile and lean also come into play to include the cloud strategy, so it’s not something to be ignored.

3) Understand the current IT operational issues and deprecated platforms.
The IT operations/DevOps/SysOps/application support would be the right people to provide insight into this, again the right person/question with the appreciation of their experience would provide a better outcome.

Recipe Item Three — Your people and Processes

1) Gather information about IT skill sets across the organisation subject to the organisation’s long-term strategy to retain the capability in-house.
Either we need to have people already skilled in the chosen cloud or people who are passionate about gaining experience, otherwise, it needs to be addressed first, before any further steps.

2) If the organisation is looking to outsource parts of IT or entire IT, then we still need to understand what exactly needs to be outsourced.
Understanding and capturing clear roles and responsibilities now and later is critical for any transformation, not just cloud.

3) Understand any macro-level drivers such as re-structuring in progress/planned, acquisitions and disposals.
All of these factors affect people, it’s critical to understand what people skills will remain and useful for the cloud.

Recipe Item four — Your compliance requirements

1) Understand any existing certifications and attempts to gain any new certifications.
Knowing these would help to understand the future state of compliance certification requirements for the cloud, this will also highlight any special security requirements other than standard security.

2) Any data related compliance requirements.
Including any prescribed location of data (at rest, in use & transit) and local/regional/internal data privacy acts such as GDPR.

3) Financial compliance such as operational budget and transparency.
Understand whether there are budget caps for overall operations, by subdomain, by business capability, and by business service.

For further reading on Cloud Strategy, have a look at Cloud transition and strategical misalignment.

Conscious Choice — Understand the worse case of not knowing all the above!

This is very important and if a business didn’t know or understand the consequences of a poor cloud strategy, it’s an IT consultant’s responsibility to clearly articulate the risk associated with not considering all of the aspects above, so the business can make a conscious decision.

For the business to understand, IT should be using the terms in a business subdomain, business capability, and business services, it may create a worse impact if we talk about a particular application with business.

An application may be used across multiple business units and a single business unit never going to understand the impact to other business units when we migrate the application to Cloud, using the terminology that business understand is critical.

In the cloud, we talk about workloads, which could be fine-grained business services rather than all the application from the entire on-premise data center.

If there is a reason that an application must be migrated in one go, then we need to understand the impact from all affected business units and business services.

Ingredients

Now you have a clear understanding of your recipe for the Cloud Strategy, let’s look at the ingredients to go with the recipe.

Cloud Provider(s) and location of data

1) The factors that may influence the selection of the cloud providers including cooperate partnership, technology strategy and required capacities are in the cloud.

2) For each business subdomain, business capacities and business services, we need to define where the data can be stored at rest.

Separation of interest for cloud accounts and data

1) Establish how the cloud accounts should structure considering the business domain, subdomain, business capabilities, environments and compliance requirements.

2) Establish data stores and their locations for all business capabilities and accounts based on data access/retention policies, data privacy/classification requirements and compliance requirements.

Understand or Establish architecture principles and standards

1) The principals must include data and technology and anything else.

2) The standards must include data classification, data application, and data ownership.

3) Microservices strategy based on the business domain.

Establish migration strategies for each business service or application

1) Using “The 6Rs” approach we need to establish a migration strategy for each business services and applications.
The 6Rs are Rehosting, Replatforming, Refactoring, Repurchasing, Retiring and Retaining.

2) Identify and catalog the datasets that need to be migrated with each business services or applications.
In a large enterprise migrating a business service or application may have an impact on other business services if they are not Microservices already and applications if they are shared across multiple business services.

3) Identify and catalog data classification and location for each business services and applications.
This is critical as they may include data that must stay on-premise, data must not allow certain regions, data must be encrypted at rest (provided or BYO key) and data that needs to be shared for wider use (limited or open).

4) If the business services or applications are going to be separated from the datasets required, then establish the data access strategies.
Here special considerations should be given for security and compliance requirements for data in transit and best to use APIs (provided by the cloud provider) than having direct access to data stores.

5) Identify and establish networking and inter-networking requirements with appropriate network access control and required bandwidth.
Here we don’t have to go down to individual NACLs or subnets, but identify the number of security zones required, how they are going to relate to in a network also across a network.

Establish policies

1) Data retention policy.
At the minimum, this will establish how long the data should be accessible via the application and how long the data should be downloadable/accessible from the archived storage.

2) Data access policy.
This would involve expanding data classification with aspects such as audit requirements, allowed to modified or deleted and versioning if modification allowed.

Summary — No single cloud strategy

All above covers a broader perspective to consider for a long-term enterprise cloud strategy that may provide benefit for business and technology strategies.

The level of consideration given to each of the above perspectives may differ from organisation to organisation and the level of maturity they are seeking.

These guidelines would help to make a conscious choice to come up with an enterprise cloud strategy.

This could be a joint effort between an enterprise architect, solutions architect(s) and cloud architect(s) “roles” with consultation from senior managers and others as required from business and IT.

The size of the organisation might determine how many of these “roles” could be combined into one person as not all organisation may have an individual for each of these “roles”.

The enterprise and solutions architect roles may need lots of people skills while the cloud architect role provides broader and deeper inside into cloud technology and the latest trends.

Last not least more than anything else IT’s primary function is to support the business, reiterating this in every solution would help to come up with the right size solution for each business needs.

Disclaimer: This article was produced in my own capacity; no association could be assumed with the organisations that I am helping at present or helped in past.