A few days ago, I participated in the DevOps 2.0 – Beyond the Buzzword session hosted in the Microsoft building. The event was sponsored by Neudesic, Microsoft, and Docker. It differed from the DevOps 1.0 session, which was sponsored by Neudesic and Amazon in the sense that it focused little (actually not that much) on Microsoft technologies (like Azure). The presentations contained a lot of interactive forums and Q&A, and was presented by Mike Graff, Kunaal Kapoor, Chad Cook, Eric Stoltze and Chad Thomas, all from Neudesic.

 

The agenda consisted of four major sections; “DevOps in Review”, “Building the Continuous Delivery Culture”, “Automating the Secure Enterprise” and “Modernizing Legacy Apps”.

 

Starting with basic questions – Is your org implementing DevOps, Is your org using the cloud, What did you come to learn today – we quickly set the stage, and the sessions started. There was one axiom I really did not agree with, especially as someone in a team dealing with R&D and participating in Morgan Stanley's Innovation program – “You cannot innovate and standardize at the same time”. I’m happy to challenge this 🙂

 

In the digital age, it will not be the big who eat the small, it will be the fast that eat the slow!

 

The questions and discussions in the session mostly focused on why and how we do continuous delivery and DevOps. We looked at Finance 101 – Net Present Value (NPV) = cashflowin/(1+r)^t-cashflowout (where r is the cost of money and t is time), and discussed how DevOps can help change each of these variables. We alsp looked into basic Return On Investment (ROI) calculations, to see how DevOps can change it to the benefits. We discussed how we see opportunity costs (the benefit that could have been realized, but was given up, by choosing another course of action) and the cost of delay (a twist on opportunity cost that combines urgency and value).

 

By the way, did you know that in the average industry, 60-90% of required features for a product produce zero or negative value (like non-automatic hygiene)? This even applies to giants like Google or Microsoft, so they are not specific to company size or industry.

 

So, why do we practice continuous delivery and DevOps? The keywords are:

• Faster Delivery – High Performing teams deliver software 20 times more often with 200% better lead time; this nicely binds into the Continious Delivery and Deployment agenda
• Safer Delivery – High Performing teams have 48 times lower MTTR and 3 times lower change failure rate; this is something that binds into the blue/green agenda
• More Efficient – High performing teams spend half as much time on rework and three times as much time on new work
• Better Security – High performing teams have a 50% reduction in security related incidents
• Improved Satisfaction – Teams adopting CD / DevOps doubled their internal net promoter score and had tripled their customer net promoter score
• Increased Profitability – Organizations practicing CD / DevOps are 26% more profitable than traditional divisions

 

The three ways to achieve the DevOps nirvana according to the discussions are: flow, feedback and experiment.

 

How to work with Flow?

 

• Make Work Visible
• Limit Work-in-Process/Progress
• Reduce Batch Size
• Reduce Handoffs
• Identify and Elevate Constraints
• Eliminate Hardships and Waste

 

The first two items are part of most teams’ Kanban implementations, so I won’t spend extra characters on them. Making problems more bite size does help maintaining a healthier throughput, and helps ironing out the bumps in the road when an item has a wrong T-shirt size assigned. Handoffs – each time you are doing a handoff, you are literally losing track of it and automatically building a queue. Try to limit the number of handoffs through automation, by using commodity components. The last two items are in some way obvious ones; although sometimes we tend to be delivering features faster than having time to recognize that we are delivering under constraints or that we create unnecessary waste.

 

When it comes to Feedback, we can look into ways to:

 

• Work Safely in a Complex System
• See Problems as They Occur
• Swarm and Solve Problems to Build Knowledge
• Keep Pushing Quality Close to the Source
• Enable Optimization for Downstream

 

How many times have you felt unsafe in a system or system’s admin UI you had to interact with, and didn’t know what the next click or swipe would result? Whether there is going to be another ‘are you sure?’ question, or have you just been able to render your environment unusable? Or checking out this question from the other side – are you monitoring the right thing? Do you understand what needs to be done when the alert comes? Is it coming through a system that is able to target them correctly? No one wants to be the target of a blastmail to 500+ people with a multi megabyte attachment trying to figure out which items are relevant; neither had you wanted to get notifications tailored to you but not mentioning any of the action items to be taken. And when an issue happens, what should be the steps followed? Yes, in short term, it’s “cheaper” to have a follow the sun support model and have the support person dealing with it, as for sure the support person would “document the steps needed for later reuse” – I never see the latter happening. Whereas, if available people do swarm, the issue might be solved at a higher realized price when it comes to manpower, but the crosspollination happening during the solution is priceless. And – it shouldn’t be a big deal to help the downstream system optimize them instead of building another layer/façade/presystem around it; as the latter would just lead to another piece to maintain in the long term.

 

Lastly, when it comes to Experiment, we speak of the followings:

 

• Enable Continuous Learning
• Create a Safety Culture
• Institutionalize Continuous Improvement
• Transform Local Discoveries to Global Knowledge
• Inject Resilience into Daily Work
• Leaders Reinforce Learning Culture

 

We learn as long as we live. With Pluralsight, Lynda, Harvard reviews and more training tools available there is no real excuse on not taking the proverb to heart. We need to support people taking a leap – looking at Morgan Stanley's Innovation Program for the second time in this one article; this may be one of the best approaches to this problem so far. Continuous improvements shouldn’t stop at writing the software. It should be part of the fabric of the team itself; implementing so called ‘kata’s to improve the process and to seek improvements of day-to-day work is more than desirable. As teams span across multiple locations, it is imperative to host knowledge share sessions, brown bags, post write-ups, and more. We should aim to record as many of these as possible and make available tagged, even sometimes transcribed/minutes written up. And when people should listen to this? Building ‘slack’ time or possibility for slack time into a system, using Pomodoro Technique and gifting yourself experimenting time for successful Pomodoros, etc. might have a bigger benefit than you think. Lastly, such change (if there are changes needed) are most successful if they are reinforced or started by management; or you experience them through mentorship – try to seek for the latter if you don’t feel the former.

 

Because, yes, DevOps2.0 needs more cultural change then technological ones – for some of the problems in the DevOps space there are off-the-shelf solutions; but to make them successful, the 20% of the technological change needs to be met with the 80% of the cultural change needed. You cannot just introduce a DevOps team between your Dev and Ops teams – that would result in another set of handovers (see above ), and no real benefits.

 

In a later session, when it came to the question of Security as part of DevOps,

 

Fewer than 20% of enterprise security architects actively and systematically incorporated information security into their DevOps initiatives (Gartner)

 

As part of looking into the importance of the enterprise DevOps process, you can look into:

 

• Automating Security
• Empowering Engineering Teams
• Maintaining Continuous Assurance
• Setting Up Operational Hygiene
• Increasing Engineering Autonomy
• Increasing Availability of Dev Technologies
• Ensuring Constant Change is the New Norm
• Leveraging Wide-ranging Operational Responsibilities of DevOps

 

We have had a long discussion of this, but I think our requirements when it comes to security and the maturity of these solutions might not be aligned to where we are now and where we would like to be in the future.

 

Lastly, as part of Application Modernization Strategies, we went into discussion of the “6 Re”:

 

• Retire – Remove the application or platform completely
• Replace – Replace the application of platform with new version or competing solution
• Remediate – Invest in extending the lifeline of the application or platform
• Re-architect – Redesign the application or platform to meet demands
• Re-platform – Redesign the application to run on different infrastructure
• Re-build – Rewrite the application to remove technical debt or change the implementation

 

The whole day was full of demos, everything from Security Kits through Kubernetes Orchestration to Mobile Crash Analysis, and useful discussions with industry peers. And the best discussion of the day? “How you get around SOX and Segregation of Duties when using DevOps?” – You don’t. Instead of that you educate the audit/regulator and show that the relevant controls and the segregation are still there.