Mainframes, cloud, and technical debt

When it comes to developing new software on any platform – not just mainframes – we’re probably all familiar with the three choices available. It can be good, or quick, or cheap. And you get to choose two out of the three.

If you want it done quickly and you want it to be good, then it can’t be cheap. If you want it developed quickly and cheaply, then it won’t be any good. Or if you want it to be cheap and really good, then it will take a long time.

Those of you who have worked in project management have probably come across Brooks’ Law. Before we talk about that, let’s look at a simple maths problem. If it takes a man (in these more enlightened times I obviously mean a person) five days to build a wall, how long will it take two men? With the simplicity of mathematics, the answer is clearly two and a half days. So, if you apply that logic to your IT project, the more people you have working on the project, the fewer days the project will take! Anyone who has ever worked on a project knows that just isn’t true. And that’s where Brooks’ Law comes in.

Fred Brooks published his book, “The Mythical Man-Month” in 1975. He concluded that adding manpower to a late project simply made it later. He explained this by saying that it took time for new people to get the hang of a project – what he called the ramp up phase. During that time, other project members were less productive because they were showing the new people what to do. And the new people weren’t productive until they knew what to do.

The other problem he identified was the communication overhead. As more people join a project, more time is spent finding out what everyone else is doing on their part of the project.

While he agreed that some tasks were simple and could easily be divided up amongst a group of people – eg cleaning rooms in hotels – even that reached a point where adding more people would mean they just got in each other’s way. And, besides, most projects require specialist work and aren’t that easily divisible.

Going back to our original three pillars of project development – quick, cheap, good – one common result of doing something quickly is what’s called technical debt. Technical debt is the implied cost of additional reworking on a project caused by choosing an easy (limited) solution now rather than using a better approach that would take longer. A proof-of-concept project is usually full of technical debt, but that’s usually acceptable because all that was needed was to prove that something good be done. However, for most projects, like financial debt, there will come a time in the future when that debt has to be paid. In terms of the project, it means that the software will have to be updated or even completely rewritten.

The consequence of that is that it will take time and will have a cost-implication. The question that organizations face is whether to get the code right from the start – with the implication that the project will take much longer than was planned. And that means it will cost more than originally planned. Or does the project team go ahead with the project as is, and let a different project team fund the technical debt they have left at some time in the future when the original team are probably working for different companies or doing different jobs for the same company? At least the original team will make their deadlines and receive any bonuses associated with that.

For mainframe sites, ‘paying’ the technical debt can result in downtime for the application and a particular service being unavailable to internal or external customers. That can result in service level agreements not being met, which can have financial consequences in addition to those associated with rewriting the code.

Internal projects are one thing, but do the same rules apply when you are buying software from a known mainframe software vendor? Is it worth skipping Version 1 and waiting until all the kinks have been ironed out and waiting for Version 2 to be released? And does the same apply to new software services like those offered by cloud providers?

For cloud providers like AWS and others, there’s money to be made from companies that are currently running their own servers, and there’s even more money to made from companies that have mainframes. And that’s why mainframe sites are being targeted by the marketing arm of these cloud giants.

That’s why AWS has announced its Mainframe Modernization service, its development and runtime environment, which is designed to make it easier for customers to modernize and run their mainframe workloads on AWS. AWS also offers mainframers the option to maintain existing applications as they are and re-platform them to AWS with minimal code changes.

All this is powered by the Micro Focus Enterprise Server, which lets IBM mainframe applications run on Linux or Windows servers. There are no upfront costs, and customers only pay for what they use.

System integrators will work with mainframe-using organization to discover mainframe workloads, assess and analyse migration readiness, then plan the migration and modernization projects.

That all sounds very good. I guess the question at the back of my mind is whether this migration will create any technical debt.