[ipaddr]

They care later when new features cannot be added, changes are delayed. A bad architecture is sometimes what you need but it will only take you so far.

Architecture is important but not as important as getting the data-model right. We can refactor out bad architecture but a bad datamodel will have missing or inaccessible data since it was created and you cannot get that back.

[darkhorse13]

Not if your company goes bankrupt trying to prematurely upgrade the architecture, which is usually a huge undertaking. I think that's the entire point of the article, the guy who wrote it is clearly using a startup POV.

[xupybd]

It makes sense to build a cheap and dirty system to start. Especially if you want to build it then inject loads of cash when it takes off. But it is still a cheap and dirty system.

Too many people do build like this initially but are not willing to pay to fix the mess when it starts to get hard to add new features.

[arcbyte]

The data model serves the architecture. The architecture serves the use cases.

Data models are a dime a dozen and are throwaway.

[ipaddr]

Your data model is the heart of your business. Let's say you have a genetic product and require the user to upload their dna results and certain datapoints are taken and stored. If you decide later you want different datapoints and have not saved the original uploaded file you can't offer past customers new products.

Your architecture can change.

[arcbyte]

Youre proving my point.

Saving the whole file or not is an architectural decision involving cost tradeoffs, technology capabilities, and business strategy.

Which data points you put in your OLTP is the data model and, as you just painted an example of, throwaway when the use cases change. Later you'll want different data points or different relations. And then you'll evolve your data model yo serve that. If you did your architecture right, it will change much less than the data in your databases.