The Talent App Store IPaaS (Integration Platform as a Service) is a software platform for building enterprise HR marketplaces, where small, best of breed pre-integrated HR applications – microservices – communicate with each other via APIs. Customers within a marketplace can click to assemble microservices together into a secure, working HR technology stack for recruiting, growing and managing talent. We also operate a publicly available, open HR marketplace at www.talentappstore.com.
We designed the TAS iPaaS around two principles – (1) that HR functionality can be best delivered as small, pre-integrated, best of breed apps that communicate via APIs, and (2) that installing apps should be as easy as the “click to install” of apps on your phone.
Those simple goals led us to several key design decisions which I’ll try and highlight here and in follow-ups. In particular, I’ll focus on how TAS can help you take control of your HR integrations, letting you build a plug and play, try before you buy HR ecosystem.
Plug and play, and agile HR
TAS lets customers operate their own plug and play HR ecosystem.
Lets say that, as a developer, you’ve built a career site app. It displays open jobs beautifully in real time to candidates on a mobile-friendly website.
By plug and play, we mean that a customer (the *tenant*) who is interested in your career site app can learn about it and click to install it. Once installed, your app should instantly, securely and automatically start communicating via APIs with the tenant’s other installed apps.
In short, it should be as easy for a tenant to click to install your app into their organization’s HR ecosystem as it is to install an app on their smartphone.
To understand how TAS helps with this, lets start by looking at how your hypothetical career site app works under the covers.
First, it needs a feed of open jobs, typically held in the ATS. So your career site app will make an API call to fetch those open jobs.
In the traditional “hub and spoke” integration model, your app is tightly coupled. It makes the API call directly against an ATS as below:
However hard coding your app to target a specific ATS is less than ideal. You don’t want to tie your app to any single ATS. You want it to work with many ATS’s – as many as possible.
An alternate API platform model that supports this, used by TAS, is the peer to peer model.
The peer to peer model supports loose coupling. Instead of calling APIs at a hard coded endpoint, apps use *service discovery*, provided by TAS, to find the correct endpoint for an API (in this case, “right endpoint” means whichever ATs the customer currently has installed).
Service discovery is often transparent to your app’s code, and has little or no performance impact, thanks to the tazzy transparent network proxy.
Thanks to service discovery, TAS has made your app loosely instead of tightly coupled. This loose coupling makes apps in TAS very resilient to changes. Swapping out one app (like the ATS in this case) for a new one leaves all existing integrations working (as long as the new ATS produces the same APIs). At the same time, your app can be used in many more environments.
New insights into your HR ecosystem
In the peer to peer model used by TAS, apps use service discovery to target their API calls. This works because TAS holds a complete registry of the APIs that each app produces and consumes, which it combines with the customer’s install choices to identify valid API **routes** between apps, and to authorize API traffic.
The registry in TAS provides a new level of insight to customers as to how API calls are flowing around their HR ecosystem. We’re all familiar with the warnings we get when installing an app on our phone – “this app will access your camera”. In the same way, when installing an app in TAS, the registry lets the customer understand the app’s exact API usage – e.g. that it calls APIs to fetch open jobs, fetch candidate details and push job applications. The customer can make an informed choice as to the risks before clicking install.
Compare this to a traditional hub and spoke integration, where an app’s behaviour – and the APIs it calls are hidden inside its code. Will the app delete candidates under some rare conditions? Was it responsible for the mysterious variation in candidate sourcing statistics last week? Its hard to tell.
The data held in TAS’s registry lets customers answer questions such as:
- “We’re thinking of swapping out our ATS – how many downstream systems will be affected?”
- “We’ve seen an exciting new careers site product – do we already have the APIs we need to plug it into our existing ecosystem”?
- “We’re evaluating using a product for fractional attribution of candidate source tracking – how much work will it be integrating this?”
- “We’re taking on a new client who is very attached to their bespoke career site platform – will it integrate with our standard platform?”
With this level of detail available about their HR ecosystem, customers are no longer working in the dark. They can be bolder and more agile about taking on new HR systems and altering their existing mix.
- Private ecosystems
- Visualizing and tracking down performance problems in a distributed HR microservices environment
- Provisioning apps
- Building disruption-tolerant apps that run reliably in a plug and play environment
- Single sign-on (SSO)
- Leveraging identity-based APIs to limit the impact of data breaches