Moving right along in this series…
The primary business problem I hear is companies have lots of “silos” and want to be able to aggregate certain data for corporate portals, dashboards & decision making, governance or claims analytics at the same time minimizing dual entry, increasing integrity and addressing various security issues. I also hear a lot of questions about “Sharepoint Integration”, which is not the subject of this post series, however due to it’s popularity I’ll use it in some examples and further dedicate an entire post series in the future.
At the end of the day, there is a fairly simple set of considerations that are the basis to achieve all of the above and whatever else you dream up. This post will focus on the concepts vs. specific products so the ideas are generally scalable regardless of what software product used or how many you own.
Generally companies want to;
1) Push a dataset one direction between two different application instances. This is the simplest type of integration. This is usually a role specific application (RSA) like NoteVault or Vela Systems sending data to a Line of Business (LOB) application like eBuilder, Prolog Manager or Contract Manager. It could also be an Office Business Application (OBA) or two different instances of the same application, for example a regional Office instance sending data to a corporate HQ instance.
2) Push two different data sets bidirectionally between two different application instances. This is very similar to case 1, but both applications are sending data to the other. An example is sending a subset of Change Order Data to from LOB applications noted above to JD Edwards or Timberline Office accounting applications, and then posting payment status from the accounting applications back to the LOB applications. You can see this is two completely different data sets, so there is relatively little risk of problems.
3) Push two like data sets bidirectionally between two different applications. This is the most complex, as you have to deal with synchronization issues. An example is an Owner and General contractor working on a building program. The owner wants all the RFI’s entered in their system of record, while the GC wants the same RFI’s in their system of record. Time to break out your Venn Diagrams. The owner may have 15 pieces of information they need, 5 of which are internal and 10 of which come from the GC. The GC may have 20 pieces of information they need, 10 of which are internal and 10 of which the owner needs. Additionally, either party may update any of the 10 overlapping fields of information at any time.
There are some other scenarios, but these 3 tend to cover most of the questions we get asked and even want to do ourselves. As you will read, similar pros and cons will enter the picture with more parties, apps, and instances. Basically multiply the above scenarios by as many instances as you want, same goal is usually present.
Stay tuned for the next post on the technical side, where I’ll address options from basic to advanced, across a range of non human/hard costs balanced with human/soft costs.