Whitepaper Governance as an enabler of the Cloud text Cloud solutions are becoming increasingly common building blocks for IT and business solutions. Yet, without some significant modifications to the governance rules, the full benefits cannot be unlocked.
Whitepaper 1 Introduction There is no denying that Cloud capabilities are increasingly becoming an essential component of businesses worldwide, and that their impact goes well beyond core IT functions. Consequently, the relationship between IT and business units, and most of the components of the governance framework are impacted. Notably, with heightened Cloud adoption, services become multi-sourced across a wider pool of providers requiring enhanced training,, and monitoring. Those modifications are too often ignored, resulting in benefits that fail to reach the levels expected by the business stakeholders and stated in the business plans. While Cloud can often provide significant benefits, moving to the Cloud implies shifting from a project to a product owner organisation. Consequently, the IT governance must be revised and updated. The impact of Cloud on governance When shifting services to the Cloud, organisations need to reassess not only IT governance, but governance at large, to realise the full benefits of the Cloud. Following a six-component framework helps IT organisations upgrade the governance structure. Organisations will have to reconsider: Roles and responsibilities on the supply, as well as on the demand side Capabilities and motivators to best enable Cloud Operations Vendor and partner Risk assessment Financial processes and systems. Figure 1 Cloud Governance Framework Financial Organisation (roles and responsibilities) People, skills performance Organisation Decision rights in the context of Cloud 1 (roles and responsibilities Organisation New roles and responsibilities (roles and responsibilities) People, skills, 2 performance People, skills performance Operations 3 Operations Required capabilities to enable Cloud in the organisation Right set of motivators to materialise potential Cloud delivery process, incl. who does what and how Cloud usage metrics and SLA Cloud provisioning process Risk Cloud governance Vendor/partner Operations 4 Vendor/partner 4 5 Risk Risk 5 6 Financial Financial 6 Selection and contracting with a Cloud vendor Operational agreements provisioning, SLA, usage metrics, etc. Cloud vendor risk Cloud rollout and adoption risks Compliance with regulatory and risk requirements Internal Cloud charge out/show-back mechanism Setting up service catalog and usage guidelines
2 Whitepaper 1. Organisation roles and responsibilities: transitioning from project manager to product owner Cloud adoption will accelerate the shift from a traditional supply side to a demand-driven organisation. Consequently, the product owner will become a mandatory role, while the project manager will see its focus change. While the demand side will have to reassess some of its core process, the supply side of the organisation will need to undergo a more significant change process. On the supply side, organisations will have to reconsider the role of its IT supply organisation given that a significant portion of the IT stack resources may be transitioned to the Cloud provider, and the focus moves from delivering projects and new systems to assessing the viability of Cloud providers and making sure services are delivered as expected in terms of both quality and cost. Key services traditionally provided in-house, such as development, maintenance and customer service will shift to the Cloud provider. Several new roles will need to be filled, among them a Cloud service architect, a Cloud service manager, a Cloud portfolio manager, and a Cloud orchestration manager. Roles that will have to change in the Cloud context are the IT capacity manager whose responsibility will encompass Cloud services, while modelling will not only be limited to in-house infrastructure, but also to Cloud infrastructure. Changes are not solely restricted to the supply side; the demand side of the organisation will also have to reconsider its role in the Cloud context. Changes to the demand process are highlighted in Figure 2. Figure 2 IT demand, portfolio and program framework overview BUs and corporate functions IT demand, portfolio and program framework overview Client s business Need BU1 BU2 Finance BU3 Need Need 1 2 3 4 Identify Assess Execute requirements feasibility program Capture value HR Etc. Need IT value-delivering services Cloud impact Do the right things......and do things right. The first step is to identify requirements: The organisation will have to perform an initial high-level assessment of the requests to prioritise the requested portfolio. To perform this initial high-level assessment, the IT demand organisation must be familiar with the available Cloud solutions for each of the required services. This high-level assessment must be carried out in terms of associated cost, potential time lines and technical solution options before moving to the next step. The second step is to assess feasibility: The IT demand organisation will have to define and study potential solutions including Cloud solutions, outline preferred solutions including an assessment of the existing IT landscape, and detail a business case including total cost of ownership. Finally, execution will be limited to the integration of the new service and training users. The demand side will have to cope directly with an increasing number of vendors and forego bespoke customisation in return for lower cost and more agility to service provisioning.
Whitepaper 3 2. People, skills and performance: moving from technical KPIs to E2E business KPIs while building product owner capabilities When moving services to Cloud the IT organisation must evaluate its capability gap and redefine its motivators not only on the IT side, but also on the business side. In the traditional IT organisation, the KPIs are geared towards project delivery and supply. Most certainly, the KPI pyramid of traditional IT organisations focuses on the more technical side including dozens of disjointed KPIs, such as application bug resolution (e.g. mean time to close tickets), infrastructure (e.g. central systems availability) and desktop (e.g. time to solve problems on desktops). In their transition to the Cloud, enterprises will have to shift KPIs to a more business-oriented end-to-end process covering quality, cost and time. KPIs will be mainly geared towards assessing the performance of Cloud vendors. The KPI pyramid might include, among other things, quality (e.g. SLA response rate), cost (e.g. workload predictable costs, Capex vs. Opex costs, workload vs. utilisation rate) and time (e.g. indicator of the workload efficiency). Once the new KPIs have been defined, the motivators, (i.e. performance assessment and bonus awards), have to be aligned with the new KPI structure. Motivators will also have to be revised on the business side. For example, the bonus for a Business Unit head may now include the IT operational expenses, since this cost is directly managed by the business. If KPIs and motivators are not revised and aligned, enterprises will encounter resistance from within the organisation to implement Cloud solutions and the Cloud will not deliver to its full potential. In terms of capabilities, business capabilities such as understanding the business vision and strategy, and capability to match business needs to Cloud solutions will gain in importance to the detriment of more technical expertise such as project and development. CIOs will be required to act as aggregators and master the ability to match business needs to Cloud technologies. The key responsibilities of a CIO will be focused mostly on understanding business needs, available technologies, and matching needs to the most suitable solution. Less importance will be placed on their ability to deliver bespoke project, manage internal IT operations and possess a deep technical expertise. While in the traditional IT organisation, the application manager had deep technical expertise regarding storage, support and maintenance. In a Cloud context the application manager will have to have a better understanding of the business side and how current technologies can address these needs. Capabilities required from an application manager in the Cloud are geared towards cross-functional collaboration, business vision, understanding of the overall Cloud strategy, etc. It is thus crucial to redefine KPIs to enable Cloud adoption and reconsider motivators in both IT and business organisations to make sure the benefits of the Cloud will be properly unlocked.
4 Whitepaper 3. Operations : as resources from the IT stack shift to the Cloud provider, operation has to reassess its role and decision-making power The more Cloud services are deployed, the more the focus of the operation department shifts from operating the on-premise hardware and software stacks that deliver a service to the end-users, to monitoring the outcome of the 'Cloudified' services. As services transition to the Cloud, whole stacks of IT resources will shift to the Cloud provider. Since those resources become available with fewer operations and less maintenance work, enterprises have the opportunity to focus more on innovation and key value-add differentiators. The impact on the operation organisation will depend on the mix between IaaS, PaaS and SaaS. In the case of SaaS, all the resources shift to the Cloud provider from networking, storage and services to the application itself. In the case of IaaS, only virtualisation, services, storage and networking move to the Cloud provider while middleware, applications, data etc. stay under the responsibility of the enterprise. As a consequence, the decision matrix must be re-evaluated: the responsibility for building and running the software shifts to the Cloud vendor. Enterprises will have little room left for customising Cloud services. However, the responsibility for testing, SLA and business continuity remain with the supply organisation. Overall, the operation organisation must monitor the Cloud vendor to make sure it delivers the expected quality, on time and cost.
Whitepaper 5 4. Vendor/partner : the key is f to first understand which services are eligible for the Cloud and assess capability of vendor to deliver Shifting a service to the Cloud provides unique opportunities to offer additional business benefits to the end-users, but it also presents new risks that must be assessed and mitigated. For instance, when a Cloud vendor goes bankrupt, the corresponding services cease to be delivered immediately. If a traditional software vendor went bankrupt, the application itself would continue to run and deliver its services; it might be difficult maintaining it, but plans can be drawn to mitigate that risk. Hence, when transitioning to the Cloud, it is critical to re-evaluate the vendor selection/ vendor process. Focus should be first to understand which processes are eligible for the Cloud (see the white paper dedicated to this topic), then understand the vendor landscape for each service, assess interoperability and finally assess the vendor s capability to deliver. Vendor due diligence in the Cloud market still remains a major challenge: though the market has matured a lot in the last couple of years, and has seen the emergence of truly gigantic players, a lot of vendors are still young and their ability to survive can be questioned. Moreover, the Cloud space is growing rapidly, and new vendors are emerging on a regular basis. Consequently, input as to the capability to deliver will come from other customer's feedback, previously signed contracts and specialised analysts opinions. Once a service has been vouched for the Cloud, it is crucial to understand the specifics of the vendor solution in terms of: Data (portability, reversibility, privacy, etc.) Interfaces and standards Ease of migration/deployment Interoperability with the rest of the IT. Figure 3 Vendor/partner process Strategy Market intelligence Contracting strategy LT procurement outlook Identification of major contracts Process risk analysis Tender strategy Technical feasibility Tender evaluation Tender preparation Tender Business benefits and costs Prequalification of new vendor Award contract Vendor risk Monitor Monitor vendor performance Corrective actions Changes to existing process
6 Whitepaper 5. Risk : risk assessment matrices must be revisited to correctly take into account the adjusted level of benefit for each service transitioned to the Cloud Traditionally, the risk assessment frameworks have focused on inward-looking elements (network outage, loss of data stored in own data centres, data centre physical security, etc.). When transitioning to the Cloud, risks must be assessed with an outward-looking perspective (understanding the vendor risk in terms of: capability to deliver services as promised, ability to remain solvent for the duration of the contract, ability to manage data securely, etc.). Our risk-assessment framework focuses on the types and origins of the risks. Each service is assessed against that matrix. (See Figure 4 Canopy's risk assessment framework). The matrix can help to identify the risk profile of a specific Cloud solution and compare it against the risk appetite profile of a specific process. An enterprise needs to score the risk per functional domain (and possibly even per Cloud vendor as different vendors may carry different risks). Risk-adjusted benefits for shifting a workload to the Cloud need to be understood and quantified (see the whitepaper dedicated to risk in the Cloud era). Figure 4 Canopy s risk assessment framework Any Cloud-related risk originates from one of five sources: User risks: if a user device is lost, stolen or discarded, its data may still be accessible Enterprise risks: related to enterprise infrastructure failure or unauthorised access to sensitive data Network provider risks: it may be a challenge to control the quality of service across different regions, which can compromise the 'availability' component of the matrix; Man in the Middle (MitM) attacks on wifi connections Cloud provider risks: provider cannot help prevent low frequency, high impact events; continued existence of the provider itself Environmental risks: political risks and risks caused by natural disasters Any Cloud-related risk originates from one of three categories: Availability: risks that may jeopardise service availability Integrity and confidentiality: risks that may jeopardise data integrity and confidentiality Compliance and auditing: risks that may jeopardise compliance to in-house and external policies, rules and regulations and auditability Source of risk User Enterprise Network provider Cloud provider Environment (natural/political) Availability Type of risk Integrity and confidentiality Compliance and auditing
Whitepaper 7 6. Financial : chargeback Cloud services based on utilisation motivators need to change to increase adoption Changing from a traditional IT to a Cloud-based one has two major financial consequences as the IT expenditures move from an investment model to a usage-based model, the cash flow is significantly modified and since services will be sourced from a multiplicity of vendors, showback and chargeback mechanisms must be put in place to make sure the right users will get charged for the services they ve used. The IT budget has traditionally been under the complete control of the IT organisation. While shifting workloads to the Cloud, financial mechanisms must be reviewed to include at least cost showback, and, ideally, cost chargeback. This means that IT needs to define services; price services; and change its systems to chargeback based on usage (See figure 5 Financial systems design phase). Organisations also need to implement tools and systems which will give business units the ability to steer usage as needed. Figure 5 Financial systems design phase Define service catalogue Engage with stakeholders Determine the level of granularity Enforce standardisation Define the services Develop customer focus and continually improve Main reason why service catalogues fail: inaccuracy of data, poor acceptance and adaptation, lack of tools and resources, lack of integration Determine pricing Build inventory of Cloud-related costs Define cost attribution model to calculate per-unit service costs Establish cost baseline and a pricing strategy (cost, cost + margin, market-based, etc.) Define user profiles Create user profiles based on formal roles and levels as well as current interaction patters Attach services and access levels to the roles Create service and billing systems Establish a self-service portal where BUs can request services Showback billing: provides tenants with reports on their IT consumption without charging Chargeback billing: tenants receive a formal invoice on their consumption It must educate BUs on their invoices and how to optimise usage Adjust related processes Modify accounting practices to enable IT ownership of CAPEX Review budget cycles and establish governance Mature demand forecasting and capacity planning processes Adapt performance practices and update KPIs As an initial step and depending on the Cloud maturity, enterprises need to enhance their show-back systems to increase visibility on services being provided as a step towards charge-back. CIOs and heads of business units are usually reluctant to move from Capex to Opex mainly because their bonuses are tied to Opex levels in the case of CIOs and manageable P&L in the case of heads of BUs. Moreover, moving to Cloud financial model means the cashflow of the company changes since there is no large upfront investment (whose depreciation can be used as a lever to reduce benefits), and since payment is realised based on usage. Consequently, in order to secure adoption of Cloud the KPIs need to be changed and executives must have their bonuses tied to the new KPIs. This will drive the desired behavioural changes.
8 Whitepaper Conclusion As more services are shifted to the Cloud, the IT organisation changes its focus from designing the inputs to monitoring the outcomes of the services delivered to the end-users. This means that most roles and governance processes must be reassessed: Financial and risk become increasingly important New, business-focused skill sets must be developed A product owner mindset must be nurtured The vendor selection process must be completely redesigned. Consequently, governance is one of the most important factors to unlock the full Cloud benefits (IT cost linked to usage, IT provided on demand, IT scalable to user needs, leading to organisational transparency, agility and efficiency). Additionally, the KPIs must be modified to make sure the organisation is aligned to the Cloud objectives. The groundwork for such effective change is laid by defining the change, creating a shared need and developing a shared vision. Our approach is focused on engaging and mobilising stakeholders, creating accountability, aligning systems and structures, and sustaining the change.
About Canopy Cloud Canopy www.canopy-cloud.com is a one-stop-cloudshop for enterprises. It provides strategic consultancy; development, migration and test environments; secure on- and off-premise private Cloud implementation; and access to a growing eco-system of business solutions and processes through a SaaS Enterprise Application Store. Canopy is an independent company, founded by Atos, EMC and VMware. Headquartered in London, Canopy is global in scope, with consultancy teams operating across Europe, North America and Asia Pacific. Canopy Consulting is a trusted Cloud computing advisor to leading private and public sector organisations around the world. Staffed almost exclusively with professionals trained at tier one strategic advisory firms, we focus on helping senior executives achieve business objectives by leveraging Cloud technologies. About the Authors Loïc Lavoué is a Partner at Canopy Cloud Consulting. Prior to joining Canopy, Loïc has worked for consultancy firms, and system integrators. He has designed numerous transformation roadmap, and has successfully managed very large transformation programs. He holds an MBA from Sorbone Graduate Business School, and an MSc from Chimie ParisTech. loic.lavoue@canopy-cloud.com +33 6 50 02 04 01 Philipp Sielfeld is an Engagement Manager at Canopy Cloud - Consulting and an expert in the field of strategy development. Prior to joining Canopy, Philipp worked at Booz & Company where he supported clients on strategy development, change and cost transformation programs. Philipp holds a MBA from Columbia Business School. philipp.sielfeld@canopy-cloud.com +49 171 7602881 Ahmed Mitwalli is the Managing Partner at Canopy Cloud - Consulting. Prior to Canopy, he was with McKinsey & Company for 12 years where he was a Partner and a leader in the Business Technology Office. He has a PhD in Electrical Engineering and Computer Science from MIT, and is a holder of five US technology patents. ahmed.mitwalli@canopy-cloud.com +1 917 982 5435 Canopy Contributors Reinout Schotman Jeremy Brann Yevgen Bolyukh Contact: www.canopy-cloud.com Mail: Canopy Ltd 4 Triton Square, Regents Place London NW1 3HG info@canopy-cloud.com +44 (0)20 8555 1637