Merging companies and integrating platforms

Mergers of two companies are common but the causes for them very. A merger may be based on the idea of increasing performance and decreasing costs by combining business activities; or of grow market share via buying a competitor’s business; or anything else. I won’t discuss the economic features of mergers here – I’m interested in software and outsourcing.

When software companies merge, two main aspects come to the forefront: integrating software platforms and outsourcing.

It’s almost impossible to find two companies that use identical software systems. Integrating distinct systems makes it possible to increase business and run both companies in sync. However, integrating platforms is a challenge – which is why I decided to write about it.

Considering the fact that most software companies outsource to Eastern Europe or Asia, merging companies causes changes in outsourcing politics. I would like to describe the issues of company mergers, and what they look like from the outsourcer’s viewpoint.

Integrating platforms

When I refer to integrating platforms, I mean high-level integration through API. Integration at the level of physical databases and data warehouses is a very complex topic that varies greatly depending on the specific case.

Integrating platforms through API has some advantages. It is the least expensive, most efficient, and, in most cases, most optimal approach. Integrating through API meets the principles of microservices.

The overall integrating project contains the following phases:

1. Forming the integration team.A central problem here is that there is no one who knows both platforms thoroughly. An integration team should therefore be formed from business and technical experts from both sides: business analysts (or product owners), software architects, and developers. An experienced project manager is also necessary to define the team, form it, develop an action plan, and establish communication.The key challenge in this phase  to establishing communication between team members. Sometimes the systems do not have sufficient documentation; in such cases team members are the only source of information, and communication becomes essential.

   The best way to establish communication is to be located in one timezone. This creates the best conditions for knowledge exchange.

2. Specifying requirements.First, business requirements should be analyzed and specified. They should answer the following questions:
   • Why is the integration needed?
   • What tasks should the integration fulfill?
   • What is the business value of the integration?
   • How will the integration influence system users? What advantages should it give to customers?

   As the business requirements are specified, technical requirements should be defined. The main question here is: What should be changed in both platforms to enable them to meet business requirements?

   Answering these questions is a determinant of integration project success. If the technical requirements are defined incorrectly, implementing them will not meet business requirements. If the business requirements have been poorly analyzed and specified, the results of integration will be useless.

3. Implementing changes.During the implementation phase, the following problems may appear:
   • Discrepancy in data format (e.g., SOAP and JSON, different data structures, field names)
     Data transfer formats require unification. Clear rules should be formed, according to which the API calls can transfer data. A single standard of data exchange also needs to be provided. Often, existing APIs cannot be used efficiently by new standards; in such cases, new APIs should be created.
   • Inconsistency in terminology
     In different companies, the same processes may be referred to using different terms. In order to enable productive work by all team members, all sources of confusion should be removed, and terminology unified. This will make it less challenging for technical specialists to implement changes.

   These problems should ideally be solved in earlier phases in order to prevent misunderstandings, mistakes, and idle time.

4. Integration testing.Integration testing is more complex and demanding than any other testing type, so it’s important to schedule sufficient time for it. QA experts from both sides should enter the team. In addition, the testing should be run properly, in order to avoid inefficiency.
5. Delivering integration enhancements to users.The last, but nevertheless equally important, phase entails informing users about enhancements provided by the integration. The business/marketing/production team needs to obtain comprehensive information about the changes implemented and form a list of enhancements, along with training existing, and performing demos for potential, customers. This allows effective delivery of the changes to existing platform users, while attracting new customers.

Each of the above mentioned phases are critical. Failing at any step will cause resources to be used improperly.

What about outsourcing?

Merging companies not only demands a change in software systems, but also affects established relationships with outsourcers.

When two software companies merge, the following cases are possible:

• Neither company was outsourcing. In this case, it is likely that they will go on developing without outsourcing. This is out of scope of our current discussion.
• One of the merging companies was outsourcing. The company-buyer might insist on imposing its own approach to outsourcing.
• Both companies were outsourcing to different companies. Here, companies will have established relationships and processes. The company-buyer might insist on working with a certain outsourcer.

In any case, when two companies merge it influences not only the companies, but the outsourcers as well. One outsourcer may lose a client; another might need to begin building relationships with a new team. This latter situation entails three aspects I want to discuss further: technical, legal, and social.

The technical aspect has already been described in part above. When integrating two platforms, the outsourcer should have developers and engineers with acceptable skills and experience. These specialists should not only examine the new platform and reveal the challenges, but also be able to perform integration successfully.

Moreover, if the outsourcer’s technical experts enter the team making decisions or implementing changes, it is better for these people to spend a period of time at the beginning of the project in one time zone – or, even better, in one room. This will enable them to establish clear communication, effective knowledge exchange, and resultative joint work. To solve problems related to time zones, the outsourcer’s specialists could undertake business trips.

The legal aspect is related to business processes, workflow, and documentation – each of which may be changed, adjusted, and reestablished after the merger. There might be a period of confusion over contracts, project orders, invoices, roles, etc. For the outsourcer, this may mean worsening bureaucratic procedures. As these procedures are reestablished, all work will continue as usual.

The social aspect might sometimes appear to be the most challenging, because human relationships are the most complicated. The bought company may resist the new outsourcer, especially if the former outsourcer met all requirements. This resistance may be expressed in various forms:

• If the company doesn’t want to form a team-outsourcer, they may interview and reject every candidate.
• When work starts, the company may discredit the outsourcer’s developers.
• The company may hinder development by using excessive bureaucratic procedures.

All these difficulties can only be solved by establishing clear communication and transparent processes from the outsourcer’s side.

In an upcoming article I’m going to write about how the outsourcer can achieve processes that are clear and transparent for customers.