The problem with acquisitions? Tying the technology together
Many companies underestimate the full plate of challenges that come with acquisitions. Immediately, those challenges are financial and logistical. Then they become cultural, organizational, and technological. (Hopefully they avoid becoming existential.)
It’s been a banner year for corporate break-ups, but there are plenty of tech companies acquiring, too. You may not be familiar with Aptean, a business software company headquartered in Atlanta, but I recently learned that it went through this process in a big way. The 1,500-person company is the product of a 2012 merger of two firms (CDC Software and Consona) that each had a string of its own acquisitions. When their executives put ’em together, they had a real mess on their hands, said Chris Thornhill, Aptean’s chief architect.
“The result was 30 companies that were really never integrated with each other—never combined into a single company,” he told me. “We had 30 vertically organized separate companies doing their own things, with their own tools. Everything from HR to software delivery and launch was in the hands of the product teams. There were attempts to try and solve that but there was really no interest. The management of the time was focused on quarterly EBITDA and the short term.”
If you’re a seasoned executive, you know how this story goes. When the companies merged, management decided it was high time to rip off the Band-Aid, so to speak, and begin a major effort to fully integrate the companies. It would be drastic: the company decided to focus on just 10 of its 30 product lines, for example. Thornhill was tasked with integrating its technology systems and business applications. Step one, he said, was integrating all of the various reporting and project management systems so management could receive one set of numbers and, with hope, gain the confidence to continue down the path they had laid out.
“You could run reports from each of them but the numbers weren’t defined the same way. A bug wasn’t defined the same way,” he said. “It was a big cultural shift to use the same definition and the same vocabulary.”
The same thing applies to “source control,” the management of engineers’ code. Aptean had at least six different repositories for code, which proved to be a problem. “That’s our intellectual property, our business,” he said. “It needs to be backed up. We need to maintain it. So we moved that to one central location.”
Thornhill said he definitely didn’t want to get the entire company on the same technology stack right away; it would be too disruptive. But he did want to achieve some commonality in an organization where each “silo” was choosing its own technology, from ASP and JSP to Ruby on Rails and Google Web Toolkit. “We wanted the freedom to move developers between products. We wanted to rebalance our internal portfolio and move resources,” he said. “The functional organization was one step toward that, but then we ran into the technical challenge: training people on all these projects.”
For the user interface function, for example, Thornhill chose an HTML5 application development framework from Sencha, a company based in Redwood City, Calif. “We wanted as few technologies as possible,” he said. “HTML5 is pretty damn close to write once, deploy everywhere.”
How can you be sure that one technology is better than many? I asked Thornhill to elaborate. “Why would you buy all the pieces of the car you liked and try to make them work together?” he asked. “It’s going to be ugly and not fit together. When you buy a car, it’s preassembled. All the pieces are made to fit together. If you try and do this piece by piece, you’re going to get mismatches. You have to solve those problems and maintain them. The technologies are all changing and upgrading independently of each other. That’s a challenge.”
And, he added, do you really want to be in that business in the first place? “You don’t want to reinvent the wheel,” he said. “You want to focus on choosing technologies that are already there for you. You don’t want your developers focusing on what they like to do, which is start from scratch.”
Fair enough. I rung up Sencha’s CEO, Art Landro, to get his take. He used a similar metaphor and likened a company’s collection of technologies and business applications to “1.4 million parts in boxes in a warehouse.” Sure, you could put together the teams to figure out how to turn those parts into a fully functioning airplane. But why wouldn’t you just buy one from Boeing and focus on your original business of flying your customers to places?
“It is going to get worse before it gets better,” Landro said. “In my last company, we worked with a major automobile parts supplier. They had 6,000 applications, through multiple acquisitions all over the world. They were trying to get down to 1,000 and they put a five-year plan in place to do it.” He added: “The problem is real and it’s out there.”
Should we be bearish on the value of business applications? Absolutely not, Landro said. They’ll remain a competitive differentiator in any industry. But your engineers are best used to make those applications better, not maintain them. “CIOs and lines of business want to do things better, faster, cheaper,” he said.
Thornhill agrees. “The hardest part is committing to doing it,” he said. “Technology is moving so fast. If you don’t keep up, you’ll be left behind. You’ll just fade away.”
This item first appeared in the Nov. 5, 2014 edition of Data Sheet, Fortune’s daily newsletter on the business of technology. Sign up here.