2. How to survive the paradox
between
development speed
and
operational stability?
Wim Peeters
Senior ALM/CLM specialist, OpenICT bvba
Wim.Peeters@openict.be
3. OpenICT bvba in a nutshell:
• Founded November 2004.
• IBM Rational Partner.
• Extensive experience in the field of software management and deployment.
• 5 DevOps core activities:
① Software Configuration Management
② Software development process support
③ Scripted automation of builds and deployments
④ Release management & coordination
⑤ Security analysis of application source code
!
• Brand independent & open source knowledgeable.
!
• Make and sell our own software: Orditool for the transport sector.
4. The Application Lifecycle Management (ALM)
Software Configuration Management (SCM)
Build and Release Automation
4
Core competencies
5. 5
Businesses require faster speed to market while at the
same time they "assume" that there is no impact on the
overall operational stability.
!
Reality shows that continuous development and
deployment, if not implemented correctly, often leads to
continuous operational failure.
Our vision on DevOps:
6. Development and Operations work earlier
and closer together to achieve the business goals.
• Drivers for closer collaboration:
▪ Business that requests Faster time to market with quality, bug free and
stability.
▪ Agile development methods that are used.
!
• How to collaborate more closely?
▪ Good Requirements, Analysis, Design
▪ Good Communication
▪ Good Integration between development teams and operational teams
▪ Good Testing and Quality Control
▪ Good Tooling and Automation
6
The promise of DevOps:
7. DevOps and
Agile Software Development
7
Agile software development is a group of software development
methods in which requirements and solutions evolve through
collaboration between self-organising, cross-functional teams.
!
It promotes adaptive planning, evolutionary development, early
delivery, continuous improvement and encourages rapid and flexible
response to change.
!
It is a conceptual framework that focuses on frequently delivering
small increments of working software.
8. DevOps and Agile Software Development
(Continued)
• Easier and more cost-effective to solve
a bug or adapt to a requirement early (1).
8
(1) Note: See e.g. NASA’s - Cost escalation through the project lifecycle - 2004 /
QA Mindset - The earlier you find defects, the cheaper they are to fix
(2) Note: this early awareness of operational concerns is known as “Shift-left”
• Operational teams should be involved early (2).
!
• Development teams adapt to the operational release process and tooling
early (2).
9. Agile Manifesto the 12 principles
1. Customer satisfaction by rapid delivery of useful software
2. Welcome changing requirements, even late in development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the principal measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10.Simplicity—the art of maximising the amount of work not done—is essential
11. Self-organising teams
12.Regular adaptation to changing circumstances
9
http://www.agilemanifesto.org/
10. Agile Manifesto the 12 principles
(Continued)
1. Customer satisfaction by rapid delivery of useful software
2. Welcome changing requirements, even late in development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the principal measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10.Simplicity—the art of maximising the amount of work not done—is essential
11.Self-organising teams
12.Regular adaptation to changing circumstances
10
Does this workin practice?
11. Agile Manifesto the 12 principles
http://www.agilemanifesto.org/
1. Customer satisfaction by rapid delivery of useful software
2. Welcome changing requirements, even late in development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the principal measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10.Simplicity—the art of maximising the amount of work not done—is essential
11.Self-organising teams
12.Regular adaptation to changing circumstances
11
NO, because it’s
13. 13
Business goals
Everybody wants to support the 3 same business goals:
① Faster time to market of the software
② High quality software
③ High operational stability
Between departments however priorities are different:
! Development teams want
change
!
“change is the thing we
need!”
Operational teams want stability
!
“change is the enemy!”
><
14. Origin of the paradox
• In our day-to-day IT work we have to deal with:
▪ People
▪ Process
▪ Tools
!
• But most developers and system administrators:
▪ Have a different backgrounds
▪ Use different processes and
▪ Use different tools
14
15. People
• Not everybody has the same mindset
• Nor has the same motivation
• Nor has the same goal
• Nor has the same skill
• Nor has the same experience
• Nor has …
!
• Cannot keep the same constant pace
• Cannot always organise themselves
• Cannot always easily adapt to change
• Cannot…
!
• People are different
15
16. Mindset conflict?
• Change is the thing we need
▪ Development: change is the thing we are paid for.
▪ The business depends on us to respond to changing needs.
!
• Change is the enemy
▪ Operations: change is the enemy.
▪ The business depends on us to keep the lights on
▪ We resist change as it undermines stability and reliability.
16
18. Organisational conflict?
18
▪ Development and operations teams tend to fall into different parts of a
company’s organisational structure.
▪ They often have different managers and different competing
corporate politics.
▪ They often work at different geographic locations, even across
continents.
▪ And the people executing the jobs tend to change on a frequent
basis.
21. Importance of the used tools
In reality:
• Tools used by developers >< tools used by
system administrators.
• Occasionally the same bug tracking &
ticketing system is used.
• Rarely the same version control system is
used.
• No integrated tool chain!
21
Result:
Lack of a clear trace from requirements to code changes to tests
to release!
Common myth:
“A tool is a tool, it all depends on the people using the tools. “
22. How do companies deal
with DevOps & tools today?
1. They use a different DevOps solution per project:
▪ With different toolsets between projects
▪ With different ALM processes between projects
▪ With different subprocesses per SCM phase
22
Limited reusability of processes and tools
Lack of integration between software tools
No traceability from development to production
Impossible to compare projects
23. How do companies deal with DevOps & tools today?
(continued)
2. They work on an AD HOC basis
▪ No ALM process
▪ One specific tool for one specific problem
▪ Mix of open source and commercial software tools
23
No reusability of tools
No control over ALM process & used tools
No scalability
24. The OpenICT approach
Define your end-to-end ALM process
▪ Start from your existing process
▪ From requirements management to production releases
Pick a toolchain that helps you to enforce your
ALM process
Use an integrated toolchain that supports
every step in the entire lifecycle
Automate your toolchain
Use it company wide
24
26. Need help with your DevOps
and ALM processes?
26Excelsiorlaan 18 – 1930 Zaventem – Belgium – www.openict.be - +32 (0)2 342 01 90
Wim Peeters
Senior ALM/CLM specialist
wim@openict.be
Jan De Laender
Senior ALM/CLM specialist
Jan@openict.be
Contact
Wim or Jan
for FREE advise
