Henrique Moody, arquitetura define o arranjo do software e não o software em si, essa é uma separação necessária. Ela realiza a orquestração, e não toca um dos intrumentos.

Dito isso, tentar escrever um software que suporte varios produtos é loucura(seriam loucura os software white label, o WP, o Drupal?), mas pensar como suportar o teste de hipoteses através de MVP não é.

A questão do futuro do software depender da aceitação ou não é a motivação desse artigo.

Nem todo software tem um software “core business”, principalmente MVPs, e esse outro ponto do que desejo abordar iniciando com esse artigo.

O core business deve estar presente no primeiro MVP mas o primeiro MVP é feito para ajudar no caminho de descobrir qual é o core business e evitar o risco de escrever um core para algo que não será o business. Me parece que se pudermos postergar o desenvolvimento do tal core business até sabermos o business teremos uma redução do risco de estarmos queimando dinheiro?

Não existe a total compreensão do negócio no D-zero. Existe sim, uma diferença entre saber que existe um desejo por algo(oportunidade) e saber a melhor maneira de entregar esse algo(solução). O MVP testa a abordagem a um problema que sua hipotese diz que a)existir, b) pode ser resolvido do jeito X.

De maneira alguma a arquitetura que desejo abordar tem por objetivo prever o futuro, pelo contrario, meu desejo nessa pesquisa é tornar possivel que o futuro possa ser qualquer um reduzindo a resistencia que uma arquitetura apresenta durante os momentos de maior risco(hipotese, teste de hipotese, definição de produto e pivot) e proporcionando uma transição mais amena para o software dedicado ao problema/solução descoberto como negócio.