Download - DevOps for Architects
www.ranger4.com
DevOpstastic
EnterpriseArchitect
Cloud Solutions Architect
Solutions Architect
DevOpsArchitect
DevOpsSolutions Architect
Application Architect
Application InfrastructureArchitect
ApplicationDeliveryArchitect
Chief Programme Architect
Business Application Architect
Cloud Architect
Infrastructure Architect
Security Architect
www.ranger4.com
DevOpstastic
“An architect involved in a DevOps Project should ensure the following:
• The various tools and environments are set up to enable their activities to be traceable and repeatable.
• Configuration parameters should be organised based on whether they will change for different environments and on their confidentiality.
• Each step in the deployment pipeline has a collection of automated tests with an appropriate test harness.
• Feature toggles are removed when the code they toggle has been placed into production and has been judged to be successfully deployed.”
From ‘DevOps for Software Architects’ by Len Bass and Ingo Weber
www.ranger4.com
DevOpstastic
“Gartner’s model rests on a false assumption that is still pervasive in our industry: that we must trade off responsiveness against reliability. The conventional wisdom is that if we make changes to our products and services faster and more frequently, we will reduce their stability, increase our costs, and compromise on quality.This assumption is wrong.”Jez Humble
www.ranger4.com
DevOpstastic
Pace Layers for DevOps
Systems of
Record
Systems of
Differentiation
Systemsof
Innovation
Traditional
DevO
ps
Change
Governance
+
+
-
-
From Gartner
www.ranger4.com
DevOpstastic
1
23456789101112
Product Backlog
FEATURES
Team selects how much to commit to do by sprint’s end
Sprint Planning Meeting
(parts one and two)TASKS
Product Owner
Input from end-users,
customers, team and other
stakeholders
Retrospective
Review
Daily Scrum Meeting and
Artifacts Update
Potentially Shippable Product
Increment
Sprint1 – 4 Weeks
No ChangesIn Duration or Goal
Product Backlog
Requirement
Team
ScrumMasterArchitect
What Agile Architecture Looks Like
www.ranger4.com
DevOpstastic
Anti-Pattern DevOps Metrics and Potential Effects
From the CA DevOps Practitioner Series: “Metrics That Matter”http://www.ca.com/us/~/media/Files/whitepapers/devops-practitioner-series-metrics-that-matter-developing-and-tracking-key-indicators.pdf
Product Function FeaturesVanity Metrics • Lines of code produced
• Function points created Vanity metrics can be counterproductive since they reward the wrong types of behavior—especially if incentives are linked to the metric. Producing more code and features without validation can also inhibit more valuable activities such as refactoring and design/ architecture simplification.
Intra-Team Metrics • Agile team leaderboards • Deployments/changes
prevented
Beware of metrics that pit teams against each other and perhaps use vanity metrics as scoring mechanisms. Strike a balance with metrics and rewards that influence positive inter-team behaviors—such as code sharing, peer reviews and mentoring. Pay particular attention to metrics that promote an anti-DevOps culture, such as measuring operational effectiveness on the ability to stop releases and deployments.
Traditional Metrics • Mean-time-between- failure (MTBF)
• FTEs: Servers
With a DevOps culture and the faster delivery of services some failure is to be expected. While not an acceptable condition, always realize that some failure will happen and responding to it is often much more important (and even less costly) than trying to prevent it.
www.ranger4.com
DevOpstastic
DevOps Metrics Dimensions
From the CA DevOps Practitioner Series: “Metrics That Matter”http://www.ca.com/us/~/media/Files/whitepapers/devops-practitioner-series-metrics-that-matter-developing-and-tracking-key-indicators.pdf
Culture, Collaboration and Sharing
Staff retention Morale/job satisfactionWiki/open source contributions Mentoring
Customer and Business Value
NPS (net promoter scores)Customer conversion (by app/function)
Lead timesRevenue per user story
Efficiency and Effectiveness Quality and VelocityFTE to customer ratiosCost per transaction/appChange / release cost burden
MTTR Cycle times
Rollback rates Deployment frequency
Operational support costs
www.ranger4.com
DevOpstastic
Balanced Scorecard
From the CA DevOps Practitioner Series: “Metrics That Matter”http://www.ca.com/us/~/media/Files/whitepapers/devops-practitioner-series-metrics-that-matter-developing-and-tracking-key-indicators.pdf
www.ranger4.com
DevOpstastic
“An architect involved in a DevOps Project should ensure the following:
• The various tools and environments are set up to enable their activities to be traceable and repeatable.
• Configuration parameters should be organised based on whether they will change for different environments and on their confidentiality.
• Each step in the deployment pipeline has a collection of automated tests with an appropriate test harness.
• Feature toggles are removed when the code they toggle has been placed into production and has been judged to be successfully deployed.”
From ‘DevOps for Software Architects’ by Len Bass and Ingo Weber
www.ranger4.com
DevOpstastic
Certified Agile Service Manager Course
• May 25th/26th
• London – Long Acre, Covent Garden• DevOps Institute course• Examinable and certified• £890 per student• Daniel Breston is tutor
www.ranger4.com
DevOpstastic
Take-aways• Architects are the glue between the business or vendor and
the IT teams, so own and improve the process of IIVOR• Start the discussion and keep it going often (feedback)• Use metrics that matter to the business not just to
technology• DO not create in isolation: collaborate, communicate, get all
involved• Find a way to test early and often what you want to do• Architects own the Why and the What: but remember that
others own the How – help them as appropriate• Govern is not the same as Governance: use just enough of
the right one