DevOps and Appification

These days the typical enterprise organization has dozens and even hundreds of apps that it creates and maintains. In this article we’ll discuss how we can apply DevOps principles and practices to such a large portfolio of apps.

The typical enterprise organization has a number of apps to aid employees, customers, suppliers, etc. There are apps for executives, middle management, and everyone else to do their every day jobs as shown here.

Some of these apps are purchased from COTS solutions or developed inhouse. For those that are developed inhouse a question I often get is ‘how can we create Agile teams for each one of these apps?’ It’s a good question given that most apps are brownfield apps and don’t require much maintenance. Also, organizations don’t have infinite resources to create Agile teams for each app as that would be impractical and obviously expensive. Plus, who wants to work on an app that is only changed twice a year?

A core principle of Scrum is for teams to be self-organizing and self-managing. The Feature teams that work on Visual Studio Team Services (VSTS) at Microsoft divide themselves into two sub-teams: 

The F-Team works on committed new work while the L-Team deals with live site issues. This is a great strategy because it allows the F-Team to focus on new features while the L-Team deals strictly with live site issues.

So what about organizations that have appified with dozens or even hundreds of apps? A very simple solution to this problem is to create Agile teams for the apps that are new (greenfield) or actively being developed (greenfield and brownfield). For the remaining apps that are in maintenance mode you could simply have the Agile teams also maintain them too. However, this is problematic because we want to shield the active Agile teams from having to do context switching and from the interruptions that can occur when a new feature is requested for the low activity apps. Imagine an Agile team that is working on a greenfield apps and many brownfield apps. It would be chaotic to say the least, but I find this practice is common because of the misapplication of DevOps principles. This is a perfect example of breaking the first law of System Thinking: Todays’ problems come from yesterday’s solutions.

The end result would be, for example, a small number of Agile teams that focus on the active apps and perhaps one Agile team to work with all of the low activity apps. This approach would also mean that we don’t have to spin up Agile teams for each app which would save money. This team would simply focus on keeping these apps up and running using DevOps principles and practices. Another benefit of this approach is that you could have the individuals on the active apps rotate every now and then to the low activity apps so that they could get a sense of legacy systems and visa versa. 

By simply following DevOps principles and practices, we can make a huge impact on our organization's ability to help us be more productive and less overworked by having to maintain multiple apps on our Agile teams.

Feel free to comment below.