BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
For organizations that are looking for a way out from under the burdens of their legacy infrastructure, application program interfaces are becoming an increasingly attractive option. Zeev Avidan, vice president of products at OpenLegacy, discusses the typical approaches taken when using APIs to modernize legacy infrastructures, why RESTful APIs are so important in these initiatives and the reasons why many organizations' "legacy" infrastructures may actually be more capable than they realize.
What are the typical approaches when using APIs to modernize legacy infrastructure?
Zeev Avidan: I would say there are two approaches. There is the very common approach: [you] take your normal service oriented architecture (SOA) with the connectors you already have for your legacy system, ... and at the end point you add an API connector, or an API layer, on top of it. We don't really like this approach -- we don't think it's a mobile first approach.
So another approach is to go with API architecture, which basically means that an API is connected directly to the back-end legacy system. It's not necessarily installed on the legacy platform, but it is roughly the legacy system. And for each system there is a different "wrapper," but basically you don't have [to integrate] local service stuff with different services, which we don't consider very suitable for mobile first strategy.
What kind of APIs are you leveraging for these efforts?
We provide the API itself, but you can also go one step forward and automatically produce the [software developer kit] -- maybe iOS, Swift or Java for Android -- that traps these APIs, so it's not just the functionality of the API. This SDK can also be used by the mobile developer as their full-functioning live release. So it can go as deep as the API, but it can go deeper than that and it can really provide the SDK functionality around the API.
Will using RESTful APIs for modernization always work, even on older technologies?
It very much depends on how exactly your back end is built. For example, if you use "green screens," which is, I would say, the most legacy of legacy, ... if you provide a way to expose them [through] APIs, [then] basically you're wrapping the accreditation layer. [And] if you have [a] COBOL program, ... you can just run them and wrap them as APIs. Then the problem isn't really that big, ... it's [a] COBOL transaction instead of [a] Java transaction, but basically it's the same type of technology.
Do you find that organizations' legacy systems are actually more capable than they realize?
Avidan: Absolutely. For a lot of customers, they went out and embarked on very elaborate projects to migrate from the legacy without realizing that, for a fraction of the cost, they could have achieved the same functionality and much more on the legacy system if they just used the same platform and migrated the applications.
But I would say a lot of customers have these concerns about a skills gap. Not many out there are skilled with COBOL or assembler for mainframe, but you can absolutely run Java-based applications on a mainframe, and you get all the benefits of your previous investment. I think there was a period of time that a lot of people in the organization were not very aware of this and many migrated. But for a fraction of the cost ... they could have got much better results for much cheaper. But I think that now they're realizing it more and more.
Discover the role of RESTful APIs in B2B integration.
Is it possible that Web services violate REST principles?
What every RESTful API testing program should entail
Are there REST alternatives for real-time apps?