Over a million developers have joined DZone.

Decommissioning Canvas – The First Step Before All Others

DZone's Guide to

Decommissioning Canvas – The First Step Before All Others

Decommissioning or cutting an application can be a daunting task because of its complexity and the range of topics to study. I propose to you here a canvas to guide your reflection.

· Integration Zone ·
Free Resource

Discover how you can get APIs and microservices to work at true enterprise scale.

Image title

Whether you want to split a monolith into microservices, replace one application with another, or split a fairly generic application by replacing it with several specialized applications, it is often the same questions that are asked. It would be tempting to try to deduce a "generic methodology." Unfortunately, it seems impossible. Indeed, every application, every IT, and every project can differ enormously. That's why I propose a Decommissioning Canvas instead.

Image title

In this article, I will explain the contents of this canvas.

Three Steps

There are three main topics to address to start a decommissioning study :

  • IT and Business Stakes — Why?

  • System Complexity — What?

  • Strategy — How?

IT and Business Stakes

Business Plan

How many times have I seen projects launched without having any information on the costs, the expected gains, the need for speed of the ROI or not, etc.? I do not like the opposite excess (we do not project without a very solid business plan and with a very big ROI) because it blocks investments that are difficult to tangible. But at the same time, business plan elements are essential to get an idea of the capabilities to be done. Should we break everything if money involved is small? Should we allow a project to live forever when we know that we spend our time burning money?


I put here the functional and nonfunctional requirements desired. Do you want a user-friendly tool? A tool that supports a very high load? Strong security constraints? It's time to bring out these kinds of points that can be very structuring. And of course, in the requirements, we must take into account the ability to do so. Do you have the skills? Are you enough in your team? Can you pay external people to do the job?

System Complexity


This is one of the topics to dig into the most! Is the data model easy to read? Can it be broken down into functional areas with few redundant tables between domains? Who reads and writes these data? How does one access it? Are there any related processes? In short, how are we going to split the model?

IT Dependencies

We try to have here a more macro view of the application in its ecosystem. How many applications is the application of our study related? What does flow mapping look like? Which business domain do they apply to, as well as the related processes?

Integration Capabilities

Here, we simply list the integration capabilities. It is necessary to see what the accessible technologies are (API, File, MQ, etc.), not forgetting that an integration can be made through services, and/or events and/or data. A number of patterns exist, and it is a good idea to approach an integration expert to study the subject.


Replacing an old Cobol application will certainly be more complicated than a .Net application. It is necessary to see what difficulties can be encountered in the technological changes because one will certainly have to modify the code of the application to be decomposed in the first time or at the end. In the same way, we will think about the frameworks used, which have the tendencies to die. Finally, are there any technological exoticisms?


Buy vs. Make

One of the least obvious questions to answer. There is no miracle answer, but we can think about how many evolutions the future system will have, the ease of implementation of these, and if the solution publishers respond correctly to the needs. Ideally, make a business plan to several years between the two choices to decide.


A crucial point, because success or failure will depend on this step. Do not underestimate the effort, and do not do it in the end!


How to test something that is changing? Will something or some features disappear or be changed? What do you change management?

Modularization Strategy

Are you going to do refactoring? Will you need a pseudo-CQRS pattern to help you modularize your application? Are you going to have to apify your application? Make a version upgrade? And what will be your roadmap on such or such functional area? How will you cut out your data model in order to modularize?

Integration Strategy

The application that you want to decommission was connected to a number of applications, and you may be able to set up new integration patterns. This is an opportunity to think about this strategy but also to see how you could share with the rest of your IT. The subject is wide, but do not underestimate the problems of going on the cloud and multi-cloud issues. Some iPaaS provides even simpler solutions than a full API policy. How many APIs are only used to enable cloud to cloud or cloud to on-premise integration? In any case, a good knowledge of the world of integration will only help you!

This canvas contains all the reflections that I could have on my previous projects, but you are free to suggest your improvements or even your own canvas!

APIs and microservices are maturing, quickly. Learn what it takes to manage modern APIs and microservices at enterprise scale.

integration ,canvas ,decommissioning services ,application

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}