Resistencia de arquitetura de software
Eu tenho utilizado a palavra resistencia para definir a caracteristica de uma arquitetura em dificultar o suporte de novas ideias durante a evolução de um produto.
Dito isso, eu gostaria de salientar que esse artigo apresenta uma ideia em constante transformação e que não sei se estou certo ou errado, logo, você deve considerar questionar — por favor, sempre faça isso — o conteúdo.
Não existe software sem pessoas.
Software é uma representação ativa de processos de negócio. A dificuldade em relacionar o software com o conceito de negócio que ele suporta provem de falhas na abstração e/ou de tradução, ou seja, provem de falhas de comunicação.
Se você se sente impelido a concordar com essa observação, creio que concordará também que software depende de negócios. Ele é desenvolvido para atingir o objetivo da área de negócios.(quando digo negócios não me refiro exclusivamente a objetivos financeiros, mas a um objetivo).
Uma coisa que depende de outra ocorre DEPOIS que a outra ocorrer.
A observação acima parece desnecessária, mas decidi adicionar ela no artigo pelo simples fato da pergunta: “E ai, ta pronto?!” também parecer desnecessária mas existir do mesmo jeito.
Resumindo até aqui:
A arquitetura de software depende da arquitetura de negócios
A imagem acima representa, ou melhor, tenta representar a evolução da arquitetura de negócios de maneira iterativa, levantando uma hipotese com especialistas ou junto a clientes ou potencial clientes para em seguida apresentar um MVP com uma solução para a hipótese.
A principal falha desse esquema é não deixar visualizar o estado da arquitetura de software que suporta o modelo de negócios. Eu consigo ver que existe uma direção para a qual esta evoluindo mas não sei dizer o comportamento da arquitetura de software.
Então alterei a representação para uma em que pudesse expressar a dependencia dos eventos e seus efeitos.
O Equilibrio da arquitetura do software não pode se tornar a limitação da arquitetura de negócios.
A linha do produto é o centro da primeira hipotese. A partir dela temos o centro da arquitetura de negócio e de software e também a base para visualizar o maximo de desvio possivel sem que cada evento (hipotese→MVP) tenha que se preocupar mais com o equilibrio do sistema(o que marca o inicio da resistencia do software) que com o teste da hipotese.
hipoteses divergentes aumentam o custo de desenvolvimento.
Esse esquema me ajudou a representar a ideia de que ao elaborar uma arquitetura para atender uma hipotese especifica você pode ter certeza de que um pivot vai torna-la inutil e desconfiar que hipoteses divergentes criarão um software com custo alto de desenvolvimento de novas funcionalidades.
E por fim, esse terceiro esquema desenvolvido para transformar a linha do produto em um espaço do produto e lidar com o desequilibrio causado pelas hipóteses divergentes e a certeza de falha da arqutetura de software em caso de pivot da arquitetura de negócios.
Nesse esquema o espaço de produto é ocupado por varias hipoteses paralelas que podem se provar corretas e continuar existindo ou serem descartadas. O surgimento de uma hipotese divergente não coloca em risco a arquitetura por que ela não foi desenvolvida baseada em uma hipotese especifica mas com base no pensamento de suportar hipoteses de negócio.
Eu creio que as perguntas que encerram esse artigo são mais importante que o artigo em si:
- É possivel existir um arquitetura liquida?
2)Como pensar uma arquitetura de software que suporte o desenvolvimento da arquitetura de negócio baseada em testes de hipótese?
3) Como fazer com que uma arquitetura que atenda (2) migre de maneira saudavel para um software mais direcionado numa fase em que o produto esta definido?
Para compreender melhor a ideia de arquitetura liquida e “resistencia de arquitetura” segue um video do super Bauman
tudo que eu quis dizer é que a arquitetura de software de uma empresa em inicio de operacao precisa ser moldada para suportar incerteza mais que certeza