Ongoing value is rarely realised when you adopt a ‘set and forget’ approach to your technology. And truth be told, even the most diligent organisations pay more attention to the performance and maintenance of critical line-of-business applications than their APIs.
Yet APIs and integration platform costs and issues can mount up and impact not only organisational efficiencies but also your security and bottom line. With that in mind, here are some telling questions we suggest you ask your technology team about the status of your application integrations.
1. Do we have design and support documentation for our APIs?
Why is this an important question? Well, the lack of documentation is a red flag.
The existence of a well-documented set of standards and approaches is critical to the effectiveness of your overall integration strategy. Without standards in place, there’s no guidance for each contractor or new team member – and it’s open season on your integration development. So much so that it’s not underheard of for a peer review to uncover half a dozen programming languages and a range of different approaches in a single environment.
With no support documentation at hand, if there’s a problem at 2 a.m., there’s little choice but to rouse developers from their beds to fix the issue – a strategy which wears thin on morale and loyalty, fast. It can be the tipping point for an employee who is aware of their value at a time when IT skills are in short supply, and in high demand. With no support documentation at hand, issues take longer to solve, and both the employee and customer experience is eroded.
Over time, the lack of formal documentation makes the evolving integration environment (and the underlying chaos) harder to maintain and move forward. It essentially becomes a house that many builders have worked on with different tools and techniques – and will fail close inspection, let alone support another storey on top.
2. How secure is our integration platform?
A sure sign of ageing technology is that there’s no longer a support offering from the vendor. And when most integrations are internet-facing and vulnerable to cyberattacks, a lack of regularly doled out (and applied) security patches is a huge issue.
Yes, you can still protect your integrations and the applications they connect, but it requires a far more significant level of ongoing investment and diligence to keep them fighting fit. Often, security issues will bubble away under the surface, unnoticed until exploited and they break surface. But by then, the damage is done. This is not uncommon when integrations have been built using less secure legacy authentication protocols such as SFA, SSL, and custom authentication solutions, rather than using modern protocols like OAuth2 and TLS.
And you’re expending energy, time, and money in making urgent fixes and urgently upgrading protocols, instead of focussing on development that advances your business. Another red flag.
3. By the way, how’s our coding looking?
This one ties back to the very first question.
Each vendor has their own set of carefully developed standards and approaches to APIs and integration. And the only way to tell if your integration reflects best industry and vendor practices is to lift the hood on it with a code review.
If your integration team or partner has adhered to the vendor and industry standards, then well and good.
But if not, your integrations can cause performance issues which impact reliability, visibility, maintainability, and more. And as we all know, when something’s not running to spec, the costs mount up, and operational efficiency goes down.
4. Has anyone reviewed this gold-plated integration proposal – or are we just signing it off?
If you’ve got existing cloud or PaaS platforms, an annual cost review is a wise exercise. And the expense is likely to be covered by the savings realised from it.
But backing up a bit – it’s also prudent to have your platform design reviewed before it’s built. This way, you can independently verify that the proposed implementation matches both the business case and budget. In addition, a review can identify where a design is overblown due to an excess of unnecessary components, or even falls short, and if there is any vendor funding available to offset the build costs.
Out of interest – a recent review of another partner’s design saw us recommend that the customer could rationalise a swag of unnecessary components. The customer took our advice and realised an ongoing saving of $6000-7000 per month – without compromising performance or security.
5. How do we know if our user and customer experience is standing up to the test of time?
Age slows us all down, and technology is no exception. And our users and customers are always the first to notice it – and kindly point it out to us.
Performance problems often creep in when you’re using a legacy integration platform (as opposed to a modern PaaS platform). Failing to maintain an environment over time means that the volume of data stored and managed results in exponentially growing databases. So a transaction that took two seconds to run when you first implemented your platform can display significant performance issues down the track – frustrating users and causing customers to abandon the web application they need to do business with you.
A regular health check of a legacy integration platform (much like a senior wellness check) can identify maintenance issues. And with proactive monitoring in place to alert you to performance degradation (for example, when a transaction takes over six seconds), it’s easier to pinpoint and remediate problem areas.
As well as scrutinising performance on an ongoing basis, it’s essential to monitor failures or error logs. Best practice is to set up notifications and direct them to your ITSM (IT Service Management) portal for escalation and resolution. Unfortunately, we all too often see issue alerts distributed wide and far around the business via email – and assigned to languish in an ‘I don’t know what to do with this’ folder.
6. Are our APIs designed to a specified industry standard?
API design makes a significant difference to the cost of delivery. When designed with industry specifications standards, for example – using OpenAPI Specification, you end up with a detailed description of how the integrations work. You can then share this standard with your partners so they can integrate with your applications more quickly.
Specification languages also enable more rapid API delivery – and save you time and money. For example, one of our customers was averaging a $15,000 cost per internally built API. By using more efficient development processes, our team delivered their APIs for $5,000 each, freeing up their budget and resources for other projects.
A mature development lifecycle also contributes to a reduced delivery cost. APIs can be recycled, rebuilt and repurposed, making future ones cheaper to develop.
7. How quickly can we deploy our integrations?
If your organisation manually deploys new or upgraded integrations, it can be a time-consuming and overly complex process. By the time someone in your business has spent six hours documenting then an additional two to three days carrying out the deployment and troubleshooting each release, you’re racking up unnecessary costs and delays. And when you have multiple teams involved, the whole process can often take on a rather nightmarish quality.
By automating the end-to-end deployment process (aka continuous deployment), the time required to deploy can be reduced from days to just a couple of hours. It requires an initial investment to set up the base infrastructure and platform and define the approach, but once done, the savings are immediate. When your ability to respond rapidly to market disruption and new opportunities is critical – speed of delivery is everything.
Test automation (aka continuous integration) is also an important consideration. Automated testing is a software testing practice that tests an API’s functionality, reliability, performance, and security. It also validates the logic of the build architecture – at speed. By comparison, a poorly performing organisation will have almost zero test automation, so they find making changes to a deployed integration not only difficult but likely to add a week to the process. When a new API can dramatically impact business, an extra week makes all the difference.
What’s the key to your integrations earning their keep?
Without good strategies and approaches in place from the outset, ‘everything integration’ takes your organisation longer, costs more, and presents you with a greater risk of errors and outages. Outages alone constitute a significant concern. Without best-practice architecture, testing, and development standards, the likelihood of outages increases, and the cost per hour to organisations is phenomenal.
If you want some sobering reading on how much an unplanned outage could cost you – check out this blog which references research from Dun & Bradstreet, Gartner and other research giants.
The speed of improvement in cloud technologies will outpace your strategy. So an integration architecture and strategy put in place ten years ago needs to be reviewed, refined, and adjusted regularly. If controlling costs and improving performance is important to your organisation (and when has it never been?) – an annual health check will ensure you’re getting the value from your integrations that you expect and deserve.
