The Allegory Explained

In yesterday's article, I wrote about application development in a roundabout way. I used the metaphor of mail delivery to discuss how scale and security requirements impact the nature of the solution that can best address the problems.

Not every solution has to provide bulletproof security and infinite capacity.  Insisting on such solutions in all situations is not the principled stand many advocates seem to think it is.  Rather, that sort of thinking is the classic error of making the perfect the enemy of the good.

This is the sort of thinking that leads IT departments to ban the use of Microsoft Access.  

[Accounting department]: We'd like to build a basic Access application to integrate these three other siloed software systems.

[IT department]: You can't use Access.  Build it properly or not at all.

[A]: How much will it cost to "build it properly?"

[IT]: Three times what you budgeted for your Access project.

[A]: We can't afford that. I guess we'll just keep emailing each other .csv exports.

Explaining the Allegory

A joke is no good if you have to explain it.  The same goes for similes, metaphors, and allegories.  But in the interest of clarity and explicitness, I'm going to do it anyway.

Household Mail => Word and PDF files

Think of this as a shared network folder with a variety of Word and PDF documents.  Everyone in a small department has full read-write access to all the files in the folder.  If the amount of info is limited and there are no major data storage requirements, this may be all that's needed for

School Mail => Excel files

As the amount of data increases, managing that data in a mishmash of unstructured files is inefficient.  With security not yet an issue, moving the data into spreadsheets is a simple way to increase efficiency.

Interdepartmental Mail => Access with an Access back-end

As the data continues to increase, individual Excel files will quickly become a bottleneck.  To ease that bottleneck, the data can be migrated into back-end Access files.  A front-end user interface in Access will help guide users and improve data quality.  

Access itself does not provide any meaningful data security in this scenario.  But it is no less secure than the options above.  If Active Directory file security on the back-end Access file is sufficient, then there is no need for a more robust solution.  This is very much like the interdepartmental envelope scenario described in the other article.  The envelopes themselves provide no real security, but they do improve efficiency of the system and help well-meaning employees act honorably.

Office Building Mail => Access with SQL Server back-end

If you need actual security for your data, migrating the back-end from Access files to SQL Server can provide that security.  A well-designed integration with SQL Server can also scale to many more concurrent users than a pure Access solution.

National Mail Delivery Service => Client-server architecture

There are technical limitations that cap the level of security you can provide with a file-based front-end user interface built with something like Microsoft Access.  For those situations that call for maximum data security, it's hard to beat a client-server architecture where there is a clean layer of separation between the user interface and the data storage.

Image by LwcyD from Pixabay