In the last post, I provided support for the idea of using multiple different tools to do different jobs. However, in order to do that effectively, the tools that you use have to be open to sharing data with and receiving data from other tools, better known as integration.

As software has continued to evolve, there are very few closed systems anymore. However, a decade or so ago there were many platforms that did not “like to play with others”. They were trying to force clients into using all of their modules by not integrating with other tools. Thankfully, the market has moved most of these dinosaurs away from this approach.

However, “open” does not mean the same thing for every piece of software. Ideally you want a tool that has no limitations in terms of how it can integrate with other products. To do so, you need to have a highly customizable system that allows you (not their programmers) to create custom fields that can become the integration points in the data. Most software allows you to add at least some custom fields to your dataset.

Unfortunately, in many cases you need to pay the developer to add the custom fields that facilitate the integration. This costs money and takes time, slowing down your integration. Try to find tools that are easy to make your own by yourself. You will thank me later!

Next, once you can add custom fields to facilitate the integration, you have to have tools that allow users to import and export data easily. Again, you do not want to have to get a support person or developer to have to import or export your data, especially if you have limited support hours with your license.

Finally, you need to decide how you are going to integrate your tools. There are generally two main approaches, flat file and API (Application Programming Interface), yes, I had to google it to make sure I was using the right term.

Flat file integration is when you export an Excel or CSV file from one product that is then imported into another piece of software. This is generally a manual process and works for non-transactional datasets. For instance, for capital planning datasets, we often use flat files as capital plans, once developed, they generally don’t change dramatically throughout the year.

The nice thing about flat files is that it is generally easy to build them within software. It is typically just a custom report that you can build in conjunction with your software partner. Some software even has report builders that will allow you to build the report yourself.

When you are dealing with more transactional data (e.g. work orders), you may want to look at an API. APIs are essentially live links between two software products. You decide which database is the parent and which is the child. When a piece of data is changed in the parent database, it immediately sends it to the child database where it is updated. Generally, the data in the child database is read only so it can only be changed in the parent database.

API’s require programming and often need collaboration between the development teams of both software products. They can be very powerful but will likely require an investment of both time and money to build.

Now that you have the right data in the right tools and your tools are actually talking to each other, we can now get down to business of Prioritizing our actions, which will take us to the next layer of the Onion in our next post.