Strumenta 
Why this interview?
Legacy modernization is a topic that I have always found particularly interesting. In this interview, we will talk about it with Graham Cunningham, the head of EMEA Operations for Heirloom, a company which has a significant reputation in this field. He will give us some very interesting insights.
Here there are some quotes I found particularly interesting:
If you look at the bottom line, or if you look at the costs involved, yearly running a mainframe, it’s a significant budget item. So, if somebody can come in and say, “Well, you know what? We can run that same application … we just take it, re-platform it and run it on standardized x86 hardware, whether that’s on-prem or in the cloud,” and it runs and performs just as well, then that’s a significant cost saving.
Many mainframe developers don’t see the benefit (…) So many times, it’s a question of showing and explaining that their skills are not now going to be redundant. They still need COBOL developers. They still need the people that have the business knowledge in the future. This is an opportunity to learn something new, but from a comfortable position that, you’re the subject matter expert, and we’re going to add a few things and we’re going to provide other people … but you’re still the expert. And so it becomes a question of pitching it correctly to the people.
We have done migrations for clients directly, but our business model is to work through the channel, to work through the global SI channel. Typically, the incumbents, they have all the relationships, and we provide consultancy services to them, and we provide our product to them. I don’t think there’s a global SI that is not a partner of Heirloom.
If you had a monolith on the mainframe, you’ve got a monolith now sitting on Java. But what you can do now is you can use the capabilities, the agility of this development environment, and this huge development community, to start to change your deployment artifacts. Split up pieces of that monolith, now, into related functions, and then deploy those related functions as a microservice. Without changing code, without changing business logic, you can actually do an incredible amount of re-architecting.
I think the legacy modernization space has really come of age in the last few years. There are many ways to do this, to move forward and modernize. We think we have Heirloom as the best kind of hybrid approach to it. But there are many ways to skin the cat, and our clients, I think, respect the fact that we don’t just go to them and say, “Oh, yeah, you have to do it this way.” We will go into a client with an open mind and see what’s best for them.
Federico Tomassetti: Hi, Graham, thank you very much for joining us today.
Graham Cunningham: Hi, Federico, nice to see you again.
Federico Tomassetti: And, I’m particularly happy to have you here today, because Graham is the head of EMEA Operations for Heirloom, and Heirloom is a company which has a significant reputation in the legacy modernization field. This is a field that I find particularly interesting, and I think you can give us some very interesting insights, so thank you for joining us.
Graham Cunningham: Oh, you’re very welcome.
Federico Tomassetti: And can you start telling a few words about you, please?
Graham Cunningham: Oh, yeah, so as you say, I’m EMEA for Heirloom Computing. I’ve got pretty much a software finance background. I live and work in Switzerland, and I’ve worked for most of the banks in Switzerland at one time or another, in private banking, investment banking, and also general retail in various technical realms. I’ve also worked as a CTO of a hedge fund doing high volume, high-frequency trading. So yeah, pretty varied background, but generally finance-related.
Graham Cunningham: And before that, I used to work for a company called Micro Focus in the early ’90s, who were obviously the big people in the migration space and legacy, though they’re a lot bigger now than when I was there.
Graham Cunningham: So Heirloom Computing is actually a group of senior managers that came out of Micro Focus about 11 years ago. These are people I’ve known for nearly 30 years. Our CEO was the global head of development, our COO was the COO at Micro Focus, and our CTO was CTO at Micro Focus. And they were basically the cloud computing team at the time, and at that time, Micro Focus decided to stop that, but these guys had a vision of moving legacy applications, and by legacy, this time I’m talking about mainframes, specifically COBOL and PL/I applications, to the cloud.
Graham Cunningham: And that’s not just COBOL code. On the mainframe, you have a CICS transaction manager, or you have an IMS transaction manager. You have data in various mainframe-specific file formats, and that data is normally also encoded in EBCDIC, which is very different from ASCII.
Graham Cunningham: And there are various other subsystems, security subsystems, third party utilities. JCL, Job Control Language, for running batch jobs also exists on the mainframe. And so when you talk about moving an application, the honest easy bit is moving code. It’s the other stuff that needs to move that is the complex … or that’s where the complexity comes.
Federico Tomassetti: So we could say that it’s very different from translating from one language to another, but remaining on the same platform, like having translating code from Python to Java, but running on the same machine, because you don’t have to translate just the language, but also …
Graham Cunningham: The platform.
Federico Tomassetti: … yeah, or the platform.
Graham Cunningham: Yeah, so the operating system utilities, or the expected utilities that exist on the platform … when you move from Windows to Linux … maybe not now, not now with Windows 10 and WSL, too, and stuff. But five years ago, that was the difficulty in writing code.
Graham Cunningham: It used to be a joke in the early 2000s that Java is write once debug everywhere, because the goal was that you’d have the same application running on Windows, on different versions of Linux, on AIX, and everything would work. And for a long time, I think until JDK 6, that probably wasn’t a reality. They didn’t have it integrated well enough into the various operating systems to make it work.
Graham Cunningham: But now, it pretty much is. Even if you’re doing file I/O, the Java file I/O works as you’d expect on all of the different platforms.
Federico Tomassetti: It took 25 years, but …
Graham Cunningham: Yeah, that’s the way it is. And, to be clear, the reason I talk about Java a lot is, although we talk about ourselves as being a compiler company, and that’s really where we got to know each other, you’re language specialists, DSL language specialists, and we consider ourselves … we’re focused on a couple of languages, and you’re focused on the generalized approach to creating compilers, transpilers, interpreters.
Graham Cunningham: And obviously, I followed your work with interest, and we’ve also collaborated a couple of times on various bits of work. I’m sure we’ll come to need to do that in the future.
Federico Tomassetti: Hopefully, yes, yes. But definitely we miss your level of expertise on the platform. That, I think is a big part of these legacy modernization efforts.
Federico Tomassetti: And I wanted to ask, what are the problems that motivate your clients to modernize their software?
Graham Cunningham: So you get various client drivers. Sometimes, it can be that a CEO comes in, we have one insurance company in the UK where the CEO came in and said, “Senior managers, the KPIs, your key performance indicators, are that 50% of your transactions have to run on the cloud.” I was like, “Well, we’re running on the mainframe. How do we run on the cloud?” And that’s when they start to look around for, “Well, how can we move off the mainframe to the cloud?”
Graham Cunningham: So it can be a fear decision on high, it can be a cost-driven decision. The mainframe platform has traditionally had high costs of ownership. They would count that those high costs of ownership come with … and by they, I’m saying IBM … so IBM would count to, that the mainframe doesn’t have high cost of ownership, because it never fails, it never stops, it never reboots, it always runs, it never goes down.
Graham Cunningham: But if you look at the bottom line, or if you look at the costs involved, yearly running a mainframe, it’s a significant budget item. So if somebody can come in and say, “Well, you know what? We can run that same application … we just take it, re-platform it and run it on standardized x86 hardware, whether that’s on-prem or in the cloud,” and it runs and performs just as well, then that’s a significant cost saving.
Graham Cunningham: Now there are, as always, caveats, to that. But one thing to remember is that the mainframe was the original cloud. They’ve got virtual machines on the mainframe. They’ve implemented transaction managers on the mainframe. Databases were created on the mainframe. We shouldn’t denigrate the mainframe. They just chose the route of creating reliability by making the thing so that it never crashed. And that kind of gold plate they had, where they gold plated the infrastructure with the sole purpose that the thing will never crash and that transactions would be transacted and committed.
Graham Cunningham: And then, the cloud has come up, and it draws on a lot of those same ideas, but it provides a reliability using redundancy, and the dynamically instantiating instances. So the cloud expects things to fail, and your job, when you move to the cloud, is to accept failure, and just make sure that it works.
Graham Cunningham: I remember reading Kent Beck, he was working at Facebook, and he gave a talk and he said one of the things that really blew his mind was when he made a change and he committed it, and he saw it ripple out, but only about 80% of the nodes received the change, and that was by design. They never wanted to get into a situation where every node was absolutely running every change. It kind of blew his mind because he had spent years and decades ensuring that every node in the J2EE, JEE Application Server, ran exactly the same version. But that becomes a single point of failure.
Graham Cunningham: And it’s a different approach, right?
Federico Tomassetti: Yeah, it definitely requires a change of mindset that maybe is not easy to do for the person that have worked there 30 years with a certain system, and can navigate very well and produce great results with that approach to understand, and approach…
Graham Cunningham: Yeah, that actually comes back to another reason people decide they want to move off the mainframe onto x86 hardware.
Graham Cunningham: Another thing we often get is COBOL to Java. “I want to move COBOL to Java,” and we don’t stress that too much. We stress moving the application and being able to make the application agile. But underneath, we do have a transpiler, which emits Java code, which automatically gets compiled. But on our day one, we do a re-platform, and the application runs and behaves exactly the same way as before, because that’s the way that we can bring the people with us, and the client can bring their developers that have the 30 years, 40 years of business knowledge, they can move as well. Otherwise, you’re going to get into a situation where you lose these people and you lose that business knowledge.
Graham Cunningham: This code is difficult enough. It’s grown over 40, 50 years. It’s got embedded corner cases in there, that in one branch office at one time, somebody walked in that had a birthday on the 29th of February. So there’s all kinds of corner cases embedded in that code base that are only known to those developers. There’s very rarely any tests, so that’s not where you can go with it. And these people, they’re either in their 60s or very close to their 60s, and they’re getting close to retirement age, so that’s another driver, a little bit of fear is coming in.
Graham Cunningham: We saw, recently, New Jersey, the computer systems fell over. And that has nothing to do with the language. That has to do with the fact that they have not invested in the infrastructure. The mainframe that they were using was never upgraded. The interfaces to that mainframe were never upgraded, and then it becomes a certain question, well if you’re going to invest money, are you going to invest it in mainframe tech, or are you going to invest it in newer technology, into cloud technology?
Graham Cunningham: And to their credit, IBM, they’re adding a lot of containerization into the mainframe. There’s many ways that you can stay on the mainframe now, as well, that it’s never going to be as … I just don’t think they’re able to compete with Amazon or Microsoft. They’re going to have to move some of their operations to the cloud, and I think they recognize that as well, which is why they purchased Red Hat and OpenShift. That gives them another entry point.
Federico Tomassetti: But then you raise a very good point that this person that have a very important knowledge of the system, and they are typically COBOL developers, PL/I developers, and are they resisting to do migration to Java, or are they collaborating with the modernization effort?
Graham Cunningham: So it depends how it’s done. When it’s the fear decision from on high, nobody likes change, and as far as … I’m not going to say all mainframe developers, but many mainframe developers don’t see the benefit. They are working in a robust, reliable environment, providing transactional services to the business and to the clients. And those back end services have been running for 30 years. Why change them, right?
Graham Cunningham: So there is a large hurdle to overcome. So many times, it’s a question of showing and explaining that their skills are not now going to be redundant. They still need COBOL developers. They still need the people that have the business knowledge in the future. This is an opportunity to learn something new, but from a comfortable position that, you’re the subject matter expert, and we’re going to add a few things and we’re going to provide other people … but you’re still the expert. And so it becomes a question of pitching it correctly to the people.
Graham Cunningham: But change for change’s sake, or let’s move to a new platform, they’ve heard it all before and they’ve seen the disasters. They don’t want any part of that, and with all people, there’s a range, and it’s not just mainframe people. It’s all people. Nobody likes change. When things aren’t working, nobody can really see the point of changing what’s working. So you’ve got to talk to people about agility, not just of the target infrastructure which becomes more agile, more dynamically scalable, but also in terms of the development process. The development process will need to change as well.
Graham Cunningham: The more I do this, the more I’m getting to the view that bringing the people with you, and taking care of the people in the migration is the most difficult thing of the migration process.
Federico Tomassetti: Yeah, I would agree. I think it’s … I was beginning to say, the same when designing domain-specific languages. It’s a different topic, or so in that case, changing languages means also changing the way you operate and means involving the people and if you manage to involve the people, you can be as technically as good as you want, but you will not achieve your results.
Graham Cunningham: Yeah. But it depends on the system as well. If you’ve got a system which has been static for 20-30 years with the old good things, almost certainly, there aren’t any people left who still understand it, or maybe there’s the one. We’ve got a couple of clients where there’s one person at the client, and they’re just scared stiff of that person leaving, because then they know they’ve got a problem.
Graham Cunningham: But they also know, there’s only one person. If she gets run over by a bus, they have a problem, and they especially have a problem when it’s on the mainframe and they can’t easily recruit people to work on it.
Federico Tomassetti: That person should ask for a raise.
Graham Cunningham: Yeah, we had one project in the States for a large insurance company, and we took it on, and it was very, very difficult. And then that’s where you got into the project. We realized that we had allocated nine months, which we just made for doing the migration. As we go into the project, we realize that a lot of it was undocumented, and it was actually a third-party product that had been bought in the ’80s, and nobody in the company actually knew how it worked. So they had to go off and hire somebody back from that original company. And when she turned up, she told us that it had taken them 16 months to install the product, and then if they moved from one mainframe to another mainframe, she would have estimated a year, and we moved from a mainframe onto x86 … actually, onto AWS instances, in nine months.
Graham Cunningham: So it was a great success, but it was unbelievably hard work, because we had completely … and we think the client deliberately didn’t explain the complexity, or maybe they really didn’t know, but it was an extremely complex application. The main reason was, as a standard product that was installed, a lot of the configuration was done in database tables. So the actual execution flow could not be discovered using static analysis tooling. You needed the database, and those database tables depended … they had multiple schemas, and the execution flow changed depending on which schema you were accessing, because they had the same table in all the different schemas, but with different data in.
Graham Cunningham: And so we’d make one run and it seemed to be okay, and then for us, as outsiders, we’d make exactly the same run, and we’d get completely different results, and it took us a long time to understand how the application was put together, because there were no documents around it.
Graham Cunningham: The code compiled on basically day one, but actually getting the data over and the application running with the correct behavior took almost nine months.
Federico Tomassetti: It’s like you are unveiling all things that the company has committed for 30-40 years, and maybe they even forgot, or someone managed to hide them for a while.
Graham Cunningham: Well, so CICS has something called background tasks, which can run, and so when the CICS system starts, you can have startup tasks. And these can be incredibly important, and they forgot to tell us that they had these background tasks. And so we were running the application for two or three weeks and not getting the right data, and we could not work it out. Single-stepping our debugger through thousands and thousands of lines of unknown COBOL code, which used the database to direct execution flow. It was really, really tough.
Graham Cunningham: And in the end, we had figured out, “Well, the data’s not there. The data that you’re expecting isn’t there,” and then somebody said, “Ah, maybe you need to run the background tasks,” and, “Oh, right, yeah, that would be great.” And that was actually the reason Heirloom … we had never done analysis as such. We’d always basically used our compiler to do an inventory analysis. Give us the code, we’ll compile it, “Oh, there’s a missing copy book,” okay. But that single project fosters into a realization that our clients didn’t know what they had.
Graham Cunningham: So we spent a lot of time and energy now building an analysis tooling that will help us do a migration. And the very first thing it does an inventory check. So we now have this … we call it blur process, where we run a service on the mainframe, and we start up an application, and then we interrogate the mainframe. So if we can start with a scheduler … on the mainframe, every JCL has got a scheduler … so we’ll start with the scheduler for batch, and we’ll get the list of jobs which are run. And then from that list of jobs, we download the JCL file automatically. We analyze the JCL file, and we figure out what third-party utilities and what programs are being run.
Graham Cunningham: And then we go back and we get those COBOL programs. And when we get the COBOL programs, that tells us what other COBOL programs we need. We build a graph of all the relationships. Then we keep going backwards and forwards to the mainframe until we build up the packet which is the application. And then we have a lot of information about the application, starting a graph database, and then we can make queries about that database and find the relationships between it.
Graham Cunningham: And we can go back as well. On the mainframe, there’s a login system called SMF, which records what applications, modules, what JCL jobs were run, in regards to all that information. So you get the SMF records out, and we can feed them in to give us … and that combines kind of a static analysis with a dynamic analysis. And then we can see that 90% of what you’ve given us isn’t run. Of the 10% you’ve given us, we’re missing five programs. We can get all this information out, and we do that as part of the estimation, the size and scoping of a project now.
Graham Cunningham: But that was all driven because we got surprised once by poor estimates.
Federico Tomassetti: Yeah … while you were talking, I was thinking that this is really important, particularly on this kind of project, to work with the specialist that had the possibility to learn these things over time. So I think that this is a field in which a company cannot improvise. You’d need a lot of expertise.
Graham Cunningham: What we find, as well, is that we go to multiple companies, and we do multiple modernizations from mainframe to cloud. And you go into a company, and first off, there’s … maybe not so much now in the last couple of years, but for a long time, there was a bit of … “I don’t believe it can be done.” So then, you would get … and they’d say, “We need to do a proof of concept. We need you to run a batch job for JCL. We need you to run some COBOL programs. We need you to move the data.”
Graham Cunningham: Actually, in the last couple of years, we’re moving away from that, because people now believe it can be done. So we don’t have to prove that it can be done. But when we go into a company, every company says that “Our mainframe is different. We’ve got some complex … and we use assembler, we’ve got a 4GL” and it’s like the old saying, “Every happy family is happy the same way. Every unhappy family is unhappy in a different way.” Well, every mainframe is unhappy or has its own complexity in a slightly different way than everybody else, but at the end of the day, there are core concepts in the mainframe world, and IBM have done an incredible job of documenting their environment. The red books are the gold standard. I wish our documentation was half as good as those red books.
Graham Cunningham: But that allows us to say we can replicate what you do on the mainframe, and unlike other people, we don’t actually implement every subsystem of the mainframe. We actually just provide a thin transparency layer, and jet JE implement everything. We take security… top secret, and we put it into LDAP. We take VSAM files, or database files, and IMS, and we put them into relational databases.
Graham Cunningham: So we just try and reuse what’s there and just do the minimum to make the program think it’s still running on the mainframe.
Federico Tomassetti: Yeah, it makes sense, because otherwise you’re still trapped on these replicated systems.
Federico Tomassetti: And I wanted to ask, how do you typically work with clients? So what is the experience that a client has? How do you start engagement? What is the process for one to have a migration project with you?
Graham Cunningham: So the key thing is our clients’ financial organizations. They typically have global SI in place. We do smaller companies, of course, but the typical scenario is a global insurance company has an agreement with a global SI, Cognizant, Wipro, Accenture, TCS, one of these guys in place. And then they will use the SI to do the migration. The migration is a complex project.
Graham Cunningham: So there’s a global insurance company in the UK, and I don’t know how much of this is public, so I won’t say any names. But they had a contract … typically, customers don’t own their mainframe. They lease their mainframe off their mainframe provider companies. They had a contract with one mainframe provider who drastically upped the price, and so they decided to switch to a different mainframe provider. And that project took about 18 months to complete, and that is moving from one mainframe to another mainframe. They had a lot to do, and a lot of interconnected stuff, and the people doing the work did a very, very good job.
Graham Cunningham: And those leasing companies are now actually a source of some of our leads, because they’re recognizing that their clients are going to come off the mainframe. We can now partner with them, just like we partnered with the SIs, to offer their clients a way forward off the mainframe onto x86 platform, and they get to keep the client. And that’s what the SIs do, is if they come to the insurance company and say, “We can move you to AWS or Azure,” and we can use Heirloom technology, then they get to keep the client, they get to do the migration, and they keep the client afterwards, and that’s quite valuable.
Graham Cunningham: And that’s really our way … we have done migrations for clients directly, but our business model is to work through the channel, to work through the global SI channel. Typically, the incumbents, they have all the relationships, and we provide consultancy services to them, and we provide our product to them.
Graham Cunningham: I don’t think there’s a global SI that is not a partner of Heirloom. That doesn’t mean we’ve worked with all of them … we’ve got partnership arrangements with all of them. But the ones where we have worked are TCS, Cognizant, Accenture, and Wipro. They’re four of the large ones.
Federico Tomassetti: Good, good, and I think it takes some ability to look into the long term, for who’s providing the mainframe to understand, not just to try to keep selling the lease on the mainframe, but…
Graham Cunningham: Yeah, well, it’s difficult, and we’ve seen that with a company in the US, one of those mainframe hosting services. They have top-level management that have seen this approach and would like to do it, but they’ve not changed the incentives of their salespeople. That obviously is a much bigger ticket item, continuing to sell a mainframe. And inertia is very powerful. Why do something if you don’t have to?
Graham Cunningham: So the salespeople are still paid and incentivized much more to remain on the mainframe. So there’s a strategy, there’s a top-down direction, but in my opinion, that’s well and good, but they still haven’t managed to create the right incentives for their own sales force to make it happen in any big way.
Federico Tomassetti: Yeah, it’s not easy to translate it from a strategy.
Federico Tomassetti: Before you named the fact that you have a product, can you describe what are the main products that Heirloom has?
Graham Cunningham: Yeah, so we have batch processing, which is we’ll take … I’ll go really basic. We have COBOL compiler, PL/I compiler, and a JCL interpreter. Those are the three main products. We have an analysis tooling, and we now also have a data connector, back to the mainframe. So it’s a service that runs on the mainframe.
Graham Cunningham: And with those four, what we can do is take migrate data, and we can migrate applications. So then, we would deliver that as a development environment on Eclipse, so that you could start your Eclipse, install the Heirloom plugin, and then you can compile your COBOL PL/I code, and debug it in Eclipse.
Graham Cunningham: But when we deploy it, we need to deploy it … the mainframe systems need to be in place. So our product actually contains transparency layers for the mainframe subsystems, for example, an SQL pre-process will generate, in our environment, JDBC calls. So instead of going directly to DB2, now we have JDBC, which allows us to use any JDBC-compliant database. But we have a great partnership with Splice Machine, which allows us to create incredible clustering scalability at the database level.
Graham Cunningham: I think I’ve mentioned security services. Security config gets mapped to LDAP configuration. VSAM files, we can map to index files, which we don’t tend to do. We tend to move them into database tables. So the product pallette is actually a development environment, well, an Heirloom SDK. It’s migration analysis tooling, which allows us to do inventory analysis and data analysis so that we can migrate the data, and then the batch processing system and CICS, and IMS transaction processing systems. And then, depending what a client has, we can mix and match those products as we go along.
Federico Tomassetti: Yeah, it seems you have a very complete and realistic approach to all the different aspects that…
Graham Cunningham: Yeah, and there are lots of tools around that as well. In batch processing, there are a lot of IBM utilities for creating connections to databases, which does some kind of file processing within a batch job. And we’ve implemented those utilities as well, and we’ve implemented them in Java.
Graham Cunningham: And we find that’s key, because when we move, we don’t just move from one black box to another black box. We move from the legacy system, that closed system, and we put people on an Open SaaS Java platform. And then we can interact with any other JVM language, and all these JVM subsystems that have been built up around Java … JDBC is one, the Jazz security API is another. All the things that we do … which kind of come to us for free, and come to our clients for free, because that translates, then, into doing some kind of nice things, as well.
Graham Cunningham: Because it’s Java … there’s a huge community involved in Java that is containerizing applications automatically, so you can now use JIB and a gradle script to compile your application and containerize it. And as soon as it’s containerized, you’re now in Kubernetes, and you can deploy the application into Kubernetes.
Graham Cunningham: And all of that comes, basically to Heirloom Solution for free. It’s not Heirloom that has to build it and provide it, the Java community provides those capabilities.
Federico Tomassetti: So once they complete the migration, they have access to all of these huge ecosystem, libraries, frameworks, and the team developers as well, because I guess that it’s easier today to find Java developers then COBOL developers.
Graham Cunningham: I mean unless, when you move the application, you’ve moved a monolith. And now you’re sitting with this … you’ve not made it any better. There’s no magic bullet. If you had a monolith on the mainframe, you’ve got a monolith now sitting on Java. But what you can do now is you can use the capabilities, the agility of this development environment, and this huge development community, to start to change your deployment artifacts. Split up pieces of that monolith, now, into related functions, and then deploy those related functions as a microservice. Without changing code, without changing business logic, you can actually do an incredible amount of re-architecting.
Graham Cunningham: And then you follow the Martin Fowler, strangle the monolith kind of pattern, and you say, “Well, those services there are changing a lot? So let’s put facade at the top of it, and let’s start to re-write,” and you can do the re-write and you can continue to do the work in COBOL, if you’ve still got those COBOL people, or PL/I people. Or, you can do the re-write for that small subsection in Java, or Kotlin, or Scala, or any JVM language you want.
Graham Cunningham: And you’re running on the JVM now, so you can actually integrate with your other JE applications. And you’ve moved the data. The data on a mainframe is … even if they’ve opened it up and it’s accessible, it’s still sitting there in EBCDIC, so for you to consume it, and there’s a translation taking place, which can go wrong if you’re dealing with packed decimal fields, there’s lots of things to go wrong.
Graham Cunningham: So if you can define it and move it once, you can debug that once, now it’s moved, and you don’t have a translation anymore.
Federico Tomassetti: From our conversation, it seems to me that as a side effect of this migration, you also unveil a lot of interesting information about the application and the different components. So that, I think, could also add later the clients to do some evolution, some reorganization, the application, because you have reconstructed the state of the application, as you needed to do that.
Graham Cunningham: Yeah, we always talk about day one, and not the Amazon day one, but day one for us and for our clients is the day when they move the application, and they re-platform it onto the Java platform, which means now that that’s day one. On that day, they’ve got exactly the same look and feel. We produce HTML, we have CSS, to make it look like the green screen. We execute the JCL as-is, so that they can run the JCL exactly the same way.
Graham Cunningham: That’s an under-appreciated part of any mainframe application, the JCL. JCL contains logic. It’s not just COBOL code that gets moved, or PL/I code that gets moved. JCL has to be moved as well, and that contains logic. So it’s something to be done.
Graham Cunningham: I’ve kind of lost my thread, there.
Federico Tomassetti: A lot of interesting things to discuss.
Graham Cunningham: Yeah. So what were we talking about, the…
Federico Tomassetti: We were talking about the fact that we unveil a lot of information when doing the translation, and we were saying that on the one, you basically replicate all the system, even the look and feel. And I think then, they can take it from there and do the evolution, because they have this visual understanding.
Graham Cunningham: So yeah, and I lost my thread, but what’s really cool about that is we’ve recognized that many of our clients would like to do that and move the application, and there’s some parts of the application that might be… Not that many mainframe applications are buggy, to be honest. They’ve had lots of years of user testing, right? But they might have some parts of the application that change on a regular basis due to regulation changes. And they would like to modernize that small piece. So day one, we move everything as-is. Day two, we talk to people about … we unveil information about the application, and we can talk to people about re-architecting, just by changing the deployment configs that we’ve put together.
Graham Cunningham: But we’re also adding to our plugins, and adding to our editor, ways to refactor and extract out facade interfaces, to enable that business logic now to become simply available to the JVM.
Graham Cunningham: We actually automatically do that for CICS transactions. So every CICS transaction becomes a callable web service in Heirloom. If you take a CICS application with a set of transactions, you can now script that set of transactions. And we’ve done some demos and shown people how they could create Angular or React from ends, completely new, Javascript only, no JS from ends, which interacts with the CICS application running on a JVM somewhere. And we’ve done that quite a lot, and that’s … many of the clients love to see that, because it gives them a way to break the green screen approach.
Graham Cunningham: It’s not always the right thing to do. A data entry terminal with a green screen, I don’t think there’s anything faster than that. If you’ve got an experienced data operator inputting onto a green screen, honestly, that is probably the fastest way to do things. The first time they touch a mouse, that slows them down.
Federico Tomassetti: Yeah, we had that similar experience when developing domain specific languages, because many clients want … the idea is they want a graphical language, because they perceive it would be simpler. What we do, sometimes, is say, “Okay, we will give you a language that you can use both in a textual form and in a graphical form,” and basically when you edit once, we behind-the-scenes edit the other ones. And after a while, people stopped using the graphical one, because they realized that with the textual one, they are more productive. So I think you have a similar scenario in this that maybe they have the perception that new interface is better, but it’s not necessarily the case.
Graham Cunningham: You know when we’re coding, whether you use Eclipse, IntelliJ or VS code, the pragmatic programmers said it best, they said you should pick an editor, learn it, and stick with it. And by learn it, they didn’t mean how to cut and paste, they meant learn the depth of that editor, because as a coder, as a developer, you’re going to be sitting in that space for eight hours a day, and you don’t want to be clicking up on a menu item to do a compile, or to save a file. You need to have the control keys in your memory. It has to be in your physical memory.
Graham Cunningham: And good programmers always have an opinion about what editor they like to use. It’s one of the things I look for. If I ask somebody at an interview what editor they use, and they use Notepad, it’s almost like …
Federico Tomassetti: A bit insane. And personally, I’m obsessed with the idea that we should use tools that improve what we are able to achieve, and indeed, the company founded Strumenta, means tools in Latin, just because of this.
Federico Tomassetti: I think we stole, already, one hour of your time. But there are so many topics that I … but I wanted to ask you if there is something that you would like to add that I forgot to ask, but you think it’s important to …
Graham Cunningham: I don’t know, really. We’re on the lookout for good people, I think, like everybody.
Graham Cunningham: But no, I think the legacy modernization space has really come of age in the last few years. There are many ways to do this, to move forward and modernize. We think we have Heirloom as the best kind of hybrid approach to it. But there are many ways to skin the cat, and our clients, I think, respect the fact that we don’t just go to them and say, “Oh, yeah, you have to do it this way.” We will go into a client with an open mind and see what’s best for them.
Graham Cunningham: I spoke with a large bank in the UK two or three weeks ago, and I told them they should stay on their mainframe. The complexity they have, and the capabilities they have today, I don’t think are easily replicated. But that was because they had written their own operating system almost 40, 50 years ago, and that one still existed, and the risk to move that for a bank is just too great. You’ve got to accept and view where risks are.
Graham Cunningham: And I would say that we come into every engagement … obviously we want to sell our skills, but we also are specialists, here. We’ve seen clients, and everybody is afraid of risk, and we do everything we can to minimize the risk. And if that for some clients means that they don’t even do the move, then so be it.
Federico Tomassetti: Yeah, because otherwise, anyway, you will have a client that is unhappy, so.
Graham Cunningham: Yeah, we’ve had some difficult projects that I think everybody has, but we’ve never had a failure, and I don’t think every company in this space can say that.
Federico Tomassetti: Yeah. And I think it’s … your very deep experience that you have also demonstrated today, I think it’s something that permits you to understand the risk, because I think that other companies willing to do legacy migration could either minimize the risk, take the job, and that’s it. But in some cases, maybe you are just not able to understand all the risk, because it’s a very complex thing to do, I think. It’s already assessing the difficulty of this project to something that requires a lot of expertise.
Graham Cunningham: And that is where, I think, our greatest value-add comes in, at that front end. We can talk to clients and we can go through their landscape right at the beginning, and we can work with them and do … and the best projects are ones we’ve worked with the client right from the beginning and worked on the business analysis, and the business case together, because then we’ve been able to see, “Well, do the numbers add up, does the risk add up, okay let’s move forward or not.”
Federico Tomassetti: I think it would be also useful to have the right people on the client side to add this exploration. Okay.
Federico Tomassetti: I would like to thank you very much for the time you have dedicated to us.
Graham Cunningham: Oh, thank you.
Federico Tomassetti: It was very interesting for me, and I hope for all the people listening, and yeah, it’s been a pleasure, and thank you.
Graham Cunningham: Yes, always a pleasure chatting to you, Federico, so.
Federico Tomassetti: So, thank you. Bye.
Graham Cunningham: All right, bye.
