Get it in writing: The criticality of documenting your cloud blueprint and operating model

Learn how the cloud blueprint and operating model ensure your cloud strategy's success.

Get it in writing: The criticality of documenting your cloud blueprint and operating model

Layout canvas

This blog is from Cloud Strategy Unboxed, a series that looks at the recommended organizational structure for the successful adoption and operation of the cloud.

Blueprint and model differences

The blueprint and operating model documents are often confused, and not all organizations consistently use the same terminology. To facilitate a common understanding, we define them as follows.

Cloud Blueprint vs Cloud Operating Model

Figure: Cloud Blueprint vs Cloud Operating Model

The Cloud Blueprint is all about executing the cloud adoption strategy. Compared to the operating model, it is more like a project management document, covering the implementation of the cloud strategy, going from the current state to the adapted ideal state.

The Cloud Operating Model is all about how to run the cloud environment once it has been built. It includes the technical capabilities, risk management, processes, operations, and the roles and responsibilities of the various stakeholders required to operate and evolve the use of the cloud within the organization. The operating model ensures that all teams are aware of what they need to do, when they are expected to do it, and how they need to do it.

For example, a cloud blueprint includes the actions required to evolve the existing infrastructure and other relevant teams to a structure better suited for cloud management, and there could be high-level requirements for building a cloud platform that is suitable for the organization

A cloud operating model would include the schedule and agenda for the recurring cloud roadmap priority discussions and a process for reviewing the currently supported cloud services.

The blueprint and operating model face similar challenges. It can be difficult to gain consensus across all stakeholders for what are often disruptive changes to the organization. Similarly, getting stakeholder agreement on the RACI can be difficult as this will include accountability for the program objectives. Lastly, it can be difficult to get the resources required to execute, without which the strategies are only an aspiration.

Structure of a Cloud Blueprint

Like most strategy documents, it’s helpful to start with an executive summary that covers the key points while avoiding jargon and anything too technical.

The overview section provides the why and how of a blueprint in general terms. The contents here are relevant to the organization but not necessarily contextualized. For example, it could include lessons learned that were described by a similar organization in a public presentation or case study. The overview section is intended to manage expectations for this document and help people understand its purpose, why it exists, and the risks of not having it.

The organization’s current state and risk assessment results are covered in detail in the discovery report, but here we can briefly summarize that and refer to the document. It is important to at least note the main points, as the cloud blueprint needs to draw clear lines and actions between the current state and the desired target state throughout the following sections.

The later sections should have content that is specific, relevant, and contextualized to the organization. From an overview of the challenges, mitigations and opportunities to the goals the blueprint strives for. It should also provide quantifiable metrics for tracking success and realistic milestones for the immediate next and following steps.

The final section of the blueprint is about delivery, from the specific streams and deliverables to the roadmap and timelines. For example, there will often be a Cloud Centre of Excellence stream. However, the details will depend on the organization. There are typically three scenarios:

  1. There is already some form of cloud team responsible for the cloud.
    The roadmap will evolve this to the ideal CCoE structure by bringing in new people to fill the recommended roles not present in the current cloud team.
  2. There is no cloud team.
    The roadmap will be to build a CCoE from scratch, finding suitable candidates internally or hiring externally where necessary.
  3. There is no cloud team and no appetite or budget for a full CCoE in the short term.

The roadmap will be two-phased. Starting with an interim cloud team that includes key CCoE roles. Existing staff will take on the roles splitting their time between their current role and the CCoE one. Phase 2 will evolve the interim team to the recommended (full-time) CCoE roles. Note that this is a deviation from the ideal state. As such, new risks will need to be identified and mitigated.

It should be noted that the blueprint is a living document. Execution should be agile, but at the same time, risks need to be managed, and budgets and timelines need to be estimated - at least at a high level.

Structure of a Cloud Operating Model

Following the executive summary, the cloud operating model should have a general overview to help manage expectations for this document. Keep in mind that this document assumes the cloud state has already been achieved following the cloud blueprint, so here we can focus on the people, process and technology considerations of operating the achieved adapted ideal state.

  • People focuses on roles and how they evolve over time as the organization’s cloud footprint grows.
    • KPIs are needed to support evolving responsibilities and provide the right incentives.
    • Ongoing training is needed to upskill existing and new hires in how to use the cloud, following the established strategy and principles
  • Process should favour automation over manual workflows, and be open to evolving and continuous optimization to remain relevant in a changing cloud landscape.
    • Besides security and risk processes, finance processes are important too. For example, monitoring cloud spend and timely reacting when it can be optimized for a given workload.
  • Technology is about the ongoing platform operations, evolving it to keep pace with cloud changes, continuous improvement of DevSecOps automation, and supporting cloud-native application design for new builds and migrations.

Some other areas are worth considering as part of a cloud adoption strategy. These could be part of the blueprint and operating model or stand-alone documents that can be referenced instead.

  • Financial strategy (FinOps)
    Covers the financial operations of the cloud. Tracking costs, budget alerts, and linking costs back to specific applications and teams.
  • Communication plan and cloud handbook
    Covers internal communication on matters of the cloud and basic understanding and use of the cloud for staff.
  • Application migration and modernization
    Each existing application should be assessed for cloud suitability and a plan drawn up. This determines which applications will be moved to the cloud, when and how they will be moved, and how much work will be done to optimize each for the cloud.
  • Compliance mapping and cloud directives
    These are the central source of truth for an organization’s security, quality, and other compliance policies in the cloud. Typically, these are derived from existing on-premises policies, adapted for cloud relevance, and augmented with new cloud-specific concerns. The directives are used to design the enforcing controls for each of the cloud providers that the organization wants to support.

Summary presentation

Creating a summary presentation deck for the different documents in your cloud strategy can be helpful. This provides a high-level overview of the key points that is easier to digest than what are often quite large documents.


The cloud blueprint and cloud operating model are two essential documents that can help organizations successfully implement and run a modern cloud management strategy. While the two terms are sometimes used interchangeably, the blueprint focuses on executing the cloud adoption strategy, while the operating model is all about running the cloud environment once it has been built. Both documents face similar challenges, including gaining consensus across stakeholders, getting agreement on roles and responsibilities, and securing the necessary resources for execution.

The cloud blueprint should include an executive summary, an overview of the challenges and opportunities, and specific, relevant, and contextualized content for the organization, while the cloud operating model should focus on people, process, and technology considerations of operating the achieved adapted ideal state. Other areas worth considering as part of a cloud adoption strategy include financial strategy, communication plan and cloud handbook, application migration and modernization, and cloud directives. Creating a summary presentation deck can provide a high-level overview of the key points of the cloud strategy documents.

Don't miss out on unlocking the full power of the cloud. Contact us today for a personalized consultation or to learn more.


make it

Your future looks
breath-taking from here


Embrace the cloud and together we’ll see your business agility, innovation and scalability soar to new heights.

Simplify the complex,
deliver the brilliant


Discover the streamlined, cost-efficient and intelligent answer to increasingly complex customer, IT and network demands.

Fill your customers’ day
with content they love


Build an irresistible content proposition and experience that keeps your customers coming back for more.

Reinvent the customer
experience. Every day.


Discover the agility to deliver a jaw-dropping digital experience that always exceeds expectations.

Make today’s impossible
tomorrow’s possible


Unlock the full potential of 5G and shape the network to create new capabilities, unique business models and game-changing opportunities.


about Amdocs

Discover how Amdocs can help your business.


Your future looks breath-taking from here.


Simplify the complex, deliver the brilliant.


Fill your customers’ day with content they love.


Reinvent the customer experience. Every day.


Make today’s impossible tomorrow’s possible.



Apologies, our website does not support this browser