Escaping the Millstone of Past IT Decisions

I have a problem. You might have the same problem. My problem is this:

At the time when I most need to be fast and agile, I am weighted down by this incredible array of legacy system and application and process complexity. Over the years – and there are several reasons for it – we have built up an amazing collection of customized, redundant, duplicated, non-standard and heterogeneous systems and technologies. I now must navigate a tortuous path through this complexity every time I want to do something innovative or to try out a new business process or business rule or expand into a new or adjacent market. Just when I need to run my fastest, I am dragging around a massive millstone composed of past decisions.

Weighed Down by Legacy Systems Infrastructure

I can give plenty of examples of this millstone. We have several document management systems. Just one of them is comprehensive enough to cover our needs but, rather than using just one, we use a portion of each of them to meet our unique needs (which, of course, assumes we have unique document management needs).

We have a home-grown language translation processing system that requires manual task and language string tracking. With this system, there is a likelihood (a high likelihood?) that we will re-translate verbiage that has already been translated.

Our legacy CRM system came from a market-leading provider but had been so customized over the years that we had not been able to do an upgrade in over nine years (more on that one in a bit).

We had multiple types of storage.

I could go on for years about our in-house developed applications. We had developed them as large, complex monoliths. Even worse, we had confused the user experience layer with the business logic layer and with the database layer. If we wanted to change the business logic of an application, we had to also change the user interface and the data structures. A simple change in the user interface meant revisions to the business logic. And because the applications were large monoliths, those changes to the business logic had unforeseen and not-well-understood ripple effects on other parts of the monolith.

What does all of this do to my agility? It kills it.

But I am not here to criticizing those who built the millstone – I suppose a few years from now someone will complain about what I am building. I want to talk about a path forward and some things I have learned that have helped me increase agility.

IT Agility Strategy

Over the years I have found one thought process that has helped me more than anything else to break apart this millstone. It is the notion that there are only a few business processes, business rules and associated technologies that deserve innovation and uniqueness. For everything else, we simplify, standardize and consolidate.

How do we know which processes, rules and systems deserve innovation and uniqueness? We divide our world into two general categories. The first category is those things that are mission critical and create competitive advantage – these are the things we must do better than anyone else. These are the things that help us win in the marketplace. These are the things that deserve innovation and uniqueness.

The second category is all those things that are mission critical but will never create competitive advantage. These are vitally important and we can never perform these activities poorly – or we will lose the market share we won with the things that create competitive advantage – but these are the things we can do well enough (rather than better than anyone else). The vast majority of our activities fall into this second category.

Let's take a look back to my list from earlier.

• Does my organization create competitive advantage with our array of document management systems? Hardly. So why then should we have a heterogeneous document management environment? Why not standardize to one platform and conform our usage to that standard?
  
  
• Do we win in the marketplace because we created some kludged-together language application? No (in fact, I could make the case that our home-grown language system is well below parity when it comes to translation.) So, let’s replace it with something we buy that we know works.
  
  
• Do customers select us over all of the alternatives in the marketplace because we have a highly-customized CRM system for case management? Even if someone can make the argument that we need to do customer service better than anyone else that does not mean that we need some wacky, customized approach to case management. In our case, we replaced our legacy, complex CRM with a new system that we implemented with zero (yes, zero) customizations.
  
  
• Do we win in the marketplace because we have three different types of storage? No! My customers don’t even know what storage system I use. So, at every upgrade point, we migrated to a single, standard system.

We have taken the same approach to our client-facing applications. Which functions and features create competitive advantage? Only those deserve innovation. For every other piece of code, we re-use, we standardize and we consolidate. In addition to our filtering features and functions based on competitive advantage, we have also broken up our monoliths by breaking them into micro-services that talk to each other via messaging tools. In effect, every micro-service has an API that allows it to connect to all other services. This change has significantly improved our agility as we can replace or change a service without blowing up those around it. Our reliability and performance are much better and some of my teams have been able to get to daily production releases.

Now, all of this begs the question, which business processes, rules and system deserve innovation and uniqueness? To answer that question I ask and answer four important questions. These are:

• Who do we serve?
• What do they need and want most?
• What do we do – better than anyone else – to meet those needs and wants?
• What is the best way for us to provide what we do better than anyone else?

If we honestly answer those questions, we quickly realize that our competitive advantage does not come from things like our storage systems, our case management processes or how we translate languages. We can then focus our innovation and uniqueness where it will actually do good rather than harm. And carrying around a millstone is incredibly harmful – particularly when I need to be fast and agile.