API integration issues #4: custom fields
Integration challenges hold businesses back, with data silos remaining a challenge for 90% of organisations. In this next instalment of our blog series about common integration issues, we shed light on custom fields, some of the common pitfalls associated with these and how to create a very smooth integration and automation experience with custom fields.Scroll to next section
Setting the scene (citing some numbers provided by a much respected competitor, Mulesoft from Salesforce):
“Study Reveals Integration Challenges Threaten Digital Transformation, With Organizations Spending on Average $3.5 Million on Custom Integration Labor Costs”
The same article further reveals that Integration challenges hold businesses back, with data silos remaining a challenge for 90% of organisations - a trend that is unchanged since their report issued last year.
In this blog series about common integration issues, we have already shed light on issues around breaking APIs, insufficient consideration of integration aspects on the cloud journey, as well as data sovereignty challenges.
Today, we would like to discuss the most significant root cause of integration challenges in terms of what is holding integrations back from being brought to life and functioning at all: customisation in IT applications. We believe this drives threats to digital transformation as identified by the study above in many ways. Let’s start with a case study.
Typical case for customisation
Imagine that you are part of the working group implementing a new IT system in your organisation. Implementing any new IT system in your business requires a great amount of effort. Often, as part of the implementation process, there are numerous process considerations and requirements of a multitude of stakeholders that need to be accomodated. These are then translated to functionality, which leads to tweaks to the standard setup of your IT system that is about to be implemented.
Your working group discusses this, and comes to the conclusion that the ‘why’ of customisation is very sensible:
> “customization increases perceived service quality, customer satisfaction, customer trust, and ultimately customer loyalty toward a service provider.”
Mostly, the customisation is organised via custom fields. These are areas where an application allows for flexibilities in its data model. Great news!
It is therefore absolutely relevant your group goes down this path, to make sure the implementation is a success.
You discover the amazing options of your new IT system, where it allows for this great level of flexibility, where it can mould around your organisation’s processes and key stakeholders. But then a big roadblock suddenly pops up: integrating your new IT system to other IT systems seems just too hard, once customisation has been built in. The laundry list of ‘what could go wrongs’ is very long and initial experiments with existing or DIY integration services fail.
The working group ultimately decides to implement a few manual workarounds. These sound very easy on paper, and like they shouldn't add too much to current workloads for those involved. But then, after implementation, they do, and are not very simple.
Where to go from here?
Online research shows that there are lengthy ‘back-and-forwards’ issues discussions on online forums occurring regarding custom field integrations. Most commonly the solution medium sized organisations pursue, is either the use of a DIY integration application that advertises the use of ‘custom fields’. Or the real hard road has been taken, and the organisation has built custom code.
Scenario 1: the DIY service, promising custom functionality
Unless you have an enterprise or equivalent software licence with an integration services provider, which is usually very expensive, and not affordable for many organisations, chances are there is no customer support on call for you to assist. This can lead to much frustration if you haven’t systemised and automated how to work with custom fields. As you might suspect, that is a niche profession in its own right.
What we also commonly come across is ‘the orphan integration’ in this context. There once was a contractor, who used an online service to develop something that worked, or James from IT did it but since moved on to his next opportunity. Either way, chances are there isn’t much documentation, and no-one else seems to be able to remember or figure it out. Maybe all associated credentials are lost, so even logging into the system presents a challenge. You get the gist: the integration’s days are numbered and a start from scratch is usually required. And it won’t make anyone happy, because anything that requires customisation equals a lot of work.
The other common occurrence is that there is a lot of shadow IT in this DIY space. People have taken matters into their own hands, leading to an ‘integrations cottage industry’. Often to the IT team’s frustration, but so long as they can’t offer a relatively affordable and easy alternative, it remains hard to convince staff otherwise. Having a single or a limited number of vendors that have a niche skillset to do integrations only makes a lot of sense in this context. From a cost perspective, but also so that the integrations meet any compliance requirements and there is proper error handling in place.
Scenario 2: custom code
If the organisation has opted to take the hard road, they have created custom code, or outsourced creation of custom code. The reason we say this is the hard road, is because essentially, these organisations are reinventing the wheel. It takes a long time to understand the intricacies of the different ways that integrations can work. The art of what is possible, and what works best in each scenario. To expect any developer that isn’t hyper specialised in this area to just come up with this, is not realistic. And therefore leads to pain down the track, felt by everyone involved with the process that the custom coded custom field integration is meant to support.
In a blog titled ‘What developers wish you knew about app integrations’, a lead Partner and developer of Krit, Kevin Hoffman, sums it up well. He goes into the main differences of a plug-in integration and something that’s totally custom, and compares it to laying a plank over a creek versus building a complicated bridge. We absolutely subscribe to his view of the world, and encourage anyone contemplating to build their own custom code for integrations involving custom fields, to read that blog post at the very least so they know what they are getting into.
The risks outlined above regarding departing contractors or employees, leaving behind orphaned integrations and to a degree, the integration cottage industry risk also applies to setting up custom code. Unless there is a dedicated integrations team established to handle custom coded integrations across the organisation systematically and well, we have not seen this scenario ending happily. And even though in principle the concept of developing a bit of code yourself may appear cheap and fast, we have seen many cases of this taking longer and being more expensive due to the lack of experience of the internal developers, as mentioned above.
Why does a service like Harmonizer alleviate these issues?
Because we manage the whole thing for you. We only need the process map and access to the APIs in scope, and that’s all. You don’t need to worry about anything else. We are hyper specialised in this area. The code, maintenance, updates, customer service, monitoring for functionality and security: we do it all for you. The best part is: this won’t break the bank - our fixed monthly fee is very affordable. If this sounds interesting, please schedule a conversation with us here.
This story is short and simple, because that’s all there is to it. Worry free.
Are you a SaaS company? Or an IT Consultant?
Keep reading below, if you want to grow your revenue.
Being able to confidently say that you can integrate to anything, no matter how custom the use case or application, has a lot of advantages in the objection handling phase of your sales cycle. When comparing your product to that of your competitors, your customer might just be persuaded by the edge that yours will integrate smoothly with what is important to them, without additional effort on part of you or your customer.
This is precisely what we can add to your value proposition. We fully understand you might choose to develop and maintain a few key integrations yourself, but no organisation that isn’t a niche integration player, can possibly offer them all. It may actually give you access to entirely new markets and verticals, if you craft a story and value proposition around this! We have certainly seen this happen with our partners Emply, Winkwaves, and Fellow Digitals for example.
For smaller software vendors or IT consultants, developing a story around integrating with well known names in the industry lifts your brand in the eyes of your customer. Especially coupled with a few testimonials of other customers using your service in combination with the established software brand.
In our letter to prospective partners, we already explain some of these benefits in more detail. For ‘custom’ benefits that apply to your situation, please head over here and let’s connect!
Photo by Girl with red hat on Unsplash