The world is an ever-changing place, and that means there is always something new that needs to be done to either improve applications running on the IBM i platform or to integrate them with other applications or interfaces on new kinds of devices. This is an important aspect of modernization, and one that often bridges the back-end databases and applications and the front-end interfaces through which end users access those applications – both of which need to be modernized, and often independently.
This is made possible by having application programming interfaces, or APIs, and if IBM i customers have tens to hundreds of databases, and hundreds to thousands of applications across their systems, they will eventually end up with thousands to tens of thousands of APIs that allow the sharing of the functionality of their applications and also allow a means to reach out and use the functionality of other software.
One of the biggest areas that we see growing is in what we call digital solutions. A digital solution is many things but mostly it’s about how the IT organization enables the business to provide better digital experiences to customers, partners, and internal employees. It includes all kinds of things, and this is by no means an exhaustive list. The APIs behind the digital solutions are created to help companies do something better. It might be to improve business processes, such as making it easier to order items for customers or to make more useful information available to self-service buyers. The one improvement that we hear most often is the need to reduce the amount of time customer service reps are on the phone with people, providing them answers, processing orders, sending out invoices, whatever it might be. Or, manual processes that have people in the middle are automated so two different systems can integrate and manage that process automatically. There is also a fair amount of integration of information stored in the IBM i systems with third-party applications or shopping carts, where customers need to exchange information stored in the IBM i system, whether it’s pricing, inventory, product numbers and descriptions, and so forth.
Just like everything else that is new on the IBM i platform, such as refacing applications or developing Web applications from scratch or integrating with third party applications, developing APIs is also new to some IBM i programmers. So they either need help through programming services, which we offer, or through products such as our WebSmart or X-Elevate, which launched last September. X-Elevate is a tool born of necessity, and was created nearly four years ago specifically because Fresche Solutions needed to automate the creation of free form RPG applications and APIs as part of big application modernization and application development engagements.
We have customers that are using API middleware servers or various open source tools to manage their API links between applications and interfaces, but there is a lot of custom API creation, too. We’re working with organizations to help them understand, adopt and implement the best approach for them – and teach IBM i shops how APIs can be used for integration and best practices for developing them in myriad languages. Then, they can be off and running, creating new applications or extending old ones.
What we see most often, and this will come as no surprise to any IBM i shop, is that companies often need a set of APIs that are very specific to their applications and their third-party integrations. There are very few companies that have such APIs already in place or tooling for creating it. And we are also seeing situations where companies are acquired, or buying companies, and they need to be able to integrate their various internal systems. The parent company might, for instance, have SAP applications and the acquired company has homegrown applications written in RPG, and sometimes there are sister companies where information needs to be shared across different application stacks. This is driving a lot of API activity because no one wants to replace applications that are working just after doing an acquisition. That may be a long-term goal – and it is often a long-term goal that never comes to fruition, by the way. The disruption and risk is not worth the limited benefits from a wholesale change like that.
That is also why we often work with ERP vendors to create API integrations into their applications so customers can expose these APIs to their customers and partners. Another example is that a customer wanted to create a native mobile application from scratch and they needed to do a direct integration with the Db2 for i database.
The main thing that IBM i shops need to be doing is to be thinking about how new digital solutions and APIs are part of their application strategy. APIs are not an afterthought or a bolt-on, they are absolutely integral to the applications. The other thing that they need to realize is that everything is possible, that you can in fact integrate the IBM i with anything and anything can integrate with the IBM i, and they can do it with RPG, PHP, Java. Node.js, Python, or whatever. And finally, organizations don’t have to go it alone – we bring the expertise, process, tools and services to help get IBM i shops started, today, and become self-sufficient in the future if that is what they want.
