Do you keep adding new features to your software without having time to properly refactor and clean up the code? Do your engineers keep adding workarounds for bad quality code that have piled up over the years?
Dynatrace provides you with full insight into what your code is really doing and how good or bad the situation really is. It identifies hot spots that you need to work on right away in order to better manage technical debt. Use Dynatrace continuously in your review meetings to monitor progress of architectural changes. Dynatrace allows you to get a grip on your technical debt.
Do you have too many developers to fit into a single room? Then you’ve got the challenge of enforcing the architectural rules you set in place.
Using Dynatrace as part of your code review shows you how developers actually implemented their features and stories. It also shows you all the 3rd party components, services, microservices, or containers (VMs/Docker) that your engineers decided to add. With this, you can react quickly if you find yourself moving in the wrong direction.
As you can’t review every code change, Dynatrace automates the process by identifying architectural changes from build to build for you by looking at key architectural metrics such as the number of service calls, allocated memory, SQL executions, and more.
Dynatrace identifies regressions based on these metrics, which act as quality gates in your Continuous Delivery pipeline, and stops bad code as early as possible. This ensures that only good quality code makes it into production.
As an architect, you have a specific idea of how the application should behave in real life. But you need feedback to make sure that reality matches expectations.
Dynatrace captures both technical (consumed resources per feature, performance hot spots under load, etc…) and business (active end users, user experience, etc…) metrics. These metrics, directly delivered to your work station, allow you to learn for future releases (e.g. remove features that are not used anymore) and allow you to react on immediate architectural shortcomings (e.g. add more services to cover peak load).