Integration vs. Modernization – When and Why?

Andy Blank, Prolifics VP Technical Sales NA, is a proponent of modern integration methods, such as using APIs and cloud platforms for systems integration.

We asked Andy to take a step back and we talked about integration vs. modernization of the systems themselves.

You talk about a modern approach to integration. We understand that the integration can be done through a modern approach, but aren’t some of these systems pretty old? Do you look behind the integration and advise on the original systems? 

Yes, we do. It’s all about the original systems. Integration is about not touching the original system. Say you have some giant SAP platform, for instance, which is running your business. Let’s say you have all of your invoicing through it, and you have all of your suppliers and your logistics through it. And who knows, maybe you also have an HR module for it – with all your people who are running your business in it. You’re not going to get rid of that. You’re not going to change it, but you also have an e-commerce website. And now your fancy new e-commerce website built on a different platform needs to get and inventory from your SAP system.

So, you need to integrate them, right? Most of the big vendors who run these systems – JD Edwards, PeopleSoft, Oracle, and SAP – those vendors are building integration points. Some of them are building their own integration middleware as well. But they’re building integration points, mechanisms for getting information into and out of their system because they know that other systems need to speak to them.

Outside system integration tools, like MuleSoft, really are just standardizing how they’re integrating to the different systems. And sometimes they adapt behind the scenes. If you have very old systems that can only integrate via files, that’s what you’ll get. If you ask for an extract, they’ll send you a text file. Or if you want to put information into them, that system will import a text file. So, some of these older systems have an old-fashioned way of getting data in and out of them. You might have to read from, or write to, a sequel database directly.

But most of the newer environments will simply hide that behind an adapter. You either write an adapter, or you call up adapter that exists out of the box. And you talk to that system. The whole point is that yes, at some point you have to talk to the old system in the old way. But you want to hide that behind an abstraction layer so that everyone is talking using a common language that they’ve agreed upon – in this case APIs.

But at what point, do those systems themselves have to be modernized or upgraded? It may be five or 10 years from now, but at some point, you’ll have to modernize beyond APIs, right?

That is correct. The endpoints systems that you’re building integrations among so that they can talk to one another, those endpoint systems do have to modernize. People do version upgrades all the time. The people who have to upgrade their version of SAP, as an example, are probably not happy about it. Because these tend to be like multi-year projects. And they’re very heavy. And they take a long time and a lot of effort at millions and millions of dollars, and they don’t want to do it. So, they might do it five years from now. They might do it 10 years from now. They’ll do it when they’re forced to.

As an example, there is a client with a system called Island Pacific, which I think is almost 20 years old now. So, they’ve been talking about doing an upgrade of that to the modern version. The old version is so old that all you can really do is send it text files. And so, every time we want to talk to that system, whatever we’re doing, we have to convert it to a text file, and send it to that system. And they will eventually have to do an upgrade to that system. But sometimes the upgrades are so painful that companies decide to just change it out.

At this point, by the time I upgrade that system to the modern version, maybe I’ll go find some vendor who’s selling a new application that does the same thing. And it will be cloud based and web based and modernized and rewritten. So, those are all calculations that Prolifics helps companies make constantly every day. What systems to upgrade, what systems to replace, where to write integrations and how to write the integrations between those systems. And it’s all kind of a balancing act.

About Prolifics

Prolifics is a digital engineering and consulting firm helping clients navigate and accelerate their digital transformation journeys. We deliver relevant outcomes using our systematic approach to rapid, enterprise-grade continuous innovation. We treat our digital deliverables like a customized product – using agile practices to deliver immediate and ongoing increases in value.

We provide consulting, engineering and managed services for all our practice areas – Data & AI, Integration & Applications, Business Automation, DevXOps, Test Automation, and Cybersecurity – at any point our clients need them.

Email solutions@prolifics.com or visit prolifics.com.