Integration architecture

    Written by HarmonyPSA on 2017-02-13 Last updated 2018-06-27 - 3 minute read

A key question we get asked a lot is “Does Harmony integrate with xyz?” where xyz either represents a system the prospect uses and loves, or an essential system that does something not forming part of a PSA’s natural footprint, so an accounting system or a monitoring platform.

In all the years of receiving enquiries, we can’t remember one that was more specific than that.

Now, it may seem obvious to a user what integrate with means, but it is not always obvious to us, so let’s break the problem down a little to help understand it better.

Classically, there are at least four kinds of interface (there may be more, but we can immediately think of four which should be enough to make the point):

• Static Data Maintenance (SDM); the first and most important requirement in good interface architecture is to ensure that static data flows are correctly set-up. This requires a clear view of the different data models in the systems being connected and the logical create/update/delete flows across the systems. These flows need to enrich data in the right sequence, but potentially edit it from any point. In addition consideration needs to be given to different security modelling and permissions, complex stuff. Note: if the static data maintenance sequencing is not correct, there is no hope for transaction flow to work robustly. Zapier can help with single directional flows, but edits and state changes present a real challenge.

• Transaction Flow; OK, static data is hard, but what about transactions? Take the accounting interface as an example. The simplest accounting interface is a journal one as this only touches account codes and they very rarely change so #1 can be accommodated manually. The most complex is invoice lines that contain product codes, these require careful consideration operationally and must be built on a robust product sync static data maintenance process. So, each time you consider passing a transaction from one system to another, ensure you have SDM correctly sorted or it will fail. Really to make this work correctly you probably need a proper Business API.    

• Data Export/Import; this is where a process ends in one system and begins in a second. Technically, this should only require an associated foreign key and consists of a value and value definition (i.e. period). It can be made to work fairly easily, however, consider the processes surrounding the foreign key maintenance (normally mapped to a field in the receiving system). Harmony’s RESTful interface and email parser can mostly deal with these easily

• Hyperlinking; is the easiest of interfaces, really simply a key field added to a hyperlink to provide direct access to another system (think a postcode and Google maps). Harmony has “smart Hyperlinks” that make this a doddle

So, before you ask whether an integration is available, think through what you actually mean in these terms.

Zapier can help with part of #1, single point to single point, but basing an interface architecture on a generic create API that only works in the simplest of cases is frankly not a great plan. It will struggle with branching data models and update actions. Take that thinking across more than one hop, and you are going to break something for sure.

Take counterparty maintenance as an example, even supposing counterparty means the same thing (by no means certain, Harmony has 5 counterparty definitions not 1 and each has multiple, different, states and these are unique to Harmony’s model), the counterparty data needs are different for CRM, Projects, Invoicing, PO’s and Accounting; address definitions are also different for Contacts, Asset Sites, Legal Entities etc. So, a CRM system can create a basic counterparty for a contract system, but will it include all the fields the latter needs? If not, how do you ensure someone steps in and enrich? Will that counterparty model also work for invoicing or SLA management (which may, for instance, need timezone)? It’s unlikely.

So, our guiding principles for ensuring a sound interface architecture are:

  • Only move data when you absolutely have to and then move only what is absolutely required;
  • Keep it simple, restrict yourself to single hop create/update interfaces;
  • Understand the data enrichment flow and how edits are processed;
  • Generally, pick the most complex data model to be the master (though not necessarily the initiator);
  • Avoid complex transaction flows and agree how reversals and error state handling works;
  • Simple placement interfaces and hyperlinking are great; they can achieve a huge amount of joined up architecture for very little cost; and
  • Where possible, use foreign key mapping to achieve joined up views without moving data around

Lastly and most importantly, seek a central system that does as much as possible and only needs connection to specialist outlier, containing slave master data only one hop away. Ensure you understand how changes take place and deal with error state handling if you go anywhere near transaction interfaces.

Harmony didn’t become the PSA tool with the widest functional footprint on the market by accident. The power of a core central database at the heart of your business is immense.

Consider this the next time your management reporting insights are ruined by data errors and duplicate master data.


About the Author: Harmony Business Systems Ltd (HBS) is the company behind HarmonyPSA, the most complete cloud PSA software on the market. Developed with functionality to cater for even the most complex needs of MSPs, VARs, ISVs and Professional Services organisations, HarmonyPSA truly is the next generation of PSA systems. HBS is an independent company based in the UK. Follow HarmonyPSA on or LinkedIn

Tags: data architecture, data flow modelling, Features, Integrations, interfaces, General PSA, transaction flows, zapier


Recent posts

Subscribe to our blog