Sometimes Even DIYers Need A Little Help

October 7, 2019 Timothy Prickett Morgan

If there ever was a crowd that liked to do it themselves, it is the IBM midrange. Well, probably more like half to two-thirds of the IBM midrange. But you know what I mean.

These companies started programming way back in the 1970s with one of Big Blue’s System/3 or System 32, or System/34 machines, and moved on to the System/38 or the System/36. The former launched in 1978, a decade after the System/3 that started it all in Rochester, Minnesota, and the latter came out in 1983, five years before the AS/400. The machines had sophisticated batch and interactive processing against flatfile or relational databases, and significantly, RPG, a high level programming language that enabled companies to encapsulate the logic that described how their business runs. When computing came to these customers, these DIYers dove right in an created their own applications, and it was a boon for both them and IBM.

All of these years later, and a lot of that code is still out there because the AS/400 architecture made a commitment to run both System/36 and System/38 code as well as absorb all kinds of new technologies and techniques as it has evolved all the way up to the modern IBM i platform running on Power Systems iron. We are talking about heaven only knows how many hundreds of billions – I meant to say B for billion because if IBM mainframes have 220 billion lines of COBOL code, with somewhere north of $2 trillion in aggregate investment by IBM’s estimates, then the OS/400 and IBM i application base, with an order of magnitude more customers and probably an order of magnitude lower budgets per customer, has probably made about the same investments in application development.

But even DIYers like the IBM i base need some help sometimes, and according to Profound Logic, a maker of application modernization tools that leverage RPG and Node.js, among other things, is seeing a big uptick in a custom application services business that the company founded a few years ago. To get an idea of what is going on, we sat down and talked to Alex Roytman, the company’s founder and chief executive officer, and Jordan Antonoff, vice president of sales and client services, about this burgeoning services business and how it is different from the traditional software tool business that Profound Logic started two decades ago.

Timothy Prickett Morgan: I always say we’re in the news business, we’re not in the olds business, so tell me what’s new with Profound Logic.

Alex Roytman: At a high level, we are doing a lot more and different types of services when it comes to modernization. In the past year, I think our business in services has tripled. As far as the different types of services offerings go, Jordan should jump in and talk about some of the new things that we’re doing with customers, things that we were not doing a couple of years ago.

Jordan Antonoff: Let’s start with a little background as to how these new services came about. We’ve always provided services to our customers, but it was never a focal point, which has been selling our software. But nonetheless, if you look back at the last 20 years, we’ve had some different customers that wanted help building out whole new systems from the ground up, or customers that we’ve helped modernize their entire green screen system and move it all over to browsers. We’ve also done a couple mobile application development projects. So we always had some interesting services projects going on.

A couple of years ago, we had increased demand from customers to help them with more hands-on application development and application modernization. Customers were asking us to help on an entirely different scope than we saw in the past. After lots of these conversations, we decided it would be a strategic move for us to build out a focused services division. So in addition to our support team, our sales team, our marketing team, and our development team, we have built out a full services team with a director of services and business analysts and developers focused on services. This was driven as much by meeting customer demand as it was to grow the business, which of course is a very good side effect.

The new services that we’re offering have a wide range. One very popular services is to have Profound Logic come in and do a three or four week modernization and transformation analysis where we have business consultants who have a mix of both the technical and business analysts spending time onsite with customers, interviewing key business stakeholders to get their input on where, with regard to applications, they stand in driving the business forward. We interview and shadow key end users to see how they use the applications to figure out what’s working and what’s not, and then present a three-year to five-year roadmap with the plan that we would recommend to help them go through the modernization process.

Other services include helping customers convert their user interfaces if I haven’t done that already, helping them with new application developments, helping them modernize RPG code. We are seeing increased interest from our customers to convert RPG code to Node.js, with the primary reasons for this conversion being the difficulty in finding RPG developers and the desire to open up their system to more modern languages. Database modernization, which is not something historically that we have been involved in, is also in demand and that is because they prefer to have one primary partner working on a variety of projects rather than having to bring in three, four, or five different vendors for the different aspects of the system.

TPM: Let me back you up for one second there. I just want to get a feel for the shape of things. Can you talk about how big Profound Logic is at this point, such as how many people are allocated to normal development and how many in services? If the revenue is growing three times as fast as the rest of the company then that tells me it’s going to be a more significant part of the business going forward and maybe the largest number of employees will end up working there like what happened to IBM Global Services, which is still the largest single part of Big Blue.

Alex Roytman: Even if you go back five years, Profound Logic was primarily a team of developers working on the software products. Sometimes developers would take some time off and work on a two-month project, but we didn’t really have a dedicated services team. A few years ago, we started with a handful of dedicated services people – maybe that was 10 percent of the organization in terms of technical resources, and now again I’m guesstimating that we are at least 50/50 in terms of product development versus services and we may even have more in services than we do in product development. So there’s been substantial growth in that side of the business. And that’s intentional, and it wasn’t an easy decision because we’ve been very successful as a software company. But we decided we need to be a services company as well. That’s a culture change, and there are a lot of struggles in implementing all of this, but we’re pretty happy with the way it’s working out.

TPM: If you look at IBM, sometimes those Global Services margins were quite nice and sometimes they were abysmal relative to selling software products, which have very high margins so IBM could afford to do hardware and services and have more share of wallet at customers if you add it all up. So how does it work for you? I’m going to guess that, given the fact that there’s so much demand for help and so little resource in the skill base for some of these new technologies, that the margins on your services are either the same or slightly better than for the software products. That’s just a guess.

Alex Roytman: I don’t have exact numbers on margin off the top of my head, but I think ultimately margins are tracked differently. Selling a unit of software doesn’t necessarily cost very much, so if you just look at it from that point of view, the margins are still in software. It always feels like if we could sell 10 more units of software that’s always easier, especially considering that ongoing development is a sunk cost because we’re going to keep our software great no matter what. To me that’s a fixed cost versus the margin.

TPM: You must view this services work as something that you want to do. All businesses have things they do, not because they are going to get rich doing them, but because they’re the right thing to do.

Alex Roytman: That’s exactly right. I get involved a lot in product development just because I have a certain vision and when I see something in the marketplace even if ultimately it doesn’t profit me as much as sometimes it’s one of those things where I say to myself: “This should exist and so I must go and build it if no one else is doing it.”

Jordan Antonoff: You’re right about the margins. Our services margins fluctuate depending on the project, how many people you can put on the project, the customer’s budget – all of that. And obviously software margins are typically really nice. But the scale for the services makes that business really appetizing because there’s so much more room to grow. You sell software to a customer, and you can upgrade them or sell them some new pieces of software, but you get to the point where that customer is saturated with software and there’s no more upselling or cross-selling. You get the recurring maintenance. But when you sell services, now you’ve opened up a whole different set of line items that can be sold – and can be sold on an ongoing basis.

Alex Roytman: There’s another thought as far as what we want to do versus what we need to do. I think the services piece was a combination of both. There’s definitely a need because if we don’t offer these services, customers are going to go elsewhere. But it’s also just a lot of fun and quite enjoyable. We’re getting to know our customers much better than we have in the past. And we’re getting brought into all these conversations that are beyond just the technical scope. They involve the business and that is it adds a different challenge and we’re a group of people that likes challenges. This gives us a chance to help customers in a different way, not just providing tools. We help them achieve other goals and tackle other projects that they couldn’t tackle before, which builds customer satisfaction. Of course, there are projects that don’t work out as well as planned. But that gives us good feedback, too.

TPM: What’s the attach rate for these services for new customers? Your installed base already has your software, and they might cycle back and ask for services once they realize you offer them. But as you sell things are you finding that you have a very high attach rate of these kinds of services?

Jordan Antonoff: Right now, word is just starting to spread about the services we offer. If customers want to just buy software from us, that’s fine. But if they are open to it, we can work with them on a consulting engagement to come in and help them analyze and understand the current state of applications and systems and build a modernization plan. The attach rate is becoming pretty significant for these services.

Now that we’re selling services, we are taking opportunities that were maybe $100,000 or $200,000 and going way beyond that. The average deal size has been increasing significantly. We’ve had a couple of customers in the past year where, historically, these deals might have been just $80,000 or $90,000 or possibly $100,000, and they are five or six times that size now with the addition of services.

TPM: Well, that’s a good thing. You have deal sizes growing and a new line of business driving that, which is why services is growing three times as fast as product sales. Why are they coming to you for services? Are they just simply running out of time? Is it that they can’t get the right skills? Is it a mix of those two things? What is making them so eager. We all know that IBM i shops are never afraid to pay a premium for a premium product, but they are stingy and have a strong do-it-yourself streak.

Jordan Antonoff: It’s a mix of reasons. There are definitely situations where it’s just simply they’re short staffed, they’re having a hard time replacing their retiring RPG developers. But then there are still lots of customers out there that have a strong development team, but their development team is just trying to keep up with the day-to-day demands in the business that modernization projects get pushed out because they need to keep the lights on. They want someone that can come in and get the modernization done in a fraction of the time so they can see the results for modernization quickly. We do modernization, day in day out.

TPM: What advice do you have for people that are stuck in the middle of a modernization effort? There are probably not a lot of companies that started yesterday, but there probably are a lot of failed or stalled projects out there. And once you let people know you’ve got this thing you might find you can’t hire people fast enough. There’s nothing worse than turning away business except not having enough.

Jordan Antonoff: We don’t want to turn away business and thankfully we’re not at that point quite yet.

Our advice to customers is to ask simple question: Where do you stand in the modernization journey – do you have a good idea of where you are and what you have left to do? Customers are often not quite sure.

The other piece of advice is don’t try to take this on your own in the IT department, involve the business to make sure that after you spend all his money on this project the business is satisfied and knows where the money went. And it sounds kind of simple or basic but it’s amazing how often that is not the case.

Prioritization is something that is extremely important. And we see a lot of customers struggling with this because they are looking at these ten different things they need to do for modernization and they’re not sure how much each is going to cost and how much value they’re going to get from each. And that’s where someone like us can come in and help them determine that because we have the experience of working with other customers so we’re not this sometimes company. We are out there, talking to other IBM i customers and seeing what worked and what didn’t.

TPM: What about Node.js? This is obviously a very big part of your strategy.

Jordan Antonoff: The increased level of interest from customers with regard to Node.js is interesting. A lot of our customers are taking a step back. They want to determine a strategic language moving forward and they don’t want to have a mix of ten different languages. We are spending a lot of time helping customers understand the value of Node.js, which first and foremost has nothing to do with our products or services – it’s about helping customers see the vision and the path that they can go down with Node.js. And a couple of years ago none of our IBM i customers we’re talking about Node or new node is and we’re hearing a lot more.

Now, many customers are dabbling in Node and doing it on their own and they’re coming to us to get advice on how to do a lot more development in Node. While Node is a very important to the direction we’re heading in, we’re not saying we’re going to help you with all the different new languages. No. We have a very defined approach and a lot of reasons why this approach should involve Node.

TPM: You’re not actually advocating for people to completely replace RPG with Node.js, I assume?

Jordan Antonoff: I’m really glad you asked that because that’s very important for us to clarify. We are not suggesting to anyone to replace RPG with Node. We have customers that come to us and say we’re satisfied with RPG, and we’re good with that. There’s no pressure to go down the path of converting RPG to Node. We will share with them some of the benefits of doing new development in Node, and using Node in our Profound JS framework for API integration and portability. But the customers that are interested in converting RPG to Node are the ones that have been thinking about moving away from RPG for a while now. But even in those situations we’re very clear with customers that we don’t recommend you take your whole system and convert it because there’s lots of portions of your system that should stay in RPG. So our approach is to look at the entire system and determine what should stay in RPG, what portions maybe need to be refactored in RPG or refactored in Node, what portions can be converted, what portions maybe can be replaced with an existing software package.

The goal is not just to go in and convert all the RPG to Node and it’s important for us to be clear about that because we don’t want to create the impression that we’re anti-RPG or anything like that. It’s not the case at all.

The one last thing I’ll share about that is over the years we had a lot of conversations with customers where we were pushing them to say with RPG and just go to RPG free and get your RPG as modern as possible and in some cases that was well received but there was a lot of situations where leadership teams from our customers told us they knew about RPG free and they don’t want to hear about it. They have made a strategic decision that they are going to start moving workloads from RPG into another language and they want help.

TPM: And you said. . . .

Jordan Antonoff: Well, eventually we decided we needed to start saying yes because we were turning customers away. And that’s when we started developing our Profound JS framework.

TPM: You didn’t say Java or .NET, I notice.

Jordan Antonoff: We do not see Java or .NET as a good strategic decision for customers to make. We actually have had several conversations with customers that have large Java systems that they’re starting to think about how to move away from Java because they’re also looking at that as legacy.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search