I always believe that all complexities in the universe originated from simple, small, and interrelated objects or entities. Things become extremely messy when various kinds of object have been mixed up together and not properly grouped. For example, consumers will find the desired product items hard to find if the available products sold in the supermarket do not well-arranged or well-classified. Besides, having the product items well-classified is not enough; ones should also know how to associate the relevancy among items to enhance the consumer's shopping experience.
The same goes to relational data modeling, object-oriented programming, user interface design, software architecture design, and even for project documentation. I came across with various kind of people in the software industry, throwing a few scenarios to me and asking me how to have a good design in addressing a specific business problem. Often, in my thinking process, before giving out my answer, I always start from two basic things: Classify and Associate.
Every business issue, or perhaps I would say every specific business domain, involves multiple business entities that have various kinds of relationship interconnected to each other. Without having all these clearly identified and understood, one may suffer in the mess and lose his/her clue in resolving problems. This may sound very basic and familiar to everyone, however, many tend to skip this process as it is 'too basic'. Others may also want to argue that 'I have done that', but most of the time, they are putting those that 'they have done' aside while cracking their head for solution. Let me give you a very good example which I got it from the real world experience:
A specific workflow system allows the registration clerk to submit a particular application from an applicant for approval. Once the application is submitted, the application status will change to 'Pending for approval'. If the applicant failed to submit a specific required information, however, the application status will change to 'Pending for information XXX'. Both 'Pending for approval' and 'Pending for information XXX' status are allowed to be forwarded to the officer for approval but the later will have the following two outcomes:
- The application will be approved by the officer;
- The officer will not approve the application and further follow-up need to be done by the registration clerk. Once the issue is settled, the officer will verify and approve the application, otherwise it will remain 'Pending for information XXX' until the problem is resolved.
The system analyst (SA) of this project approached me and asked: "Can we add a button called 'Reject' and notify the clerk that the application needs to be resolved further? But I want the status to remain as 'Pending for information XXX' instead of 'Rejected'."
Here, the SA had made a couple of mistakes:
- She was trying to give herself an allowance for not classifying 'Pending for information XXX' and 'Rejected' under Application Status, which may add confusion and complicate the status logic.
- She did not realize that when she asked for the 'Reject' button to be added and at the same time remain the 'Pending for information XXX' application status, she was actually trying to add/change the ATTRIBUTE of the specific application status.
To resolve this issue, the simplest solution is to allow the officer to add a Remark to the specific application of this status while remain the status logic of 'Pending for information XXX' (Pending for information XXX with Remarks). As such, the system can still notify the registration clerk by distinguishing the difference between 'Pending for information XXX' and 'Pending for information XXX with Remarks'. Here, the Remarks will become the ATTRIBUTE of any application status. It also act like a subtype of each application status -- with or without remarks.
Of course, there are couple of ways to resolve this issue in a proper classified and associated manner, such as creating a new status called On-hold and have a status selection control (e.g. radio button or dropdown list) for the officer to select instead of having a one-status-one-button approach, which will never be agile and facilitate extensibility. The UI designer can then remain the consistency of the UI design by having the Save and Cancel buttons across application forms, which later could possibly be converted into reusable UI framework.
CONCLUSION:
Improving the skill of classifying and associating business entities in a logical manner will not only help making the complicated-sound business rules simple but also help ones to explain the solution logic in a clearer and more systematic way. In addition, complex business problems can be easily resolved once the job of classifying and associating business entities has been completed and well-defined. The reason behind this is that, the clearly defined business components and relationships provide higher visualization of the problem and hence making the path to solution visible.
