In Part One of this series, I described the problems that many modern enterprises, with multiple teams, are currently facing. Each team – Project Management, Development, Testing, Management, and others are using their own tools. This approach may work for them, but in many cases communication between the groups is difficult, if not virtually impossible.
Although different groups may have the same data, different formats make it difficult to share, or even to determine and handle these redundancies. Employee satisfaction drops, operational efficiencies suffer and, in general, the entire situation can be a major mess. The multiple tools, multiple data and storage formats, and even the difficulties that arise when one system tries to talk with another have created a major problem.
So how do we decide on the solution to this problem? Considering that there are two basic solutions – migrate tools so that there are fewer tools to maintain, or integrate the tools so that users can remain productive while allowing data to be available on a broader scale. The most common approach is to minimize complexity (for example, reducing the variety of systems and processes) and to minimize costs (evaluating license costs vs. migration costs). One solution may be to combine systems – for example systems A, B, and C are all migrated into System A, and to integrate other systems – perhaps integrating systems D and E into System A.
The first step to be used in determining when to migrate versus which systems to integrate is to create an inventory of applications. It is amazing how many applications are in use across multiple departments, multiple business units, and multiple locations. With the ease of installation and low cost of licenses for some products (like the $10 for a 10 user license for Jira) the applications seems to proliferate like rabbits!
Create an inventory of applications , by collectingdata on how and why each application is used. Next, analyze which of the systems can be combined or integrated. Be warned – this list will only grow as more organizations hear of this initiative.
In the next blog in this series, I’ll explore the options for managing this complexity, the pros and cons of each approach, and list some of the gotchas (what do you have to look out for)
Read the earlier post:
Johnathan McGowan is a Sr Solutions Architect at ConnectALL. He is responsible for customer-facing technical resource for the ConnectALL integration tool. He works with Account Managers to assess prospect needs and build demo integration solutions, guide prospects through product evaluations, and assist clients with their production deployments.
