Cloud doesn’t solve everything…yet, according to Report Factory
Many firms decide over time that specialised software systems are a better solution to specific issues. The ones we see regularly are specific time entry and time capture solutions, expense reimbursement and management, as well as super specialised onboarding and AML (Anti Money Laundering) solutions. Marketing, CRM and HRIS/Payroll (Human Resource Information Systems) are further examples.
Whilst modern practice management solutions (PMS) typically have some capabilities in these areas, the specialised tools certainly expect to deliver significant risk reduction and increased information and financial efficiency. These are often, but not always, cloud based.
Which brings us neatly to integration. As has always been the case, a ‘best of breed’ (BoB) approach to these composite solutions requires efficient, secure
and reliable integration, intelligently applied and properly managed. A combination of cloud, on-premise solutions and cross integrations between them, increase complexity, risk and criticality of integration solutions.
Much more so than on-premise BoB solutions, cloud solutions tend to be VERY specific in the problem they are trying to solve. This is both good and bad. It’s good because the focus means the problem is solved in a direct rather than scattergun – one size fits all type approach. It’s bad, because being small solutions increases the requirements for solid, well understood and robust integration design and execution.
Not just names
This level of integration covers transactional integration, not just the somewhat simpler name, address, phone number stuff. Fee earners get a bit stressed when time entries are missed, duplicated or compromised on any level. AML transactional history and storage for subsequent audit are high-profile and legislative requirements.
Integrating staff data including payroll and related expenses is critical for financial efficiency and reporting accuracy. We find it incredibly surprising how many firms are still doing manual journals for payroll data integration.
Twice now, when assisting firms with new integrations, we discovered reporting from HRIS and PMS environments showing different numbers and ranks of staff at the same reporting data; Not just on a per team basis either, IN TOTAL as well. This shows a in a simple way, the criticality and importance of proper integration and the obvious risks of not doing it well.
Tools vs skills
There are quite a few good integration tools around. Many are also capable of cloud to on-prem, cloud to cloud etc. Design skills for integration are probably more important than the tools, but you certainly need access to both. Designing integrations is not straight forward if you want reliability, audibility and timely accuracy.
This is of course even more important and visible when dealing with transaction integrations like time entries and payroll costs. When you start relying on external data providers for integrated AML verifications you are really into some critical areas of risk and management.
Important considerations in integrations involve logging events, tracing errors, allowing for retries and recovering from integration failures. Most of these are
best designed in at the start.
We’ve had experience in all these areas, and indeed pulling apart and repairing integrations attempted by others which clearly were not delivering on the ‘authorised accurate and complete’ mantra that we accountants are fond of, and for good reason.
Transactional integrations highlight the need for skills that understand the issues in such integrations and indeed the skills in understanding the nature and timing issues associated with transactional integration generally.
Being able to trace specific transaction failures in logs, having alerts when there is a failure (and there will be) and having a planned and documented route to trace and correct all make the integration more robust and reliable.
It is critically important that integrations are trusted, and for them to be trusted they need to reliably perform.
API vs non-API integration
Application programming interfaces (API’s for short) are methods published by software vendors in order to get data into and out of their software products. They really do make a huge difference when working on integrations, from three primary perspectives:
- The data is coming out or going in as the application vendor intended, respecting any business rules defined by the vendor or configured by the firm.
- Typically using the API’s protects your support agreement with the application vendor because of it being essentially their method of interacting with the application rather than you digging around directly.
- Most API’s have ‘throttling’ algorithms to stop the external interfaces from destroying the performance of the main application by limiting the number of API calls per second or minute etc.
The other thing that API’s do for us is provide speed and simplicity of integration development, and that’s a big win for everyone involved.
Integration documentation and control
As integrations become more commonplace and more required, it’s super important that you have solid documentation of what, how and why the integrations do what they do. This documentation needs to be readable, by normal humans, in straightforward terms, as well as being accompanied by technical documentation to aid later maintenance and trouble shooting when the original author of the integration is long gone (a common issue!!).
Ideally you’d like to see all your integrations able to be controlled, or at least monitored, via a single user interface. Such an interface would show the last successful operation date and time, how many records were moved in which direction, any error messages and the next scheduled time of operation (if indeed it’s a scheduled integration). We’d consider this a minimum, but if you can then drill directly into the integration and troubleshoot it, then all the better, but the top level interface at least makes the monitoring and notification of issues much more focused and straightforward, even if you then need to turn elsewhere to troubleshoot it.
Triggered vs. Scheduled integrations
Integration steps can be the subject of regular schedules, like “every hour check this system for new or changed records and then push the changes to that system”. Alternatively they can be triggered where an event (a new or changed record) in one system generates a call to an integration to change another system.
Both are valid and both have their place/advantages. In our experience good integrations typically start as manually run, then move to a schedule and ideally to a triggered approach over time, as confidence in the quality and reliability of the integration grows. So, why not just go straight to a triggered approach?
Well of course that is possible, but it comes with risks. Quite often triggered integrations can have (initially) unintended consequences, like excess traffic, updates that actually aren’t required or worse still, incorrect actions that get to large volumes before they are discovered as the triggered integrations have been pumping away in the background unnoticed for a few days or weeks.
By following the more careful, manual, scheduled and then triggered lifecycle, the integrations have a better chance of being edited, debugged and controlled in a more deliberate manner and less likely to wreak havoc on the whole environment. Of course we all test these things in test environments before anything happens, but real users and real transactions and live environments will always throw up some unexpected conditions and situations, hence this more measured approach.
Conclusion
Integration tools are well developed and relatively easy to use. The proliferation of specialised cloud solutions means integrations are becoming and will continue to become more and more important over time. Skill and planning probably matter more than which tool you use (although that’s still important).
Used wisely and carefully, integrations can take all systems to a much, much higher level of efficiency and accuracy, and as such are something worth pursuing, wisely
