Einstein stated that “Everything should be made as simple as possible, but no simpler.” and for hfx this has become a mantra and even our core values are expressed by one word: simplify.
We follow this principle both in terms of our processes, methodology and vigorously within our cloud solution design and development. The first challenge we tackled with Time and Attendance was the complexity of reflecting real world work rules within a simple and easy configuration that end users could quickly master and enable them to take complete ownership of the solution. The result was amazing; implementation time reduced from 9 months to 1 month enabling the customer to achieve accelerated ROI and significantly reduced costs of configuration and implementation.
This success gave us confidence to tackle the next challenge which was more nuanced but no less radical; solving the thorny issue of integration using Application Programming Interfaces. As a group of seasoned developers with over 30 years’ experience of integration (and a combined list of over 250 interfaces developed under our belt) we looked at the fundamental issues with integration. We recognised that the issue had little to do with coding ability, language but everything to with mindset.
At a high level we recognise three key mindsets that pervaded all interface development characterised “The Solicitor Mindset”, “Pedantic Officialdom” and “S.E.P or Someone Else’s Problem” – Our analysis revealed all 3 mindsets in all 3rd party integrations we had ever seen and worked with historically. Each requires a little explanation to see how they manifest;
The Solicitors Mindset:
If you have ever had dealings with a solicitor (whether when buying/selling a house, Non-Disclosure Agreement etc) you will instantly recognise the legalise, Latin and jargon that seems to confuse rather than clearly communicate its purpose. Any attempt to simplify the text is met with a firm response by the solicitor that “Its not meant for you but for another solicitor”. This is a lazy excuse to avoid clarity and simplicity by relying on someone else with 7 years legal training to decipher text that could and should have been presented in a way that a lay person could understand. This same mindset influences the development of API’s with the argument being that the P stands for programming so there is no need to simplify the API as its not meant for anyone other than another programmer.
We’ve all had this when asked to fill out a form to change some information. Often you must enter the very same information they already hold and then when you hand it in you are told you’ve used the wrong form (often they have different forms to register new information versus amend existing information). When you fill in the correct form (which is almost identical to the other form) you are then told you must use blank ink rather than the blue or that your signature isn’t fully in the box provided (which is often too small) – I could go on, but you get the point. This very same approach is often applied to Application Interfaces. As with Pedantic Officialdom the whole purpose isn’t to make life easy for the consumer (or 3rd party) but a lazy approach to make it easier for the recipient.
Someone Else’s Problem:
Incapsulating and extending on both the previous mindsets is the overarching view that it is someone else’s problem to decipher and to comply with these pedantic and overly cumbersome rules. This approach to integration enables API’s to be created very quickly but the consequence is that they are dumb, brittle and difficult to work with and significantly increases the effort by the third party.
A New Paradigm:
Overcoming these issues isn’t a question of technology, coding skills or even language, its harder than that because it requires a paradigm shift in thinking about the whole approach to integration.
However, as with all challenges we were confident with the right approach we could completely turn integration on its head to simplify work for 3rd parties and especially to our customers.
The first design principle we applied was that the API shouldn’t be developed for another developer, it should be developed so that a competent IT professional or implementer could consume the interface. This principle ensures that we don’t make assumptions about who will be consuming the interface and a good test to ensure that the interface is a simple as possible (but no simpler).
The second design principle is that the API should be intelligent and not pedantic in terms of the calls into the API (for instance demanding a different call to add information versus amending information or refusing data based on lazy or pedantic rules). If the new data requires the creation of associated or dependent information the API can automatically create this on the fly rather than simply failing. This simplifies the work for 3rd parties whilst reducing both manual entry and lazy rejection of data.
The third design principle was that the API should be easy to configure, so that if requirements change (e.g. some information previously sent IS no longer required) the API can ignore the data without the need for changes by the 3rd party. This ensures that the interface is flexible, and our solution can adapt to changes in data without the need for either the 3rd party or the interface to change. It builds in flexibility.
These 3 guiding principles enable a paradigm shift and focus all the intelligent development work within our solution making it simple to integrate from a 3rd party perspective. It turns integration on its head by making “integration our problem” rather than “Some Else’s Problem” and this changes the mindset with the result that issues are tackled and eliminated from the get go.
This approach rapidly increases integration time, reduces the need for testing and 3rd party development work. It also means that with a simplified approach to web services we can easily integrate legacy/on-premise third party products even if they are csv based using our rapid scripts that convert these into web service calls.