Agile has long been considered an exclusive software paradigm. Agility as we all know is a mindset and as the Law of Conservation of Agility states, it needs to be inculcated.
Imagine that you want to go on a healthy diet, and you focus only on lunch, ignoring the dietary considerations of breakfast and dinner. Can you really turn around your health this way? Just as a healthy lunch alone would not give you the complete health benefit, agility in application development alone will not enable you to create customer value faster. The focus needs to be on the end to end value stream, which includes infrastructure.
Now what does agile infrastructure encompass? It means a couple of things:
- The transformation of the infrastructure organisation and
- A pervasive DevOps mindset across the enterprise.
In my conversations with customers, this transformation of infrastructure teams is often referred to as AgileOps/AgileInfra and some organisations even refer to it as DevOps. Some organisations refer to infrastructure teams as Ops team. That explains the use of the term “AgileOps.” To me, AgileOps is a highly localised agile mindset shift for infrastructure teams.
DevOps is a much larger umbrella that encompasses business, dev, test, support, and infra teams all working together as one team to delight the customer. The ultimate objective of DevOps movement is the ability to introduce changes in the system with speed, quality, and reliability in a sustainable way.
Here are the 4 principles to bring agility to the infrastructure organisations
1. Break the Silos
“Silos build the wall in people’s minds and tie the knots in their hearts” – Pearl Zhu, author and digital visionary
Network, Compute, and Storage do not add customer value separately. They need to work together. Organisations that have such highly compartmentalised and siloed teams need to break the barriers and bring them together. Agile infrastructure teams need to be T-shaped just like their application counterparts. This is a skillset model in which team members should be deep in one skill and have basic knowledge of all other skills required for the team. Apply systems thinking and try to provide better customer value as a whole instead of optimizing individual infrastructure components.
One of the fundamental principles of lean product flow is fewer handoffs. Infrastructural service offerings should be well structured with cross functional teams. The offerings and teams should be optimized such that end to end to end service delivery can be completed with least number of handshakes.
2. Infrastructure as Code
We all know that agile works well in the software world, but infrastructure is not really software. So, if infrastructure could be software based, agile should work well there, shouldn’t it? The goal of infrastructure organisations needs to change from operate mindset to creating self-service automated solutions. Application teams should be able to spin up and deploy infrastructure on demand. We need to take a software defined approach to everything including infrastructure.
The true measure of success for such a team is the turnaround time to bring up a Data Centre if an infrastructure component like a server is damaged. In the world of manual configurations, it may take a long time to bring up the Data Centre again. With Infrastructure as Code, the turnaround time can be much lower.
3. Skillset transformation
For a while, we have had sys admins manually perform configurations on systems. This needs to change to automated scripts doing such mundane tasks. Infrastructure engineers should have software engineering skillsets.
Infrastructure teams should aim to become automation experts and to continuously create automated solutions so application teams can consume infrastructure as code. Organisations need to invest in upskilling system admins to system automators and make them uber software developers.
This is a key component of successful Site Reliability Engineering (SRE), made popular by Google. SRE is the concept of running operations through software expertise. SRE requires that the people responsible for latency, performance, availability, monitoring, and capacity planning are excellent software engineers and do not accept doing things manually, over and over again. This also leads to better trust and respect between software engineering/application teams and site reliability teams.
Often big walls exist between application and infrastructure teams. We need better communication and collaboration between infrastructure and application teams. Application code can be a black box for infrastructure engineers. Similarly, application developers often lack the visibility to infrastructure and hence the expertise of writing code that is easy to support and scale.
Better infrastructure skills should permeate application teams. They need to have the mindset of “we build it, we run it, we support it.” Involving application teams in supporting outages leads to more “supportable” code being written and hence better customer experience.
DevOps is often seen from the lens of application development and support teams. Infrastructural skills and infrastructure teams also need to be in the mix.
As an agile mindset gains ground across sectors, almost every organization is trying to explore how it fits in their context. A lot of IT infrastructure organisations are grappling with the same. The intent here is not to prescribe any practice but to understand the foundational principles that can lead to faster value creation for customers.
Breaking silos, better communication and collaboration, and software defined everything leads to skillset transformation and a DevOps mindset are the principles that can effectively lead infrastructure teams to that goal. As in any agile transformation, this can neither be outsourced nor be delegated. Following the LI Quadrant of Agility is a proven pattern for leaders to successfully lead their organisations to the ideal state.
Excellent info, thank you Prateek!
Very well thought out, Prateek. I'd love to hear your thoughts on how to achieve this in an organization, especially in terms of creating the Agile mindset necessary to be able to do the things you mention. That, in my experience, is the biggest challenge to becoming truly agile.
Comments are closed.