Interview

Why is modernization so difficult?

Shawn Livermore:

Right - so it’s definitely one of the most challenging things for companies to do. Because - from what we have seen - the reality for our prospects and clients is that the narrative of many organizations’ IT footprint is a story of growth under fire. Most companies’ stories are remarkably similar. They will tell you that what began as a very simple and very effective software and database solution for a growing company has now devolved into an enormous, complex web of integrations between software, databases, web services, and file exchanges. And of course, it gets even more complex with each year that goes by, adding new employees, losing existing employees, the code gets touched by so many different people, and, of course, partnering up with other firms and vendors that require certain formats and certain technology to be in place… So really, it’s just, a never ending battle to protect the centrality and the quality of your inner workings, not being swayed by every force of nature that comes in contact with that braintrust that maintains the core intellectual property of your organization so it’s really all about that existing internal IT footprint, and all the applications that sit in place. If those apps and that data are well-maintained and thoughtfully put together, you’re pretty much going to be OK with any sort of integration conversation. And of course, modernization is much more straightforward. But as soon as that begins to sway, It’s very difficult to bring it back into alignment. And so, let’s talk about if it was not well-maintained, and if it was not well-formed. If it was conjured together, piece by piece, and included some bad decisions along the way, or some failed integrations or specialized technology or software that has become obsolete or unsupported. This is when your infrastructure begins to fall apart, and some heroic efforts from the key developers are necessary to keep everything together.

"...some heroic efforts from the key developers are necessary to keep everything together."

And of course over time, it seems that those heroic efforts continue and repeat themselves more and more - unfortunately - so you will find yourself in a sticky situation if some of those hard decisions to modernize are not made early on and - throughout the process actually. Every few years there are some of these key upgrades and carefully thought-out projects that have far-reaching implications into the future, and those are what drives up the difficulty level of the eventual modernization effort, because it’s all those spaghetti integration and connection points. Those are the pain-points that drive up cost and make the modernization conversation nearly impossible.

As a part of the process of engaging with clients, what are some of the early conversations that take place with C level executives as the pontificate modernization?

Shawn Livermore:

So with the C-level, we will often discuss what you’d expect… budgetary constraints, previous efforts toward modernization, any frameworks they may prefer for how to even approach the topic, because for some organizations, this is a massive undertaking that could take 5 to 10 years to complete and tens or even hundreds of millions of dollars. So the stakes are high. And then the general temperature of the board of directors comes into play. What does the board want to do? Who is advocating for modernization and how does ownership see the situation? etc.

But at the VP and director level its a little more involved. We talk about the key software applications, the critical databases involved, all of the integrations between vendors and partners, and what systems are systems of record versus downstream applications. A lot of times we are told to stay away from certain applications, and not worry about certain areas of the organization. Then later, we often will learn that those applications and data areas were actually pivotal in critical to the entire story of modernization and should’ve been looked at in the first place. There’s a lot of storytelling happening, exposing the rationale and logic, behind certain decisions, and as you dig deeper and speak with some of the boots-on-the-ground developers, you find the story changes quite a bit, and they have a whole different perspective and will surface so many other factors that had been a part of those key decision-making moments. So the executive-level dialogue, of course, is quite different, and often executives are not even fully aware of the entire story, and were told information by their mid-level management, that proved to be vague and not the full reality of the situation. So there are certain times where that becomes an opportunity to help clean-up the history of events, clarify and retell the story and that allows management to make some better informed decisions about what to do from where they are today.

If you could break it out into ‘pillars’ of thinking or the core concepts of the debate around modernization, how would that shape up?

Shawn Livermore:

Sure. So the key pillars or elements of any sort of mental model would probably include primarily the drivers of modernization first. What are the drivers? Is it primarily cost? Or is it obsolescence? Usually it’s those 2 together. An old mainframe is at the center of so many large organizations’ IT footprints, really it’s astounding how common this situation is. The conversation repeats over and over. If we had to plot this out in to a 2x2 set of quadrants, I would mark this on the right side, for “rational” or “logical”. That is - it makes a lot of sense. It saves the company money to modernize based on cost savings and obsolescence. They can’t run that old mainframe forever - that’s reality. 

"They can’t run that old mainframe forever - that’s reality. "

Then we have the pillars that are on the left side of that matrix, which I would mark as “fear” or “irrationality”. That side is an entirely different set of narratives. This is where so many conversations are seated with emotion or scarcity or precursors, or any sort of presuppositions that will instantly steer decision making or corner options into only a couple of possible directions. This is where the culture will drive the outcome. And that’s where it’s really critical to have a third-party come in and help because they are not drenched in culture. They are completely separate from it and that can make all the difference in the world - given the fact that leaders of so many companies make decisions half the time based on attitude and culture, rather than what is rational and logical and fiscally responsible. So mapping it out this is truly where are you find yourself is trying to push the conversation toward the right side of the spectrum, where objective decisions can be made, and leaders don’t get caught up in fallacies, like sunk cost fallacy or cognitive biases of all sorts.

Let’s drill some more into the fear pillar. How does that really play out and how does that process of disarming it work?

Shawn Livermore:

Right well, it’s just human nature, we sort of naturally just tell stories about everything. And fear is often  one of the drivers of so many stories. So they will say words, like we can’t do this, or we must not do that… They will couch the project, so tightly, that there’s not much analysis allowed. So you often find yourself cornered into very specific parameters before even performing discovery, and this becomes problematic. So we really often will have to find ways of reverse engineering the situation, and helping them to broaden the horizon a bit before engineers can offer the maximum amount of value to the company and to  the initiative. 

So yes, the fear issue is very real and I think it also stems from the common situation, where those who sit in the senior executive positions, do not rise through the ranks from engineering roles. And, because they don’t have a technical hands-on background with software or data, and are not necessarily hands-on - because of this they are not as comfortable jumping right into the more detailed discussions and so they will lean on a high-level synopsis of most situations. That layered So they’re not really dialed in and they don’t really understand and because of that they trust advisers to give them whatever the minimum amount of information is that they can tolerate to make that decision. So that can drive some outcomes ultimately.

For the senior executives you work with, are incentives aligned? That is, are we seeing executives properly incentivize towards the 10 or 20 year objectives of the company?

Shawn Livermore:

That’s a tough question because it’s really not our role to address or analyze an executive’s incentives. We are there as a value added partner to come alongside leaders and help shape the direction of their tech stack and help modernize some of those hard-to-reach applications and systems. But yes the issue of incentives is very real - and bonuses or earning contracts are a part of that. Sometimes it can become a conflict of interest to suppress what needs to be done and what needs to be spent on infrastructure and application modernization in exchange for a good year of profits.

Psychologically, how does the shift take place to re-orient the business? Is there a watershed moment typically? Or is it gradual and incremental?

Shawn Livermore:

Usually it’s gradual and something that everyone knows is going to be needed someday. But yes, I think there are often some key, breaking moments that cause executives to fire-up the conversation on modernization to replace that old mainframe or rewrite that old software application that everyone complains about. It might be a budget planning session that reveals increased spending on mainframe licensing, or maybe a random unexpected system outage in the night that causes people to ask the harder questions and poke at the causes of the downtime more and more. Or I have seen it where a new board member or new executive that joins the team starts asking questions, and the issues reveal some dysfunction or avoidance… the issue has been swept under the rug for literally years. So it varies widely between clients but ultimately it feels like the conversation is danced around for a while before it’s finally engaged.  

And you know what’s interesting is that once it’s engaged, it’s a process that looks really familiar over and over again. The budget gets looked at first, then the actual work. When in reality, it should be the other way around. The actual work should drive the cost and not taxation or budget expectations or anything else. This is a trap. Because the moment you set the budget without unpacking and fully understanding the entire scope of work involved, you’re setting the stage for disappointment or perceived missed targets. Once numbers start being thrown around to the board, it’s impossible to get that out of their minds. They’ve been told one thing and now it keeps changing. So this process should be performed in a particular order and in alignment with fact and reality and not conjecture or guesswork.

What is a great example of a company that invested and modernized their mainframe system and came out the other side to a far more capable and for more efficient software application footprint?

Shawn Livermore:

I remember reading about Delta Airlines and how they had a mainframe that was about 40 or 50 years old. Sometime after 2010, they decided to modernize the mainframe and brought in some help. It was actually quite an involved process because they had a distributed system architecture. They had to go back and rewrite other supportive applications that would interface with the mainframe or touch the same data as the mainframe. So it was pretty involved, and they spent a good amount of money getting it all fixed. But ultimately, they were able to reduce their use and dependence on the mainframe by around 50%, which, in the grand scheme of things, for a company of their size, was a massive cost savings within their IT budget and gave them brand new opportunities to deploy modern apps in their core line of business. As a result, they increased their ability to satisfy the customer ultimately. Their call center was seeing a lot better numbers, flight attendants were happier and personalizing their engagement with customers, and flight-based services were improved. So many parts of their business were instantly modernized as a result of that hub being fixed. And that’s pretty much how it always works. If you fix the core route of an organization's IT footprint, you really have your hands around it in a heartbeat. You have surgical access to the inner workings of the patient and are able to instantly improve the entire business. 

"By modernizing our technology infrastructure, we're taking advantage of the latest technology to improve our customer experience, drive efficiencies and grow our business."

Richard Anderson, CEO, Delta Airlines

So we talked about budget, fear, narratives and stories,... How do you attack these psychological barriers? 

Shawn Livermore:

Well, it’s always through partnership. Ultimately, we try to be an enabling arm for our clients. We're effectively helping them dig out the details and retell their own story. We trace back their steps to decades ago in some investigative journalism and reconvene with key subject matter experts to siphon out the key decisions and moments. And that’s probably the hardest part - even harder than the technology itself - because you’re dealing with the psychological connection points and mental barriers that people are quietly grappling with.

Overall, it’s a journey of details, and that detailed process has to play out thoughtfully and in accordance with the client's expectations. And some clients simply do not want to hear the answer quite yet. They want you to go and do the digging and feel the pain and understand the gravity of what cages or constraints they’re having to work within. And that’s totally acceptable for us. We are happy to engage at that level as there’s so much good that can be done in partnerships that allow us to become deeply invested and deeply ingrained in the culture of the firm we’re working with.

So, to answer the question, I think it’s a bit of procedural caution and staggered layers. Providing the details in waves, contextual to the research and the investigative efforts of the analysts and architects on the team, to uncover all of the shadowy applications, databases, systems, and complexities. It’s in those conversations and those intricacies that we find a lot of the answers. But many times they want us to find them ourselves and not be told the answer at the beginning, so it’s a bit of a confirmation step for them. They want to be assured that we fully understand their systems before we go and help modernize.

‍