Which team structure will enable DevOps to flourish ?

1. z
DevOps
Topologies
Sushma Chakkirala, Program Director,
Secure DevOps @GTS Labs IBM

2. z
DevOps Transformation and Culture
Continuous Innovation, Feedback and Improvements
DevOps Lifecycle
Monitor & OptimizeRelease & DeployPlan & Measure Develop & Test
IBM defines DevOps as an essential Enterprise capability for continuous software delivery and
management that enables organizations to innovate rapidly to capitalize on new market
opportunities, and reduce the cycle time to collect and react to customer feedback
DevOps is a movement that requires a cultural and organizational change. DevOps practitioners
should also consider culture which is a hard thing to transform.
There is strong co-relation between team topology to team chemistry, individual performance,
organizational capability and effectiveness of software delivery process

3. z
How Team Topology impacts culture
“Conway’s Law“ states that “Organizations which design systems
… are constrained to produce designs which are copies of the
communication structures of these organizations.”
Alignment between business goals, system and team structure and
collaboration structure is critical for becoming truly agile.
Silo Attributes
Heavy handoffs, conflicting goals,
resistance, friction, order taker &
givers, defensive, blame game
Collaborative Attributes
Simple or no handoffs, shared
responsibility, trust, self-service,
autonomous, open communication
channels, mutual respect

4. z
DevOps Team Topologies Framework
There are many types of topologies that
can effect DevOps transformation. Each
topology comes with its pros and cons.
Matthew Skelton and Manuel Pais
documented common team topologies
used by organisations.
See http://devopstopologies.com/ for
catalogue of team patterns and anti-pattenrs
Which team structure will best fit my
organization given the current skills
and culture?
Which structure will enable DevOps to
flourish in my organization?
How to transition from ‘now’ to the
‘nirvana’ structure?

5. z
Personas & Roles & Responsibilities
These are not separate, but interdependent entities that have to come
together to put software into production.
Seamless handoffs, Collaboration and Shared ownership of
common areas needed to design systems and continuously improve
‘production readiness’.
Dev - Plan, Code, Build,
Test. Specialty includes
coding, testing,
algorithms, application
design
Ops – Deploy, Monitor,
Operate, Release,
support. Specialty in
Infrastructure, OS
administration, HA, On-
call support, incident
management

6. z
DevOps Patterns and Anti-patterns
Anti-patterns
A. Dev vs Ops: D-O
B. DevOps Team Silo: D-DO-O
C. No Ops Needed: D.DO-O(0)
D. Tools Team: D-O(T)
E. SysAdmin: D-O(S)
F. Embedded Ops: D(DO)-O
G. Dev vs DBA: D-O(DBA)
Patterns
1. Dev+Ops: D+O
2. Shared Ops: DO
3. Ops as IaaS: D.DO-O
4. DevOps-as-a-Service: D..DO..O
5. Temp DevOps Team: D-DOT-O
6. DevOps Evangelists: D-DOE-O
7. SRE Team: D-SRE-O
8. Container-Driven: D©-O©
9. DB Capability: DO(DBA)-O
A pattern can become an anti-pattern when the team and the leaders exhibited siloed attributes
Potential “To-Be” Team patterns for the future

7. z Type 1: Dev and Ops Collaboration - D-O
Characteristics
 Dev leans on Ops for operational concerns
and includes Ops
 Ops must be comfortable pairing with Dev
and asking difficult questions on
performance, reliability and rejecting
deployments
 Both have shared goals and mutual respect
Effectiveness: High
Suitability: Technical leadership and team

8. z
Type 2: Fully shared Dev and Ops - DO
Characteristics
 Embedded Dev and Ops
 No visible Ops team – NoOps
 Context switching, product focus, mix of skill
set
 Budgetary constraints, startup mode
Effectiveness: High
Suitability: Web based product & Bootstrap

9. z Type 3: DevOps as IaaS(Platform) – D.DO-O
Characteristics
 Team within dev provides thought
leadership on operational features,
metrics, monitoring, provisioning
 This team communicates to IaaS
 Less collaboration, easy to implement
Effectiveness: Medium
Suitability: Traditional IT Operations and use
of public cloud

10. z Type 4: DevOps as a External Service – D..DO..O
Characteristics
 Orgs that don’t have finances to invest in
operational aspects
 Dev team reaches out to external provider
to build test environments, automation,
monitoring, advice on Ops features
Effectiveness: Medium
Suitability: small organizations who don’t
want to invest in Operational expertise

11. z Type 5: DevOps team with an expiry date – D-DOT-O
Characteristics
 Temporary team to bridge between Ops
speak and Dev speak
 Temporary virtual team
 Translate to Operational aspects such as
SSL offloading, LBs
Effectiveness: High
Suitability: Precursor to lead to Type 1

12. z Type 6: DevOps as Evangelists D-DOE-O
Characteristics
 Facilitating DevOps practices
 Spreading awareness
 Keeps Dev and Ops talking
 Goal is to become redundant by enabling
the org
Effectiveness: Medium to High
Suitability: Orgs where the Dev and Ops tend
to drift apart

13. z
Type 7: DevOps as SRE – D-SRE-O
Characteristics
 Explicit handoff model
 Dev team has to provide evidence that SW is of
production quality with metrics, logs
 If SRE team is happy with the code and agrees to
support in production
 SRE can reject the SW and ask Development to
improve the code
Effectiveness: Low to High
Suitability: High engineering and organization
maturity

14. z
Type 8: Container driven collaboration- D©-O©
Characteristics
 Containers minimize the need for
collaboration
 Encapsulate deployment and runtime
requirements of application to container
Effectiveness: Medium to High
Suitability: Works very well but beware of
the ‘just deploy’ mindset

15. z
Thank you!!