Talking Modernization With Profound Logic

Modernization, in its many guises, seems to be a big driver of the IBM i ecosystem these days. For a long time, high availability software was major propellant diving the market alongside System/38 and System/36 upgrades–a kind of modernization effort in its own right. Then along came the ERP wave in the 1990s, and packaged software is all the rage. Now, the diehard IBM i faithful need to update their code to work with modern devices and to look and feel like other modern software, and they need some help.

A programmer or two using good tools are perhaps better than a dozen programmers coding things from scratch, and even if they are not, using the right tools to modernize applications can speed up the process considerably. Time is money, so it all comes down to return on investment in theory. In practice, modernization projects don’t always meet their goals, so in a sense their ROI is negative.

Last week, we had a chat with Alex Roytman, founder and CEO at application modernization tool maker Profound Logic, about what is happening out there in the IBM i base and get some insight on what is happening with modernization efforts and how this might help bolster the IBM i community over the long haul.

Timothy Prickett Morgan: You know me well enough that I always want to know how many, how much, and all kinds of metrics about any phenomenon–and application modernization is no different. As far as you can tell, how much activity is going on in the IBM i market, what kinds of applications get modernized, what part of the portfolio tends to get modernized, and what are the prospects for growth here? That is a lot at once, so let’s take them one at a time.

Alex Roytman: I have a different take on what modernization is, actually, so let’s start there. I think that it is a continuous process, meaning that the applications that we feel are modern today are not going to necessarily be considered modern five years from now. So it is something that you have to do on a constant basis.

So we are working with a ton of customers that have modernized, but with older technologies, such as screen scrapers as one example, and now they are moving beyond that because we provide automated tools to go at the source code level and take you beyond the 5250 protocol and not have those limitations. So they kind of went through one round of modernization and that was good for its time, 10 years ago, and now they have the opportunity to take these same applications, which might have been taken to a client/server interface, and now the standard is a web browser and the next thing may be mobile.

That is on the user interface side, but on the application code side, the same type of stuff is happening and there are many different ways to get at it. So you can start modularizing RPG code and improving it, and now there are new open source options available. We are getting very big into open source, and that is JavaScript and Node.js on the server side, and that is a fairly new, cutting edge to some extent. It feels to me like a wide open market, and if I were to predict, there will be something like us to work on and technology to come up with many years down the road. If you are able to keep up with the pace of change, there is always opportunity to modernize something.

TPM: What do application modernization projects look like out there in the base?

Alex Roytman: I think most of the shops still have yet to fully modernize, and they have work to do. Customers have projects that they started 10 years ago and they went down the path to rebuild things in Java or PHP, but what I see is that sometimes, companies are maybe just a little too ambitious and they have big applications that are ERP systems that run an entire company or division, and it is not easy in one go to replace or update everything.

So often what you see is that people head down one road to modernize, say by rewriting it in Java or PHP, and literally, 10 years down the road they have only done 15 percent of the code in the entire application. These are typical scenarios that I see, and now there is a need to do something with the green-screens and RPG on the other 85 percent as well as maybe updating the 15 percent again.

TPM: My sense of the IBM i customer base is that there are somewhere between 20 percent and 25 percent of the customers who are very active. They are on Software Maintenance support, they stay relatively current with a modern machine with a fairly new operating system release, and that penetration is not abnormal in the IT space by any stretch of the imagination. Unix, Windows, and Linux systems have the same ratios of current to vintage.

Is that active portion of the IBM i base a fair foundation for a total addressable market for application modernization, or can you try to attack the whole base because it is less painful to modernization applications than it is to move off of the platform. The base is losing something like 2 percent per year, which is not as good as growing mind you, but it is not a mad dash for the exits, either.

So how big is the target for modernization?

Alex Roytman: I feel like it is a bigger target market for us than just those companies who are staying current. Even those that have plans to get off the platform, which we don’t promote or support, they either realize right away or after some attempts that this migration is not going to happen very quickly. So they have to do something with the existing system.

One of the things that we are doing with Node.js, which helps companies if they are moving some applications to a different platform, is that with Node.js you can communicate with that new platform and meanwhile talk to the existing platform. We have some very interesting technology that we have built that allows Node.js to be very tightly integrated with existing IBM i applications. So for those moving to open source tools, Node.js and its links to IBM i are not in a different silo and therefore you can do it iteratively. So it is not going to be a project that takes ten years and millions of dollars and only after that time will you see if you were successful or not. You are able to get things deployed on a regular basis and see ROI much quicker.

TPM: The hyperscale companies like Google and Facebook certainly operate that way. They are doing continuous development, and frankly, most of these companies were doing this from the day they were founded although it was not called continuous development at the time. This is the way to approach things, and it seems to me that big bang software projects are pretty much dead. I don’t think anybody can afford to do this.

I am very happy that Node.js has come to the IBM i platform and that you and others have built tools for it, but it is not a panacea even if it is a new and interesting integration point and there is some elegance with doing development in JavaScript on both the client and the server as Node.js allows.

What other things that are not on the IBM i platform that are out there in the open source community need to be brought onto the platform?

Alex Roytman: Frankly, there is so much work to do here. Yes, IBM has ported Node.js to IBM i, and so now you can do all of these cool things. But we are trying to bring more capabilities and integration. For instance, we have an automated way to convert RPG to Node.js, and it is going to take us a while to perfect this. So we are not really concentrating on anything else but these core areas. We have done things to modernize COBOL because there are still shops out there using COBOL and customers have been requesting this functionality. So we brought the capability that RPG OpenAccess offers to COBOL because IBM doesn’t provide this. There is a lot still to do on the user interface side. We do a lot of development, but it is for these core areas.

I feel that this is where the investment needs to be. When we are out there and competing with other options for modernization, which means using tools or rewriting to Java or PHP or moving to packaged application software, I want to make our option to be so cost-effective that you cannot ignore it. I think that by keeping that R&D going forward and making sure it is 10X better than the other alternatives, there is a lot of business to be done.

TPM: While I realize that Profound Logic is a private company, can you tell us how business is doing?

Alex Roytman: We have always been a small company, but with a small group of very smart people and that is a key philosophy. We want to hire the brightest minds in the industry. We have been growing fast in terms of revenue, and just within the span of a couple of years, we have gone from a dozen employees to around 30 now–and we are still hiring. That’s pretty quick growth.

TPM: At that size, you are hitting a point where you can’t personally manage everyone. You are managing a pretty diverse group, with many geographic locations and talents.

Alex Roytman: Because we are trying to get the best people, sometimes we end up hiring people in other states or countries, and we have contractors in Europe, too.

We have about 1,500 customers, and we have different types. Some we get involved with very intimately, and in some cases these are big engagements where we are handling a lot of the work. And in other cases, people just buy software from us, and even there it varies because we have smaller tools and utilities for modernization and we have other customers that need a bigger suite of things. We are diversified inasmuch as not all of our eggs are with just a few customers, but some are definitely bigger than others.

There are a lot of customers in the IBM i base that have done “modernization” inasmuch as they have bought a tool from us or a competitor, but that is just the beginning. We had a web development tool that we launched back in 2003 and a lot of our customers modernized through that, or they might be using a competitors’ tools, but now they are looking to upgrade because they want to do rich user interfaces as opposed to HTML.

I feel that there is a big number of customers that have done something, but even the ones that have done something have more to do still.

I see different areas of modernization. What has become more relevant recently is not just the functionality and the user interfaces, but also being able to bring on people to maintain the applications. And if you still have code that is monolithic and fixed format RPG, you will be struggling because the RPG developers that can maintain that are soon to retire, and you need to do something about that code base. That was less of a concern ten years ago than it is now, and it is related to the field of modernization.

TPM: Do you work with IBM on this, or do you have a different set of tools for this?

Alex Roytman: We do this as a services engagement sometimes and other times we work with ARCAD, our partner that fills in some of the things that we don’t specialize in. ARCAD has a tool that will take RPG code from fixed format to free format, and the ability to go fully free format is a big deal and a chance to move that forward and modernize.

Another way to approach this is on the Node.js. We can take existing RPG code and port it to Node.js in a fairly automated way, as I have said, and a lot of customers are interested in this. And that just opens us up to a whole new pool of developers. The tool can also modularize the code as well, meaning that if you have something that is monolithic and everything was in a global namespace and making a change to a program meant you had no idea what the side effects were. We can first put it into a syntax that more people recognize and second make it modular so that if you are making changes and it is going to just affect a spot of code, you know exactly what you are changing.

TPM: You are working to perfect this RPG to Node.js converter. What is the status of this tool?

Alex Roytman: The way that we do Node.js conversions is that we do not give the tool to customers. It is always done on a services basis, and we come in and run the converter and then we know, for instance, the tool is only going to be 90 percent perfect in converting the code. It is very hard to expect customers to fix the other 10 percent, so we get engaged and it is a project for us to figure out the things that don’t convert.

This is new for us, but we have this theory that this is the way to start, to engage and handhold with customers. Once they kind of get going and they convert part of their systems, then we might be able to let customers use the tool directly. We have been shipping it since COMMON in May, and it was used for internal development and some alpha customers before that. We have seen a ton of interest in this.

The neat thing about this is that customers don’t have to do it all in one go. They can strategically pick even one program, and put Node.js into the ILE architecture and if an RPG or COBOL or CL program makes a call to function that has been converted to Node.js, everything still works as it did before. The old code just uses the new code, and the new Node.js code can call RPG, COBOL, or CL programs, too.

That is a very key capability that we have, allowing customers to do this one step at a time. If you take any other sort of open source tool or even IBM’s support of Node.js, that is a completely distinct silo and then you have to do one of those big bang projects.