Thoroughly Modern: Strategic Things to Consider With APIs and IBM i
August 10, 2020 Timothy Prickett Morgan
The great thing about application programming interfaces is that many of the ways that programmers need to interact with system and application software are predefined and allow for consistent access to features and functions as well as data. To a certain extent, the APIs are what make such software useful. The API describes how the interface works, and libraries (in the sense of the software market at large, not the OS/400 and IBM i definition of that word) are developed to implement the functionality of the interface.
The fun bit is that not only system software makers like IBM get to make APIs, but so do other tool makers and application software providers and – here’s the fun bit – programmers can create their own APIs to meet their specific needs. This can be a bit like the wild west if not brought under rein.
To get a sense of how to approach APIs strategically, we had a chat with Marc Hunter, vice president of innovation at Fresche Solutions.
Timothy Prickett Morgan: Thanks for taking the time. We haven’t had a chance to speak before. Let’s start with a little bit about yourself and what you do at Fresche?
Marc Hunter: It’s great to be here. My role at Fresche is vice president of innovation, which is a relatively new role within the company. It’s pretty exciting because it lets me push the edges of what we do based on where there’s customer interest, the perception of value or the possibility that there will be value down the road.
TPM: That puts you in the front row of getting insight for the innovative things that customers are looking to do and some of the challenges they are dealing with.
Marc Hunter: To a certain degree, it does. Our Client Advisory and Presales teams also have a lot of interaction in that area. On a recent project, we collaborated and worked with the client to determine their needs and then we evaluated what the Product team had available. We then worked with the Product team to build in some automated capabilities and bridge that gap to get the project done so the client could take the solution to market quickly. That’s a big part of the innovation side – simplify the complexity and speed up time to value.
TPM: I understand that Fresche is doing some interesting work with APIs these days. I assume the market has a lot to do with that. What are companies looking to do?
Marc Hunter: At the highest level, a fundamental problem most IT departments have is complexity. Applications get bigger and complicated. This is known as the monolith: People start writing code, and they write more code, and the code gets bigger and bigger and bigger. It starts to exceed the capacity for anyone to think clearly about it.
The more complex the code is, the more error-prone it becomes. This makes it difficult to advance the state of that technology because you end up with some terrible all-or-nothing choices, where you might need to throw out all of the code or stay with an outdated technology or approach.
One solution to complexity is to subdivide. If you subdivide a complex issue into two, three or 500 things, you make it smaller. Smaller is inherently better because it’s easier to understand and it can be replaced independently. You’ll often hear words like modularization to describe this concept. API stands for application programming interface and API brings the interface to this particular challenge. The interface is the way things talk to each other, the connection, and the glue.
If I decide to subdivide my application in two parts, how will those parts talk to each other? The way they talk to each other is an interface. And so, an API is a definition, a description, a convention, a language, a protocol, an agreed-upon way that we’re going to exchange information.
In the human sense, when you pick up the phone, we have an interface. We have a standard series of acceptable phrases that are used to initiate communication. In our case, right now, we’re using English. That’s the protocol that we are using to transmit information between my part of the world and your part of the world.
When we’re talking about modules, we want to simplify it as much as possible. Fundamentally, the promise of API is to bring simplicity to a very complicated software problem, which splits our code up into smaller pieces. Now, we need to make sure they can all work together.
TPM: Is it all about splitting things apart, or could it be independent pieces that need to talk together?
Marc Hunter: That’s another way of describing splitting things apart, right? You may not have had a single code base that did it all before, but you have a single problem that can be solved by different components, by different technologies or by different vendors.
Broadly speaking, when you have an API, it means you have a structured way that you can work with that third party. When you break things up, everything becomes a third party in a sense. You have the code that lives in its bucket and everything outside of that bucket becomes a third party. If you have a well-defined API, it doesn’t matter whether the third party is code that you wrote before, code that you wrote yesterday, code that was written by a consultant or code that exists in the cloud.
TPM: Could you share some of the challenges that customers are approaching you with?
Marc Hunter: One of the most popular type of APIs are REST APIs. There are a lot of reasons why they’re popular, but one of the most common uses of a REST API is to divide. You might have some back-end code that needs to work with databases and business logic, but its job has nothing to do with what things look like.
Then you might have other code that’s Angular, React, or plain old HTML and JavaScript. Its job is to make things look a certain way, interact with user input and digest what the business operations should be. This is a division that is great to make when you’re designing an application. One reason for that is the developer skills are quite different when they’re working in one area versus another area. Front-end developers have a different skillset, different areas of concern and different technologies. Ideally, you will have a front-end development team (if your organization is big enough), as well as a back-end developer team. This allows everyone to focus on what they do best, and those areas can talk to each other through the REST API.
Some things evolve faster than others. Your front end may evolve quickly, and you may decide in 24 months that you want to redesign your front end, or you want to add a mobile front end. If you’ve designed your application with an API mindset, these changes don’t affect the back end.
Another category of APIs is interfaces between platforms to divide the back end for the application from the front end. For example, our customer portal integrates with Salesforce, and we can reach out to Salesforce to retrieve information. We can also reach into our own systems to get information. In a sense, you can build aggregator solutions that take the best from different providers. If you have an eCommerce application, you might have a payment processor, or you may interface to a shipping company to find the status of where a package is. You might interface with Google in order to show a map. The possibilities really become endless.
TPM: Is it difficult for people to build APIs?
Marc Hunter: The degree of difficulty has a lot to do with your development culture and the age of the application you’re dealing with. I would propose that anybody writing a new business application should do it with an API mindset. You have to think in that way in order to organize the responsibilities. It’s like a business, where we create job descriptions. One person has a set of responsibilities that’s different from another person’s responsibilities.
In API-based development, we take a complex problem and subdivide it. If you think in those terms, you’re off to a good start. However, many customers started writing an application 20 years or even 30 years ago, and that wasn’t the way of thinking. They have the challenge of taking a big piece of code and breaking it up to make it more API-friendly.
We think of this as unique to the IBM i world, but almost every large company starts by writing software until it gets big. All of a sudden, they realize that this software that is essential for the business to operate is starting to slow them down because it’s too complex.
If you were to search the internet for advice on how to break up the monolith, you would find hundreds, maybe thousands, of YouTube videos and discussions because it isn’t a technology problem as much it’s a problem with how the application was originally designed.
TPM: Is there something that works better for IBM i applications and companies who might be approaching an application with monolithic code?
Marc Hunter: There isn’t really a one size fits all. When our team looks at the problem that a customer has, they come up with a solution that best fits that particular need.
That said, perhaps another division in the company has designed a front end on another platform, C# or in Angular. Now they’re approaching the IBM i people and saying, “We need this information from you.” If you expose a REST service from IBM i (which is not hard to do with our tools), you can service them in a way that they’re familiar.
It really depends on what the business problem is. In some cases, the business problem is slow development. That may involve a more comprehensive analysis of the application so it can be split up more. Maybe it needs a different kind of API or a different kind of interface.
TPM: Now, most legacy IBM i applications have been running for decades, often with millions of lines of code. Do you have a recommended approach in terms of how to carve it up?
Marc Hunter: Great question. This can get a bit tricky. We have our X-Analysis tool that help with the analysis of a large IBM i application. This is a great place to start when you’re looking at considerations and determining what links to what. These monoliths are almost like a spider web, where everything tends to touch everything.
Initially, you might want figure out how to cut a thread and slowly disentangle different parts from one another. Tools like X-Analysis can help you figure out where to cut. From a technical perspective, it will show you the program that is looking into something that it shouldn’t. Maybe it should have an interface instead of directly grabbing data from another place. It’s a little bit surgical in that sense. A tool like X-Analysis gives you the insight into where your surgeons should work. In many cases, this would take place before you start designing an API.
TPM: I understand that you have been enhancing Fresche’s tools and that you have built some capabilities to make it easier for customers to develop APIs for their applications on IBM i. Can you talk a little bit about that?
Marc Hunter: We’ve expanded on the API capabilities in WebSmart, for new RPG or PHP web application development, and Presto, for modernizing existing green screens. Our Nexus Portal solution also uses APIs to manage users, groups, permissions and more. In many cases, our customers are at the beginning of their API journey. They want simple APIs, very quickly, because they’re often in a budget constrained situation.
One of the most interesting examples is WebSmart. WebSmart generates programs in different languages based on different inputs. One of the new capabilities that we’ve added is to use the OpenAPI specification. OpenAPI is an industry standard way of describing a RESTful API. If you’re a company that is using this to keep track of your APIs, or if you want to use this to manage and track your APIs, WebSmart now allows you to use that description of an API to generate the actual API framework.
One of our customers recently used the OpenAPI definition to generate an interface to an existing back-end program. The changes to the back end are very minimal at this stage. WebSmart allowed them to quickly expose their existing back-end capabilities through a RESTful API to another internal application that isn’t on the platform.
I know there are a lot of buzzwords in there, but the key difference here is that WebSmart is letting you start the design process based on an industry standard OpenAPI specification. While this feature was developed for a specific customer need, it opens the door to a host of possibilities for other ways to implement APIs, which we’re excited about.
Presto has had an API for a number of years that involves manipulating your green screen session. Say you’re on a webpage and you want to start a green screen session. You then want to navigate through a menu option to another menu option and type in a value, then retrieve something that was on that screen and give it back to a web application…. This is a case where the application is too complicated to create a clean API.
Instead, you can create almost a “virtual” API and that enables you to navigate through the green screen application and extract the piece of data that you’re looking for. It’s a little more complicated, but it has the added benefit that you don’t have to mess with the back-end code. Sometimes it’s a third-party application or an ERP on the back end. Sometimes it’s so mission-critical that nobody wants to modify that back end in case it breaks.
Previously, the API in Presto was a JavaScript interface. That meant that you could only leverage the feature if you were in a browser or somewhere that was using JavaScript. We came across a client who was using a C# application and they wanted go to a green screen via a C# application to retrieve arbitrary data from different places within the session. To accomplish this, we added a new Presto feature where the API is now a REST API. This means it can be accessed from essentially any language, making it more flexible.
TPM: Do you have any words of advice for someone who is about to begin looking at developing APIs?
Marc Hunter: What I would say is keep the faith. The reason I say that is because it’s kind of like diet and exercise. It’s absolutely essential to long-term health. If you neglect it today or tomorrow, it’s not going to make a big difference. However, one of the most dangerous aspects of software development is to put aside some of the higher-level concepts like API development and modularization because you have important things to do right now. When you do that, you create future problems, which are much harder to solve because they become larger problems in the same way that we talked about earlier.
It’s worth taking some extra time upfront to think about subdividing your efforts, how you might split out the functionality and how you might delegate functionality to the proper stakeholders. If you invest in that upfront, it will absolutely pay off down the road. So, keep the faith and think big.
If you’d like to learn more about how Fresche’s IBM i web and mobile development solutions can help you build APIs and leverage your investment in IT, check out this recent webinar: Achieving Quick IBM i Modernization Wins with Web and Mobile Development
This content is sponsored by Fresche Solutions.
Marc Hunter, vice president of innovation at Fresche Solutions is cut his teeth over 25 years ago developing IBM i modernization tools on an old B10 above a garage. Today, he leads the Fresche innovation team from the Sidney, BC, Canada, office.
Hunter is passionate about software development and problem solving and has taken multiple products from conception to successful launch. As a serial tinkerer, Hunter is always exploring new ways to bring value to customers and is constantly seeking to improve development processes.
Outside of work, Hunter and his wife manage a three-ring circus – life with five kids! He also coaches a FIRST Robotics team.
