Non Functional Requirements (NFR’s) are a type of requirement that is used to judge the operational nature of a system. They’re things like scalability, fault tolerance, accessibility, maintainability, extensibility, performance, etc. NFR’s are often called the “ilities”. I call them the “Tony Stark’s” of your Avengers team because they can seriously make or break your project.
Tony Stark NFR is that of system performance, more specifically, microflow performance.
Recently the large data and integration nature of a Mendix project meant that Product Owners were likely to need the definition of how long features took to complete. From the time we’ve spent modelling Mendix we’ve noticed 2 flavours of Microflows emerging, the detailed type of Microflow were system detail work is done (things like editing strings or crunching data) and high level flows containing business logic most meaningful to business. Due to the relevance of the business we decided, as a Mendix Scrum team, to implement a practice of measuring the business level Microflows as a form of measuring the NFR element of performance. The result was that the business was empowered to make decisions about what features to include/remove in order to make round trip performance goals. Not only that but using scatter diagram display widgets the team was able to deliver a mechanism for Product Owners to effectively monitor their entire process allowing them to keep vendors honest.
This is how we implemented the practice of measuring the performance of those business flows:
1. Create Meta entity
The first thing is always to attack the problem from an entity model perspective. Here we created a Meta Performance entity to save the meta information about the system performance. Simply we included a start and end time as well as a description of the feature name so that users know what feature is taking a measured time. Lastly we created a “TotalTimeInSeconds” calculated attribute to present the time the feature took to complete – but more on that in step 3.
As a side note: Mendix 5 actually gives you the functionality to populate these Meta Performance feature names with the feature titles from Sprintr. A neat way of bringing business even closer to the running solution.
2. Run the microflow
Simply create the Meta Performance entity within the business level Microflow using an initial time stamp at the (using [%CurrentDateTime%]) start of the Microflow. Similarly save the timestamp under the “EndTime” attribute as the last action of the same Microflow. Be sure to only save the entity in the last action of the Microflow. That way you minimize the impact of the performance measuring the Microflow as little as possible.
3. Measure, save and present to the user
Lastly, using the calculated attribute on the Meta Performance entity calculate the difference between start and end time using the “secondsBetween” microflow.
By measuring the performance of business level Microflows it enables Mendix Business Engineers to use accurate metrics to improve the application as a whole. Furthermore it empowers Product Owners to make effective decisions about their product.
This post was part of a series that MendixAndBeyond.com is doing on including effective metrics in your Mendix projects that will allow Product Owners and Mendix Business Engineers to build better systems.