System Design Tip 2 – Linking related behaviour

 

Why it’s important to link related system behaviour

When designing any system or application, as a Solution Designer or Business Analyst, it is important to think through the longevity of your decisions. There are three main things to consider when trying to solve immediate change requests or enhancements. I’ve listed them in order of importance. 

1. 1. Will this change affect existing parts of the system?
      This is important because you don’t want to fix one issue and create another.
   2. How easy is this change to maintain in future release cycles?
      Understanding this will help with overall system maintenance, something that is often overlooked when trying to get a project over a deadline. Are you simply pushing problems into the future, by trying to get quick wins?
   3. Will someone else understand this design, is it logical?
      Someone is bound to come across your design in a future release, if its not well documented, it will be a nightmare to maintain or change. This is equally important for testers and help desk staff (level 1 and 2). Will other people be able to debug and find the root cause of an incident if your logic is convoluted?

To help remedy all three of these issues, it is important to group related behaviour to one piece of decision logic. 

Real life example

Say for example you are designing a user interface for customer to submit an application form. When the customer enters their date of birth the system does the following:

1. 1. A message pops-up telling them why they need to provide this information, 
   2. A new screen appears in the process flow, asking for country of origin details, and
   3. On submission the customer needs to upload a copy of their birth certificate.

Here is what a solution designer should and should not do when designing this system. 

Do this.

All three of the above features are linked, they are related to the customer’s date of birth. It is best practice to ensure all three related outcomes are linked to one piece of decision logic. Meaning the popup message, the new screen and the required documentation should all be linked to a piece of code/logic, something like the following:

IF 

date.of.birth in database is not null

THEN 

display pop-up message AND

add new screen to process flow AND

add the required document to the submission screen.

END

 

The above logic basically says if a valid date of birth exists in the database, then trigger the 3 system actions (message, new screen and required documentation). The logic infers the date of birth is in a valid format, because validation should be applied before it is saved to the database. 

Don’t do this.

Here is what a Solution Designer should not do. They should not create three independent triggers for each system behaviour related to the customer’s data of birth. 

1. 1. A message pops-up giving them a warning.
      Triggered by: UI screen element, on-click on date of birth field.
   2. A new screen appears in the process flow, asking for country of origin details.
      Triggered by: Database element, if date of birth exists in database, display new screen.
   3. On submission they need to upload a copy of their birth certificate.
      Triggered by: Process flow, if the new country of origin screen exists. 

 

Why take this design approach?

There are a few reasons it is important to link related system behaviour to one piece of controlling logic. 

My tips