Some people might think that agile and infrastructure is an oxymoron or at least the “odd couple”. My task is to try to at least get you to think there is something in this “agile infrastructure”. For those of you working in infrastructure, you may be thinking Agile is for development teams and not us. Others may be thinking we already supply the right services to the business, so why do we need to be Agile? Others again may be thinking we already treat our infrastructure as code. A few of you may have implemented a DevOps program, and I hope you will all get something out of this piece.
What is Agile Infrastructure? Many answers to this question, depending on your point of view, ranging from DevOps to resilient operations to delivering to the customer quickly to cloud to applying agile methods to infrastructure products. My view is that there are aspects of all of this when creating a truly agile infrastructure and is multi-layered. This may seem like fence sitting but in the end we are trying to deliver a reliable product to the customer for a risk appropriate price, while delivering business value. If it is not delivering business value then why are you doing it (a subject for another post)? Delivering something the business values, especially in the infrastructure space is difficult as the majority of infrastructure is hidden under layers of other ‘stuff’. The most visible aspects are generally only thought about when they go wrong or the access disappears; the cry of “the network is down” when generally it is not the network, but access to it. One has to remember that in the eye of the consumer they ARE one and the same thing.
So what do we want Agile Infrastructure to do? Agile infrastructure needs to ensure the following:
- Deliver business value overall
- Enable change that works frequently
- No downtime due to change
- Reduces complexity
- Makes everyone heroes not just a few individuals
- Versioning of the infrastructure
- Process driven
- Address resistance to change
- Predictive and proactive maintenance and monitoring
The multi-layered agile infrastructure provides most of the answers to the above except for the money to implement! But if you can show the business benefits of delivering the above and make small changes that start to show benefits, then you can gain credibility to deliver on bigger slices. Just remember that it is a journey and not a once off program.
The layers are my interpretation of what it takes to deliver on agile infrastructure. Feel free to add your comments and challenges. My message to the infrastructure teams is that agile infrastructure is more than the infrastructure/operations teams, and needs to embrace their customers who are generally project/developer teams.
All the layers need to work together to deliver Agile Infrastructure overall. A break in any one of these layers will deliver a sub optimal result – the sum of the whole is much bigger than the individual parts.
This is probably the hardest area as it involves people change. Unless the change happens from the top and is supported the change will fail. Parachuting in Lean/Six Sigma/Agile experts will not work as skills transfer does not happen easily. In this case projects will be completed but understanding will not come. Look to train the trainer and embrace agile/lean activities in the everyday work routines of the organisation.
Development and infrastructure needs to be seen as parts of the whole, not separate entities. The architecture and design of applications must facilitate delivery into production. This includes understanding the operational impact at the concept stage, and ensuring the business intent of infrastructure needs remains without interference from project budgets with business agreement. Deliver the needed infrastructure sooner via the development teams, and migrate both the infrastructure and application though the delivery process.
The agile operations team moves from firefighting to a ‘customer centric and getting things’ done approach. This usually necessitates changing the operating model, breaking down existing silos and creating smaller cross functional teams. Identify and document the operations processes, apply lean principles to remove unnecessary waste, and then finally automate as much as possible. Development teams need to understand and allow for the, at times, unpredictable nature of operations incidents. Drive resilience into the day-to-day operations as well as the products coming into the production environment.
So what do I mean by agile technology? The most obvious choices for agile technology are virtualisation and cloud (in its many forms, but one could include SDN and virtual storage). Anything here that takes way the need to physically or individually configure items and deliver as required (not withstanding that underneath there is physical hardware). Look to create and own the continuous build servers, test servers, and version control servers to foster the link with development teams.
So we have some agile infrastructure methods and agile infrastructure practices, now you have to add the last part of the secret sauce – create your set of agile infrastructure principles that are relevant to your organisation and your organisation culture. Good luck!