Evaluation of an application portfolio with the 3D City model

Qualilogy_TechnicalDebt_PortfolioLast week, I presented the different levels of maturity in software quality and how the measure of the technical debt can help to progress through these different levels, for a proactive and optimized management of application quality.

On this occasion, I spoke of using technical debt as part of the evaluation of a portfolio of applications, along different axes. After this post, I was thinking about what I could do with a 3D graph of such a portfolio, using the eXcentia’s plugin ‘3D City Model’ (1).

I have already presented this plugin in previous articles: City Model, City Model – New release, Critical City where I explained how to customize the 3D graph using our own formulas, and finally the ABC metric to investigate the metric of the same name.

3D representation of a portfolio

SonarQube_Portfolio_ListI have a SonarQube instance with a portfolio consisting of several applications, for a total of 5.7 millions lines (MLoc) of Cobol code, 485,000 lines (KLoc) of ABAP code (SAP applications) and 205 KLoc of J2EE applications. I actually created three portfolios ‘Cobol’, ‘J2EE’ and ‘SAP’ and a ‘Global’ portfolio combining the previous three.

I did this with the help of the SonarSource’s plugin ‘Views’, which can aggregate multiple projects or code analysis into a single view, in order to consolidate different metrics and measures along different axes: business, technology, etc. Anyway, in different portfolios.

Unfortunately, the 3D City plugin does not support Views, although eXcentia plans to develop this functionality in the future. But fortunately, the plugin comes with a widget that I found interesting for what I wanted to do.

SonarQube_Configure_WidgetSo I log into Sonar as an ‘Admin’ user, in order to configure the widgets of my dashboard …

… and choose the menu ‘3D Code Metrics’ in order to show only the widgets from this plugin. Then I select the widget ‘Filtered Megalopolis’:


I will configure it by choosing a title for this graph, and in the combo-box ‘Project filter’, I will select ‘Projects’. Any other filter based on ‘Views’ does not allow to display the 3D model, so I use this widget to view my overall portfolio, with all its applications.


However, you can use different filters, which should allow you to try different groups of projects. For instance, I can create a filter on all the analysis with a name starting with ‘Cobol’ and thus list only Cobol projects, as it would be with a specific portfolio for these applications.

I will not speak further about the configuration of the widget, I’ll let you discover it by yourself (the posts mentioned above can help you), so I’m going back into the dashboard to work with this representation.

In the dashboard, you can click on the graph to move your ‘city’ in all desired directions, and also use the mouse wheel to change its size, that is to say its overview. You can also click on any building to have information about it.


Here, we can see our most important Cobol application named ‘Billing’, with 2.5 MLoc  in 116,019 functions (Paragraphs or Sections in Cobol, Java methods or functions for 4GL languages) and a Cyclomatic Complexity (CC ) of 434 218 points. Ah, this is Cobol, it’s big eh? There’s a lot of work here.

But what particularly called my attention are these two red bars at the foot of the giant Cobol applications.


Here we have two Abap applications:

  • CO_OT1 with nearly 350 KLocs and more than 54,000 points of CC.
  • CO_OT2 KLocs with less than 100 KLocs and more than 14,000 points of CC.


Clicking on what looks like a flask in the graph menu, I can display different values ​​for different dimensions of my 3D city. I can see that the color represents the complexity by function so that, proportionally, the Abap objects of these two applications, as they are very red, are much more complex than in other applications.

Just looking at this 3D representation of my portfolio, I can identify SAP applications with a maintainability and a testability lower than the giant Cobol applications!

Color is also the criterion that we will play most times.

For example, in the following chart, I selected the ‘Blocking’ technical debt, that is to say the cost of remediation of ‘Blocking’ issues (highest violations of good programming practices).


We see that the application CO_OT2 is now green, ie with no ‘Blocking’ issue, while our first application CO_OT1 has a blocking technical debt of 2,100 minutes (3 days and 4 hours).

What other feature, possibly defective, can I identify?


Here I configured the color with the percentage of duplicated rows, commonly called the ‘Copy/Paste’ code. The more duplicated blocks of code you have, the more difficult the maintenance of this code because you have to reproduce any change into each ‘Copy/Pasted’ block , and the risk of bugs will be high in case you forget just one. In an application so difficult to be tested, you play with your maintenance budget and the satisfaction – or dissatisfaction – of your users.


On the above graph, the level of comments is correct, which is not uncommon for Legacy applications. Cobol is also green. The red blocks represent J2EE apps. It has become fashionable not to comment anymore in Java.


So now I know that I have two SAP applications with a complexity (by function) higher than in any other application in my portfolio. Who says complex application says an application difficult to test. With more than 50,000 points of CC, CO_OT1 requires to design test plans in advance, ideally before the development phase of the project and that must be automated with testing tools, especially if you want to avoid regressions, especially when you have so much duplicated code. In addition, a complex code means a lower maintainability, so higher costs of evolution but also a higher risk of introducing a defect into the code, and thus bugs for the end user. Hence the increased importance of investing in the tests.

SonarQube_IssueBlockersIn addition, this application has a technical debt about ‘Blockers’, sure not very important, but when I go to the ‘Issues’ page for this application, I can see 40 violations on two rules ‘System C functions should not be used’ and ‘Internal source code processing statements should not be used’.

In both cases, these different kinds of instructions are reserved by SAP, as they can change or disappear from one version to another. This is also one of the major problems of a SAP release upgrade, the most expensive ever.

Besides, the fact that we meet 40 of these ‘Blocker’ defects on this application CO_OT1 and on none of the other Abap applications makes me believe that this project team – or this outsourcer – does not know these critical rules. This is a point that we will have to check, and maybe think to some training.

Finally, the high rate of duplicated code compromise the maintainability and the reliability of this application. Another reason to consider a refactoring. However, the documentation – the level of comments in the code – is decent and should facilitate (relatively) this operation, with the objective of bringing technical debt to an acceptable level and to remedy the above problems.


Obviously, I could proceed with the assessment of my portfolio and get the same information in other ways, for example by using the following page ‘Compare’ in SonarQube.


I will probably use it to gather in a single table the different numbers and metrics that I have previously identified using the plugin ‘3D City’. Nevertheless, I would have to set up this page with all the projects of my portfolio and on a much larger number of metrics to identify potential problems on my various application areas. The advantage of the 3D City model is to provide:

  • An immediate identification of problematical applications.
  • A much more effective visualization than browsing tables of numbers.
  • The choice of the most useful metrics for an audit of my portfolio.
  • Thus a quick and easy diagnostic.

Then, I can zoom in the applications I have identified and work on action plans that will address the problems found, and more precisely quantify the costs of remediation associated with the technical debt.

Simple, efficient and also very fun, this ‘3D City’ plugin is a must. It’s simple, customers love it.


(1) If you want to do the same, you can download a trial version (two weeks) of the ‘3D City’ model here: http://www.excentia.es/en/plugins/city-model/download, or here for previous SonarQube releases: http://www.excentia.es/en/plugins/city-model/versions.

Leave a Reply

Your email address will not be published. Required fields are marked *