Point ofview devops
Download as PPTX, PDF2 likes78 views
The document outlines a point-of-view on facilitating customers' digital transformation using AWS DevOps during the sales enablement phase, focusing on essential components such as culture, processes, risks, and commercial models. It emphasizes a risk-averse, incremental approach to DevOps implementation, particularly for large enterprises, and includes guidelines for proof of concept (PoC) and stakeholder responsibilities. The document aims to establish a conversation framework to help navigate customer engagements in a competitive landscape.
Point ofview devops
- 1. POV : DevOps Solution WHAT TO ASK AND DELIVER DURING SALES ENABLEMENT PHASE
- 2. Agenda • Introduction • Culture, Process and Aspirations • Key Questions • Commercial Model & Roadmap • POC • Stakeholders • Risk assessment and creating solution boundaries
- 3. Introduction This document is not attempting to write a white paper on AWS DevOps . Its a point-of-view on how to make in-road to customers digital transformation. The current document focuses only on the automated development ,integration and deployment aspects. Global customers chooses nice technical consulting companies to create digital transformation journey-while Indian companies or the offshore centers of the global tech companies get to do only the implementation or testing. However, due to economic pressure many customers business head is opening up to see “value” propositions through the regular outsourcing contract. That’s when free consulting for digital transformation has become one tool to edge over the competitive vendors. The internet if full with information on how to work on AWS DevOps services but no document can be found on how to start the conversation in the sales enablement phase. Here I am documenting some of my exposure with several customer engagements . Generally customers business leads do not like to hear very aggressive solution propositions coming from large Indian companies or offshore centers. That's why the solution has to be very risk averse, short term goal oriented and tangible methods of measuring the gains.
- 4. Where to start? To start from the place customers already reached S H M Complexity Level No DevOps Some CD/CI, Open for automation New enterprise, new apps To start with the design thinking workshop to see the risk vs gain in short and long run. Often times no short run gains rule out the investment decision Requires extensive workshop and POC or Due Diligence to explore a set of questions explained in slide #6 Relatively easier for a new startup where the organization has no baggage and DevOps can be created on a clean slate DevOps transformations for large/medium established enterprises are never simple; its either hard or harder depending on the several factors described later in this deck; this should be a relatively long term journey than just like project roll out ; it involves the collective delivery discipline of the organization than a engineers’ skill;
- 5. A Commercial Model & Roadmap • DevOps transformation or new implementation should be executed under T&M model unless the vendor understands the customer’s technical environment and culture with full certainty • If there is any pressure on the price point then it will be good idea to keep the design phase under T&M and implementation under fixed price range • During the phase the implementation timeline , effort and phases are to be determined based on the POC execution • What if customer does not have time for POC- then the implementation should be under T&M construct
- 6. POC • The POC must seek the following answers for Minimum Viable Pipeline (MVP) : • The architecture pattern – microservice, serverless, dependency schema, monolithic legacy • Grouping of apps and services fit for POC based on business criticality and technical arch • Availability decision – categorization of apps and service for Blue/Green type of deployment • What kind of routing required for different apps( Route 53 vs EBS) • Depends on the high and unpredictable loads ( favored by route 53) • Frequency of release ( EBS is better for lifecycle management) • Environment ( Dev, Unit Test, SIT , Component Test, UI test, Staging, Sandbox, Prod) • Defining the team Structure and location ( Dev-Infra-tool team or Module wise single team ) • How many CI/CD pipeline to be created • How volatile is the infra requirement & schema ( complexity of CloudFormation scripts) • Release process workflow via CodeStar or any other orchestration tool ( how many non AWS applications to be used in the CI-CD pipe line and the relevant plugins testing) • COTs proprietary release process and deployment testing • Application security & Compliances (if any) • The key KPIs definition and collection from the cloud trail • Any high frequency release plan to designed(temporary re-org of blue green) • No engagement can achieve the end state under one project contract, it is significant achievement if one vendor team can meet the MVP agreement with customers
- 7. Stakeholders Stakeholders Responsibility Impacts Business Lead To define the application criticality , outcome of the investment and the Business KPIs to be tracked Decision of the availability ,phase wise apps, NFR mapping towards business KPIs Architects Application architecture , new roll outs , decommission due, key services , external plugins, archi. governance process The grouping of the apps for running POC and creating specific test scenarios for dependency checking Product Owner Input on team discipline , culture, program phase delivery, scrum teams , frequency of the releases , release governance to decide on the team structure of the team CIO The KPIs that to be reported to the Business out of the DevOps implementation ( e.g. Feature release rate, Backlog reduction rate, POC must attempt to design 2-3 key KPIs that should be tracked from the day 1 via CloudTrail for the success of CIO)
- 8. Risk Assessment & Boundary The solution must be designed highlighting the observed risks during the POC and creating a boundary condition. • Slow on Org Change Management: • It is often observed that the dev team is not always ready to get on boarded to the new concepts and fast automation. In such cases a manual or semi automated deployment should be designed in the initial phase • Time windows should be defined for different type of apps; vendor must consult in stopping fully automated DevOps for legacy or to-be-retired apps • Even if lean architecture followed , wrong design of microservice may involve dependency-these cases are to be highlighted as risk elements • It is recommended to consult customers not to aim for frequent release in the initial phases • Roll out must involve only one geo to start with or one app in all different geos • The outcome KPI of DevOps implementation, if at all to be shown ( it is a very rare requirement as observed in India) should be progressive with a bare minimum commitment in the first 6 months • It is safe to assume a moderate size company ( let say 15-20 B USD revenue) may take about 18 -24 months before achieving full maturity that too depends on people, process, geos