Guest Column | December 5, 2018

Assessing Your Software Application's Business Logic

By Denis Syraeshko, Intetics Inc.

Choosing The Right Field Service Software

Business logic causes a certain amount of ambiguity; tech people probably think about code lines while non-tech employees expect the conversation to turn to the decision making process. Both could be right, in a way, since software development is about decisions made by users and processed by software applications.

When explaining business logic theoretically, the definition would be: the custom rules or algorithms that handle the exchange of information between a database and user interface. It is important to understand 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 business rules are formal expressions of business policy. They are about opening dashboards after the login page, offering bonuses or discounts. In an application code, these rules sound like, “If the customer buys two or more products, apply a discount. If not, don’t apply discount.”

As a user, you may be wondering why you should bother. The thing is you deal with this every day even though you don’t realize 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 a customer will return — it’s all about customer loyalty.

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’s worth doing every major system or application update. It is also important to consider not only how often to run the business logic assessment, but who does it and what process the are followed.

Years after trying and testing, I came to realize assessments run by a third party are more reliable than those run by the internal team. Though your team of experts have the specific domain knowledge and understands the application, there is a simple — and possibly unexpected — truth your expert knows too much. As the assessment is not automated, human factor is inevitable. Your expert will not be unbiased.

Consider this rule number one: invite the outside expert to assess the business logic of your application to ensure neutrality.

A proper assessment of 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 the following stages we use the at Intetics:

  1. domain investigation
  2. analysis of business needs and application goals
  3. mapping business needs to application logic
    1. creating a business scenario according to the specification and business needs
    2. running business scenario in the application (questionnaire)
    3. analyzing the result of scenario running (passed, failed, partially passed, not run)
  4. deciding if application achieves business goals

This can be rule number two: follow the process and use the questionnaire.

To ensure consistency, I would recommend basing the assessment on a set of metrics as they help measure business process quality. At Intetics, we chose metrics based on those we used on our projects, requested by our clients, described in the industry best practices, and those that were considered as the most essential in 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 rule number three: 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 explanations and recommendations; without them the questionnaire answers give you nothing. With 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 (number four: create and study the assessment report and apply the recommendations.

What is in the assessment for you?

First, improved business logic raises application credibility among users. It creates a certain level of comfort; for example, it’s very nice an app adapts to the time zone you are located. Users like these small, though necessary, features.

Second, correctly created application workflow increases both sales and customer loyalty. The interdependence is apparent. The workflow defines the interface and, if the interface is good, users are stimulated to interact with the app more.

Third, the better the app completes business objectives the happier you are.

What if you won’t assess the business logic? Well, probably nothing disastrous happens but, if one day your customers get a discount for one item and do not get a discount for five, there is obviously something wrong with your app. What’s more, if you leave vulnerabilities in your business logic untouched, there soon will arise security and confidentiality issues and hacker attacks.

The bottom line is, though checking and assessing business logic is not regarded as an essential process the development teams should not neglect it as sometimes little though extremely painful bugs hide where you do not expect them to be.

About The Author

Denis Syraeshko is a project manager at Intetics Inc. For 15 years his considerable skills in problem-solving, planning, business analysis and prototyping, budgeting, quality control, and risk assessment, helped him to run and launch several projects simultaneously.  Currently, Mr. Syraeshko is one of the leading managers at Intetics. He is the head of AI and ML Centers of Excellence, a Certified Scrum Master and teaches applied mathematics in Belarussian State University. Mr. Syraeshko holds BA in information systems and technologies in economics.