By Denis Syraeshko
Project Manager, Intetics Inc.
The article was originally published in SoftwareBusinessGrowth.com
Discussing the aspects of the business logic may cause certain ambiguity. Tech people would probably think about code lines while non-tech employees may expect the conversation to turn to the decision-making process. Both could be right, in a way, since in software development industry business is about decisions made by users and processed by software applications.
If explaining business logic theoretically, the definition would mean “the custom rules or algorithms that handle the exchange of information between a database and user interface”. It is important to understand that business logic is the part of a computer program that contains the information (in the form of business rules) that defines how a business operates.
To make things clearer, it worth mentioning that business rules are formal expressions of business policy. They are about opening dashboards after login page, offering bonuses or discounts. In an application code, these rules sound like “if the customer buys 2 or more products, apply a discount. If not, don’t apply discount.”
As a user, you may think: “Why should I bother?” The thing is that you deal with it every though you do not even know it. For users, a proper business logic is the guarantee of a clear working application. They understand it, they like it and want to use it. For the application owner, a proper business logic guarantees that a customer will return. It’s all about customer loyalty. Combining this all, assessing the product correctness and suitability to a given business problem is a must.
The assessment of the application’s business logic can be held at any given moment of time. There are no specific requirements or some obligatory schedule you should stick to, however, relying on personal experience, I can say it worth doing every major system or application update. It is also important to consider not how often to run the business logic assessment but who does it, and what process the person follows.
Years after trying and testing, I came to realize that the assessment ran by a third party is more reliable than the assessment ran by the internal team. Why so? Though the team of your experts has the specific domain knowledge and perfectly understands the application, there is a simple, and possibly, the unexpected truth, your expert knows too much. As the assessment is not automated, the human factor is inevitable. Your expert will not be unbiased.
Let’s take it as a rule #1. Invite the outside expert to assess the business logic of your application to ensure neutrality.
A proper assessment of the business logic should follow a certain process, while the expert assessment approach relies on the industry best practices and standards. Ideally, based on the domain investigation, research of business needs and application goals, the expert creates a checklist or a questionnaire. Users, stakeholders, product owners, developers, anyone involved in app development goes through the questionnaire. This provides the expert with an overview of the application state.
The overall process can go through such stages (we use the at Intetics):
- Domain investigation
- Analysis of business needs and application goals
- Mapping business needs to application logic
- Creating a business scenario according to the specification and business needs
- Run business scenario in the application (Questionnaire)
- Analyze the result of scenario running (passed, failed, partially passed, not run)
- Decide if application achieves business goals
This can be rule #2. Follow the process and use the questionnaire
To ensure the consistency, I would recommend basing the assessment on a set of metrics. They help to measure business process quality. At Intetics, we chose metrics basing on those we used on our projects, requested by our clients, the ones described in the industry best practices and those that were considered as the most essential in the ISO standards.
Effectiveness – the level of product performance according to specific customer requirements.
Quality – the compatibility with internal and/or external systems and correct application’s processes execution for the achievement of the specified goals. The processes included in business logic should not have unpredictable errors and unnecessary steps.
Data safety – the correctness of the data flow in the business logic. The data should be up-to-date and detailed on every step of the process.
Simplicity – the ease of use. Users should achieve specific goals with effectiveness, satisfaction, and comprehension of the process.
Business Rules and Policy – system/app compliance with business rules and (or) policy agreements. Business rules can constraint business logic execution and determine functional and (or) business requirements to the product.
Competitiveness – describes app characteristics in comparison with similar competitive products that can be used to cover the same users’ needs.
This looks like a rule #3. Use metrics to run a comprehensive assessment.
Based on the results, the expert should create a report describing the state of the business logic. The report should include the explanations and recommendations, without them, the questionnaire answers give you nothing. With the analysis and recommendations, you can create the app innovation roadmap. If you are lucky, you can pride yourself on creating an ideal application.
One more good rule (#4). Create, study the assessment report and apply the recommendations.
What is in the assessment for you?
First, the improved business logic raises application credibility among the users. It creates a certain level of comfort, for example, it’s a very nice thing if an app adapts to the time zone you are located. Users like these small though necessary features.
Second, correctly created application workflow increases the sales and customer loyalty. The interdependence is apparent. The workflow defines the interface if the interface is good, users are stimulated to interact with the app more.
Third, the better the app completes the business objectives the more you are happy.
What if you won’t assess the business logic? Well, probably nothing disastrous happens, but if one day your customers get a discount for 1 item and do not get for 5, there is obviously something wrong with your app. What is more, if you leave vulnerabilities in your business logic untouched, there soon will arise security and confidentiality issues, hacker attacks and something else. Do you think this is something you can prevent?
The bottom line is that though checking and assessing business logic is not regarded as an essential thing today, however the development teams should not neglect it. As sometimes little though extremely painful bug hides where you do not expect it to be.
Learn more about software assessment
Image credit: freepik.com
