An Introduction to Minimum Viable Architecture

You can get the technology decisions wrong as long as changing the technology doesn't mean throwing away all your business logic and starting again. There always has to be coupling somewhere; just don't couple your business logic tightly with the technology.

I completely agree with this article. I can only offer one counter argument:

Once you have delivered, you have lost your mandate for delivering something. This is a political argument and points rather to a problem with the organisation rather than the architectural design.

What I've experienced in the past is that while you may be making the correct choice delivering exactly what is needed at the time, the political judgement once the scalability of the delivery is revealed to be insufficient is extremely negative.

<quote>If you don’t end up regretting your early technology decisions, you probably over engineered</quote>

More often than not, when you regret your early technology decisions (or architect/design decisions), you probably under engineered.

In 18 years of work, in both small or large shops, both commercial and defense, I've seen far more under-engineering (typically in the form of happy-case-only programming) than over engineering, independent of methodology (agile/scrum, iterative all the way back to waterfall.)

<quote>Rearchitecting is a sign of success; if you never need to, either you overbuilt or nobody cares.</quote>

This claim is even more dangerous. It is ok to do refactoring, in fact, it is necessary to maintain a healthy control of entropy.

Re-architecting, on the other hand, that is another ball game.

There are tactics, and there is strategy. Continuous tactical changes (represented in design and implementation improvements) are a sign of success in having a good process in place.

Strategic changes (represented by potentially costly architectural changes), they can only come when they are truly needed, and must be minimized.

Why? Because of the cost. If re-architecture is required because of an externally driven event (say, a merger between companies, or bankruptcy by a provider of a vital COTS component), then achieving it would be a success.

Re-architecture because enough diligence wasn't made up front (simplest architecture == simplistic architecture), then that is a change that was preventable via greater architectural diligence up front. It is a change that costs money (and since it was preventable, it must be seen as a loss.) Thus, it is a failure, not a success.

This is excluding the growth, extension and enrichment of an architecture that is amenable to enrichment. I would not call that re-architecture.

Re-architecturing, the mere notion of the word, and using analogies from the physical world, implies significant, if not destructive changes to the original architecture.

You don't go from pipes and filters to an event driven architecture and call it success on the effort if you knew a-priori that the problem statement required the later and not the former.

That is a failure no matter how you cut it because. And it seems to me that a lot of people conflate architecture with design or implementation-level details.

I like the concept of Skateboard, Bike, Small Car, Large Car to show MVP. But how do I go form a skateboard to a canoe? The business logic is reusable to some extent, but as the technology will not scale, I need to start over. Starting over on different tech requires new logic. All I keep is the requirements and I lost a lot of time with my business partners. What can be done upfront to check viability of scale?