In a blog article earlier this week I reflected on the DIY perspective that IT people espouse when it comes to integration in their own companies. I titled the article 5 Lies. These observations were borne from conversations in the first half of the year with prospects across North America. At the same time I also had similar conversations with companies who continue to custom code integrations for their applications. Sometimes these were application providers our customers had to interact with because their trading partner used the particular solution, or sometimes it was application vendors who were intrigued by our integration offerings and contacted us.
During those conversations, it was clear that these companies were sometimes unaware there was a better way to approach the integration of their applications while avoiding the issues of “do it yourself” custom code. Sometimes it was because they were stuck in an old business model that was at one time very lucrative but increasingly having a negative impact on their business with frustrated customers and negative customer feedback. What was also clear was that many applications are in a state of transition. Driven by cloud offerings with robust APIs, many legacy systems are bolting on integration pathways or are remaining with the old school model of “we do it all”. So here are the 5 pitfalls I identified.
The 5 Pitfalls
I Don’t Need Your Middleware, We will Custom Code the Integrations; 15 years ago most software companies tried to provide the all in one platform to their customers. The thought was lock your customers in, we do everything for them, they have one neck to strangle and Bob’s your Uncle so they are better off. Well as Dylan sang “Times They Are a Changin'” and they have changed in a giant way that have caught many application vendors flat footed. There has been an explosion of easily consumable cloud platforms that users can turn on and off as needed. The problem is linking those inhouse and cloud based solutions to each other. A long list of analysts, from A to Z, have identified this as a major IT issue. So the application vendor that tries to custom code each and every integration is doing their customers a giant disservice. First, you have to ask yourself what is your core expertise? If its integration then you are not an application vendor, unless of course you sell middleware. If you are an application vendor it is probably not coding integrations to a disparate list of cloud and on premise solutions that is your core expertise.
We Have to Custom Code Because No One Knows our Application as Well as We Do; This argument usually follows the I don’t need your middleware argument. Let’s face it. Application vendors and their agents make money on custom coding. I won’t deny it. The bigger question is whether customing coding is of benefit to your customer. I frankly don’t think so. I have spoken to so many companies who are really fed up with their application vendor, who charges a kings ransom, takes too long or even fails to deliver on custom coded integrations regardless of how well they know their own application. This puts their customer in a difficult situation. They potentially lose business because of their application provider and in turn feel like they are being held hostage. Not a good scene all round. So this begs the question, do the labour costs to the client and the opportunity cost of your developers’ time to focus on more strategic and repeatable business worth something to the business?
VL as well as our partner Liaison offer solutions and expertise that allow application vendors to address these pitfalls. We would love to hear your thoughts.
Become A VL Partner