Evergreen Applications: A Myth or Reality?

The business environment is changing at an ever faster pace. As part of this momentum, business teams expect IT to adapt their applications so they can address the latest business conditions quickly. The problem? Most IT departments are unable to respond at the speed the business expects them to, and as a result, people are taking their own destiny in their own hands- no longer calling upon IT. The fact that they may put the company at risk is often not thought of. So, how could we get the best of both worlds and have an IT department that can respond to the pressing needs of the business? Are “evergreen” applications feasible or is it a myth?

Not all applications have the same refresh cycles

First of all, let’s look at the application portfolio. Not all applications have the same refresh cycles and require speedy updates. Some applications actually require stability. In general, I believe we can group applications in three categories. Originally Geoffrey Moore started talking about “Systems of Records” and “Systems of Engagements”. I’d like to add the concept of “Systems of Change,” and in the following paragraphs, I’ll explain what I mean by that. It’s always somewhat difficult to put applications in specific buckets, but different types of applications clearly have different needs. So, let’s look at this in more detail:

  • Systems of Record are the ERP-type systems we rely on to run our business (financials, manufacturing, CRM, HR). They have to be “correct” and “integrated” so all data is consistent. And they were traditionally designed for people who have no choice but to use them. You want them to be stable as they maintain the history of your company. They contain the “single value of the truth”. You will update them when required, but often this is once or twice a year. 10Actually in many industries, these systems are regulated, in some they need to be certified, so regular change is not really on the agenda.
  • Systems of Engagement are systems which are used directly by employees for “sticky uses” – like email, collaboration systems, and new social networking and learning systems. They “engage” employees and I would add partners, customers, suppliers and everybody the company wants to “engage” with. Needs for engagement change as markets shift, as projects start or stop, as relationships evolve. So, regular updates of the systems are required to address the needs of the business. You can argue that email will probably change less often than collaboration systems, and that is probably true, but you’re talking here of weekly to monthly changes. We’re in a different world here.
  • Systems of Change. Software is increasingly part of the products and services companies provide. The world is quickly becoming digital. Over the last year or so we have seen leading companies experimenting in all areas. Marketing departments create variations of their customer interactions for groups of customers so they can see which one provides the best business results. In its quest to identify “killer apps” for the Internet of Things, R&D departments search for services they can provide to users and experiment. These are just a couple examples of how new technologies and the trend to the digital enterprise changes the way enterprises do business and go after new opportunities. What is really important is to be able to very quickly adapt what you propose so you address issues, patterns, deliver new ideas etc. You’re talking about several changes a day.

Where you can argue the current IT departments are set-up to address the changes needed to be implemented in the Systems of Record, you quickly realize they are unable to address the needs of the other two. This is where new approaches are required. Things need to happen much faster. The time span from development to deployment in production should be reduced by an order of magnitude at least. The question is, what should be done?

Create a collaborative culture.

Software developers should be passionate, curious, creative according to supercoders, while operations people should be analytical, problem solvers, focused and driven. Having the two working together is not always easy because of the differences in viewpoint. In design for manufacturing, I highlighted in a previous blog entry, this had been addressed by having R&D people participating in the introduction of new products in manufacturing while production people supported R&D. I would suggest to do something similar in the early phases of the implementation of DevOps as this will lead to a better understanding of both parties and initiate collaboration. It is that collaboration which is key. When making choices, the developers need to think about operations, and frankly, in the traditional world, this is most often not the case.

Collaboration is of the essence to create fast turn around and reduce the development to production cycle drastically. Agile creates a collaborative spirit within the developer community, basically integrating development & testing. Now we need to extend this to the operations teams. As pointed out in “The Phoenix Project”, there are three ways describing the values and philosophies that guide DevOps processes and practices:

  • The First Way, is about the left-to-right flow of work from development to IT operations. It is focused on reducing “waste” in the supply chain. To maximize flows, small batch sizes and intervals of work are needed, never passing defects to downstream work centers. This includes continuous build, integration and deployment. This is where automation comes in. This is where lean comes in.
  • The Second Way, is about the constant flow of fast feedback from right to left at all stages in the value stream, preventing problems from happening again or fast enabling detection and recovery. This is where Kanban plays a role. Stop the production line when something fails and focus on correction of the issue prior to restart.
  • The Third Way, is about creating a culture fostering continual experimentation, requiring to take risk and learn from success & failure, and understanding that repetition & practice are the prerequisites to mastery. It’s all about continuous improvement.

All three are interlinked. Walk through your current DevOps cycle and at every step, ask 5 times why it is done. You’ll quickly understand the activities that are value added and the ones that are not. Ask yourself why you need the latter. This is actually lean 101.

Automate and Standardize

How often are developers re-inventing the wheel, or recreating something that already exists elsewhere in the organization? Often. Part of it is “not invented here”, but a large part is related to the lack of knowing what exists. Both need to be addressed through communication and governance. Set standards and have a governance board deciding over the need for creating new standards. If a developer needs something new, he’ll go to the governance body and argue why this is needed. The fact of having to do that typically eliminates 90% of the so-called new requirements as developers realize they can get away with something that already exists and don’t need to spend effort on arguing their case. Communicate what exist through knowledge management systems, the presence of artifacts in topology designers etc. It will help standardize the deployments, facilitating and reducing the operations efforts required.

And then you’ll have to automate deployment and testing so the cycles become shorter. I always remember a discussion I had with a colleague from our software team a number of years ago when they had just started using automation in their development processes. He explained me that they used to code from Monday to Thursday and then spend Friday preparing the build and running the tests, so next Monday they knew what had to be corrected.

Through the use of automation, once the developers had clocked in their software for the day, a build of the software was automatically started, once done it was deployed in the environment and automated test scripts were run. So, when next morning the team came in, they started by reviewing the test results and took appropriate action. Not only did this allow them to develop 5 days a week rather than 4, but also reduced the time they were coding things around a problem.

Sure, you can take this further and do several builds a day. Depending on the needs of the application this may or may not be needed. Again, be pragmatic here.

Can your Applications be Evergreen?

I believe we have everything in place to ensure evergreen applications if we manage to destroy the dev/ops divide. This requires a cultural change as we discussed earlier. It implies a good understanding of the end-to-end process and forces collaboration. But what are you thinking? I’d like to have your views.

The original post appeared on the CloudSource blog in May 2015.

Tell me what is going through your mind.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s