For software development teams to make meaningful progress, they must invest in efficient monitoring, reporting practices, and tooling. This is because only by keeping track of select metrics, such as those pertaining to application performance, will you know whether you are on the right track. Without knowledge of whether the software is functioning and performing as it is supposed to, there is no way of knowing what, if any, changes need to be made.
In this article, we explain why reporting is crucial to any serious development endeavor and how Cortex provides reporting services to teams.
What is reporting?
Reporting is the fairly straightforward practice of monitoring certain metrics defined per a project’s business goals and using the insights derived to make informed decisions. These can be decisions that developers and other team members make on an everyday basis or more high-stakes judgments that leadership and management are responsible for. Reporting is similar to activities such as continuous testing and code reviews in that it enables teams to refine their workflows as well as the actual code.
Because a microservice architecture is so complex, and reporting needs to be thorough to give developers and leaders alike a comprehensive picture of the ecosystem, it is best to automate this process. Manual reporting is not only cumbersome but also easily susceptible to human error.
Adopting the right approach to reporting
Conversations around the different aspects of the development process, such as production readiness and security audits, don’t usually touch upon progress reporting or reporting to leadership. Instead, they tend to take a more tactical approach, asking questions about the number of services vetted, and to what extent a particular service meets its compliance requirements. Even when they are actively handling a migration, developers look at it from this standpoint i.e., focusing on the percentage of the migration that has been completed to counting the number of Jira tickets that are still open.
This approach comes with developmental and operational risks, one of the bigger ones being the onus it places on individual teams and migration trackers to report on the areas of risk that the software is susceptible to encountering. As a result, it is hard to get visibility into other pressing questions, such as whether some particular departments or divisions are not getting the resources they need to complete these migrations or are lacking the infrastructure to meet these kinds of production readiness standards.
How, then, can teams and leaders make informed decisions that go beyond acknowledging that they are falling behind and scrambling at the last second to make changes?
Often, when teams do think about leadership reporting, they are tempted to take a surface-level approach that begins and ends with sharing status updates with leadership. However, it is worthwhile to take an alternate route and consider the task from the perspective of increasing the team’s chances of success in particular initiatives, whether that is production readiness or security. Taking this approach involves communicating both status and risks and being proactive about managing those risks. It also means taking the initiative to actively combat an issue immediately after noticing it.
This is also the approach Cortex takes. Our offerings are not limited to ongoing activities that span the lifetime of your company, such as production readiness, but also include migrations and security audits, for instance. These are more ad hoc processes, but we treat their reporting in the same way, in that we overlay all this information available and relevant to the development process. From organizational data and product and domain areas, to tier or service information, Cortex overlays this data so that teams have increased visibility into particular initiatives at multiple layers of granularity. By doing away with opaqueness and making the most minute yet relevant details visible, we provide teams with the support they need to start making more informed decisions.
Why is reporting important?
Let’s take the example of a service from the perspective of an engineering leader who is looking at production readiness. As an engineering leader, you might ask, why is production readiness important? Why am I looking at that from a reporting standpoint? It is either the case that the service is meeting it or it is not. However, imagine there is a team that is either grossly under-resourced or has not been migrated over to the new infrastructure. As a result, they can't set their SLOs and measure metrics such as uptime, resulting in their production readiness lacking. To support and equip that team with the tools they need to move forward, you need to bring such information to the surface.
How can you do that? Approaching the situation from a different viewpoint is the first step. So for example, by looking at even something like production readiness from the lens of your org chart, you can begin to understand if there are specific areas that you need to be investing in. For instance, you may need to assign more team members or help the team migrate over to the new infrastructure. As a leader, this practice helps you make more informed decisions, which not only contributes to lasting impact but can also help you reduce risk on the business front without placing demands on teams to be production ready. It is not a black-and-white effort. Instead, it has more to do with treating it as information to be relayed to the relevant parties such that it can subsequently be used to make better decisions. That is one of the reasons we choose to overlay that kind of data at Cortex.
Efficient reporting also helps you make more informed correlated decisions. Say you are running a security audit, and need to figure out whether there is a difference between tier three and tier one services, as you should likely be focused on one for the time being. If you are tracking these services in JIRA, you will not have the kind of visibility you need and will not know what level each service is. You would have to manually maintain that information yourself. So it is useful to treat reporting as a first-class citizen in the software development process. Doing so helps teams nail prioritization.
Alternatively, you may be curious about product domains: are there specific product areas that have higher uptime versus others? If so, why is that? Is it because specific products have been migrated off of the monolith into microservices or vice versa? If you are using scorecards and your service catalog system does not have reporting built into it as a first-class citizen, it will be of little help when seeking such information and subsequently attempting to make informed decisions. Although it may seem counterintuitive when teams are already equipped with more tactical practices such as checklists, reporting continues to remain an important piece of the software development puzzle.
Reporting also comes in handy when dealing with historical information. When you think about production readiness, you might think of it as a checklist, and you might wonder why you need to have historical reporting when you have set up reporting in real-time. Historical reporting is valuable in that it helps you make comparisons and see where you stand now, which is necessary to know how to proceed in the future. Maybe there has been more product work recently, or there have been changes to the infrastructure that have caused the teams not to be able to meet their goals. Or it might be the case that there has been a concerted effort by specific teams that is driving up their production readiness overall and you can then see that in your uptime metrics as well. So being able to see historical data lets you make an informed decision based on whether the metrics are trending upwards or downwards.
Production readiness, for instance, is not limited to a single moment in time. Something that holds today will not necessarily be the case six months from now. For example, just because your code coverage is adequate at the time of release does not mean that the coverage will meet those standards six months from then. So instead of viewing it as a static task, consider treating it as a more dynamic endeavor. Doing so helps you go back and look at the data to find out which areas, in particular, are starting to trend backward. If you find specific areas that multiple teams are starting to perform poorly in, you can proceed to add that as something to tackle as part of your ongoing maintenance process.
So, the point is not simply to churn out services and go into production as soon as possible. Teams must shift their focus to figuring out how they can ensure that they are looking into the assets more often and keeping track of what is going on. Perhaps the code coverage is starting to fall behind and that is why certain services are not marked as production ready anymore. Maybe that means that teams are not writing enough tests because their CI pipelines are undesirably slow. With robust reporting practices in place, you can return to the appropriate junctures and fix any issues. It is virtually impossible to make decisions like that if your team is unaware of the information stored in your historical data and cannot pinpoint where things are going south.
It also promotes a culture of accountability. Reporting reduces the gap between the team on-ground and leadership by ensuring that communication channels are kept active and that everyone is on the same page. Knowing that engineering leadership is in the loop regarding the developmental activities of the team boosts their sense of responsibility. Simultaneously, team leadership is driven to make important decisions and support the team in this way. Reporting practices are valuable in that they contribute to instilling trust and accountability in companies in the long term.
All in all, the value of reporting is evident in how it helps teams drive progress better. Reporting adds another layer of visibility for teams, equipping them with the information they need to limit the influence of risks and make well-thought-out decisions. It also enables leaders to be more efficient in their planning and investment choices.
How does Cortex enable such reporting?
Cortex’s services are built to give teams this kind of reporting. Using the data available via your service catalog, organization information, and the hierarchies, it provides comprehensive reporting on metrics that are of value to teams in that they enable informed and impactful decision-making processes.
Our service catalog is packed with information about each of your services, ranging from data on dependencies to ownership details. It acts as a repository that helps developers make sense of the microservice architecture that they are working with. By gathering the information in one place, it does away with the need for teams to search far and wide for what they need. In some ways, then, a catalog functions as a comprehensive report available to the team at all times. This is in addition to the specific, dynamic reporting that Cortex provides to teams based on the information they seek.
Cortex’s Scorecards are the drivers of robust and customized reporting for our customers. It allows leaders to define specific rules and standards that they expect developers and services to meet. Whether these are metrics for operational readiness or development maturity, leaders can compare actual performance versus the expectations to get a sense of what is working and what needs to change.
You might, for instance, build a DORA scorecard to monitor the team’s performance against DORA metrics such as MTTR and deployment frequency. Or, you might be interested in building scorecards for your resources to encourage best practices around resource management.
The scorecards use Cortex Query Language or CQL to set these rules, which allows for high levels of customization and flexibility so that leaders can benefit from precise reporting. They can also collect information from your integrations, helping you cast a wide net. Once the metrics the team and leadership are interested in are set using scorecards, you can track them for individual microservices or adopt a more global approach. The reports are automated and employ charts and heatmaps to help visualize the information.
Leaders are not only tasked with decisionmaking about services and resources, but also the teams that drive development. Cortex has a Team Hierarchies tool that also comes with in-built reporting features to notify leaders about the state of their teams’ performance. With insights into bottlenecks and progress vis-à-vis team goals, leaders can make smarter operational decisions too.
With robust reporting mechanisms and a range of services that complement each other, Cortex can provide your team with the best software development experience. Book a demo with us so that we can help you make the most of what we have to offer.
.avif)
