When doing the 'right thing' isn't the right answer!

By Matt Heller

Having run development, systems operations teams and security teams, I can tell you that getting true agreement is impossible. Fortunately, we only need to reach a consensus to proceed with the business. Even consensus is difficult because each of those technical teams comes from a different place, and they are all correct in their perspective. This issue seems to be exacerbated when it comes to web applications. Perhaps it is due to the more rapid pace of change and the interconnected dependencies, and sometimes it is about control. Whatever the reason is for a given organization, we see the same theme again and again with customers. They have passionate and highly intelligent technical teams debating the best path forward – all trying to do the ‘right thing.’

One of the most common ‘right thing’ discussions is about how to manage competing dependencies around web applications. For example, we have customers that over time have deployed tens of versions of Java. Ignoring the reasons as to why Java has incompatibilities between even minor versions at times, these companies face deciding on a path forward now they have all these versions. There are essentially two main answers – recode and ‘fix’ them all to use one version, or leave them alone.

As an engineer, the ‘right answer’ is to recode and clean it all up. The technical debt costs of maintaining all those versions are high and the systems operations costs to maintain updates involves its costs. Not to mention the security risks with running older versions, etc. So the right answer seems clear, right? Not quite.

Looking at that same issue, customers have repeatedly calculated the costs of recoding all of their apps to rationalize down to a single version of Java. Those direct costs are never below the millions of dollars (or Pounds, or Euros, etc.). Moreover, the indirect costs get added on top of that. What projects CAN’T they do while the business waits for the technical teams to do the recoding? So after spending all that time and money, the company hasn’t advanced at all. They are literally where they were before, with a new year on the calendar and less money in the bank. However, it was all worth it because they cleaned up the technical debt, right? Not quite.

During that recoding period, I can assure you that at least one new version of Java was released, if not more than one, so they are again out of date. That’s the nature of things…there will always be a technology treadmill. Today’s modern and new is tomorrow’s legacy system. It’s an immutable law of technology. Moreover, the business didn’t wait around for the technical teams; they went around them. Now there is new technical debt and a host of new applications delivered outside the IT organization.

When we have this conversation with customers, we invariably get the asked ‘so you’re telling us to do nothing?’ Not quite. We believe you should very much attack the problem, but do it in a more business and technically advantageous way. We believe you should balance the development, operations and security technical issues in a way that mitigates the risks, effectively reduces technical debt AND avoids systems operations support costs. This approach allows the business to get the best of both worlds – they resolve the issues while not creating new ones. It’s not easy and requires teams to reach consensus rather than agreement.

By taking this managed approach the business will thrive and move faster as they proceed to the future. Using this process enables flexibility by removing dependencies and associated limitations, allowing the organization to make decisions based on business needs rather than technical limitations or required dependencies. So the solution isn’t just limited to Java or a single use case. Our customers are leveraging this approach over and over to manage – and control – change in their organizations. The result is repeated cost savings, unimpeded technical deployments, and rapid product rollouts.