An approach to settling technical debt in your application portfolio

A small summary of some key aspects in the approach to fixing the technical debt in your legacy application portfolio.

Risks of old technology in your software portfolio typically are:

  • The development and operations teams have little or no knowledge of the old technologies and/or programming languages.
  • Program sources have not been compiled for decades; modern compiler can not handle the old program sources without (significant) updates*.
  • Source code for runtime programs is missing, or the version of the source code is not in line with the version of the runtime. The old technology to do static calls (meaning, including every called program statically in the runtime module) makes things even more unreliable.
  • Programs use deprecated or undocumented low level interfaces, making every technology upgrade a risky operation for breaking these interfaces.

A business case for an project to update your legacy applications

  • A quick assessment of the technical debt in your application portfolio, in technical terms (what technologies), and in volume (how many programs).
  • An assessment of the technical debt against the business criticality and application lifecycle of the applications involved.
  • An assessment of the technical knowledge gap in your teams in the area of the technical debt.

Then, how to approach a legacy renovation project:

Take an inventory of your legacy. With the inventory, for every application make explicit what the business risk is, in context of the expected application lifecycle and the criticality of the application. Clean up everything that is not used. Migrate application that are strategic.

Make an inventory of the artefacts in your application portfolio:

  • Source code: what old technology source program do you have in your source code management tools.
  • Load module: what load modules do you have in our runtime environment,  in which libraries do these reside.
  • Runtime usage: what load modules are actually used, and by which batch jobs, or application servers.

Consult the business owners of the applications. You may find they do not even realize that they own the application, or that there is such a risk in their application. The application owner then must decide to invest in updating the application, expedite the retirement of the application, or accept the risk in the application. In highly regulated environments, and for business critical applications in general, the risks described above are seldomly acceptable.

Next, unclutter your application portfolio. Artefact that are not used anymore must be removed from the operational tools, throughout the entire CI/CD pipeline. It is ok to move things to some archive, but they must be physically removed from your source code management tools, your runtime libraries, from your asset management tools, and from any other supporting tool your may have. 

Then, do the technical migration for the remaining applications. If the number of applications that must be updated is high, you often see that organisation set up a “migration factory”.  This team is combination of business and technical expertise, that develops tools and methodologies for the required technology migrations. Remark here is that experience shows that more than 50% of the effort of such migrations will be in testing, and may be more if test environments and test automation for applications do not exist.

*Most compilers in the 1990s required modifications to the source programs to be compile-able. The runtime modules of the old compiler however, remained functioning. Many sites choose not to invest in the recompilation and testing effort.Nowadays we accept we have to modify our code when a new version of our compiler or runtime becomes available. For Java for example, this has always been a pain in the back, which is accepted. For the mainframe, backwards compatibility has always been a strong principle. Which has it’s advantages, but certainly also it disadvantages. The disadvantage of being an obstacle for technological progress, or in other words, the building up of technical debt, is often severely underestimated.


Design for recovery means you take explicit measures in your software systems for unexpected situations.

Recovery plays at every levels of our software system, from user interface to backend software components, and from our functional parts to our infrastructure components.

In your code you make sure to catch as many possible error situations as possible – meaning you catch any possible error that can occur, and handle errors as locally as possible – where they occur. You apply Forgiveness and correct errors or mitigate their consequences. Then, when issues occur, you make sure you have have designed for recovery.

Wirfs-Brock  identifies the following options for recovery:

  • Ignore the request. Yes in some cases, you can recover by ignoring a request. If for example you know your client will retry, you could choose to ignore a failing request. Or, somewhat better, you could log log an error and ignore the request.
  • Admit failure. You signal an exception, try to clean up residuals and give up the opreration.
  • Retry. When the failure is likely to be caused by some temporary condition, a retry may be the best option. You see this applied in databases, where the rows you want to access are locked by another thread; you want to wait, for some limited time, for the lock to be released.
  • Perform an alternative action: in agreement with your clients, you may wish to design for an alternative action. Alternatives are usually less perfect, less efficient, but preferable over a total failure.
  • Appeal to a higher authority. Sometimes you can not do more than inform a higher authority about the error. The higher authority may be your business owner who then can contact end customers to inform them about a process that is stuck, and keep them informed about a resolution.

In designing for recovery we have to weigh how much effort and cost we spend on designing recovery actions.

See also Error handling, Foregiveness.

GSE Achitecture workgroup kicked off

On March 29, the Dutch affiliate of the GuideShare Europe – a (the) user group of IBM technology – kicked of a new working Architecture group.

During this event Geer Haas and Michiel van der Wal from the Sociale VerzekeringsBank (SVB) presented the history of the Dutch Sociale Verzekeringsbank and the role of the mainframe in their IT operation. Jan Schravesande from IBM presented an architecture vision on digital transformation in an organisation using mainframes.

In an open forum ideas around objectives and mechanics of this new working group were discussed.

Seneqa was a sponsor of this project.

Mart Gombert, executive producer at MG Creative, created this impression of the kickoff.

If you have any questions or suggestion, please feel free to contact me at

Microservices and traditional (mainframe) applications at the Dutch GSE

Yesterday we have an excellent discussion during the presentation/workshop I presided at the Dutch Guide and Share in Almere. This conference was the local variant of the global GSE – the IBM user group.

We had about 15 architects from leading Dutch organisations in the room entertaining a lively discussion.

I had prepared some slides to guide the discussion, based on my earlier blog post on the topic of microservices and traditional application architectures. The slides are here: Microservices and traditional application architectures.


Art, Engineering, IT Architecture

Is Architecture an Art? Is IT Architecture an Art.

It is a debate, in fundamentalist IT architecture circles. Really.

Engineering is the application of mathematics, empirical evidence and scientific, economic, social, and practical knowledge in order to invent, innovate, design, build, maintain, research, and improve structures, machines, tools, systems, components, materials, processes and organizations.


Art. The expression or application of human creative skill and imagination, typically in a visual form such as painting or sculpture, producing works to be appreciated primarily for their beauty or emotional power:
The art of the Renaissance
Great art is concerned with moral imperfections
She studied art in Paris

So, Architecture may be Art (most of the time).
IT Architecture is Engineering. There is no beauty or emotion involved.
(And also architecting buildings is largely engineering)

It the 19th centure the notion of Art emerged as an independent entity. Before that everything we call art today was plain craftsmanship. Business.

In the last century art movements have tried to redefine art as craft. I believe that was Bauhaus. Then art becomes engineering, again.

Everything is art.
Art is nothing, or everything.
Engineering, (IT) architecture is a method.
Art is an end state.

Close Menu