So, I find this variable without a description. The new tab should have an entry for this, so developers will be actively triggered when "violating" architecture.

This is somewhat in line with the feature request of not being able to publish in certain situations, like architecture violations.

As we all know that architecture of an application is very important. 

In Architecture Dashboard, the technical debts we find may be simple or complex such as,

"Missing description in public elements", "Long undocumented flow", "Duplicate disabled code", "Cyclic dependency related issues" etc.

While developing itself, developers should get a warning message stating "This will become as technical debt in architecture dashboard - do you want to proceed? " during publishing the code or taking dependencies at any point Or highlighting those elements in different color inside service studio.

This suggestion can be made available for the most frequent architecture issues.

This will speed up the delivery and will reduce the effort for the architecture review.

Thanks.

Hi,

I believe that we can be faster to solve problems (following the culture of "fail fast, correct faster") if we can have access of the most technical advices from Architecture Dashboard directly in TrueChange.

We already have many advices there, but I believe that we can be more agile if we can have direct access to most of the problems that are reported in the AD without access it.

Stuff like this I believe that can be a great boost to have it in TrueChange:

Those are just examples from a print.

Best regards,

Ricardo Pereira

Yes, that would be great, and I believe OutSystems will think the same. The reason is not is probably related to performance, time, and money to do so.

Ideally, you have a modern software development platform that guides you to not create technical depth in the first place.

Get AI Mentor issues before publishing in service studio, so that the developer closes the development without discontinuities of having to verify the next day on AIMentor. Like it is, it's very hard to put AI Mentor issues in the definition of done.

AI Mentor Studio warnings/technical debt, are what they are.

You can use the application, but solving these is highly advised (but not mandatory).

Checking AI Mentor Studio for suggestions and improvements should be an iterative part of your workflow, solving technical debt, part of your backlog.

AI Mentor Studio analyzing an application, takes time. You can only include the 'Check AI Mentor Studio' as a step in your Definition of Done, if the business accepts it will take time to deliver a high-quality application. Otherwise, that's is your direct disclaimer.

Hi,

One thing that has always made me wonder is why Service Studio does not automatically detect cyclic, upward and side references?

It would be useful if after consuming an action from another module there was at least a warning that a violation of best architectural practices was happening.

We could even go further and not even show up in the list of references to import if that happened.

That is, there could be a way to classify modules within service studio or service center and if a _LIB module wanted to import an action from a module in a higher layer, it would not even appear in the reference list.

Thanks 

Hugo