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