Melvin Conway foi um cientista da computação e programador. Por volta de 1968, em um de seus estudos (“How Do Committees Invent?”) na sua conclusão escreveu:
“Ao desenhar seus sistemas, as organizações estão fadadas a produzir cópias de suas estruturas de comunicação.” Melvin Conway
Isso na época (55 anos atrás!) foi questionado por carecer de uma comprovação mais ampla. Com o passar do tempo, este estudo comprovou na prática as suas conclusões que hoje conhecemos como A “lei de Conway”.
Antes de prosseguir, gostaria acordar com você que é um software (no sentido mais amplo): “O software é fruto de um processo intelectual e colaborativo que reflete as ideias e processos das pessoas e equipes envolvidas”.Com base nas duas provocações acima, uma das possíveis reflexões poderia ser:
Se o software reflete as ideias de pessoas, processos e comunicação, e o que desenhamos e produzimos são cópias das estruturas de comunicação na empresa, seria justo dizer que o sucesso de uma boa arquitetura (no sentido mais amplo) precisa primeiro sensibilizar pessoas, processos e comunicação para então discutir e implementar padrões, especificações e tecnologias.
isso faz sentido para você?
Em uma troca de experiências recente pelo LinkedIn referenciei a mesma “lei de Conway” no âmbito social/comportamental pois acredito que seja mais ampla que o escopo tecnológico. Sistemas podem ser traduzidos como plataformas / mídias digitais e organizações podem ser traduzidas como sociedade. Esta sociedade nos últimos anos vem se expressando cada vez mais nas plataformas / mídias digitais (para o bem e para o mal), reduzindo-se ao viés de confirmação, valendo aqui outra reflexão:
O que estamos fazendo para não sermos fadados a reproduzir as estruturas destas mídias em nossas relações pessoais/profissionais, refletindo até na forma que escrevemos nossos sistemas e como resolvemos os nossos problemas?
As áreas estruturantes devem trabalhar com vários times qualificados e com tomadas de decisões estratégicas junto com gestão da empresa.
Para tudo funcionar precisamos:
- Decisões sejam compreendidas (processos).
- Decisões não compreendidas, são mal interpretadas e isso leva a resultados indesejados.
- Clareza entre os times negócio e tech (comunicação)
- Falta de clareza sobre um PROPÓSITO gera atritos entre os envolvidos e quase sempre implica em quebra de prazo e retrabalho.
- Engajamento de todos (as pessoas que decidem e pessoas que fazem acontecer).
- Sem engajamento não existe arquitetura que funcione
Resumindo, o que fazemos no dia a dia como arquitetos é avaliar e implementar PROPÓSITOS, com tomadas de decisões tecnológicas fundamentadas (pelo menos na maioria dos casos) na engenharia de software.
Este trabalho é apoiado e incentivado por uma evolução constante do negócio, processos, comunicação, tecnologias (emergentes ou não) e pessoas.
Então quando me perguntam o que é preciso conhecer de padrões e tecnologias para integrar o nosso time de arquitetura corporativa, começo fazendo um “disclaimer”:
Arquitetura NÃO é somente sobre tecnologia é essencialmente sobre pessoas!
Ao final do dia que o realmente importa é obter resultados profissionais e pessoais de acordo as minhas, as suas, as NOSSAS expectativas.
Tenham um excelente dia! Eu sou Fernando Cerqueira e entrego estratégias digitais para os desafios do presente, com propostas de inovação para um futuro sustentável.
