SlideShare a Scribd company logo
1
DEVOPS TRANSFORMATION
1
2
WHAT IS DEVOPS?
• It is a practice
• It is a mentality and culture
• It is collaboration
• It is agile operations
• It is software approach to ops
• It is rapid IT service delivery
• It is not a permanent team
• It is not a profession
• It is not only software tools
• It is not only code infrastructure
• It is not a System Engineer
3
features released faster, reduced cycle times,
higher deploy rates, contained issues, ability to
change fast.
Faster time to market
increased availability, increased change success
rate, embrace failures.
Increased quality
increased time spent on value adding activities,
increased amount of value being delivered to the
customer, better collaboration among teams
Increased collaboration
WHY DEVOPS?
4
SOFTWARE DEVELOPMENT
QUALITY ASSURANCE IT OPERATIONS
Required to produce code while not having
a chance to know how it behaves and
performs in production like systems, how
customers feel about it, how it matches
with actual needs.
Software Development Team
Whatever is given to ship in
production, make sure it runs. If it
doesn’t – hack into it somehow.
a.k.a. Deploy and Pray
System Engineering Team
Responsible to adhere to high quality
standards, very often blindly without
being given all the tools, resources and
lacking coverage.
Quality Assurance Team
BEFORE DEVOPS
The space in between representing
confusion, misalignment, walls, and stress.
Wall Team
5
Collaboration
Developers and System Engineers
working together make it possible to
better understand each other and
make cool things such as automation.
Queuing
Customer focused prioritization, overload
identification points, calmness, better services, and
task scope improvements.
DevOps team
A point to seed the DevOps approach -
team setup as a transitional step to
infuse cooperation of developers and
system engineers.
DEVOPS – Transitional Team approach
(there is no right or wrong – whatever works!)
Silos
Overstrained
The Bad The Good
Having an all-powerful team
creates an isolated silo and an
operational knowledge bottleneck.
Capability and expertise increases leading to
increased scope of responsibilities and
competencies while overall team throughput
can reach limits.
Confused
Initially, expected confusion on what
specialties and opportunities can be covered
by who within team. This can be manifested
as team overload and chaos, queues will help.
6
NEXT LEVEL TOWARDS DEVOPS: TECHNICAL
Full Virtualization
QA, Feedback systems, and Logs
Uniformity & Automation
Independent releases
Containers & Service discovery
GroundsGoals
http://www.slideshare.net/AgronFazliu/devops-transformation-technical-and-organizational-goals-68059115
See DevOps Transformation – technical aspects
7
NEXT LEVEL TOWARDS DEVOPS: ORGANISATIONAL
INFRASTRUCTURE
CONFIGURATION
DEVOPS
CODE & DATA TOOLCHAINS
Product teams are independent, having full
expertise and responsibility over software
development, testing, deployment toolchain, and
production software operations.
Indicative (team decides):
50% Software development
20% Infrastructure-as-code development
20% Product testing automation
10% Innovation
Product DevOps Teams
Site Reliability Engineering Team is small but responsible for
the internal and production container infrastructure-as-code
reliability and performance.
Indicative (team decides):
40% Operate Infrastructure, reliability, performance at scale
30% Innovate and improve production/IaC
30% Business/Customer technical expertise
Site Reliability Engineering Team
Operations KPIs
Software SLA
“SRE team is responsible for availability, latency,
performance, efficiency, change management,
monitoring, emergency response, and capacity
planning.”
“DevOps represents a change in IT
culture, focusing on rapid IT service
delivery”
8
HOW WOULD DEVOPS ORGANISATION LOOK LIKE!
Production
SoftwareSLA
9
SANITY CHECK: CONWAY’S LAW
Production
“Any organization that designs a system
(defined broadly) will produce a design
whose structure is a copy of the
organization's communication structure!”
Customers
Organization!
Architecture!
http://www.melconway.com/Home/Conways_Law.html
10
WATCH OUT POINTS!
Customers
Focus not on output
and development but
on outcome and
customer needs.
Cooperation
Independence does
not mean isolation,
therefore people
collaboration is
paramount to function
within one roof
Vision
Ensure that teams
running own
products do not drift
away from company
vision and goals
Mentality
Reach a point of
understanding that
independence comes
with responsibility
10
1111
Learn
Trust your tests and data
Independent Teams - Reach technical product independence
Internal eq. production
01
02
04
WHAT FIRST?
Automate until bored
Virtualize everything
Rely on your Feedback Systems
SRE Team - Manage IaC & containers at scale
Innovate
Docker probing Improve
Scale
03
12
WHAT OTHERS ARE SAYING! So, you don’t feel lonely 
Question 4
Who manages the DevOps initiatives?
• Development teams
• Shared management
Question 3
Creating appropriate testing environments for databases can be difficult.
What approach does your organization generally use?
• The testing environment resembles the production environment as
closely as possible, including transaction and data scale
• Use transaction capture and replay from production to test with data
replicated/masked from production
Question 2
What is the key element to successfully implementing a DevOps approach?
• Support from executive leadership
• Ensure that there are flexible, available resources
Question 1
What is the most significant drawback in traditional development processes?
• Difficult to respond to changing business requirements
• Lack of communication between development and operations
39%26%
36% 39%
16%
55%
31%
32%
DELL, 2016: The Current State and Adoption of DevOps
top two answers
13
If you automate a mess, you get an automated mess.
Rod Michael, Rockwell Automation.
Reconsolidate the technology
Maintain business growth and expansion
Assess transition risks
Re-organize towards independent product teams
Master system and organizational scaling up/down
Innovate & Improve
Summarized
13
14T H A N K Y O U !
Questions!

More Related Content

DevOps Transformation - Another View

  • 2. 2 WHAT IS DEVOPS? • It is a practice • It is a mentality and culture • It is collaboration • It is agile operations • It is software approach to ops • It is rapid IT service delivery • It is not a permanent team • It is not a profession • It is not only software tools • It is not only code infrastructure • It is not a System Engineer
  • 3. 3 features released faster, reduced cycle times, higher deploy rates, contained issues, ability to change fast. Faster time to market increased availability, increased change success rate, embrace failures. Increased quality increased time spent on value adding activities, increased amount of value being delivered to the customer, better collaboration among teams Increased collaboration WHY DEVOPS?
  • 4. 4 SOFTWARE DEVELOPMENT QUALITY ASSURANCE IT OPERATIONS Required to produce code while not having a chance to know how it behaves and performs in production like systems, how customers feel about it, how it matches with actual needs. Software Development Team Whatever is given to ship in production, make sure it runs. If it doesn’t – hack into it somehow. a.k.a. Deploy and Pray System Engineering Team Responsible to adhere to high quality standards, very often blindly without being given all the tools, resources and lacking coverage. Quality Assurance Team BEFORE DEVOPS The space in between representing confusion, misalignment, walls, and stress. Wall Team
  • 5. 5 Collaboration Developers and System Engineers working together make it possible to better understand each other and make cool things such as automation. Queuing Customer focused prioritization, overload identification points, calmness, better services, and task scope improvements. DevOps team A point to seed the DevOps approach - team setup as a transitional step to infuse cooperation of developers and system engineers. DEVOPS – Transitional Team approach (there is no right or wrong – whatever works!) Silos Overstrained The Bad The Good Having an all-powerful team creates an isolated silo and an operational knowledge bottleneck. Capability and expertise increases leading to increased scope of responsibilities and competencies while overall team throughput can reach limits. Confused Initially, expected confusion on what specialties and opportunities can be covered by who within team. This can be manifested as team overload and chaos, queues will help.
  • 6. 6 NEXT LEVEL TOWARDS DEVOPS: TECHNICAL Full Virtualization QA, Feedback systems, and Logs Uniformity & Automation Independent releases Containers & Service discovery GroundsGoals http://www.slideshare.net/AgronFazliu/devops-transformation-technical-and-organizational-goals-68059115 See DevOps Transformation – technical aspects
  • 7. 7 NEXT LEVEL TOWARDS DEVOPS: ORGANISATIONAL INFRASTRUCTURE CONFIGURATION DEVOPS CODE & DATA TOOLCHAINS Product teams are independent, having full expertise and responsibility over software development, testing, deployment toolchain, and production software operations. Indicative (team decides): 50% Software development 20% Infrastructure-as-code development 20% Product testing automation 10% Innovation Product DevOps Teams Site Reliability Engineering Team is small but responsible for the internal and production container infrastructure-as-code reliability and performance. Indicative (team decides): 40% Operate Infrastructure, reliability, performance at scale 30% Innovate and improve production/IaC 30% Business/Customer technical expertise Site Reliability Engineering Team Operations KPIs Software SLA “SRE team is responsible for availability, latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning.” “DevOps represents a change in IT culture, focusing on rapid IT service delivery”
  • 8. 8 HOW WOULD DEVOPS ORGANISATION LOOK LIKE! Production SoftwareSLA
  • 9. 9 SANITY CHECK: CONWAY’S LAW Production “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure!” Customers Organization! Architecture! http://www.melconway.com/Home/Conways_Law.html
  • 10. 10 WATCH OUT POINTS! Customers Focus not on output and development but on outcome and customer needs. Cooperation Independence does not mean isolation, therefore people collaboration is paramount to function within one roof Vision Ensure that teams running own products do not drift away from company vision and goals Mentality Reach a point of understanding that independence comes with responsibility 10
  • 11. 1111 Learn Trust your tests and data Independent Teams - Reach technical product independence Internal eq. production 01 02 04 WHAT FIRST? Automate until bored Virtualize everything Rely on your Feedback Systems SRE Team - Manage IaC & containers at scale Innovate Docker probing Improve Scale 03
  • 12. 12 WHAT OTHERS ARE SAYING! So, you don’t feel lonely  Question 4 Who manages the DevOps initiatives? • Development teams • Shared management Question 3 Creating appropriate testing environments for databases can be difficult. What approach does your organization generally use? • The testing environment resembles the production environment as closely as possible, including transaction and data scale • Use transaction capture and replay from production to test with data replicated/masked from production Question 2 What is the key element to successfully implementing a DevOps approach? • Support from executive leadership • Ensure that there are flexible, available resources Question 1 What is the most significant drawback in traditional development processes? • Difficult to respond to changing business requirements • Lack of communication between development and operations 39%26% 36% 39% 16% 55% 31% 32% DELL, 2016: The Current State and Adoption of DevOps top two answers
  • 13. 13 If you automate a mess, you get an automated mess. Rod Michael, Rockwell Automation. Reconsolidate the technology Maintain business growth and expansion Assess transition risks Re-organize towards independent product teams Master system and organizational scaling up/down Innovate & Improve Summarized 13
  • 14. 14T H A N K Y O U ! Questions!