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:
Doug Bass is a certified Atlassian consultant and trainer and a certified ScrumMaster. He is an experienced systems architect with experience in distributed application design, database architecture, network design, and project management. Author of the first relational database for military applications in the UK and the first java-internet based chat application, Doug teaches classes in object-oriented design. He holds a Masters Degree in Information Architecture. He is a consulting partner for Atlassian’s product suite, and architect of several of Go2Group’s products including the CRM Plugin (JIRA and Salesforce integration), JIRA/Perforce plugin, and ConnectALL (a multi-application synchronization solution). Doug contributes his free time to the United States Power Squadron where he teaches classes on safe boating.