OPEN DATA CENTER ALLIANCE SM EXECUTIVE OVERVIEW Cloud Maturity Model Rev. 3.0 CONTRIBUTORS Allan Colins T-Systems Christoph Jung T-Systems Immo Regener PwC Lucia-Marie Muench Mariano Maluf The Coca-Cola Company Matt Estes The Walt Disney Company Ryan Skipp T-Systems Tom Scott The Walt Disney Company William Dupley Hewlett-Packard Open Data Center Alliance, Inc. 3855 SW 153 rd Dr. Beaverton, OR 97003 USA Phone +1 503-619-2368 Fax: +1 503-644-6708 Email: admin@opendatacenteralliance.org 2015 Open Data Center Alliance, Inc.
TABLE OF CONTENTS CONTENTS 3 Legal Notice 4 Introduction 9 Overview of the Cloud Maturity Model 10 Description of the Cloud Maturity Model 21 Maturity and Quality 21 Self-Assessment 22 Conclusion 2
LEGAL NOTICE 2016 Open Data Center Alliance, Inc. ALL RIGHTS RESERVED. This OPEN DATA CENTER ALLIANCE SM Executive Overview: Cloud Maturity Model Rev. 3.0 document (this document ) is proprietary to the Open Data Center Alliance (the Alliance ) and/or its successors and assigns. NOTICE TO USERS WHO ARE NOT OPEN DATA CENTER ALLIANCE PARTICIPANTS: NonAlliance Participants are only granted the right to review, and make reference to or cite this document. Any such references or citations to this document must give the Alliance full attribution and must acknowledge the Alliance s copyright in this document. The proper copyright notice is as follows: 2015 Open Data Center Alliance, Inc. ALL RIGHTS RESERVED. Such users are not permitted to revise, alter, modify, make any derivatives of, or otherwise amend this document in any way without the prior express written permission of the Alliance. NOTICE TO USERS WHO ARE OPEN DATA CENTER ALLIANCE PARTICIPANTS: Use of this document by Alliance Participants is subject to the Alliance s bylaws and its other policies and procedures. NOTICE TO USERS GENERALLY: Users of this document should not reference any initial or recommended methodology, metric, requirements, criteria, or other content that may be contained in this document or in any other document distributed by the Alliance ( Initial Models ) in any way that implies the user and/or its products or services are in compliance with, or have undergone any testing or certification to demonstrate compliance with, any of these Initial Models. The contents of this document are intended for informational purposes only. Any proposals, recommendations or other content contained in this document, including, without limitation, the scope or content of any methodology, metric, requirements, or other criteria disclosed in this document (collectively, Criteria ), does not constitute an endorsement or recommendation by Alliance of such Criteria and does not mean that the Alliance will in the future develop any certification or compliance or testing programs to verify any future implementation or compliance with any of the Criteria. LEGAL DISCLAIMER: THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN IS PROVIDED ON AN AS IS BASIS. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE ALLIANCE (ALONG WITH THE CONTRIBUTORS TO THIS DOCUMENT) HEREBY DISCLAIM ALL REPRESENTATIONS, WARRANTIES AND/OR COVENANTS, EITHER EXPRESS OR IMPLIED, STATUTORY OR AT COMMON LAW, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, VALIDITY, AND/OR NONINFRINGEMENT. THE INFORMATION CONTAINED IN THIS DOCUMENT IS FOR INFORMATIONAL PURPOSES ONLY AND THE ALLIANCE MAKES NO REPRESENTATIONS, WARRANTIES AND/OR COVENANTS AS TO THE RESULTS THAT MAY BE OBTAINED FROM THE USE OF, OR RELIANCE ON, ANY INFORMATION SET FORTH IN THIS DOCUMENT, OR AS TO THE ACCURACY OR RELIABILITY OF SUCH INFORMATION. EXCEPT AS OTHERWISE EXPRESSLY SET FORTH HEREIN, NOTHING CONTAINED IN THIS DOCUMENT SHALL BE DEEMED AS GRANTING YOU ANY KIND OF LICENSE IN THE DOCUMENT, OR ANY OF ITS CONTENTS, EITHER EXPRESSLY OR IMPLIEDLY, OR TO ANY INTELLECTUAL PROPERTY OWNED OR CONTROLLED BY THE ALLIANCE, INCLUDING, WITHOUT LIMITATION, ANY TRADEMARKS OF THE ALLIANCE. TRADEMARKS: OPEN CENTER DATA ALLIANCE SM, ODCA SM, and the OPEN DATA CENTER ALLIANCE logo are trade names, trademarks, and/or service marks (collectively Marks ) owned by Open Data Center Alliance, Inc. and all rights are reserved therein. Unauthorized use is strictly prohibited. This document does not grant any user of this document any rights to use any of the ODCA s Marks. All other service marks, trademarks and trade names reference herein are those of their respective owners. 3
INTRODUCTION None N/A Initial Ad Hoc Repeatable Opportunistic Defined Systematic Measured Measurable Optimized Figure 1: The cloud maturity model has five progressive levels of maturity. A maturity model is a tool intended to help an organization analyze its current state, define a target state within the context of business objectives, and then perform a gap analysis between current and target states. When ODCA first introduced the Cloud Maturity Model (CMM), version 1.0, it was quickly adopted by many organizations. These early adopters provided constructive recommendations and feedback toward improving its usability. For this reason, the ODCA has developed an updated version that is designed to be more user-friendly. The new CMM includes more detailed explanations and enables the structured development of a set of plans and changes necessary to achieve appropriate business objectives. The Open Data Center Alliance has identified the need for a CMM that enterprises can apply in order to: 1. Support the development of a balanced cloud strategy and roadmap in any enterprise 2. Understand the various dimensions that constitute cloud maturity from the perspective of the consumers and the providers of cloud services 3. Develop focused investment initiatives (i.e., a roadmap for their journey to hybrid IT and cloud adoption) to move selected cloud capabilities/ domains to target maturity levels in order to improve their effectiveness 4. Steer priorities relating to cloud service usage and adoption 5. Leverage the ODCA publications to identify characteristics and artifacts that enable an enterprise to increase cloud maturity and service success through cloud service adoption 6. Maximize the potential to achieve the expected benefits of the cloud, to an acceptable degree 7. Provide a roadmap of projects to accomplish the changes in maturity levels for each domain 4
The ODCA Cloud Maturity Model maps cloud maturity from two key perspectives: Business capabilities in specific domains Technology capabilities in specific domains these groupings include maturity levels for the individual cloud service models such as: SaaS, PaaS, IaaS, DBaaS, platform integration as a service, and information as a service among others The objective of the CMM is to help enterprises build custom roadmaps toward more effective hybrid IT aligned to their specific needs and objectives. Defining Objectives The objective of the CMM is to help enterprises build custom roadmaps toward more effective hybrid IT aligned to their specific needs and objectives. Hybrid IT references the use of traditional internal IT systems and cloud environments. This includes the participation of external partners, systems, and services simultaneously. Hybrid IT considers the multiple layers of people, process, and technology across the enterprise IT in the context of the different operating models driven by IT service type, internal delivery models, and external delivery models. The business domain capabilities addressed in the CMM provide a comprehensive view of the maturity model s stages through the lens of business use of the cloud. Across business categories this perspective includes cloud service models, cloud deployment models, and capabilities per cloud domain. The technology domain capability perspective of the CMM provides a similar view of the enterprise s cloud maturity through the lens of cloud and information and communications technology (ICT). These perspectives on cloud maturity offer a way for an enterprise to plot its maturity level in the context of a number of possible use cases, which enable them to select the ones best suited to their business needs. Some enterprises are organized (or targeted toward business models) such that one or more of the cloud service models are of little value or produce an inverse total cost of ownership. These enterprises can assess their maturity across the cloud service model that is applicable to the enterprises, without the added complexity of the service models that do not apply. 5
Notes on Cloud Maturity Model 3.0 1. The CMM does not provide detailed solutions to the enterprise adoption of cloud or hybrid IT. The CMM provides a roadmap to adoption, pointing to potential gaps and possible frameworks and solutions to consider. 2. The CMM treats enterprise IT as a service provider, not a consumer. This creates consistent CMM results. 3. Outcome guides answer, What does the delivered result look like? 4. The CMM provides a portfolio of domains from which the user can select appropriate ones to assess. The user does not have to assess all the domains, we recommend that a user assess only the domains that are necessary to deliver their specific use cases. Not all domains are required or optimal for all enterprises to pursue. 5. Establishing hybrid IT is a journey that is taken as a set of defined steps. The process does not necessarily include the whole enterprise at once. The objective of the CMM is to achieve the expected cloud benefits. This is accomplished by ensuring that the necessary elements are identified and an actionable roadmap is in place. In cases where an enterprise will use a combination of two or three cloud service models, plot maturity across SaaS, PaaS, IaaS, and Info-aaS, among others, independently CMM helps IT strategists chart cloud maturity in the context of the specific technology and service approaches, the ability to use them, and the ability to operate a diverse set of IT platforms as represented by the hybrid IT model. The objective of the CMM is to achieve the expected cloud benefits. This is accomplished by ensuring that the necessary elements are identified and an actionable roadmap is in place. For example, if an enterprise is striving to achieve speed, then a certain amount of automation and process integration needs to be in place between the consumer and the provider. 6
The Benefits of Cloud Technology Some of the expected benefits arising from the use of a mature implementation/integration of cloud technology include: Increased capability in certain domains new features and functions for the business that don t have to be self-developed Efficiency reuse of standard designs and solutions with coordinated development, operations, and support Velocity ability to change and deploy services in near-real time Flexibility ability to scale and change services to align with dynamic business needs Quality increased focus on standardized services that are engineered, operated, and supported consistently across the enterprise Differing Enterprise Types, Differing Aims When using the CMM, it is important to note that there are significant differences between the enterprise types. Consider typical public and private enterprises. The aim of the public sector is generally to serve the people, while the private sector enterprises are generally established with profit motives. Public-sector enterprise objectives: maximize social welfare, support economic growth, serve the citizens of the country, make political gain, cost not an issue, create jobs Private-sector enterprise objectives: maximize profits, make business gains, reduce production costs, decrease time to market Stated benefits and objectives in the Cloud Maturity Model should consider both enterprise types and need to be applied individually. The CMM identifies five levels of cloud maturity, but it is not necessary for an enterprise to aspire to CMM Level 5 in all cases. Different levels in the 7
It is up to each enterprise to determine for itself where it wants to be and what actions and enablers will take it there. different domain capability areas may also be acceptable when they meet that enterprise s requirements adequately. It is up to each enterprise to determine for itself where it wants to be and what actions and enablers will take it there, per domain capability. In addition, this combination of legacy systems is viable: Private and hybrid clouds providing infrastructure as a service (IaaS) Platform as a service (PaaS) Software as a service (SaaS) CMM 5 does NOT dictate pure public or SaaS-based systems. It describes a managed set of controls, processes, and systems to help to consistently manage cloud services in line with business priorities, with sustained and enterprise aligned processes. As an enterprise progresses through introspection and ascertains targets, it is common to identify islands of excellence within the enterprise that show more cloud maturity than other areas. This is normal and an indication of being at CMM 1 or 2. A consolidated, cohesive enterprise-aligned cloud strategy will enable consistent measurement and rating of the entire enterprise. Clearing the Air: Legacy and Cloud Maturity Legacy environments will not go away. They add value for many years and should not detract enterprises from developing a cohesive and effective cloud roadmap and strategy as well as a strong cloud maturity achievement. Everything does not have to be on a federated cloud for an enterprise to be in the more mature rating levels. An enterprise could achieve a high CMM rating by: 1. Identifying consistent frameworks and controls 2. Enabling selected business systems according to a defined set of categorization 3. Running according to a defined strategy in the cloud 4. Representing the characteristics and artifacts identified in the CMM model 8
OVERVIEW OF THE CLOUD MATURITY MODEL The CMM provides an end-to-end visualization (adoption roadmap) of how the use of cloud services develops over time. It also shows how the enterprise can increase its ability to adopt cloud-based services within defined objectives, governance, and control parameters. As the enterprise matures, use of cloud-based services becomes more sophisticated, comprehensive, and optimized. The CMM plots the progression of structured cloud service integration from a baseline of no cloud use through five progressive levels of maturity. CMM 0: Legacy CMM 1: Initial, ad hoc CMM 2: Repeatable, opportunistic CMM 3: Defined, systematic CMM 4: Measured, measurable CMM 5: Optimized 9
DESCRIPTION OF THE CLOUD MATURITY MODEL Figure 2 gives a summary description of each maturity level. It does not differentiate among the various types of cloud technology, cloud methodologies, or cloud deployment models. Each of these factors will be taken into account as the progressive levels of cloud maturity are explored in detail. CMM 0 Legacy CMM 1 Initial, Ad hoc CMM 2 Repeatable, Opportunistic CMM 3 Defined, Systematic CMM 4 Measured, Measurable CMM 5 Optimized Legacy applications on dedicated infrastructure No cloud approach. No cloud elements implemented. Analysis of current environment s cloud readiness Mapping and analysis of cloud potential for existing systems and services. There is some awareness of cloud computing, and some groups are beginning to implement cloud computing elements. Processes for cloud adoption defined An approach has been decided upon and is applied opportunistically. The approach is not widely accepted. Redundant or overlapping approaches exist. Informally defined or exists as shelfware. Initial benefits realized from leveraged infrastructure. Tooling and integration for automated cloud usage Affected parties have reviewed and accepted the approach. The documented approach is always or nearly always followed. ANALYSIS CAPABILITY GAINS EFFICIENCY GAINS Manual Federation Cloud-aware applications are deployed according to business requirements on public, private, and hybrid platforms. Governance infrastructure is in place that measures and quantitatively manages cloud capability. INCREASES IN VELOCITY AND QUALITY Federated, interoperable, and open cloud Capability incrementally improves based on consistently gathered metrics. Assets are proactively maintained to ensure relevance and correctness. The organization has established the potential to use market mechanisms to leverage inter-cloud operations. PROACTIVE Figure 2: These are descriptions of each level of the cloud maturity model. Summary of CMM Levels Progression through the various maturity levels is based on the analysis of a number of parallel specific capabilities or domains. CMM 1. The existing environment is analyzed and documented for initial cloud potential. For limited systems, pockets of virtualized systems exist. They lack automation tooling and are operated under the traditional IT and procurement processes. Most of the landscape still runs on physical infrastructure. The focus is on the private cloud, although the public cloud is used for niche applications. 10
CMM 2. IT and procurement processes and controls are updated specifically to deal with the cloud. It defines who may order services and service elements and how this is done. The private cloud is fully embraced with physical-to-virtual movement of apps and the emergence of cloud-aware apps. CMM 3. Tooling is introduced and updated to facilitate the ordering, control, and management of cloud services. Risk and governance controls are integrated into this control layer. This ensures adherence to corporate requirements and local regulation. Complementary service management interfaces are operational. More sophisticated use of SaaS is evident, and private PaaS emerges. CMM 4. Online controls exist to manage federated system landscapes, distributed data and data movement, distributed application transactions, and the cross-boundary interactions. Defined partners and integration exist, enabling dynamic movement of systems and data, with supporting tool layer integration (for example, service desk, alerting, commercial systems, and governance). Cloud-aware apps are the norm, and PaaS is pervasive. Hybrid apps develop across cloud delivery models. CMM 5. All service and application deployments are automated, with orchestration systems automatically locating data and applications in the appropriate cloud location and migrating them according to business requirements, transparently (for example, to take advantage of carbon targets, cost opportunities, quality, or functionality). The CMM levels enable the realization of a number of cloud characteristics described in the following list. These in turn translate into the enablement of business functionality and value (benefits). These benefits are the recommended results of positioning domain capabilities within the various CMM levels: functional capability gains, efficiency gains, quality gains, and velocity gains, which ultimately result in powerful business strategy enablement. 11
Concepts for Cloud Integration Federated. Federation refers to the ability of identity and access management software to be able to securely share user identities and permissions. This ability allows users to utilize resources located in multiple clouds without having to generate separate credentials in each cloud individually. IT is able to manage one set of identities, authorizations, and security review processes. From the user perspective, this enables seamless integration with systems and applications. Interoperable. There are two key concepts of interoperability: (a) The ability to connect two systems that are concurrently running in cloud environments, and (b) the ability to easily port a system from one cloud or external system to another. Both involve the use of standard mechanisms for service orchestration and management, enabling elastic operation and flexibility for dynamic business models, while minimizing vendor lock-in. Open Standards. The term open refers to both software and standards. Open source software operates at a fast rate of change supported by diverse, vibrant community updates. These frequent update cycles provide access to the latest features and functional capabilities, including performance and efficiency improvements. The use of common application programming interfaces (APIs) or abstraction layers makes it easier for end users to rapidly consume cloud services from different providers to meet business requirements. Even if the software is not open source, it should adhere to open standards in order to maximize the benefits of cloud deployment. Process for CMM Assessment To effectively assess an enterprise and determine a roadmap of actions and planning, follow a predictable process. The CMM is a framework that includes a series of use cases and questions that can be used to develop an interview agenda. 12
Select stakeholders for their selected domains. This team should be comprised of a multidisciplinary group of individuals led by an executive at a level high enough to arbitrate any disputes that might arise. Stakeholders are likely to come from the ranks of architecture, IT operations, compliance, legal, security, applications, business owners, and others. Conduct interviews with these stakeholders using the questions in the CMM. Use separate interview sheets for each interview and note who was interviewed. Use the answers to the questions to establish maturity levels. Assessment Process Define scope of analysis with Requestor = Define objectives, target CMM level, timeline, scope as mandate Mandate of the CMM Analysis Select appropriate domains from the CMM to analyze based on pre-defined scope Within scope of Requestor Identify specific parties based on identified domains and scope, for interviews Within authority of Requestor Perform CMM analysis based on included domains Identify gaps and closure actions, potential benefits & ROI Directed toward defined objectives and timeline Create report/roadmap closure plan and list domains not addressed with potential impacts of each excluded domain Potential future enhancement and expansion of the journey Figure 3: This is the recommended process for a self-assessment leading to a contracted external assessment, a full self-assessment, or an external assessment. 13
STEP ACTIVITIES RESULT 1. Define project. Define the project, including: Overall scope and objectives Use cases, domains, and cloud service models Target CMM levels Timeline and milestones/quality gates Basic conditions and project risks 2. Identify stakeholders. Identify relevant stakeholders and personnel to interview. Agree to the interview schedule. 3. Perform assessment. Conduct interviews. Review documents. 4. Consolidate results. Consolidate result documentation. Reconcile draft results with stakeholders and interviewees (if required). Project charter Interview schedule Result documentation Assessment results 5. Identify gaps and develop closure actions. 6. Create report, including assessment results and closure actions. Identify potential gaps between assessment results and the targeted CMM level. Develop closure actions. Create report, including: Project charter Assessment results Roadmap closure plan Roadmap closure plan CMM assessment report Table 1: Detail Activities in the Assessment Process 14
Use Cases for CMM Start the assessment by determining the enterprise s objectives. These are often more easily identified in the context of a number of use cases, which can be compared to the enterprise s current planning. Table 2 lists some typical use cases. USE CASE USE CASE DESCRIPTION POTENTIAL APPLICABILITY POTENTIAL ACTORS CMM RANGE TIMELINE (months) 1 Ability to rapidly provision infrastructure and platform services for development and test systems from private, public, or community clouds Dev/Test Iaas/ PaaS, Private Internal/ External Cloud, Public External Cloud, Internal or External Community Cloud Dev/Engineering, DevOps, Test, Integration or Build/ Deploy Teams and Systems 1-2 6, 12 2 Ability to integrate SaaS with back-office systems SaaS Back-Office Integration, SaaS SA (System Administrator), Network Team, Business Team, Finance, PMO, HR, and other back office teams 1-3 6, 12, 18 3 Ability to provide onpremise data residency for SaaS implementations SaaS Data Residency, SaaS (Master and Transaction) Data Management, SA (System Administrator), Network and Security Teams, Governance, Risk and Compliance, Legal/Privacy 2-4 6, 12, 18 4 Ability to deliver and/ or consume data as a service (DaaS), data stores (relational, object, KV, graph, file, etc.) from a private, public, or community cloud for development and test applications Dev/Test Data Stores, Information as a Service, Data as a Service, Platform as a Service SA (System Administrator), DBA (Database Administrator), Dev/ Engineering or DevOps, Test/QA Team 2-4 12, 18 Continued > 15
USE CASE USE CASE DESCRIPTION POTENTIAL APPLICABILITY POTENTIAL ACTORS CMM RANGE TIMELINE (months) 5 Ability to deliver and/ or consume middleware and similar platforms (e.g., JBoss,.net, Apache, Tomcat, Citrix, IIS) from a private, public, or community cloud or via integration as a service or integration platform as a service for development and test applications Dev/Test Middleware, PaaS, SaaS SA (System Administrator), Dev/ Engineering or DevOps, Test/QA, Integration, Build Teams and Systems 2-4 12, 18, 24 6 Ability to begin experimenting with cloud native applications (e.g., running on Openstack or Cloud Foundry) Experimenting with Cloud Native Apps, SaaS, PaaS, IaaS Dev/Engineering, DevOps, Architect 3-5 12, 18, 24 7 Ability to rapidly provision IaaS and PaaS from a private, public, or community cloud for production applications with full operations support and integration with service and operational management systems and processes Production IaaS/ PaaS Dev/Engineering, DevOps, Test/QA, Integration or Build/ Deploy Teams and Systems, OPS, Service Management (config, incident, change, problem) 3-5 6, 12, 18 8 Ability to deliver and/or consume DaaS data stores (relational, object, KV, graph, file, etc.) from a private, public, or community cloud for production applications with full production support and integration with service and operational management systems and processes Production Data Stores, Information as a Service, Data as a Service, Platform as a Service SA (System Administrator), DBA (Database Administrator), Dev/Engineering or DevOps, Test/ QA Team, OPS and Service Management 3-5 12, 18, 24 Continued > 16
USE CASE USE CASE DESCRIPTION POTENTIAL APPLICABILITY POTENTIAL ACTORS CMM RANGE TIMELINE (months) 9 Ability to deliver and/ or consume middleware and similar platforms (e.g., JBoss,.net, Apache, Tomcat, Citrix, IIS) from a private, public, or community cloud or via integration as a service or integration platform as a service for production applications with full operations support and integration with service and operational management systems and processes Production Middleware, SaaS, PaaS, IaaS SA (System Administrator), Dev/ Engineering or DevOps, Test/QA, Integration, Build Teams and Systems, OPS and Service Management 3-5 6, 12, 18, 24 10 Ability to migrate production workloads on demand from a private, public, or community cloud to a separate private, public, or community cloud provider on-demand (SLA, peak load, or financial driven) SaaS, PaaS, IaaS, DaaS, IP-aaS, Information-aaS Business Teams, Ops, Service Management Team, DevOps, DBA (Database Administrator) 4-5 12, 18, 24 11 Ability to develop and deploy production-ready cloud native applications (e.g., running on Openstack and Cloud Foundry) Production Cloud Native Apps, SaaS, PaaS, IaaS Ops, SA (System Administrator), Build, Deploy (Integration) Teams 4-5 12, 18, 24 12 Ability to dynamically manage production workloads utilizing an internal private cloud and two or more public or community cloud providers with a combination of legacy and cloud native applications and associated middleware and infrastructure, providing geographic redundancy while maintaining SLAs for a peak business event Multisite Elastic Computing, SaaS, PaaS, IaaS OPS, SA (System Administrator), Build, Deploy (Integration) Teams, Business Teams, Service Management, DevOps, DBA (Database Administrator), Integration Teams, Build Teams, Service Management Teams (config, incident, change, problem), Architect, Data Management, Network Teams, Finance, HR, and other back office teams, PMO 5 6, 12, 18, 24 Table 2: Use Cases for CMM Analysis 17
Maturity-Level Outcomes To effectively steer the control sets for the various domains, a set of outcomes per domain are defined. These can also be used to help enterprises determine the target state for each domain. Many of the domains have dependency on each other that is, one cannot be at a certain maturity level without the other being at a supporting maturity level, but this is not necessarily so for all cases. Based on the use cases appropriate to the enterprise, it is also possible to down-select to the appropriate domains that should be considered that is, many domains are enumerated in the control sets, but not all of them are appropriate to every use case or enterprise. Example Domains and Associated Outcomes DOMAIN CMM 0 CMM 1 CMM 2 CMM 3 CMM 4 e.g., Finance Expected Outcome at CMM Level 0 Expected Outcome at CMM Level 1 Expected Outcome at CMM Level 2 Expected Outcome at CMM Level 3 Expected Outcome at CMM Level 4 (People, Process & Technology aspects) (People, Process & Technology aspects) (People, Process & Technology aspects) (People, Process & Technology aspects) (People, Process & Technology aspects) Table 3: Further information is available in the detailed analysis material. 18
Based on the applicable use cases, the consultant or auditor may select the applicable domains and capabilities from the following range below. For an effective analysis, select no more than twelve domains. Reviewing too many domains at once could lead to a very long and tedious process and fail to yield the effective roadmap and priority plan result that the CMM intends. Strategy Finance Enterprise Strategy Structure Organization Culture Skills People Capability Business Compliance Process Efficiency Velocity Flexibility Bus Process Technology Quality Governance Procurement Commercial Projects & Services Portfolio Mgt Projects DOMAINS LAYERS BENEFITS Figure 4: Business Domains 19
The Technical Domains are represented below: Enterprise Architecture IT Architecture Applications Management Tools IT Operations (IT) Processes Security People Capability Technology Infrastructure IaaS PaaS STaaS Process Technology Efficiency Velocity Flexibility Quality SaaS IPaaS Information Data Data Lifecycle Mgt DOMAINS LAYERS BENEFITS Figure 5: Technical Domains 20
MATURITY AND QUALITY In context of maturity, it is important to note that maturity is independent of quality. Increased maturity does not necessarily mean increased quality. One can buy a service or product appropriate for business needs that is rated either high or low quality. Having increased maturity allows the user to maximize the advantage and benefits gained from such services. Typically maturity relates to processes, governance, integration levels, defined frameworks and methodologies. These all lead to sustainability, repeatability, and effectiveness. The following table represents those differences as Bronze, Silver, Gold, or Platinum quality levels. These may relate to additional functions and features built into the service or product. Maximizing the Benefits of Maturity CMM 1 CMM 2 CMM 3 CMM 4 CMM 5 Bronze X X X X Silver X X X X X Gold X X X X Platinum X X X Table 4: The Xs identify that there is correlation between quality and maturity. SELF-ASSESSMENT The ODCA developed a detailed questionnaire to assist enterprises in assessing cloud maturity and identifying potential development areas, expecting that these areas will lead to potential investments. The questionnaire is designed to address each of the various domains at the people, process, and technology levels, as well as the potential outcomes and answers per level. It identifies appropriate target states that realize specific benefits for the individual business. This gives the enterprise an accurate assessment of its current state and reveals the development gaps where 21
resources need to be invested. Once targeted, the enterprise can focus people, processes, technology, and possibly cash to resolve these gaps. Figure 6: Example Assessment Leveraging Selected Domains The maturity level is set in the context of business objectives and the resulting benefits sought. The questionnaire supports enterprises performing selfassessments of cloud readiness levels, developing a roadmap of actions to build or improve domain capability, and determining the ability to achieve maximum value from cloud-based services. Assessing selected business units, support units, or just the IT department does not alone reveal the detailed and complete state of the enterprise s cloud maturity. Some complexity lies in analyzing how and why the business units use cloud services. This includes identifying the various departments involved and then assessing those departments using appropriate questions from the questionnaire. CONCLUSION When an enterprise s technology and business strategies align to meet the optimal cloud maturity level, the enterprise should achieve a federated, interoperable, and open cloud environment that delivers expected benefits. This in turn will enable the expected business value that cloud services represent to that enterprise: capability gains, efficiency gains, quality gains, flexibility increases, and velocity gains, which ultimately result in powerful business strategy enablement. 22