Creating Order of Chaos
Whether as a result of merger or acquisition, or you are simply seeking to consolidate across departments, technology integration is a challenge. There are multiple areas to contend with when trying to bring consistency to diverse technology groups. Here are 3 big ones, and some approaches to overcome them:
People
In this case, I’m referring to your technologists — programmers, sys admins, database administrators, etc. Unless the groups in question have similar roots, or you’re lucky, it’s very likely that your people will have diverse technology backgrounds. This is both an asset and a liability. It is an asset because diverse perspectives can help produce a more well-rounded solution in the end. It is a liability because you’ll have diminished ability for teams to collaborate on a single platform (language, OS, database, etc). People have a tendency to stick with what they know, so when technology selection occurs, religious battles may ensue. Think Linux versus Windows, .NET versus Java, SQL server versus MySQL.
Systems
If all systems under your company’s roof were developed in the same programming language or were built on the same platform, reusability is maximized. For example, Java libraries or .NET assemblies. Today’s systems have a greater likelihood of being developed with interoperability in mind — meaning, using container technology or being API-based. However, the investment to achieve this type of interoperability is only likely to have been made if a business need for such integration pre-existed. It’s quite possible that components or entire systems exist as black boxes.
Data
There are some data elements that are likely to be housed by every system in use. For example:
- Users
- Accounts / Clients
To make cross-system data useful, and to allow for a seamless user experience across applications accessing diverse data stores, you’ll need to solve the problem of linking data entities. Does user John Smith exist in multiple databases, and if so what is his user ID in each ? Is Acme Corp in one system the same as ACME CORPORATION in another, and if so what are their account numbers ?
Technology Integration Approaches
At a high level I see two integration approaches, tightly or loosely coupled.
For a tightly coupled approach, you’d be migrating functionality and data from one system to another, and decommissioning parts of, or entire systems. Depending on how well the systems align with each other, this can range from a modest effort to a herculean one. Also, if you’re dropping existing systems and consolidating to fewer platforms, you may have disillusioned team members from the deprecated system teams who feel like the odd person out. If they leave you could lose valuable domain knowledge. On the other hand, a successful migration reduces complexity (including those pointed out in Data and Systems above), and potentially reduces your costs. Though understand that it may take some time to recoup your migration investment.
A loosely coupled approach would mean leaving systems largely intact, and not disturbing existing teams and technologies. Integration can be achieved ‘on the surface’. One example of this is wrapping existing functionality in an API for consumption by external systems. Other examples include implementing single sign-on (SSO), or putting a ‘skin’ on existing applications to maintain a consistent look-and-feel. This is perhaps a lower-cost solution in that it avoids dismantling systems that perhaps come with a high cost to re-develop or to migrate. However the data problem described above needs to be overcome.
Conclusion
Bringing together disparate technology teams is not easy. Depending on your investment horizon, you can take different approaches, each of which solves different parts of the problems to varying degrees.