I think we all have a problem. And it is potentially a huge problem.
The pace of technology change today is crazy fast. About four years ago, my team developed bleeding-edge, earth-changing customer analytics using bleeding-edge, earth-changing technologies. Today, no one in their right minds would use those same technologies -- the world has moved past them and on to better tools. All in just four years.
In the 2016 Forbes CEO survey, 77% of the CEOs expressed concerns about their organizations being able to keep up with the pace of technology change and 41% said that their organizations would be significantly transformed by technology in the next three years.
These data points set the stage for what I think is our problem: At a time when we most need to be fast and nimble, we are weighed down by an incredible array of legacy system, application and business rule complexity. Over the years -- and there are several reasons for it -- we have built up an amazing collection of customized, redundant, duplicated, nonstandard and heterogeneous systems and technologies. We now must navigate a tortuous path through this complexity every time we 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 we need to run our fastest, we are dragging around a massive millstone built on past decisions.
I have plenty of personal examples of this millstone:
Our legacy CRM system came from a market-leading provider but had been so customized over the years that we were not able to do an upgrade in over nine years (more on that one in a bit).
We used multiple types of storage.
I could go on for years about our in-house developed applications and their inability to keep up with the pace of technology change. We developed them as large, complex monoliths. Even worse, we 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 also had to 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 brought 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 don't want to focus our time together on criticizing those who built the legacy 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 keep up with the pace of technology change. I want to help your IT organization from getting crushed by the pace of technology change.
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 learn that by dividing our world into two general categories with one thing in common: They contain mission critical technology.
The first category comprises those things that are mission critical and create competitive advantage -- these are the things we must do better than anyone else. These are processes, rules and systems 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 also the things we can do well enough (rather than better than anyone else). The vast majority of our activities fall into this second category. Perhaps we can look back to my list from earlier.
CRM replaced: 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.
Storage standardized: 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.
Client-facing apps revitalized: 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 reuse, 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 microservices that talk to each other via messaging tools. In effect, every microservice 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.
Going fast: Four questions
Now, all of this begs the question of which business processes, rules and system deserve innovation and uniqueness? To answer that question I ask and answer four important questions. They 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.
About the author:
Niel Nickolaisen is a veteran IT leader, currently serving as the CTO at O.C. Tanner Co., a Salt Lake City-based human resource consulting company that designs and implements employee recognition programs. A longtime SearchCIO columnist, Niel is a frequent writer and speaker on transforming IT and IT leadership.
Watch these videos for Niel's advice on de-customizing ERP projects, developing a risk-based IT security strategy and two approaches for developing mobile apps.