Why Best of Breed is becoming the norm

building clouds facade glass panels

Best of Breed Workforce Management Solutions are now increasingly chosen over the traditional Best of Suite HCM providers.

Research by Navigo reveals that overwhelmingly (69%) choose a Best of Breed provider to meet their needs rather than a suite. It also discovered that 50% more organisations were “Very Satisfied” with a Best of Breed than those who purchased this as a module of HCM.

This maybe a sign that changes in the workforce are occurring more frequently and organisations need more agile and adaptable solutions. This seems to be confirmed by the study with the average age of a 5 years for a WFM solution compared with 7+ for HCM Suites.

Whilst a rapidly changing workforce environment may be a contributing factor, it is  cloud technology that is accelerating the move away from Best of Suite towards a new paradigm of “plug and play” applications in the cloud.

Historically Best of Breed applications where held back by limitations with integration. Many applications didn’t “play well” with other applications or even devices. But this is changing fast.

In the 1980’s your choice of printers was often dictated by the word-processor (or even computer) you purchased. But the introduction of “software drivers” removed this restriction and now with “plug and play” no-one worries about whether the printer they purchase will work with any of their applications.

This revolution in technology – largely forgotten – is being played out within modern cloud applications. Today we share content to Facebook, Twitter, LinkedIn and many other cloud platforms without even thinking about the enabling technology that seamlessly integrates these applications together.

Web and cloud integration technologies make integration simple, secure and in many cases real-time. Data flows seamlessly between applications and without the need for organisations to involve their IT departments.

Historically IT departments would spend significant internal resource trying to knit on-premise applications together to avoid users having to dual key data into separate applications. Now, many modern cloud providers provide integration plug-ins to other vendors without the need for any internal work. Likewise, the adoption of Single Sign on (SSO) standards has meant that user experience across platforms isn’t impacted.

This represents a watershed moment in vendor selection. Historically organisations had to weigh up the trade-offs between a fully integrated suite that didn’t quite meet their business requirements versus a Best of Breed option that didn’t quite meet the “joined up” experience that users required.

With next generation cloud “Best of Breed” applications removing this barrier, organisations no longer need to sacrifice business need over user experience.

It also enables organisations to adapt more quickly to changing situations and without the costly and long delays required to replace a monolithic application. If a specific solution cannot be adapted to the new way of working, then it can be replaced without needing to replace the entire suite.

Ultimately organisations are looking to become more agile and the new world of “Cloud Plug & Play” has enabled them to do just that.

To find out more about our cloud solutions visit HFX or Contact us

Introducing A New Integration Paradigm

black and white blank challenge connect

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.

Pedantic Officialdom:

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.