Properly Dispositioning OutSystems Architecture Dashboard Findings

The OutSystems Architecture Dashboard (OSAD) was introduced a few years ago to help OutSystems development teams see issues with their code and fix them. There are a few misunderstandings about OSAD that I run into on a regular basis, and hopefully we can clear those up so that teams can use it better and more efficiently.

A lot… and I mean a lot… of people treat the OSAD findings as a to-do list. And what I mean by that, is they act as if every finding is a problem that must be resolved.

Nothing could be farther from the truth. OSAD is an automated static code analysis tool. It doesn’t know the difference between “this is a decision I made because the business logic required this implementation logic” and “this is a decision I made because I wasn’t thinking this through all of the way”. There’s a reason why there are disposition codes like “False Positive” too! This isn’t to bash OSAD in any way, here at CDR I mandate that it be used weekly at a minimum (and I am automating things to make it be a daily use!), but the tool is automated static code analysis, it is more diligent than a person, but not as smart as a person.

What this means for you is that you should treat the findings as a list of red-flags, rather than a clumsy way to generate Jira tickets (that said, a way to generate Jira tickets straight from OSAD would be welcome).

Image from Giphy — Text: “Well I’m just seeing a couple of red flags”

For each finding the process should be:

1. Understand the finding itself (not always obvious from the name, the detailed descriptions and resolution instructions are a big help here!).
2. Go to the code and understand the business logic; is this an actual “problem to be solved” or is this a “proper implementation of the business logic”?
3. If it is a “problem to be solved” create a ticket for it and either leave the finding as-is (knowing it will be resolved soon in the code and the finding will go away on its own) or hit “snooze” on the finding (because you are pushing the ticket to backlog and it will not be resolved soon). Your goal here is to get the finding list clean so you can focus on new issues as they show up rather than constantly re-evaluating things you have already looked at.
4. If it is a “proper implementation of the business logic” use the appropriate resolution in OSAD to make it go away forever. Usually this will be “Mark as resolved — won’t fix”. Please use the “False Positive” as often as it is correct to do so, as this provides feedback to OutSystems to help them improve the algorithms!
5. Prioritize the tickets made according to whatever criteria make sense. I suggest a 2-axis categorization of difficulty and impact, sorting by descending impact and then ascending difficulty to order things. To explain that a bit more, the easiest things with the highest impact first, then more difficult, high impact tasks, the low difficulty, low impact tasks, followed by high difficulty, low impact tasks. This gives us “low hanging fruit” that can yield immediate impact, while then moving on to high impact items that are more effort.

Having an action plan to disposition the findings from Architecture Dashboard allows you to quickly and efficiently get your architecture squared away and in a better place.

J.Ja