Cloud

Moving to Multi-cloud: Roadmap Considerations

Norman Dee By Norman Dee Global Practice Lead, Operating Model Consulting Service Enablement September 24, 2018

This blog is part of the Moving to Multi-Cloud series, which gives practical advice on how to move your multi-cloud strategy forward.

Not All Roadmaps Are Equal

Many organizations are busy working on the move to multi-cloud, but all too often their initiatives are disconnected and scattered, with application developers building in one set of clouds and infrastructure teams building up their multi-cloud capabilities without sufficient alignment with the application teams.

These organizations typically start with an infrastructure roadmap focused on getting their new technology in place. The impact to the operating model and service delivery is often an afterthought. When it comes to applications, many organizations have a “cloud first” approach looking to build or update their applications in public clouds without regard to data compliance, inter-dependencies or real cost. They have expectations of increased availability, scalability, speed and flexibility at lower costs.

To build an effective roadmap, you need to understand and integrate infrastructure, operating model and application activities. There are major dependencies between these areas that impact the success of the transformation.

Infrastructure Considerations

The first step in determining infrastructure roadmap initiatives is to understand your current state. Key dimensions to consider include:

  • Services: Is there a service catalog? Are the services standardized? Is there a self-service capability? Do you offer both infrastructure and cloud-native services?
  • Inventory: How accurate is the CMDB? Is it aligned with the services IT provides?
  • Asset alignment: Is asset information (for example costs, contracts, service lifecycle) linked to the CMDB?
  • Stack: What software components (e.g., VMware, container-based, OpenStack) and approaches are being used to deliver services?
  • Security: What kind of ID access management and data protection is there? Are the rules and processes sufficient and consistent for a multi-cloud scenario?
  • Funding model: Is the budget project-based or IT-owned? Is there a showback/ chargeback capability? How will it be impacted by a multi-cloud implementation?  Will the rates be platform or service specific?
  • Physical environment: How many data centers to you have? What are the sizings? Actual peak utilization? What are the various technologies? Is there virtualization? What is the current public cloud usage?
  • Monitoring/Performance: What kind of monitoring is there? Real-time monitoring, alert management, business alignment, or escalation management? How is performance measured and reported? Is there a performance database, dashboards, or SLA reports? Will there be a single pane of glass for both internal and external systems?

You also need to define your target state, which will drive your data center strategy. Depending on the application strategy, the target data center will not to be as big if you’re moving some applications to the cloud. Think about the effects of increased virtualization, software defined infrastructure (SDDI), flash, and converged/hyper-converged infrastructure. Also consider services-based architectures (IaaS, PaaS), and resiliency strategies. Think about having a service catalog that offers self-service provisioning of these services.

Operating Model Considerations

As you build out the roadmap, current roles and processes will need to evolve to be more in line with the services and development methodologies. Is there a true service management operating model? Is the IT operations team integrated with the application operations teams? There may need to be new IT service-based roles and processes, as well as new DevOps roles and processes.

How closely is IT working with the business units and with developers to understand and manage both IT and cloud-native service demand? Business Relationship Managers (for aligning business needs with IT services), Service Portfolio Managers (for managing the catalog and services life cycle), and Demand Managers (for structuring the demand) roles may have to be created.

Do you have a capacity management process? Is it siloed, integrated, or federated? Is it linked to demand, organic and new business trending? Are there dashboards indicating effective capacity utilization, predictive needs? What do you need to do to be able to right-size your operations to ensure resources for current and future services?

Consider a financial management strategy for transparent service-based pricing and billing. This will allow you to recover costs for services based on usage as well as demonstrate market-competitive pricing.

Application Considerations

Your applications and infrastructure strategies need to be coordinated between the Application Development teams and IT. Rather than just shifting virtual machines to the new infrastructure, think about determining disposition of current applications:  determine which should be migrated to the new environment, which should be moved to public cloud, which should be replaced with SaaS applications, and which should be retired.  Prioritize applications moving to the new infrastructure, making sure that the progress of infrastructure capabilities closely matches the technical needs and business priority of particular applications.

In addition to applications, there are many, many development tool stacks available; typically every application development group has different combinations of tools and integration environments.  These often require infrastructure resource APIs for the rapid provisioning and decommissioning of developer needs.  A partnership between the app dev teams and IT where both agree on the development stack, or a standard API that IT will provide, is essential. This will enable the application teams to simply request the environment they need, freeing them to focus on their real work – developing applications. This may mean reviewing the current portfolio of tools, understanding where there are opportunities for rationalization, or building a standard API for infrastructure resources. All of this is dependent on the size, culture and diversity of the lines of business IT supports.

Focus on Outcomes

Rather than trying to address many requirements and features with a large, long-term development project, developers often focus on an agile approach, quickly delivering just a functional piece of what’s needed, or a minimally viable product (MVP). They then adjust development of the next MVP based on feedback from the first MVP.

This is an effective strategy for transformation roadmaps as well. Align activities and deliverables across infrastructure, operating model and applications. Think about overall transformation outcomes, not just those of each transformation area. For example, think about the minimum infrastructure services that are needed by application owners and software developers which can be built in a few months, versus trying to create the perfect set of services that may take 1-2 years. Similarly, for operating model, focus on a small set of processes and roles that can quickly be aligned to a more agile cloud operating model instead of trying to overhaul all processes at once.

Set a short timeframe for the first MVP milestone, ideally at 4-6 months.  Each MVP milestone should have metrics and deliverables for specific outcomes. The idea is that you’re trying to get beyond programs that go for years before they deliver value, you want to be able to show value at each stage of the transformation. The outcomes for each MVP stage should be carefully monitored, and the following roadmap stages modified based on the feedback.

Don’t Forget About Governance!

Successful transformations include a dedicated governance track, with regular reviews of program progress. Consider including a Transformation Program Office (TPO) integrated within your IT organization to provide overall transformation oversight. The TPO, often composed of a high level project manager and enterprise architect, operates as the single point of accountability for, and management of, schedule, resources, scope, budget, issues, and risks.

Consider incorporating a steering committee of key stakeholders and decision makers whose input and support will ensure business alignment and executive sponsorship. Think about integrating a change management program to ensure smooth business operations during the transformation.

A communications program to promote success at various stages of the transformation, including metrics where you can, is critical. This helps everyone understand what’s going on while building confidence and support in the program.

Summary

By integrating infrastructure, operating model and application activities, establishing metrics and identifying outcomes, as well as defining the overall governance needed to successfully manage the transformation, you will be able to build a highly prescriptive and effective transformation roadmap.

Blog in the Series

Moving to Multi-cloud: How to Get Stakeholders Aligned (Part I)

 

Norman Dee

About Norman Dee


Global Practice Lead, Operating Model Consulting Service Enablement

Norman Dee is the Global Practice Lead for Operating Model Enablement at Dell EMC covering transformation tools for Operating Model, IT Financial Management/Business Case and Capacity Planning. In his role, he helps enterprises fully understand the technical and financial benefits of operating model and infrastructure transformations. His career has spanned roles from directing worldwide projects to CTO/CIO, across multiple industries including financial services, publishing and online retail.

Read More

Share this Story
Join the Conversation

Our Team becomes stronger with every person who adds to the conversation. So please join the conversation. Comment on our posts and share!

Leave a Reply

Your email address will not be published. Required fields are marked *