Workflow and Database Design Iterations
This piece continues with the theme of building order. In a previous article, I used a phrase that 'workflow building is an iterative process and is constrained by what is practical and desirable.'
At Coracle, we had a case recently which highlighted this issue.
The Coracle Learning Line platform allows people to keep a permanent record of their professional learning progress. Even if they leave and go to another employer, take a year off to go to college, or get married and change their name, they don’t need to set up a new profile and above all, they won’t lose evidence of all the many types of learning they’ve done.
We were building a new product for a client involving a website where a student could sign up for a course by concurrently accessing our main data repository. Workflows were required to handle communications (such as emails) with the new student from the main data repository.
A test database was built very quickly, and it included basic details such as the student’s name, the company they worked for, and the course they were following. But it soon became clear that there were a number of additional functions we had to consider.
Questions such as, "What if the student changes his/her name?", "What if they changed company?", "What if they wanted to cancel and close their account?" came up in discussion. Clearly, the initial test set-up would not be able to handle these. The database structure was not up to handling the job and needed to be extended.
Our first task was to write down a list of the most important events we needed to handle on the website and within the database. This list became the documentation for the extended functionality and each item on the list soon became referred to as Record Type 1 or 2 etc.
For example Record 1 might be the 'event' of achieving membership of a professional organisation. Record 2 might be a name change as a result of getting married. And so on.
The Record Type was used as a shorthand description of the whole array of requirements within each case, and it soon became clear that a new field named Record Type would be useful as a concept within both areas.
This Record Type became the key element of bridging between the website and the database. Both website and database designers immediately knew what was needed in each record type and could both consider their designs independently whilst being focused on the same end point.
Thus, in a very short time, the iterative design process had been simplified and was immediately capable of expansion, simply by adding additional record types. The design had been improved to handle a wider variety of types of activity than was at first considered and many additional features could be introduced as or when required.