After many years of working in "the software industry" I have (with the help of colleagues) come to an undeniable realization:
There are only two types of software.
In the nearly two decades of designing, architecting, and writing code for software I have spent an unimaginable amount of time hyper focused on pseudo-perfection. More meetings than I can count debating the minutiae of second versus third normal form, and whether or not BASE32 or BASE64 were appropriate for a non numeric unique identifier.
I'm not proud of it, but at one point in my career there was an entire week dedicated to the precision of a localization debugger and whether or not it needed to be compatible with Serbian and Polish characters in case we were to have a customer in either country in the future.
Let's be honest; if you have ever worked in software or written code in any professional capacity before, you are not being honest with yourself if you cannot relate to some degree.
I believe if we take a step back there is a far more appropriate view of software as described by the "60/60 rule" as explained in Frequently Forgotten Fundamental Facts about Software Engineering:
Maintenance typically consumes about 40 to 80 percent (60 percent average) of software costs. Therefore, it is probably the most important life cycle phase. Enhancement is responsible for roughly 60 percent of software maintenance costs. Error correction is roughly 17 percent. So, software maintenance is largely about adding new capability to old software, not about fixing it.
He goes on to explain that the majority of "maintenance time" is in fact time spent learning or becoming familiar with the software which inherently results in maintenance being more difficult than development of new software.
All of this is to say it is all but a certainty that the minutiae of the project will change if not in the short term, definitely over the long term, and thereby extra effort in the requirements and/or design phase will be virtually worthless.
Your efforts at the early stages of design and requirements gathering should focus on the absolutely deal-breaker requirements to deliver value to your customers. In so doing, your engineering teams can deliver that and whether or not they used RDBMS or NoSQL will be literally irrelevant to the customer.
Just for reference, some of the changes I have personally been involved with over my career that hopefully highlight this point:
- Changing a "database" from MongoDB to MySQL on a production system
- Moving a >100m ARR product from bare-metal to AWS
- Changing frontend frameworks from Angular to React
There are so many others but I hope the point is made; not even the fundamental data-center is static and will change. What matters is your customers' ability to use and find value in your products.
Stop wasting time with the minutiae and focus on delivering value. Your teams should be empowered to build with whatever technology they want provided they assume the responsibility of the maintenance and any associated training or "learning curve" to develop.
Beyond that, it either works or it doesn't!
header vector created by freepik