Are APIs the natural choice?
When businesses think of tech integration, APIs are universally the first choice that comes to mind. There are obvious reasons for this. API technology offers an easy way to integrate your databases and programs with (external) industry applications, allows data to be automatically moved between systems and applications and makes your business processes more fluid. It is no surprise that APIs have become the de facto tech integration choice for most companies across various sectors.
However, they are no silver bullet. Companies do not live in a utopia where they can just grab a plug-and-play API and effortlessly integrate it into their systems. They have to consider topics such as legacy systems, IT capabilities, departmental differences and much more. But because APIs are considered trendy and cutting-edge technology nowadays, most companies do not think twice before deciding on an API-based integration. The end result, unfortunately, may fail to live up to expectations.
This is why we at Mobilexpense advocate for a customer-tailored approach when integrating expense management solutions. Our philosophy is to take time to understand your end purpose and IT ecosystem in place and look for the technologies best suited to realising that goal. It is only after carefully considering all factors that you will find the optimal solution in terms of cost, ease of use and maintenance, and performance. And that process must start with posing the right questions.
In this blog post, we elaborate on the questions that you should always ask yourself in an integration use case.
What do you really need for an effective integration?
The following four criteria are usually valued the most when evaluating an integration architecture: synchronicity, data formatting, security and the data volume transferred. Whichever aspect is indispensable for your use case will determine the integration approach you should take.
Integrations can be either synchronous or asynchronous. Synchronous designs transfer data immediately while asynchronous designs can do so at a later point in time. If communicating and updating small or medium-sized packets of data in real-time across different applications is essential to your integration, then the answer is easy: you need synchronous APIs. No other technology solves the problem as well. But if you only have to communicate information once every day or week, then you might be served just as well by an asynchronous solution such as a traditional secure file transfer protocol (SFTP). After all, why invest in a race car for a simple drive around the corner?
For example, imagine a company that employs a hybrid workforce and makes use of different HR tools for external or international employees. Periodically, they have to gather all expense employee profiles and hierarchies from these various HR tools and synchronise them in the expense tool. This begs the question: is real-time user provisioning in the form of an API truly needed when the customer can only unify their employee profiles periodically? If they do not mind batch data uploads with a time delay, then file transfers might simplify the integration by easing bulk uploads and processing, while preserving maintainability and cost-effectiveness.
Aside from the question of synchronicity, you have to take into account how frequently and how much information you transfer. As mentioned previously, APIs shine when you use them to send small or moderate volumes of data at frequent intervals. Using them to handle large volumes in bulk, however, may cause various issues if you are unprepared. Examples of nasty surprises include skyrocketing cloud costs during peak times, big transfers that fail midway through the process or IT systems that turn out to be ill-equipped at handling unannounced and/or concurrent large data uploads from external parties.
Assume that you are a customer who processes expenses through credit card issuers. Depending on the credit card company you’re partnered with, they can either send you small chunks of credit card data in real-time or a large batch of data once a week. In the former case, an API solution would work just fine. In the latter case, the data processing might overload or paralyse your system. Various remedies are possible: adapting your solution to exchange data in smaller bulks, or opting for a less synchronous alternative such as transferring the information in the form of a secure interface and scheduling its processing through a controlled and optimised infrastructure.
The choice for an integration solution should in no small part depend on how standardised or customised your company systems are. Native API architectures work best when you plug them into systems that work in a standard way. But the more you customise your systems and (by extension) your data formats, the more you shift away from that 'sweet spot' that APIs were originally designed for. Many companies, especially organisations that have been in business for decades, tend to have adapted their processes and applications to fit their needs. As a result, their existing ecosystems are no longer fully compatible with standard API integration solutions. They would be forced to either tinker with the native API or cobble together other makeshift measures, sacrificing key advantages of API technology such as efficiency and automation.
If you highly value custom interfaces in your integration, that is a trade-off you will likely have to make when you make the choice for a standard API. Another valid option is to reduce your API to a plain data transfer solution, which would however negate the major benefits of having a full-bodied API. A third and often underexplored option is to opt for a more asynchronous architecture (SFTP). In some situations, they can be the most attractive choice in terms of ease of use as well as costs and benefits.
Take the example of a customer that employs a highly customisable system such as SAP S4/HANA. They use custom field names and itemise their accounting transactions in a very specific way to optimise their internal business processes and accounting. That approach, however, may leave them unable to use standard APIs out of the box without band-aid solutions. In such a situation, a ‘traditional’ file transfer method would offer the same functionalities at a fraction of the costs and effort involved, and greatly simplify the process of extensively customising the data format.
Data security is more important than ever in the age of privacy. Here, though, it should be noted that the type of integration architecture does not matter as much as the way it is implemented. APIs, SFTPs and other data transfer methods are all safe as long as the integrator has the necessary expertise to manage and maintain a secure implementation. One caveat, however, is that developing or implementing API security may require more technical know-how and capabilities than other options.
In some projects, we had customers opt for API-based integrations with basic authentication options such as basic auth. When implementing the necessary safeguards (e.g. firewall restrictions and TLS/SSL communication), problems involving API key protection popped up that were hard to remedy. In other projects, customers needed a highly secure authentication method with bearer tokens. But they discovered that the authentication mechanism was too difficult to implement within their company systems.
A high-quality SFTP client would have achieved an equal if not higher level of security through credentials management and other ready-made solutions such as IP whitelisting or trusted certificates. Sometimes, simplicity is the ultimate sophistication.
Evaluate your options
Considering all these factors, it is clear that a detailed thought process needs to precede any decision on an integration architecture. Yet all too often, we see that APIs are viewed as some kind of black box technology that can magically glue everything together at the press of a button. As a result, many companies insist on using APIs, the hottest product on the shelves, without even giving the alternatives a second glance. And thus, they often miss out on excellent options.
It is for that reason that we at Mobilexpense have an entire team of implementation engineers and product managers. As a partner, we offer you our combined expertise as well as a set of solutions that slots right into your existing ecosystem and evolves over time along with your systems. Rather than just handing you a standardised API service, we take a look at the ins and outs of your business and your personal requirements first. Only then do we propose the best, custom-tailored implementation method—whether that be APIs or SFTPs.
Make no mistake: APIs are a fantastic solution for tech integration and will become even more important as time goes on. However, very often, a different approach can give you identical results at lower cost and with much less hassle. Besides, your choice need not be permanent. There is nothing wrong with using a reliable, short-term alternative to get off the ground. Then, once your company is API-ready, you can implement standardised APIs to augment your integration experience with real-time capabilities and other features.
Ultimately, what matters is that you find a solution that meets your needs. To do that, you must first ask the right questions. And that is where Mobilexpense can help you.
You may also enjoy
these related stories