I have consulted on large system implementation projects for an exceptionally long time (25+ years!). In that time, I have seen dozens of projects, each with its approach. Twenty or so years ago, there weren’t many options for Interface Development and a Platform for integrations with other systems, so companies built them custom. There wasn’t much choice but to build them, so even companies whose primary business isn’t software development got into the software building game. Thus came the proliferation of custom software development at companies whose primary business is not building software.
So, as the last several decades have passed, companies have made a couple of different choices when integrating systems within their organization: 1. Build custom software interfaces, or 2. Use a tech-heavy tool to apply some standardization to software interfaces. In both cases, they’ve had a reliance on Information Technology (IT) groups to help support those interfaces, often without any context of how many or how complex their integration environment was becoming over time. And as other priorities come up and IT organizations are strained to deliver on a myriad of different projects, their ability to support and advance existing software steadily declines. Even relatively small, but extremely impactful, changes for the benefit of the business get put off because there is no time or budget for such small efforts. There are other priorities, and the small stuff often doesn’t get done.
This wasn’t twenty years ago. But the corporate baggage of all this custom development has piled up over the last few decades (or more?!). Companies are in trouble and some of them don’t even realize it…yet.
As technologies like the Cloud have become more trusted and available, software companies have started to offer software-as-a-service in record numbers. These companies, some of them new start-ups, have begun to offer standardized software in areas never-before seen. This includes offering software that allows different systems to talk to one another more easily through standard interfaces. By this, I don’t mean standard “protocols” like SWIFT messaging or FIX, which are “standards” in the Financial Services industry. I mean software that implements these protocols for companies in a simpler, more standard way.
While integration technologies aren’t new in the last few years (tools like Informatica have been around for decades now), the end users that integration software is built for today and the overall User Experience (UX) has. Tools like Informatica were built to be used by people that had technical skills or knowledge. The better tools today often leverage more user-friendly technologies like Natural Language Processing (NLP) and modern User Interfaces (UI) to supply tools to non-technical (business) users to allow them to perform what can be extraordinarily complex tasks without understanding software development or programming.
Fast-forward to today and there are thousands of existing companies that have developed custom software that allows their internal systems to talk to each other. In most cases, those custom interfaces haven’t been touched, updated, or improved since they were originally developed. No advancement. No innovation. Only status-quo. Worse, the business risks continue to grow over time, as new, more innovative competitors appear, key-people who know and developed those interfaces begin to leave the company, and technologies used become outdated and become unsupported.
It doesn’t have to be this way. It SHOULDN’T be this way for companies anymore. It’s not necessary, given all the advancements over the past several years. Today, you have software tools available with the ability to handle various levels of complexity. There are tools like Zapier, which allows for very quick, basic integration between systems. Mulesoft offers an ability to manage all the various APIs used by an organization, albeit requiring resources who understand such technical things. Tools like Emissary help non-technical users to build complex interface development and data comparisons in a fraction of the time.
If your company is still building custom software or supporting custom interfaces, and you don’t work for a software company, it’s time to reconsider how you’re working. With the advent of the Cloud, advancements in communication, changes in pricing to more subscription-based pricing, and the proliferation of new offerings, there is little reason for companies to develop their own. Focus on the business you are in and get away from developing custom software.
