Integration of disparate applications is problematic for many reasons and there’s various ways of going about it.
Firstly, a team may attempt to complete the integration themselves, which draws internal resources away from their day to day activities, which in turn might be valuable billable time for an engineering team. During this period, the nominated integration architect would have to evaluate different methodologies, with only a high-level idea or goal of what the final integration should look like. Once a decision is made, a learning process begins, whereby the architect is tasked with learning a new technology skill from scratch, new technical terminology and the intricacies of how to create a successful Integration.
There is a rule of thumb with integrations that follows the 80/20 ratio. The majority of the work is logical, and to a degree, easy to design and implement. The devil, alas, remains in the detail – i.e. the remaining 20% – the translation of data between the applications, the complex logic needed to maintain data integrity and the processes needed when something goes wrong.
This is where many internally driven projects come screeching to a halt. The outstanding 20% is often unattainable, resulting in an integration that does not meet the requirements fully, or has gaps and pitfalls. Often the benefits of the integration are almost completely nullified by the manual processes that are still required to ensure the correct data is where it is needed at the right time. It is at this point, with a lot of effort expended by the individual or team that the project is abandoned, or “put on hold indefinitely” to quote one of our customers after I described this scenario. I received the following comment from him that he had sent to his team:
The legacy project (for this integration) has been going for six months now and we don’t even have specifications yet, so using the 80-20 rule, this should take 2 years to get going properly if we decided to go internal.
Secondly, an organisation may wish to use a 3rd party platform to assist with the integration. Choosing a platform or provider is in itself a time consuming process, especially if they appear to be talking in a language from a different planet. That platform then has to be learned, and the architect is still responsible for the design, implementation and testing of the integration. After all, being provided with a platform is only a gateway to software to enable systems to connect. The platform doesn’t understand the way you use the specific applications, what you want to achieve or provide guidance on best practice. Help doesn’t come cheap either – many platform providers charge over $1000 per day for integration assistance, so in addition to paying for a platform, you have to pay more for assistance on how to use, manage and keep the integration optimised. When the original architect leaves and another takes over responsibility for the integration, confusion often occurs because the new owner almost certainly questions why things were done in a certain way. As a result, BAU updates and optimisations to the integration become problematic, especially as the platform provider doesn’t know either – they have provided software, not a solution.
To summarise, both approaches have their drawbacks, so Recursyv has a unique approach in assisting clients with Integrations. As we like to say – “Platforms are great, but people are better”.
At Recursyv we work to identify the requirements and document them upfront, providing guidance along the way based on our experience of applications, data, API’s (their strengths and limitations) and the intricacies of integration. Once a design is agreed upon, our engineers create the integration using the Recursyv platform and hand over a pre-built integration for testing and optimisation. When the final tweaks are made and tested (and there are always tweaks!) the integration can be unleashed on live production data. We find the best integrations are the ones you don’t notice, they just happen – you set it, then forget it. Full documentation is provided and retained both with our customers and in our encrypted environment, so if a change is required, or responsibility for the integration or application moves from one person to another, the answers to questions are a phone call or email away, not buried deep within an internal system, or the brain of somebody who is no longer with the business.
This human/technology hybrid provides many benefits – someone who knows ‘integrations’ is involved from the start, there’s a real person at the end of the phone to talk to, there’s no new platform to learn, no coding required and no management of API’s with vendors, to name just a few. It also works out vastly more affordable both in the short and long term.
Use cases are plentiful, maybe you have acquired another business and need to connect your service desks or CRM systems, or a mixture of the two? Often we assist organisations, especially in the MSP world, who need to connect their service desk with a customer or supplier’s, automating tickets and updates to meet SLA requirements and add value to their clients. Another large area of growth we are experiencing is in the business intelligence and data warehousing space, where multiple data sources are pooled into a single system to enable organisations to create reports with speed, efficiency and accuracy.
If anybody has any queries about integrations, we’d love to hear from you. Our engineering team and CTO love to discuss idea’s and challenges, so please do feel free to have a chat with us, we’re based in the UK, although we have instances of Recursyv and clients all over the world.