At Greater Risk for an IT Disaster?
According to the Harvard Business Review, 60 percent of all mergers and acquisitions (M&A) end up destroying shareholder value. While much of this failure is caused by a strategic mismatch between the two organizations, smooth integration of the operations of the organizations – especially the IT infrastructure – is also critical to the long-term success of a merger.
The airline industry offers a case in point, where customers, regulators, and industry analysts are left wondering if the string of well-publicized IT outages that left thousands of passengers stranded are a side effect of the long line of airline mergers. American acquired TWA in 2001; US Airways merged with American West in 2005, and then with American in 2015. Delta merged with Northwest in 2008; and United merged with Continental in 2010. Five years after its merger with Continental, the Wall Street Journal reported that United’s struggle to merge operations was at the heart of an outage that grounded planes and passengers in the peak summer travel season.
Can a merger or acquisition leave companies at greater risk for an IT infrastructure-related disaster? A majority of IT disasters are driven by problems within an organization’s IT infrastructure, so it makes sense that integrating two disparate IT infrastructures will bring an added risk of infrastructure failure. What, then, are the best ways to mitigate those risks, and how can an organization recover quickly when and if it does happen?
High Stakes, and Three Basic Choices
Mergers and acquisitions are high-stakes events. Jobs are on the line. Careers can be made or broken. There is a time pressure to show returns on investments quickly, and it is probable that the IT budget is not going to increase, so there is budget pressure as well.
When undergoing a merger or acquisition, those individuals managing IT operations have three choices:
- Keep it separate. Run the IT operations of the two companies as separate systems and keep them isolated. This approach hinders companies from achieving economies of scale – one of the main business cases for entering into M&A. It is more of a holding company with two separate streams.
- Choose best of breed. Perhaps Company A has a better CRM system while Company B has better back-end systems. Evaluate the portfolio of applications supported by both companies and select the best systems from each to create an environment with the best of both worlds.
- Rip and replace. View this as an opportunity to build a whole new system, replacing the systems of both companies with a completely new one.
Typically, companies move toward the second option, but the decision of what path to take depends on the company’s business strategy and long-term goals, as well as the circumstance of the M&A. While expensive and rare, a company that plans to grow through a series of M&A may choose to replace its existing systems with a completely new system that will allow for several integrations over time. In a leveraged buyout situation, where there is pressure to show the ROI as soon as possible, companies may opt for the best of breed option. Companies also need to consider how their choice will impact stakeholders such as customers, partners, and employees.
Adding Complexity, Adding Risk
A best-of-breed approach adds a level of complexity to an IT environment that introduces potential points of failure. The approach involves integrating existing systems with new and unfamiliar systems that are not necessarily designed to work together. There is a difference between building a completely new system from scratch, where there is full visibility into its compatibilities and dependencies, and working with an unfamiliar system. No matter how carefully you architect the new infrastructure, the lack of familiarity with the new system’s dependencies and compatibilities presents a major risk to a successful integration. Every implicit assumption made by the original developers lays like a land mine, waiting to blow up when least expected.
For example, Company A may have built a backend database, and it is performing as required, handling the traffic from Company A. However, adding in the traffic from Company B may take the database beyond its capacity to scale, because it was never designed to go to that level. Things can be tweaked to fit the new workload, but the database is likely to be susceptible to performance issues as the traffic grows or if there is a sudden burst in traffic.
Adding Disaster Recovery to the Mix
You also need to consider how the integration of IT systems and applications will affect disaster recovery (DR) plans, and it should not be an afterthought. It is crucial that companies take a new and holistic look at their DR plans, or else they risk not having a fully recoverable system at the end.
If you are pursuing a best-of-breed strategy and are integrating systems from the two companies together, you can no longer look at them independently. You cannot have a DR plan for systems from Company A and a separate DR plan for systems from Company B because there are probably new system dependencies that you did not have before. Best practice is to completely remap the systems, with all the dependencies, to ensure that you have a DR plan in place that will recover the full IT environment.
Application Dependencies Are Key to a Successful IT Environment, Post Merger
The ability to understand and map the interdependencies of underlying systems, and then tier applications based on their potential business impact is critical to business continuity. It is hard enough when you are designing an IT environment from scratch, but doing it during an M&A process is far more difficult and even more critical. As you tie together systems from the two companies, you now have parts of the infrastructure applications talking to each other that were never designed to in the first place.
And here is the tricky thing: you cannot rely on the documentation of these dependencies. The reality is we do not always document things the way we should. Often, applications are moved ad hoc from one system to another to balance workloads or for other reasons, and people often forget to document the changes. This becomes even worse during a merger or an acquisition, when the pressure of time and board-level focus on results makes it all the more likely that people will take shortcuts that will ultimately bring more risk to the infrastructure. This is why a down-and-dirty hard-target search is necessary to map applications and systems as they exist in the real world.
As an example of how critical it is to fully understand the interdependencies of all applications and systems, there was a company that recently underwent a full restoration at a remote location after a disaster. The recovery was a near total success, with virtually 99 percent of the systems up and running successfully. Everything was recovered except for one single system. And it turned out that none of the users could log in. The company had overlooked one crucial part of its infrastructure in the recovery plan – the active directory (AD) server. Despite the company’s nearly flawless recovery, it was as if the company had not recovered at all, because none of the end users could actually access the applications.
Testing Reduces Risk
M&A often results in an IT environment that is far more complex than the company is used to, making it much more likely for systems to fail. The more you plan out the integration, and the more you are able to test it to iron out issues before you go live, then the fewer problems you’ll have afterward. Testing a system before it goes live will help avoid the pain and embarrassment of fixing a failed production system after it is made available to the public.
The same holds true about testing any DR plans. There are many companies that would never dream of putting an application or system into production without testing. Yet when it comes to DR, people are very willing to skip testing and take the risk of trying to figure it out when disaster happens. The complexity of an IT environment post M&A makes it much more difficult to fully recover from a failure. Having a fully integrated and thought-out DR plan is a first step. Testing it thoroughly to ensure that it works, that nothing has been left out, and that everybody knows what they are supposed to do will give you a fighting chance at a complete and successful recovery.
Plan for the Long-term, and Follow Through
The key to successfully managing an IT environment through a merger or acquisition depends on three things.
First, what is the organization’s long-term plan? Is this a one-off acquisition, or is it the first of a larger series of acquisitions? While cost reduction and economies of scale are almost always a factor in a merger or acquisition, the approach to merging IT environments must be aligned with the strategy of the overall organization. Think carefully about the long-term goals and build a plan to get there. While time is always of the essence in an M&A, keep in mind that every shortcut taken now may have long-term implications.
Second, if you are building a phased approach, then make sure there is follow up on the future phases. It’s easy to do something “temporary” in order to get working on other priorities, but if you never return to implement a more permanent fix, then the temporary expedient becomes a potential risk for failure. The other thing to keep in mind is potential dependencies. Is everything done “quick and dirty” to get things working quickly, or are you taking the approach to design and architect these integrations carefully so that you understand those dependencies well? A careful approach not only makes for a more reliable IT infrastructure, it becomes easier to plan for recovery during a disaster.
Finally, make sure the DR planning is part of the whole process. Do not think of it as an afterthought, leaving it to Phase 2 or Phase 3 once the first rush of the integration is in place. DR should be something that you think about from the very beginning. Not only do you never know when disaster will strike, but the process of DR planning will help you map dependencies and create a more robust IT environment.
Joseph George is a highly experienced technology product management leader with a strong understanding of technology, extensive business management experience, and proven analytical skills. He serves as vice president of global recovery services at Sungard AS.
