Want to drastically increase the chances of success for your cloud programme? Get into the details! Uncover and resolve dependencies as early as possible!

This article is part of the limited preview of the “The Missing Cloud Programme Roadmap”, a generic roadmap for any enterprise cloud adoption programme.

1. Executive Summary
2. The Cloud and Enterprises
3. The Missing Cloud Programme Roadmap
   1. The Cloud Programme Roadmap
   2. The First Iteration of The Cloud Programme Roadmap
   3. The Unavoidable Disclaimer
   4. The Roadmap for The Missing Cloud Programme Roadmap
   5. The Manual for the Missing Manual
   6. Building the Business Case
   7. Starting the Cloud Programme
      1. Key Achievements
      2. Setting up the Cloud Programme
      3. Attracting the Right Mind- and Skill Sets
      4. Putting People First
      5. Determining the Build-Out Principles for Cloud
      6. Getting Into the Details
         1. Selecting CSPs
         2. Assessing and Resolving Dependencies
            1. Corporate Services
            2. Teams and Processes
         3. Application Inventory
      7. Recording Outcomes: The Cloud Guidebook
   8. Iteratively Building the Delivery Pipeline
   9. Iteratively Executing the Delivery Pipeline
4. A Cloudy Future

Getting Into the Details

With the cloud programme started, staffed, and the build-out principles determined, it’s time get into the details and secure the success of the programme. Well, or at least significantly increase the chances thereof.

Selecting CSPs

Early personal and programme-independent experimentation with several CSPs will most likely have occurred up to this point in time. Several experts might even already be offering various opinions on which CSPs the organisation should adopt.

A thorough assessment of the strengths and weaknesses of each CSP by the cloud programme should provide a data driven answer for the organisation based on factual evidence.

Obvious CSP candidates may very well vary by locale, regulatory requirements, or preferences. The assessment should be based on the requirements of the organisation as documented in the Cloud Manifesto and identified in this phase.

While the technical capabilities are a major factor in the assessment, legal or financial opportunities, such as guarantees, indemnifications, preferred price points, or sustained usage discounts should also be taken into consideration.

Given the far reaching impact of the cloud programme, there’s a decent chance that the assessment will take its time, as data points and metrics from almost every part of the organisation need to be collected.

Once candidate CSPs are identified, negotiations should start and aim at signing contracts; note that this can take several months, depending on the size and speed of the organisations involved.

Moreover, this phase also serves to lay the foundations of a strong working relationship with the selected CSPs. This includes securing all the necessary help the organisation can and will rely on during succeeding phases. Without it, who’s going to bridge gaps in the CSP offerings or provide crucial SME knowledge?!

Assessing and Resolving Dependencies

Regardless of which CSPs are eventually chosen, all their cloud offerings need to be integrated into the corporate ecosystem in order to eventually become first class citizens.

Unless the organisation decides to rebuild everything from scratch, chances are that existing services, processes, controls, and many more need to be adapted to work with the cloud. Let alone create new ones.

This creates dependencies for the cloud programme. Up to the point of these dependencies becoming roadblocks when they cannot be resolved.

Thus, continuously identifying and monitoring the resolution of dependencies is a critical activity of the cloud programme. Especially, as it is often confronted with deep and complex dependency chains.

The first dependency assessment deliberately highlights high priority ones. Those are dependencies that can or should already either be leveraged from or extended to the cloud and will be needed fairly soon.

Categorising and assessing dependencies at this early stage allows to start initiatives to resolve them before they become roadblocks!

Bare in mind that the success of the entire cloud programme depends on these initiatives. Start, staff, and support them so that they can and will succeed!

Corporate Services

Like any other platform, the cloud should also integrate with a series of common basic services provided by the organisation, better known as corporate services.

Leveraging corporate services facilitates organisation-wide standardisation through re-use, unlocks economies of scale, and allows to more easily meet regulatory requirements.

In the context of the cloud programme, these corporate services and their functionalities include, but are not limited to

• Network Services. Allowing seamless and well-controlled connectivity to and from the cloud. Additional software defined services worth considering — both on-premise as well as in the cloud — are
  • Firewalls. Allowing to selectively open ports or IP ranges.
  • Network Routing. Allowing to create, isolate, or bridge networks.
  • External Facing Proxies. Allowing flexible access to the internet.
• Identity and Access Management (in short: IAM). Allowing users to log onto environments and being granted certain access privileges.
• Privileged Access Management (in short: PAM). Allowing users to escalate their privileges.
• Logging and Monitoring (in short: L&M). Providing historical and near-real time information about actions and activities performed by processes or users across environments.
• Asset Management System. Allowing the organisation to keep accurate records about all assets it has or had possession of.
• Toolchain. Allowing engineers to develop compliant applications and eventually deploy them onto environments. Key components are
  • Developer Desktop. Providing engineers with suitable tools and processes to develop applications.
  • Version Control Systems (in short: VCS). Unlocking distributed collaborative development of applications.
  • Continuous Integration/Continuous Delivery (in short: CI/CD) Pipeline. Automating most parts of the software delivery process.
  • Binary Artefact Management System. Serving as a repository for binary artefacts.
  • Deployment Model. Outlining the deployment process and providing corresponding tooling.
  • Software Supply Chain Security Tooling. Ensuring the integrity and security of the entire software supply chain.
• Secrets Management and Vaulting. Allowing the seamless handling of secrets or credentials, ranging from keys to certificates and licence files.
• Configuration Management System (in short: CMS). Allowing seamless and consolidated configuration of all elements in an environment. Note that this should be an independent system. And not a Git repository!
• Service Mesh. Easing the adoption of distributed compute. While maybe not immediately required, the existence of such a service encourages the adoption of more platform-native approaches.

Note that the above services are also the very first integration points of any cloud into the corporate ecosystem. This makes the existence and availability of appropriate corporate services a prerequisite to the success of the entire cloud programme.

Teams and Processes

Apart from the direct dependencies on the services and corresponding processes identified above, the cloud programme also has dependencies on numerous other teams, most likely stretching to nearly the entire organisation.

A selection of the teams that need to be prepared for the eventual adoption of cloud are

• Sourcing. Procurement of services or applications running in or on the cloud requires revised or new processes ranging from updated contractual negotiation patterns to supporting novel billing models and methods.
• Legal. Limiting the organisation’s exposure requires new standards, frameworks, and processes.
• Developers. Engineering for the cloud requires new standards, patterns, frameworks, processes, tooling, and environments. Arguably, one of the most impacted teams.
• Operations. Operating the cloud platform or applications running in the cloud requires new standards, processes, tooling, and runbooks.
• Support. Supporting the cloud platform or applications running in the cloud requires new standards, processes, tooling, and runbooks.
• Audit. Providing a comprehensive audit trail, or even better, full traceability, visibility and observability of all cloud environments, requires new standards, patterns, frameworks, processes, tooling, and integrations. Let alone the ability to handle the speed of the cloud.
• Compliance. Ensuring compliance, let alone continuous compliance, requires new standards, frameworks, tooling, processes, and integrations.
• Users. Using services or applications running in the cloud requires updated integrations, revised manuals, as well as providing suitable training and support.
• Business. Providing or leveraging services or applications running in the cloud requires new standards, processes, integrations and sign-offs.

Bear in mind that the mere speed of the cloud will most likely require significant changes. Anticipate them early and support impacted teams as soon as possible. The success of the cloud programme depends on these teams succeeding.

Application Inventory

The most visible deliverable of the cloud programme is a platform which applications can leverage. Applications migrate to the platform according to their “cloud suitability”. The first step towards assessing potential candidate applications is to have a complete overview of the organisation’s application portfolio.

For every application in the organisation, the application inventory system should include data points on

• Lifecycle Status. Indicating whether the application is actively being invested in, maintained, or being divested.
• Application Owner. The people (plural intended) responsible for the application and also the first points of contact.
• Application Documentation. All documentation in regards to the application, including legal documents, manuals, and (especially for the cloud programme) recent and accurate architecture documents.
• Systems Development Life Cycle (in short: SDLC). The (ideally standardised) pattern used for planning, creating, testing, and deploying the application.
• Environments. The current environments the application is deployed to.
• Deployments. Historic and current deployments of the application.
• Metrics. All available metrics as used and collected by the application or mandated by the organisation, such as footprint in the environment or any other noteworthy data points that should be taken into consideration when assessing the application.
• Dependencies. All hardware and software dependencies of the application. Note that this also allows to eventually derive any potential vulnerabilities.
• Enterprise Integrations. All upstream and downstream integrations of the application.

Now, most modern organisations will already have and operate an application inventory system. However, the absence of such a system poses a great challenge, as is prevents making data driven decisions based on factual evidence. As such, it is a hidden dependency which can severely impact the delivery of the cloud programme.

Recording Outcomes: The Cloud Guidebook

Find out more about it in the next article.

So, How Do You Resolve Dependencies?!

While the above Worx for Me!™ when it comes to getting into the details and resolving dependencies, thus significantly increase the chances of success, you may have an alternative or better way.

Think this is all rubbish, massively overrated, or generally heading into the absolutely wrong direction?! Feel free to reach out to me on LinkedIn and teach me something new!

As always, prove me wrong and I’ll buy you a pint!