Integration, done well, is a powerful time-saver for a business. Data magically moves from one system to the next with no re-typing or errors. The business cost benefits are immediate and cumulative.
IT Integration projects used to be slow and expensive. Polonious have been on a journey to improve this over the last decade. We now know that we, and our customers can be confident integration challenges are not the painful undertakings they once where.
Polonious currently have 21 product integrations that push and pull data from many sources including:
- Investigation information sources (7)
- Claims systems (2)
- Fraud analytics products (4)
- Video interviewing systems (1)
- Accounting systems (2)
- Link analysis systems (2)
- Others (3)
We also have many more integrations to internal client systems scattered across a multitude of data sources, methods and security protocols.
Each of these integrations built on the methods of the previous one. All have the same foundations to their success.
This integration series will explain what’s different about our approach and why we are great to partner with if integrations are something you’re concerned about.
Part 1 is concerned with the state of integrations when we began the journey, what the problems and frustrations where and a little bit of a look ahead to what our principles for integration became.
Part 2 covers the first pieces we use to ensure significant cost and delay is removed from integration projects without causing quality and security issues. I’ll discuss the lego blocks that make up an easy integration process.
Part 3 covers our current list of integrations to give an example of what’s possible for your business, as well as some of the more complex components we wheel in for complex requirements. One thing that is pleasing is to see our clients take our API sets and use them in place we never expected. Sales reps triggering fraud cases from Sales Force Mobile being one recent example. We will also touch on the future, what we’re doing next to further help with the integration needs of our customers.
A decade ago, when Polonious needed to integrate to other systems, this was how the projects generally worked:
Big budget integration projects.
Regular, big, team meetings involving project milestones. Participants included the business, IT network and security people, IT development teams. Lots of discussion about approach, governance, everyone being heard. Very expensive undertakings.
Waterfall project plans which coordinated the efforts on both sides of the IT discussion.
Delays by any part of either party’s team slowed the whole project down. For example, we once waited 9 months for the other party’s FTP site to be set up correctly.
I and many or us at Polonious were very frustrated with this process – we knew a lot of it was out of our hands. Unlike many things in the IT world which had clear paths and standards, a lot of the issues we encountered were associated with ‘bikeshedding’. By way of example, here are some of the long discussions from those days:
Security. Many teams we encountered needed a detailed discussion of how we were communicating securely. They often had different thoughts and requirements that needed to be discussed and agreed upon.
Protocols. This was the glue that allowed systems to communicate. This varied from SFTP / XML / Webservices and other methods. A lot of people are still used flat file importing also.
Field discussions: what goes where. This was to the most point a business the discussion that required IT resources. These discussions shouldn’t have needed IT resources.
Integration projects accounted for at least 30% of our IT resource budget most years until we spent the time to work out how to get control of this process. As a bonus, during this time, the IT world moved on a little – clearly we weren’t alone in these frustrations.
We believe that we now have the integration challenge down to a fraction of it’s previous frustrations and delays. I’m hoping that this little series can help a little with your team’s challenges, if not, with understanding our approach and how that can help if we need to integrate together someday.
Here are the main points of advice I’ll be covering with examples of where it’s worked and how it works for us and our clients:
Fix your integration efforts on secured REST, preferably with OAuth2 – as soon as possible.
Make your REST services flexible enough so that business people who will use them. Yes, business people..
- When considering working on integration, start with improving your core REST services, the next integration project will benefit from it.
When you can’t use REST – adapt. Write adaptors to translate the other party’s communication needs into your common REST calls so that all of your internal verification, security and updates are consistent.
Of course, I’d love feedback on this as I’m sure the journey is not complete. You can reach me by email here: firstname.lastname@example.org or by linked in here. Part 2 follows next week.