Don’t Forget the Business Logic
The business is at the heart of software development
Many programmers create software that looks great, and has incredibly interesting technology under the hood.
Then people don’t use it, and one-star reviews greet the release of the software. The developer doesn’t get feedback from users and misses the opportunity to understand their user-base and make the software that will truly change the world.
How does this happen?
How can we ensure that our software will be suitable for the target market?
Read on…to find about why business logic is so essential in software development…
Business Logic is the part of the program that encodes business rules and manipulates data according to those rules.
In practice, it gives your software a reason to exist and an opportunity to give customers a great experience.
The Business Logic Example
When developing an ecommerce website, you would be asked for a shipping and billing address before being asked for payment
The Business Rules Example
An address must contain a number for the address.
The email provided must contain an @ symbol as well as a . symbol following a traditional validation process for such.
For the purposes of this article, Business Rules and Business Logic are used quite interchangeably even though the terms represent different parts of a particular software application.
Software Developers: Aim high
It is perfectly acceptable for software developers to create software that they find stimulating to produce, and perhaps want to learn a new technology or implement something that is interesting.
You know what. This is absolutely fine.
You need to make your job as interesting as possible in order to remain productive and push your career forwards.
This needs to be balanced with the idea that software (and the features and functions contained within) need to meet a need. This need is usually called the business logic of the requirements of the software.
Part of successful software development is the balance between the process of creating software, and meeting the needs of the target market for that set of features and functions.
If you don’t meet the needs of your customer, what are you doing?
Put Control in the Hands of Users
When the business has a need, this is delivered through the software development process but this has to be driven by the business needs and requirements.
As a result, the Agile methodology has the Product Owner role that is responsible for managing the product backlog. It is inevitable that this role should represent the business, and ensure that the resultant software delivers the required business logic in the correct domain.
To hammer home the point, Dogfooding is where organisations use their own software as a means to not only test the software but put the software into the heart of the business.
The business drives software development. To put it another way, software should deliver the needs of the business (but not the other way around).
Business Rules Make Sense
When a customer uses an ATM they are, in a sense, using a teller that can either be a machine or a person. The process where they ask for (say) the balance of their bank account it similar but also subtly different (for example an ATM always gives you your card before the cash you have asked to withdraw — because if not customers are likely to forget their cards).
Although we are using a machine for the customer journey (and ultimately business purpose), the fact that the customer is interacting with a machine is not the focus. From a customer perspective the focus is on getting things done, and from the business perspective the focus is on the business logic.
Control flow logic interacts through Business Logic
Control flow logic, that is loops and branching through IF:THEN:ELSE patterns don’t really effect the customer.
I mean, OK, if there are bugs and the software application crashes then the customer will be disappointed and may stop using your software.
However, in well designed and well performing software the user should interact with the software through a well-designed interface that may (or in some cases absolutely does not follow this) and obfuscates the code that is written by software engineers.
To say this again, one of the functions of a software application is to obfuscates the code and software development process that went into the software.
This means that our software if working to deliver the business logic (the business rules) while hiding the software engineering process that actually produced the software in question.
This brings into stark contrast the idea that software engineers work just to complete nicer and faster solutions. If they aren’t delivering business logic, what is the point?
People should not be in the place where they are continually developing tech demos that aren’t in the hands of customers.
When you develop successful software people actually use it, and although this may be because people are interacting with the software through ever more developed and exciting user interfaces ultimately they are delivering business logic.
Isn’t it time you started to think about the work that you do, and how best you can deliver the business logic seamlessly to your customer?
Extend your knowledge
- Wikipedia have produced an article about Business Logic (HERE)
The Twitter contact:
Any questions? You can get in touch with me here