As someone creating business software, there is one element that you can’t skimp on – the structure of the data that the software will use. The benefits of building good data structure can make all the difference between sloppy software and a powerful running beast.
It’s All About the Data
Virtually all software stores data. All software has a way of handling data as it’s being used or stored for future use. Let’s try to define what data structure is and what it looks like.
If you have bookshelves in your home, consider them as the way you store your data, or books. You can easily rearrange the books on the shelves for a different ‘data structure’. You have shelves that you keep your fiction on. On other shelves, you put your nonfiction. You put your tall books on the big shelf. And you put all your paperbacks, neatly stacked, in the paperback row. You can even buy new bookshelves and create a completely new and refined structure.
Data structure example
Take a personal contact program, like ACT! With ACT!, salespersons can keep up-to-date information about the clients they communicate with on a frequent basis.
Within ACT!, a salesperson will take running notes about a client’s data – their current mailing address, phone number, cell number and email address. Every facet of the customer’s profile is data.
If this data changes, they can easily bring up the record for their client, make a change and save the new information. They can review the entire user list and search for clients who meet specific criteria.
Example – the salesperson needs to find clients that live in Melbourne. By plugging in the term and asking the software to search for matching cities, the salesperson can instantly have a list of contacts at his fingertips.
Notice the important role data plays in every feature of this marketing software. However even more importantly, let’s look at how this data is structured.
Let’s take one client record. In this record or entry, we have the pieces of data that make up this client’s location or address information. This data might include the address, apartment, city, state, zip code or postal code, country.
Good data structure is vital
Good data structure means a strong, well mannered program and means future upgrades will be simpler to make. Thi sis key when creating business software that will last into the future.
Let’s take another element of the data about the client – dates.
You’ll find data referring to what happened during any given conversation. You’ll find the date when initial contact was made. We’ll look and find data regarding the date when the client placed orders.
In another part of the client’s record, we’ll find bits of information, or data, regarding the contact’s purchases. We’ll find the items they purchased, and the quantity and purchase price.
As you begin to look at all the facets of data collected for one client, it starts to look like the directory structure you’d see on your computer’s hard drive. Let’s take a look:
- [ contact ]
- [ mailing address ]
- [ street address ]
- [ city ]
- [ state ]
- [ country ]
- [ postal code ]
- [ contact dates ]
- [ salesperson comments ]
- [ client comments ]
- [ purchases ]
- [ invoice #1 ]
- [ product number ]
- [ product name ]
- [ quantity ]
- [ invoice #2 ]
- [ product number ]
- [ product name ]
- [ quantity ]
Using this structure, we now have a Success Map or outline that we can dump raw data into – quantities, addresses, phone numbers – and make sense out of! So, if I gave you a postal code, you would recognise that this belongs inside the contacts mailing address. And our structure becomes a data structure – a model for all of our data to neatly fit into.
Visualise the data structure
Looking at the model again, we’re starting to see the data structure for this sales contact program. It almost looks like we are reverse engineering the program – and we are!
Let me give you an example of why doing this for your software is so important. Bad data design means you’ll spend extra time patching data “holes”.
Let’s pretend that we’ve finished developing our sales organiser using the data structure listed above, and during the course of using it the first week, we’ve determined we’re missing a field. We should have a field in our contacts>address branch of the data structure called apartment. Seems simple enough, let’s just add it to the program.
Hmm … The software doesn’t have a way to add and remove data fields. So we have to dig into the code and make changes in the way the data is stored in the database. We have to update the database. Then change the way the forms handle input by the user. You will have to fiddle with the way the screens look to make everything fit properly. Then also need to adjust the way the program validates the data to ensure the user isn’t entering invalid or incorrect information.
Phew.
And then we have to go through and bug test everything again, because we don’t know how this adjustment is going to affect other parts of the software.
New features and re-testing
We might have a feature that allows us to print out our client’s address. Now that we’ve added apartment information, we will need to adjust the reports that print out the contact information.
And once we’ve done all this, how are we going to make it available to our customers? Do we issue a patch? Or do we make a new software release available for this minor change?
All that work simply to add one field to the program? Yep. And believe me. Making changes to the data structure late in the game is a time-burner. In doing so, it can become a major expense headache, as well.
How do we get around this problem? It’s simple – and it’s a message you’ve heard echo from the beginning – spend plenty of time planning.
If you are creating business software and you overlook data that’s important to the project, bite the bullet and make the change.
You will overlook fields late into your project.
You’ll get a good idea from a friend about a feature you should add to the project – which will mean changing your data structure. As a result, you might find that you’ve overlooked something obvious. And if it makes sense, bite the bullet and make the change.
Get all the data at the start
How do you ensure that you get all the data necessary early on?
Spend time reviewing the notes you’ve made while you were researching. Make liberal use of your User Stories you’ve put together earlier in your Success Map.
You’ll also want to do real-time research. Talk to the people who will be using this software. Ask them about what bits of data they’ll find important to use on a daily basis.
Find out what bits of data they’d like to be able to capture. Explore what their needs are presently and what data would be useful later for them.
If they are already using software similar to the type you’re building, literally watch the way they use the software. You can find out what data fields you’re missing by watching what data they are entering.
Then the important task of organising this data comes next.
This process is quite common; I’m not breaking new ground here. It’s called data normalisation and is typically done when databases are being created. There are numerous texts on the subject and I recommend that if the subject interests you to delve into research regarding ‘data modelling’.
You don’t have to become an expert in data structure or databases for your project to be successful – you simply need to be detail-minded.
Use the tree structure we looked at earlier as an example of what you want your software’s data structure to resemble. Continue until you’ve thought about every bit of data the software will store and use.
If you plan on having a programmer put your software together, put together as much of the data structure as possible beforehand.
Your architect or programmer will be able to translate your data structure directly into the database that will be used with your software.
I think our Success Map is almost finished! We’ll be able to start moving real soon.
Conclusion: creating business software
That’s it – we are ready.
If you’re developing your first application, and you’ve completed your Success Map, congrats! You now have a complete guide to your software. At this point, you could ship the Success Map to your developer and have a finished product in weeks.
If you’re building it yourself, you have a logical guide you can follow through the course of its construction.
Keep a copy of everything stored away safely. You won’t realise the value of this when creating business software, until much later.
Keep an extra copy offsite – this Success Map is gold. Don’t lose it. Ensure that it does not get eaten up by a virus. Be careful that junior doesn’t overwrite it with his homework. The Success Map truly is the heart of your project.
