As the adoption of cloud-based systems increases the need to integrate keeps pace. Here we discuss what you need to know when connecting cloud systems.
Once was a time when one of the arguments against migrating to Cloud systems was the lack of integration capability. Not so now – the integration capability of Cloud systems is very much active and relatively straight-forward.
A large number of cloud integrations are available for adopters to utilise immediately: out-of-box as it were. A small amount of configuration and you’re up and running. Subscribe to a cloud-based CRM and even if it has an in-built eMarketing capability, chances are the ability to integrate with a number of well-chosen eMarketing alternatives has also been built in. The supplier doesn’t want their system not to be selected because it doesn’t integrate with one of your exists systems. As well as in-built integration you can use 3rd party connectors. Microsoft Flow – associated with the Microsoft Office 365 suite of applications – has a very active community developing a range of integrations to be used and is a good example of a 3rd party connector of systems.
So, if you’re choosing a Cloud system, and it provides a range of out-of-box integrations, i.e. integration capability that requires configuration rather than development, you’re probably well covered in terms of establishing connections and realising the benefits with minimal considerations. Or, if the product is highly popular you’ll likely find a range of 3rd party connectors at your disposal.
But what if your system doesn’t have any pre-packaged integration capability? This is likely when you’ll be considering developing a custom integration.
Developing a Custom Integration
Again, thinking of times past, considering an in-house development of an integration was a feared undertaking – assumed to be costly and problematic. The development of Web Service communication, which underpins integration of Cloud systems, thankfully resolved a number of the issues that were experienced with integration of on-premise (DLL based) integration.
Many of the cloud solutions available today provide a Web Service based API (Application Programming Interface) that allows connecting to that system for the purpose of accessing its functionality and information. The API is there to be used by those who chose to use it. But, if you are considering custom development of an integration there are a number of key considerations to be aware of.
1. Alignment to End-User Functionality
Be aware of what you may want to do with the integration and that it supports what your end-users would routinely undertake. For example, the API may provide the basic functionality of executing a particular transaction, e.g. creating a sales order. But it may not support all the data capture and handling that end-users would utilise. Therefore, be sure that any custom configuration, for example, you’ve been enabled to make can also be supported by the integration.
Verifying authorised access to an external Cloud-system is critical in securing the data it contains. Therefore, you should ensure that the API honours the wider system security by authenticating the connection from the external system. This should be a given – but one aspect to consider closely is how the authentication is managed. Authentication is primarily driven by the sharing of encrypted ‘keys’. Some API authentication mechanisms only allow authentication with end-users, i.e. people rather than automated processes. This has implications if your developing an automated integration that operates at the server, rather than user level.
3. Updates Beyond Creation
It’s hard to imagine any API’s that by default don’t support creation of system entities, e.g. sales orders. However, a watchpoint is how updates to previously created entities are managed. Ensure the API does provider the ability to request updated information specifically. This allows information in both systems to remain current and accurate, and if developing a synchronisation process will allow the integration to be streamlined and volume of data sharing minimised (rather than having to undertake cumbersome processing of all information with every transaction).
4. Cost of Transaction Volume
With many systems, access to the API functionality will bear no additional cost – but pricing does vary and should be verified for each system. Furthermore, access to the API functionality may be free, but some suppliers apply a charge related to the volume of transactions that are triggered within a given period. Therefore, if you’re integration synchronises data between two systems, and the synchronisation is triggered frequently then the number of calls made per day may result to a cost; or you may choose to throttle the synchronisation frequency to accommodate the cost implication.
5. User Feedback
If you’re fortunate enough to be assessing the capability of the API as part of the system selection process there may be some key indicators of its quality. Many API’s related to Cloud systems have product support information which is publicly available. This can be a good point of investigation to assess how well the product is supported, i.e. in terms of competency and response time – but also to gauge the feedback from developers. Developers who are not supported well or identify inadequacies in the product have a tendency to air those views in support tickets. If you sense a dis-satisfied developer community, this is a strong indicator of whether this product is right for your purpose. Equally, if the vendor is transparent they may have a rating system which is openly available.
We’ve seen that connecting Cloud systems can in some scenarios be a very straight-forward exercise if an out-of-box integration capability exists. Where a custom integration is required there are a number of watchpoints, but as the competition is the Cloud marketplace increases the quality of API’s is increasing; and with a few well-chosen considerations to be explored you’ll be able to select a system with a quality API that supports your business requirements.
If you have any questions related to this article or if you’d like to discuss integrating systems please contact us.