Peter Sayer
Executive Editor, News

DTN’s CTO on combining IT systems after a merger

Feature
Jul 15, 2022
AnalyticsData Management

To successfully merge IT systems after an acquisition, ask the right questions before doing the deal, and build the team before building the application, says Lars Ewe.

Lars Ewe, CTO, DTN
Credit: DTN

DTN is more than just a weather forecaster: It also offers decision-support services to companies in agriculture, energy, commodities, and the finance industry. Its weather-related services can be as simple as helping utilities predict short-term demand for energy, or as complex as advising maritime transporters on routing ocean-going cargo ships around developing storms.

Over the years, DTN has bought up several niche data service providers, each with its own IT systems — an environment that challenged DTN IT’s ability to innovate.

“We had five different forecast engines running in the company through various acquisitions,” says Lars Ewe, who inherited the thorny IT environment when he joined as CTO in February 2020. “Very little innovation was happening because most of the energy was going towards having those five systems run in parallel.”

The forecasting systems DTN had acquired were developed by different companies, on different technology stacks, with different storage, alerting systems, and visualization layers.

“They had one thing in common,” jokes Ewe: “They all were trying to predict the weather!”

Working with his new colleagues, he quickly identified rebuilding those five systems around a single forecast engine as a top priority.

The merger playbook

Enterprises often make strategic errors when combining IT systems following an acquisition, Ewe says. “The number one mistake I see is, ‘Since we acquired you, clearly we win,’” he says. “Just because A bought B, you don’t want to assume that A has better technology than B.”

Another common mistake is to go solely by the numbers, picking one company’s IT system over the other’s because it has the highest revenue or profitability, he says: “The issue there is that you’re oversimplifying the process.”

Given the investment in time and money necessary to merge two companies’ IT systems, “it’s worthwhile spending an extra few weeks up-front to make a more thorough analysis of which solution or which pieces of which solutions should come together,” Ewe says. Jumping straight in and making a wrong decision can cost more in the long term.

Ewe consulted with product and sales management, and with customers, to identify the needs DTN’s single engine would have to satisfy, as well as the use cases it would serve, before evaluating the existing assets against those needs. He had other requirements as well, including that the system should run in the cloud. To ensure the success of the decision-making process, Ewe brought together the staff who were running each of the forecasting systems into one team.

“You’re starting with five teams, and everyone thinks that their baby is the best baby, and the other babies are all ugly. It’s natural,” he says. Also natural, he adds, is fear among IT workers that their employment is tied to the continued existence of the system they maintain.

To combat that, Ewe emphasized the potential for growth from the start. “We have so much opportunity here that there’s more than one solution where we can apply their talent,” he says, noting that there would be plenty of work building analytics and insight tools around whichever forecasting engine was chosen.

A succession of team-building exercises helped develop a trusted environment where staff saw themselves as part of the larger whole, in which they were willing to discuss the disadvantages of the system they worked on, as well as its advantages. This enabled the team to select one engine to carry forward and to identify capabilities that the other engines offered that DTN should consider reimplementing in its selected platform, Ewe says.

For example, Ewe didn’t want to lose the data those other engines worked with. So he had it all cleaned up and consolidated into a common store. “Historical data is very important for weather prediction because it provides a feedback loop into the models,” he says.

DTN staff did much of the implementation work. “I am a firm believer in in-house resources. They’re just more motivated; they have more incentives to make things successful,” he says. “When you think about what skill sets do you need, it’s a broad spectrum: data engineering, data storage, scientific experience, data science, front-end web development, devops, operational experience, and cloud experience.”

DTN did rely on external help in building the high-performance computing infrastructure in the cloud, partnering with Amazon Web Services: “They realized that there was a real market for high-performance computing in the cloud, and they wanted to find a partner that actually had clear requirements, a clear mission and clear knowledge of high-performance computing,” he says.

The results exceeded Ewe’s expectations, doubling the throughput of the forecasting system to the point where DTN can now run global models hourly. “In fact, we don’t even schedule them. Usually these systems are batch-driven, they’re scheduled, and we’re now event-driven: When underlying data changes in a meaningful way, we kick off a new model compute. That is sensational.”

Tuning for the customer

Ewe had to encourage other cultural changes in the team, beyond uniting it around one forecasting engine. “I had to help everyone understand that this engine we were building was just the underpinning of larger solutions that we were trying to build on top of that,” he says.

With access to easily scalable supercomputing resources, there’s a temptation to crank up the accuracy of the forecast model, but, as Ewe says, “You have to ask yourself, ‘Is what I’m now optimizing even having an impact on the consumption side?’”

In other words, is the output of the forecasting model good enough for customers’ use cases? That’s a tricky question, but easy to answer with the right data, he says: “You often can simulate it: If I were off by a half a degree, what impact would that even have on the ship routing algorithm?”

Forecasting merger success

Some post-merger IT challenges could be avoided — or at least more easily planned and budgeted for — if IT weighed more heavily in the negotiation process leading up to an acquisition. But getting a seat at the merger negotiating table is a challenge for IT leaders: Such discussions are often conducted with the utmost secrecy.

At DTN, says Ewe, “We have a sophisticated due-diligence checklist for technology. There’s a lot in there, but it gives us more visibility up front of what it is that we’re trying to merge or integrate.”

Among the areas the checklist invites the negotiating team to consider, he says, are the talent, “because you are buying people just as much as you’re buying technology,” and the interdependencies of the IT systems, to get a sense of what is required for the merger to work.

“If you’re not part of the process, then you are at least represented through a mechanism, a process,” he says.

After going through the process a few times, CIOs should have the data to demonstrate how important a good IT match is in a successful merger, Ewe says, “and hopefully earn a seat at the table.”