This month, we’re going to talk about how we validate some of what we did in last month’s exercise. In last month’s development diary, we talked about determine what information needed to be stored. You might think we found it all, but this is where changes tend to happen. Now, we’re going to dig into more about the process.
A written outline (and even a conversation) can sometimes hide nuances required for an application to work well and meet the often complex requirements businesses have. As a developer, it’s our job to convert those written outlines and conversations into something workable. To do this, we must determine the workflow. I remember my Systems Analysis class back in college speaking about “data flow diagrams” and we even had to create some as part of our project. It wasn’t until I got deep into creating a discount system for the shopping cart platform I created back in my early career that I realized just how useful they were.
We can only map out a process in our head to a certain degree and the more complex a process is going to be, the more likely we are going to need some kind of diagram to illustrate how it should work.
The project we’re following along with is a compliance auditing platform, something which has a great many nuances (not to mention federal regulations) that apply to the process. This is further complicated by the fact that access needs to be extremely controlled.
I started with a simple enough process: inviting business associates to sign the required agreement. This seemingly simple process revealed a number of holes in the data model I created for last month’s blog. First off, I had left out pieces necessary to allow for audits. I also left out a structure to manage invitations. It actually got to the point that I needed a bigger canvas to work on.
Here’s a sample data flow diagram (what I generally just refer to as workflows). It’s one of many that we will produce for this application as we think through how it needs to work.
