devops for architects

www.ranger4.com

DevOpstastic

WebcastDevOps for Architects

www.ranger4.com

DevOpstastic

Your Panel Today

Helen Daniel

www.ranger4.com

DevOpstastic

Why are we having this

conversation?

www.ranger4.com

DevOpstastic

Architects

Development

Operations

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

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

Bi-Modal IT

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

Microservices

www.ranger4.com

DevOpstastic

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

Containerisation

www.ranger4.com

DevOpstastic

www.ranger4.com

DevOpstastic

Agile

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

Security

www.ranger4.com

DevOpstastichttp://stwww-production.herokuapp.com/calculator/

www.ranger4.com

DevOpstastic

www.ranger4.com

DevOpstastic

Metrics that REALLY Matter

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


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


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

What now?

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

www.ranger4.com

DevOpstastic

Be DevOpstastic

devops for architects

Technology