Know the Business Case for Rearchitecting

Today, it’s pretty normal to write new applications in a “cloud-native” way. Whether we deliver to a public cloud or use a container fabric behind the firewall, we commonly work with microservices or serverless. A data store is as likely to be block storage or Mongo as it is a traditional database. This makes sense. Small components match well with DevOps teams operating independently (see Conway). In general, modern architecture, infrastructure, and delivery approaches support more frequent releases and more resiliency in production. All good things.

However, most apps are not new. A typical enterprise can have many hundreds to a couple of thousand existing applications. Do they sit as they are until replaced? Do we rearchitect them all? Will some move? And if so, which?

As you embark on a program of application modernization, I suggest taking an economic approach to deciding which applications (or parts of applications) to modernize. The first questions are for “the business” and are about speed and business agility. If, today, we can release changes quarterly, does that hurt us? What value would you see from being able to introduce small changes within a month, or a week, or day? Do we have a problem with outages or downtime that would be worth investing in at the cost of features? Understanding the value of more agility helps identify the kinds of changes that might be required, which you can then begin to consider the cost of.

Paul Hammat has done great work examining necessary changes as you accelerate from Quarterly to Daily releases. In short, everything. I’ve expanded on his work in the graphic below.

One thing that’s clear is that to move from quarterly to monthly releases, architecture and infrastructure don’t really need to change. A little bit of Agile development and some basic continuous delivery automation can go a long way – especially with automated tests.

Once you are moving faster than releases every week or two, you really need to have decoupled microservices running on programmable infrastructure (cloud).

Modernizing Part of an App and Our Story of Doing It

An effective modernization strategy is to employ the “Strangler Pattern” to incrementally move from old architecture to a new one. Generally, the parts of the application that are going to most benefit from the new approach are targeted first. The team carves functionality out of the existing system, moving into new microservices. They create an API boundary between the old and the new. This process is repeated until the old is gone and the new system is just microservices communicating by API.

For some larger applications, the economics tell us it makes sense to stop part way. One part of the application runs cloud-native and potentially in a public cloud and another part running as it had been. With an API boundary, that is acceptable.

I lived this approach about ten years ago. At the time, we were selling UrbanCode AnthillPro, a continuous build and deploy tool. Anthill was on-premises enterprise software that customers hated to upgrade. We would release every month or two and customers would upgrade once or twice a year.

In the CI/CD space, you need a lot of integrations with other tools like source control and testing as well as targets to deploy changes to. For a new product in the space, this caused a challenge. Every customer you would try to sell would have something new to integrate with and that would require a new code and a new “release” of some sort that the broader customer base didn’t want. Or while you waited for the normal release cadence, the customer would move on and buy from someone else. That stunk.

So there’s the business pain: a real lack of agility where it mattered caused by a monolithic architecture. So what did we do? We put the code that handled different categories of integration behind APIs, and pulled the integrations themselves out into small self-contained packages.

For us, part of architecting for speed was shifting that code from Java to Groovy in order to avoid requiring compilation. Now one of our team in the field could fix a bug on the fly while working with a prospect, or have an easy copy and paste baselines for building a new integration. We could build a new integration in the field and our competition couldn’t. Not only did that give us the ability to win deals by “having” an integration, but it also showed how our customers could extend the tool. Existing customers also benefitted. They could take updates to integrations without having to do a full upgrade cycle. That’s a good business outcome for a couple of man-months of development. In our modern tools, like IBM UrbanCode Deploy, we now have over 200 of these plugins and an open source community for creating more.

Don’t Leave the People Behind

Architecture and packaging were a big part of this shift, but it is a world where “everything” has to change. Each integration has a building job and needs to be tested and released. As an element that works differently than the core, we found that splitting off a slice of our development team to work on these makes sense. They are more likely to reprioritize work to quickly fix, update or create an integration that developers working on the next big core feature. While the core team might work with sprints moving towards significant release dates, the plugin team took more of a pure Kanban approach to handle being more interruption-driven.

Did we continue to strangle the monolith? Not really. The business case wasn’t there for other elements of the product. But our newest offering? You bet UrbanCode Velocity was written cloud-native on containers.

Moving Forward

In an enterprise with hundreds of applications with many interdependencies, any modernization is going to feel partial. Whether it is part of an application or an application that is part of a larger system, the challenge is to look at what the business needs from technology and make sure the architecture, infrastructure, toolchains, and process line up. Find those places where the value is high and the cost is tolerable. Those are your wins.

My IBM colleagues are here to help, too. The Cloud Garage team brings a ton of modernization experience to our clients and there are also tools like IBM Transformation Advisor which can look at a Java app and quickly suggest how easy it would be to run it in a container (and what work you need to do to get it there).

Talk to the business to understand where speed matters and how much is needed. From there, pick where to invest in modernization and where to muddle through.