Celil çiynekli

ITSM Cloud Transformation AWS Special ITIL Based CONTENTS • • • • • Definitions Cloud Operating Model (COM) AWS Cloud Adoption Framework (CAF) Modernizing Operations in the AWS Cloud Change, Config, Release and Deployment Management • Last Notes • Industry: Pharmaceutical • Subject: Journey from on-prem data centers to AWS cloud. DEFINITIONS • Scope: Business Applications, Databases, other Infrastructure Services and IT Service Processes. • Target/Objective: Make all discoverable AWS cloud CIs operational with ServiceNow and ITSM Processes on March.2022 • ITSM Tool: ServiceNow • What is Cloud Operating Model • Product Based Approach • 6 Transformational Steps • AWS Operations Domains Cloud Operating Model (COM) What is Cloud Operating Model (COM) The Cloud Strategy aligns business outcomes with technical outcomes and defines a high-level framework for governance and management of resources in a multi-cloud world. Where the Cloud Strategy defined the “what” and “why” of cloud service adoption, the Cloud Operating Model defines the “how” and “who” for the ongoing governance, management and operationalization of cloud services. Similar concepts can be described in any other resources as “Cloud Adoption Framework” (like AWS), “Cloud Operating Architecture”, “Service-Oriented Model” or any other number of combinations. A successful cloud operating model (COM) enables organizations to operate applications reliably and securely in the cloud. A key component of leading COM approaches is the adoption of a Product based approach of the cloud platform. By adopting a product mindset, each team can take the responsibility and accountability for increased awareness, ownership and operational excellence. Product definition is important as it's the interrelationship between products, the customers that use the products (consumers), and the teams that create the products (suppliers). A product in this context is defined by: Product Based Approach 1. Performing a constrained number of common tasks very well, 2. Having clearly defined inputs and outputs, 3. Being useful to multiple customers, and 4. Continuously improved to meet the needs of those customers. Each Product Team fully functional from business to operations, they are wholly accountable for all aspects of their services. Properly functioning product mindset are four key foundational concepts: • Appropriately defined products are fully and completely owned from requirements to production support by a single team. • Culture of accountability, empowerment, and self-reliance for each product team. • A clear structure of what is minimally required for a journey to production and who is influential/responsible in each step along the way. • The product definition, metrics, and dependencies 6 Transformational Steps Six steps that companies should follow to build out a successful Cloud Operating Model. (AWS called that as Cloud Center of Excellence (CCoE) or Cloud Enablement Engine (CEE)): 1. Work backwards from the customer 2. Re-envision the world as products 3. Organize teams around products 4. Bring the work to the team 5. Reduce risk through iteration 6. Own your entire lifecycle The AWS Operations Domains shown below represents a framework, based on best practices, that will enable IT (and business) organizations to transform their current ITIL (and other) based Operating Model towards a cloud-based architecture adapted model. AWS Operations Domains The domain model currently focuses on different aspects and highlights where they align into the CEE responsibilities. (Please check "Cloud Operating Model 6 Transformational Steps" section for CEE) It is important to note that these domains continue to evolve through continuous improvement and should be considered as the 80/20 rule in covering most operational processes that a majority of company will need. There may be additional operational processes unique to a company’s organization or specialized industry that need to be taken into consideration. ITIL and AWS Operations Domains are compatible. ITIL, like all frameworks it is not perfect and has its set of criticisms. When hard-linked into systems (monitoring, ticketing, support services, etc.), ITIL processes can be complex to transform. The purpose of the domain model is to help the CEE own and establish its operating model roadmap. AWS Operations Domains and MVP (Minimum Viable Product) cycles as shown next slaty. • What is AWS CAF • Transformation Domains • Foundational Capabilities • Six Perspectives • Cloud Transformation Journey AWS Cloud Adoption Framework (CAF) What is AWS CAF AWS CAF is an important supplement to enterprise ITSM frameworks used today because it provides enterprises with practical operational advice for implementing and operating ITSM in a cloudbased IT infrastructure. ITIL and AWS Cloud Adoption Framework (AWS CAF) are compatible. Like ITIL, AWS CAF organizes and describes all of the activities and processes involved in planning, creating, managing, and supporting modern IT services. It offers practical guidance and comprehensive guidelines for establishing, developing, and running cloud-based IT capabilities. The AWS CAF organizes guidance into six areas of focus, called "perspectives", and each perspectives has many "foundational capabilities". Transformation Domains The cloud transformation value chain in the following figure shows that business outcomes are accelerated through cloud powered organizational change (transformation) that is enabled by a set of foundational capabilities. The Transformation Domains represent a value chain where technological transformation enables process transformation which enables organizational transformation that enables product transformation. Key business outcomes include reduced business risk, improved environmental, social and governance (ESG) performance, as well as increased revenue and operational efficiency. • Technological transformation focuses on using cloud to migrate and modernize legacy infrastructure, applications, and data and analytics platforms. • Process transformation focuses on digitizing, automating, and optimizing your business operations. • Organizational transformation focuses on reimagining your operating model; how your business and technology teams orchestrate their efforts to create customer value and meet your strategic intent. • Product transformation focuses on reimagining your business model by creating new value propositions (products, services) and revenue models. Foundational Capabilities Each of the transformation domains described in the preceding section is enabled by a set of Foundational Capabilities shown in the following figure. A capability is an organizational ability to leverage processes to deploy resources to achieve a particular outcome. This capabilities provide best practice guidance that helps you improve your cloud readiness (your ability to effectively leverage cloud to digitally transform). AWS CAF groups its capabilities in Six Perspectives: Business, People, Governance, Platform, Security, and Operations. Six Perspectives You may not need to tackle all the foundational capabilities at once. Evolve the foundational capabilities and improve your cloud readiness as you progress through your cloud transformation journey. Consider tailoring the suggested sequence shown in the following figure to your particular needs. You can find details about each Capabilities from below AWS CAF links: ➢ Business Perspective ➢ People Perspective ➢ Governance Perspective ➢ Platform Perspective ➢ Security Perspective ➢ Operations Perspective Cloud Transformation Journey To succeed in your transformation, you’ll need to envision your desired target state, understand your cloud readiness, and adopt an agile approach to closing the gaps. Transforming incrementally will allow you to demonstrate value quickly while minimizing the need to make farreaching predictions. Adopting an iterative approach will help you maintain momentum and evolve your roadmap as you learn from experience. • Envision phase focuses on demonstrating how cloud will help accelerate your business outcomes. It does so by identifying and prioritizing transformation opportunities across each of the four transformation domains in line with your strategic business objectives. Associating your transformation initiatives with key stakeholders and measurable business outcomes will help you demonstrate value as you progress through your transformation journey. • Align phase focuses on identifying capability gaps across the six AWS CAF perspectives, identifying crossorganizational dependencies, and surfacing stakeholder concerns and challenges. Doing so will help you create strategies for improving your cloud readiness, ensure stakeholder alignment, and facilitate relevant organizational change management activities. • Launch phase focuses on delivering pilot initiatives in production and on demonstrating incremental business value. Pilots should be highly impactful and if/when successful they will help influence future direction. Learning from pilots will help you adjust your approach before scaling to full production. • Scale phase focuses on expanding production pilots and business value to desired scale and ensuring that the business benefits associated with your cloud investments are realized and sustained. Identify and prioritize transformation opportunities in line with your strategic objectives. Deliver pilots in production and demonstrate incremental business value. Align Envision Scale Launch Identify capability gaps and cross-organizational dependencies. Expand pilots and business value to desired scale and ensure that the business benefits associated with your cloud investments are realized and sustained. • Operations Integration Domains • Best Practices o Readiness o Automation o Integration Modernizing Operations in the AWS Cloud The process of modernizing operations in the cloud involves Readiness, Automation, and Integration. In a migration project, these activities are commonly referred to as Operations Integration (OI). The following diagram shows the 15 OI domains organized in 4 functions. Business outcomes can be categorized as follows: • Operations Readiness: Understand how you currently perform IT operations and how you will operate in AWS. One way to achieve this business outcome is to define a cloud operating model (Please check "Cloud Operating Model" section) . Operations Integration Domains • Operations Automation: Invest in automation to deliver an AWS operating model. • Operations Integration: Continue using current IT tools and extend them through integration to AWS. Best Practices Related to Readiness, Automation and Integration Workshops are an effective way to understand your current operating model and to define an AWS operating model. The following diagram shows suggested operating models. Below three models do not imply levels of maturity. You can select one of the "Optimize" and "Grow". "Sustain" is your current model. Best Practices Related to Readiness, Automation an d Integration • Sustain: This model takes on a Traditional Operations approach. This activity-based model we can see in most organizations where engineering, operations, infrastructure and application teams and boundaries exist. • Optimize: In this model Application Engineering is now also responsible for Application Operations. Think of this as DevOps for the application team, where they own the full outcome of delivering and operating their application. • Grow: In this model application engineering is responsible for their applications, but in order to avoid stifling innovation for high-growth areas of the company, they are empowered to build out platform capabilities. This model for teams that are using AWS tools for automate nearly all changes and other operations. (please check "Balance Between Budget & Service Quality" section) Best Practices Related to Readiness, Automation and Integration You can use a number of AWS services to automate your IT operations. The following table lists the 15 OI domains and provides information to help you select the right service for each operational need. Area Cycle 1 focus and tools Platform architecture and governance Governance, guardrails, enterprise architecture and platform design for AWS, tagging, AWS Systems Manager. Usually covered by deploying the AWS Landing Zone solution, AWS Control Tower, or AWS Managed Services. Event and incident management Logging and monitoring, service restoration, Amazon CloudWatch, Amazon Simple Notification Service (Amazon SNS). Provisioning and configuration management Template consumption, infrastructure as code, AWS Service Catalog, AWS CloudFormation. Availability and continuity management Reliability, serviceability, resiliency, Availability Zone failover, volume backup, SLAs for cloud. IT change management Compliance and controls, risk management, AWS Service Catalog, AWS Config, AWS CloudTrail. Resource inventory management Transparency, resource lifecycle, AWS Config. Identity and access management Least privilege, AWS Identity and Access Management (IAM), federation, usually implemented through the security workstream. Security management Security controls, security incident response, specified by the security workstream. For example, see the automated patch management guide on the AWS Prescriptive Guidance website. Financial management Tagging, billing report, cost optimization (right-sizing, governance), AWS Trusted Advisor. Capacity planning and forecasting Fit for purpose designs, resource trends, AWS Config, AWS Trusted Advisor, budget. Organizational change management Training, communications, transformational buy-in. Best Practices Related to Readiness, Automation and Integration You are not expected to have all of your IT operations fully automated on day 1. Take a phased approach instead. For example start by carefully prioritizing the core operations functions shown in the following diagram. For other functions you can populate Capabilities and Considerations Best Practices Related to Readiness, Automation and Integration The following table shows the common integration patterns between ITSM tools and AWS. • Using Cloud Tools & Impact on Processes and Resources • Change Management with AWS • Configuration Items in the Cloud • Deployment Practices • Fast, Accurate & Reliable Changes • Small & Fast Changes Change Management Configuration Management Release Management Deployment Management Using Cloud Tools & Impact on Processes and Resources By using some AWS Services; deployment of new services, software, patches, and configuration changes can almost all be automated, and they should still be governed by a change process. Because of that when redesigning ITSM processes, it is important that what technology you are using. Actually cloud adaptation updates of ITSM model come from cloud specific ready to use technologies and cloud shared service architecture. Here are some (but not all) automation and risk reduction opportunities by using AWS tools. Every decision at this point must be include your ITIL based Cloud Operation Model. Please not that it is not an AWS Cloud tools advertising. I'm trying to explain impact of using cloud tools (capabilities) on both ITSM processes and resources. Change Management with AWS It's key to remember that all changes should be delivering business value and that change management should be focused on optimizing business risk. The benefits of automation can dramatically reduce the business risk associated with change and increase business agility, ultimately delivering more business value. Agile methodologies and the automation capabilities of the AWS Cloud go hand in hand with change management as they are also designed to deliver business value quickly and efficiently. There are some key areas that may require existing change processes to be modified to adapt to new methods of delivering change. "AWS Systems Manager Change Manager" is an enterprise change management framework for requesting, approving, implementing, and reporting on operational changes to your application configuration and infrastructure. *It is not an AWS Cloud tools advertising. I'm trying to explain impact of using cloud tools (capabilities) on both processes and resources Configuration Items in the Cloud You can use "Auto Scaling groups" to detect failures automatically then using predefined health checks, and servers can be automatically replaced with exactly the same configuration. Auto Scaling groups can also be used to automatically provision additional resources to meet business demand. Thence you don't need to open Emergency Change or Normal Change with long steps (for provision) in AWS cloud and not need extra engineer resource for these tasks. In addition to that these tasks completed very quick so, you reduce business risk dramatically. When approval is required to make a change to a configuration item, existing change management processes may forbid these automated scenarios. This scenario is where it may help to redefine what items are considered to be configuration items. The Auto Scaling group and the image that is used to create the servers should be considered as the configuration items because they are the items that may put the business at risk if they are configured incorrectly. With "AWS Config", you can track the relationships among resources and review resource dependencies prior to making changes. Once a change occurs, you can quickly review the history of the resource's configuration and determine what the resource’s configuration looked like at any point in the past. AWS Config provides you with information to assess how a change to a resource configuration would affect other resources *It is not an AWS Cloud tools advertising. I'm trying to explain impact of using cloud tools (capabilities) on both processes and resources Deployment Practices Another key consideration is understanding the business risk when deployingin the AWS Cloud. Regardless of whether or not a deployment is an application, a patch, or a configuration change, an optimized cloud configuration can automate the deployment process through an unchanged pipeline. This ensures repeatability and consistency across multiple environments, as well as enabling automation of software testing, compliance testing, security testing, and functional testing. "AWS CodePipeline" automates your software release process, enabling you to rapidly release new features to your users. With CodePipeline, you can quickly iterate on feedback and get new features to your users faster. Automating your build, test, and release process EC2 Image Builder significantly reduces the effort of keeping images up-to-date. There are no manual steps needed for updating an image, nor do you have to build your own automation pipeline. EC2 Image Builder significantly reduces the risk of non-compliant images being used. Use deployment patterns that reduce risk, such as blue-green or canary deployments. Ensure that there is comprehensive testing in pipelines, including load, performance under load, and resiliency testing. Effective monitoring on the key performance indicators (KPIs) is a requirement, and automated rollback should be triggered if those KPIs indicate that thresholds are likely to be exceeded. *It is not an AWS Cloud tools advertising. I'm trying to explain impact of using cloud tools (capabilities) on both processes and resources There are two areas in which Change Management process may need to be adapted: Fast, Accurate & Reliable Cloud Based Change Management 1. Because the risk and impact to the business of a failed change is greatly reduced, changes can be made more frequently and with more confidence in the rollback plan. 2. As a result, the second area for consideration is the acceptance of rolling back changes. If failed changes have a much lower impact due to the speed and consistency of roll back, activating roll backs should be considered to be part of the normal process. If automation, pipelines, and deployment methods are in place, it may be possible to reconsider the approach to Standard Changes. By understanding the risk-reduction strategies that are enabled by the AWS Cloud, it should be possible to widen the scope of a Standard Change to include deployments that would have previously been considered as Normal Changes due to the risks associated with them in your on-prem IT environments. Regular scheduled and unscheduled changes should flow through an unchanged pipeline that ensures all of your best practices are met before implementing a change in production. Different policies and procedures should exist for emergency changes, or changes that require manual processes during deployment. Small & Fast Changes Make Your Company Much More Agile As changes become more frequent due to increased automation, there is a risk that Change Management becomes overburdened. Make frequent, small, reversible changes. Make changes in small increments that can be reversed if they fail. In an environment of small, frequent changes, standard changes should become the new normal so proper scrutiny can be given to normal changes. A reduction in the size of a change reduces the risk of disruption. Smaller changes also mean that change can happen more frequently. By changing more frequently, the organizations capability of changing is improved. • DevOps and Agile • Change Required in Operational Team • Change Required in Processes • Other ITIL Processes in Cloud Last Notes DevOps and Agile Agile is a software development methodology that embraces the change inherent to project requirements over time. What is certain is that the adoption of Agile for software development requires an IT organization to be able to respond more quickly to resource requests, which McKinsey call “Agile Infrastructure”. The recommendations that McKinsey suggest for agile infrastructure is very much aligned with the Cloud Operating Model concepts described in this post. DevOps defines a culture where development and operational teams are embedded to own all aspects of a service or application lifecycle, to deliver software faster and more reliably. “DevOps”, “Agile” and other processes can be considered components of the Cloud Operating Model. There is enough overlap in organizational structure and processes that they do not conflict. My recommendation is to adopt the pieces of each that make the most sense for your organization. Change Required in Operational Team A good first step is the creation of a crossfunctional team with experts from the critical IT areas represented. Often this matures into a “Cloud Center of Excellence” that is responsible for setting standards, overseeing governance and making decisions about the onboarding or creation of new services. As the organization matures further this team will either be superseded or augmented by service delivery teams that are dedicated to – and organized around – the services delivered by the Cloud Service Model. The example shown here is not a reporting structure, rather a hierarchy of governance, best practices, and shared services. Operational Maturity You are no longer delivering infrastructure components; you are delivering solutions consumed as cloud services and supporting them requires that the operational teams are organized around the services. This may be one big reorganization effort or a phased approach. Change Required in Processes The Cloud Operating Model requires a complete review of existing operational standards, policies, and processes to determine which can be ported from the legacy way of operating, and those that should be updated or retired. There may be a requirement to create new processes and rewrite policies. Common operating processes need to be reviewed, streamlined or replaced to provide an efficient, consistent experience across public and private cloud environments. Examples are listed below (this is not an exhaustive list) • Data classification and data protection • Compliance and security requirements and processes • Workload placement policy and process • Access control • Service/resource lifecycle management • Financial model – chargeback or funding of shared, short-term resources, budgeting, reporting • Integration process with backend systems and shared system requirements • Governance processes and policy enforcement processes • Responsibility and Accountability • Monitoring, SLAs, reporting, alerting, logging, incident response, service monitoring • Resource rightsizing, dynamic scaling • License management Other ITIL Processes in Cloud ITSM Processes Capability Incident management Monitor and remediate cloud service issues automatically, with programmatic actions to minimize disruption. Provisioning management Drive new infrastructure deployment stacks from your existing IT service catalog. Patch management Cloud-aware OS patching that schedules, applies, and tracks patching on cloud services. Access management Integrate and manage user directories and AWS Identity and Access Management (IAM). Security management Extension of existing cloud configuration checks with the addition of the Trend Micro product to check for malware and other incidents. Continuity management Backup and recovery of cloud services and cloud stacks (complete environments). https://docs.aws.amazon.com/prescriptive-guidance/latest/migrationoperations-integration/welcome.html https://docs.aws.amazon.com/whitepapers/latest/building-cloud-operatingmodel/building-cloud-operating-model.html https://docs.aws.amazon.com/whitepapers/latest/change-management-in-thecloud/change-management-in-the-cloud.html RESOURCES https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloudadoption-framework/welcome.html https://www.axelos.com/resource-hub/white-paper/itil-4-and-the-cloud https://www.axelos.com/resource-hub/white-paper/best-practice-in-the-cloud https://www.axelos.com/certifications/itil-service-management/extensionmodules/itil-specialist-acquiring-and-managing-cloud-services https://citeseerx.ist.psu.edu/viewdoc/download?doi=-&rep=rep 1&type=pdf