IBM i DevOps TechTalk #26
SYNON

R.B. – Welcome to IBM i DevOps Techtalk, where we discuss key topics and questions with ARCAD experts. I’m Ray Bernardi and I’ll be your host today. Today I’m joined by Alan Ashley. He’s a senior solutions architect here at ARCAD Software. If you’re still maintaining a Synon application and you’re wondering how to eliminate that technical debt, then this discussion is for you.
We’ll talk about the reasons it’s a good idea to exit the Synon Case tool and how to do it successfully. So let me pass this to Alan to get started.

A.A. – Now, Ray, as we start talking about Synon or CA 2E as it’s now known and just for everybody’s benefit, I’m not going to try to say CA 2E the rest of the time here, so I’m just going to refer to it as Synon. So as we know, that Synon is a code generator that dates back to the previous century.
What are some of the issues that people have using Synon today?

R.B. – You just hit on it. Exactly. The technologies. Age is the first thing. It hasn’t evolved for years. So your applications really get isolated from newer technologies. There are many issues and we could probably talk about this for a full 30 minutes. I mean, a shrinking talent pool, for instance? Most Synon experts, they’re retiring and younger developers, they’re not going to learn this tool.
They’re not going to work with Synon. So if you’re embedded and Synon, you’re going to lose that talent and you’re not going to be able to go forward. The other thing that’s going on with Synon is the maintenance costs.

A.A. – I was going to say that maintenance cost, that I’ve seen some of the reports on two and three times what they’re paying. I mean that’s ridiculous.

R.B. – Doubling and tripling. Now that’s just the maintenance cost for the software. That doesn’t include the maintenance costs of actually maintaining your application using Synon. Remember, you’re using an aging technology. Now, the other thing about Synon is it’s going to offer a really poor end user experience. Synon applications, there are green screen interface and that’s kind of outdated.
If you’re trying to get to mobile technology or web based user interfaces and things like that, it’s going to be very hard to meet those expectations for you, for your business and for your end users. If you’re using Synon as your tool for developing your applications and you’re severely limiting yourself as far as integration goes.

A.A. – I know when I’ve looked at a couple of times on LinkedIn and I’ll just have for once, I just do Synon jobs. There are so many jobs out there looking for someone. And guess what? Nobody’s taking those because of what you just said. We’ve all kind of reached that age of. I’m nearly retirement, I’m Synon, but I’m not going that route. And the 20 years old is not touching Synon with a ten foot pole. No, that’s not going to happen.

R.B. – There’s no way they’re going to do that. You’re also limiting yourself as far as integration goes. We hit on that just a little bit earlier, a Synon generated apps that really hard to integrate with things like APIs, cloud part, cloud platforms, web services, things like that. And I worked with Synon way back when.
I’ve actually seen it. I’ve worked in the models and so on. And what you’re dealing with is a really cryptic database structure and a really rigid architecture that makes modern modernization almost impossible. It’s extremely complex to do anything with this stuff. The code that it generates is very difficult to look at. I worked with companies way back when.
I’m talking 15, 20 years ago that wanted to exit Synon. And what they would do is they would take the models, they would generate the code. They would stop working in the models and they would work in the code that Synon generated. And it’s next to impossible to understand what’s going on inside that code, which sent their maintenance costs for their applications sky high.

A.A. – So I’m guessing it’s not creating it. And, fully free.

R.B. – Oh, no. Not even close. If I recall correctly, you can generate, RPG and COBOL. Either one of those, and again, both of those are dated as well at this point in time.

A.A. – So, right. So you mentioned 20 some odd years ago people trying to get off of this. Why is it so hard to get off Synon?

R.B. – Most of the business logic for applications for organizations using Synon is embedded in what’s called a Synon model. So they have years and years of business logic embedded in these models that are difficult to look at. Even after you generate code from those models, it’s still difficult to look at. So those rules embedded in those models, a lot of times they’re not real well documented within the organization outside of that Synon tool.
So if you’re not going to use the Synon tool, then you could have difficulty with your business logic. You could have difficulty understanding what your business logic even was, and trying to modernize that type of an application with those type of constraints. It’s almost impossible to Synon to proprietary architecture. Let’s face it.
So they use that unique model based approach and they generate RPG or COBOL.

A.A. – They are kind of locked in.

R.B. – They’re absolutely locked in. So that structure really doesn’t map to modern languages. It doesn’t map to modern frameworks. It doesn’t map to automation like DevOps and so on. None of that is possible. If you’re stuck on Synon. So these are some of the difficulties moving away from it, just wanting to be able to use things like DevOps, for instance, everybody’s, the big buzzwords modernization and DevOps, not with Synon. It’s not going to happen.

A.A. – So I’m just kind of thinking here. So there’s really just a couple of options that you have. You can rewrite it. And you just mentioned reading that code is problematic to begin with. And yes, it is technically RPG code, but it doesn’t make sense to most developers if they were just to read it natively, it wouldn’t for me. So do you do Java RPG. You get a rewrite option right.

R.B. – Alan, you and I have talked to how many companies I don’t know that have tried the Java rewrite option. And how well did it go.

A.A. – It does not go because one of the things is, is when you start talking about performance, Java when written to run, really, IBM i, database level I/O RPG is right. That new RPG model is going into that. So I mean if you don’t rewrite it, you can always go just buy a new application, basically a rip and replace, which is dangerous. And I worked with a company and they weren’t moving away from Synon, but they were moving away from their homegrown application.
They spent two and a half years getting away from it. And then two and a half years coming back. Because the package out of the box wouldn’t do it for them. Said their rip and replaced replace was literally rip replace rip. Go back to the original.

R.B. – Exactly. I mean the problem with leaving Synon is getting code that you can work with when you’re done. That’s really where specialized tools come into play. Because Synon, like I said, generates RPG, it generates COBOL. And then what you need to do is you need to take that and move it into a modern language like Free Form RPG, Java or C++ whatever.
So that’s one of the things that ARCAD can do for you, but we can actually do that transformation into those modern languages. And we can do that. And like I said before, maintain all of your business logic and so on. Which is really important because the business logic embedded in these models is the uniqueness of some of these companies.
And it’s been developed over decades. And you just don’t want to lose that.

A.A. – Right. So that takes me to the third point I was gonna mention is like our Synon mass conversion project is taking all this code, and we have a team of people that go through it, and when you get done, you have functional Free Form RPG, you have DDL tables. Now you’re actually going to start seeing performance improvements of your application because it’s taking advantage of the new IBM i architecture, the modernization aspect of things. And now you can get these younger generation of developers coming and going, oh, I understand what’s going on here. So there’s a lot less risk if you were to go that route and use the ARCAD Synon conversion strategy and go with it. It lowers the risk. There’s always risk. But this is something that we do and we work with you going through it because you understand your business logic. And so it’s a partnership. We go through this.

R.B. – What ARCAD does is automatic, automated code transformation. That’s what it does. Other option like you mentioned is rewrite your application from scratch, start all over again in Java. So what’s the bad part about that? It’s probably five times more expensive than converting what you have in place right now.
It’s going to take you 2 to 3 times longer than an automated transformation would. And there’s a high risk of creep and failure in that approach. So rewriting an application from scratch is not something I would even consider. I just wouldn’t even go that way. What else could you do? You could replace your application with something off the shelf by an application and try and adapt it to what you’re doing now, and you could lose your uniqueness within the business and so on.
So these are things that ways I just would not go. So the best way to go is to fully automate the transformation of your software of that Synon model into RPG Free into microservices, which is exactly what ARCAD is doing. We’re talking full automation and risk free conversion. We offer 100% automated conversion.
We’ll take your Synon generated code up to freeform RPG and SQL. And we eliminate all the manual rewrite risks involved in that. And they’re high. Those risks are very high. For instance, what’s the company? Orange. We’ve worked with Orange.They worked on it for years, and they reached a failure point.

A.A. – They I think worked on it like eight years on trying to do something, trying to move off platform.

R.B. – To go to Java. Yes. Hundreds of developers and decided this is not the way to go. And where did they end up? They ended up working with us because again, we offer that full automation and that risk free conversion. And we can also include automatic regression testing during this. So you’ve heard of the product verifier obviously.

A.A. – Yes, that’s for an auditor. You’re saying hey, you’re taking all your code from this this show me that it still works.

R.B. – Exactly. And prove it to yourself that it still works before you put it into production. This is the business you’re talking about. This is your bottom line. If you do this wrong, this is going to cost you and it’s going to cost you dearly.

A.A. – I think Orange said they are saving a round of me, probably over that now, a year and just the after the conversion just of not having to maintain it. Going through that. And so just looking at some of the numbers that I had on Orange, I looked them up was they worked on it for about eight years trying to do it themselves.
Yep. They worked with ARCAD and we turned everything into Free Form. And around 15 months, just by the sheer volume that they had. That’s how long it took us to do it based on their sheer volume. 15 months is a whole lot better than eight years. How much money was wasted in eight years?

R.B. – Right. And why were they doing this? They were doing this because they wanted to futureproof their application. Because they knew that Synon 4GL is not way not where to be anymore. They wanted to be in modernily. They wanted to be in microservices. They wanted a DDL database. They wanted to use SQL.
They wanted to open the door for things like Rest APIs and modern DevOps practices, and they could not do it with their Synon application. The other thing that they were facing was a skill shortage. They didn’t have the skills to continue to maintain that Synon application. They just didn’t have it. However, once it’s converted to RPG Free Form, it’s much easier to maintain.
You can attract younger developers who look at that, and it’s syntactically equivalent to Java, if you will. They can read that code where they can’t read the code that comes out of Synon. So there’s a lot of reasons to move off a Synon. There’s a lot of reasons to work with an automated tool. I mean, if you want to work with DevOps and integrate into a modern framework, you’re not going to do it with a Synon model. You need to get out of that Synon model. And that’s what we’re offering.

A.A. – Exactly. And we do have, some more information coming up on it. I think it’s in December. We’re actually doing a webinar on that. So be sure to check out our website, sign up for that, to get some more information on it. But if you are a sign up shop, why are you still there?
Knowing that the developers that support it are leaving, the maintenance costs are climbing, and you’re going to be stuck with old code. That’s not going to be really modernized. So you’re really handcuffing your enterprise and your company from moving forward, particularly in today’s world where everything is moving fast. The concept of case tools was great back in the day.
You could build stuff without really knowing what you were doing. That world has changed. You need to be agile. You need to be quick. You need to be able to pull people in and out and understand what’s going on. You can’t pull anybody in to look at a Synon case tool if you have never used one and have an eye on what’s going on.

R.B. – Yes. You’re not going to hire a new developer to do it, that’s for sure. You got to be dealing with somebody that’s been in the industry for years and years and years and probably very close to retirement age.

A.A. – And they’re going to, of course, charge more for their service because it is a limited availability of resources. They can charge what they want to support it.

R.B. – Skills are pretty rare at this point in time.

A.A. – All right, thanks Ray, for talking about Synon. And again, we do have that webinar coming up and we’ll have some more information there. But if you are Synon, visit our website and get some more information on that. Because you do not want to be here in five years, we should have moved off.

R.B. – Exactly. I hope you enjoyed listening to this techtalk on Synon how it’s aging technology and there’s declining support for it. How there’s a shrinking talent pool, how integration and modernization is challenging if you’re still using Synon. And the risks of staying within the Synon model.