Once the business requirements have been collected, another part of the business dimension emerges, including a way to identify the essential metrics around the business problems that you're solving. These metrics should be determined and expressed concerning the business domain, in order to understand how well an application addresses the business requirements that it was designed for.

Let's revisit an example that we used in the previous chapter. Suppose that the bank is currently using the post office to send monthly bank statements to its clients. In this case, you know a priori, how much money it costs, and the tasks involved in accomplishing the goal. In addition, you even know how many clients you have and how much paper should be printed, according to specific dates. After the implementation of your system, you will want to know that all of your clients are receiving their bank statements. Consequently, you will want to implement a mechanism to identify how many bank statements are being sent by the application, and which notification channels are preferred. This information will be used in the near future, in order to identify new business opportunities, discover when the system has problems, and monitor the ROI of the application. After all, the implementation of a system is guided by a business's needs, and you have to verify that those needs are met.

Once the application is in production, an excellent technique for assessing the business health of your application in the wild is to build bots. These bots exercise your application as a regular user; you'll want to at least create bots around the most important functionalities of your application. If not, how will you know if your application is working?

This goal can be achieved by executing scheduled checks that will send you notifications with the obtained results. This simple technique will give you confidence that the application is working as expected, and is providing a service to your clients—who are the purpose of the system.