DevOps is the popular kid in school. Everyone wants to be in DevOps gang (even if DevOps is a bit of a jerk at times). Like all gangs, trailing behind the most popular kid are the recognised sidekicks – say hello to DevSecOps and BizDevOps – also rapidly gaining popularity and respect.
The agile movement, and the demand to be agile, brought about DevOps which is fast gaining momentum.
The one thing everyone happily agrees in unison, is that there is no formal definition of DevOps. This can lead to confusion, especially in large financial institutions that live by definition and structure. There are some great sources out there; Gene Kim's "3 ways" from the Phoenix Project, Debois and the 4 areas (Note Debois and Shafer are credited with founding DevOps back in 2008 in an Agile Conference in Canada) and now the DevOps Infographic.
In the DevOps Infographic EntArchs shows the key considerations large financial institutions should consider when adopting DevOps.
In the scramble to jump on the DevOps bandwagon, many product vendors now offer large organisations the ability to do rapid releases, adopt modular architectures and releases and do "DevOps".
However organisations have typically invested in their IT landscape and have many large stable applications (typically Systems of Record) that do not need to be changed rapidly. Agility does not mean Stability is bad! Similar to the 2 Speed IT philosophy, using Enterprise Architecture best practices, identify which parts of your IT landscape should remain stable, should require high investment and low parameterisation & configuration. Do not be tempted to "Scrum" or "DevOps" everything, stability should be popular too.
Typically projects in your systems of insight or engagement maybe DevOps candidates, but the key is to use Enterprise Architecture best practices to select the right projects for DevOps, more on this coming soon.....
It is here that the first DevOps mistakes are frequently made.
Large financial institutions typically have dedicated development teams (sometimes near or off shore) and regimented Operations teams. EntArchs has witnessed many large financial institutions building "DevOps" teams solely in the development department, while operations plods on oblivious at the other end of the corridor or Europe. DevOps requires a change in behaviour and therefore culture, bringing these teams together.
Compliance and regulation play a role in how IT teams are constructed in large financial institutions. Sarbanes Oxley is an excellent example, in a post Enron world - where one man could bring down an institution - it was decided that only Dev shall Dev and Ops shall Ops. That one man cannot push everything to production.
The correct DevOps team structure is important here. It will ensure continued compliance while adopting the correct unified philosophies. For more information I recommend reading John Willis and Damon Edwards CAMS (Culture, Automation, Measurement and Sharing) and Dan North's Behaviour Driven Design.
This is nice and simple.
An automated broken process is still a broken process. Adopting DevOps is a good opportunity to examine how certain manual processes work and if they can be improved or repaired.
EntArchs once worked with a client who had lengthy, broken processes to provision dedicated user access to servers. This client then invested a lot in a PaaS solution to provision infrastructure faster and in an automated manner. Their users found that they could get servers faster, hours rather than weeks, but were still then waiting 3 weeks to get their login. It proved to be more frustrating to users than before.
The beauty of the openness of the DevOps definition means that after completing the first steps above you can define your DevOps for your organisation. In our infographic we have highlighted key areas to consider:
Your tool selection in these areas will depend on your technologies, languages and scripting of choice. Your level of automation will vary depending on your need for rapid production releases. For some organisations the definition of rapid production releases might be hourly for another weekly.
While you do not need to align to a formal industry definition of DevOps, take the time to define DevOps for your organisation.
Before making investments - as a result of embarking on a DevOps journey - build a test stack in the cloud to verify your stack. Regulation within your organisation maybe such that you cannot use public cloud, but setting up a test stack (with no private data) will verify your tool selections, level of automation and level of agility before investing in internal licenses, infrastructure and operational changes.
You should consider every DevOps release cycle like a mini project. Therefore you should set KPIs to measure your level of improvement and feedback into your DevOps cycles. This way you should see improvements and your velocity (in scrum speak) increase. KPIs to consider might be:
Perhaps the most important KPI is that of the cultural change - which is hard to measure due to its unquantifiable nature. However lessons learnt from KPIs, will feed back into your DevOps cycles, improving your delivery, changing your teams behaviours and permeating the coveted culture through your organisation.