Estamos descobrindo maneiras melhores de desenvolver
software, fazendo-o nós mesmos e ajudando outros a
fazerem o mesmo. Através deste trabalho, passamos a valorizar:
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita,
valorizamos mais os itens à esquerda.
Criaram a primeira sugestão de processo Scrum apresentada na OOPSLA em 1995 OOPSLA (Object-Oriented Programming, Systems, Languages & Applications)
A Arquitetura de Soluções tecnológicas, em todos os seus níveis, sempre foi responsável por garantir que as aplicações fossem as mais adaptáveis e resiliêntes. Tentando olhar além do funcional e preparar o software e o processo para mudanças e impactos futuros.
Ou seja, a base da boa arquitetura é fomentar a agilidade.
Balancear estes dois pilares é o grande desafio das empresas. Se a empresa focar muito em inovação, pode gerar um grande problema de custos e escala futura. Por outro lado, se olhar apenas para eficiência, com certeza perderá oportunidades de negócio e tração.
Em um mundo de incertezas, é cada vez mais complexo para qualquer time de Arquitetos tentar prever padrões dentro de ecossistêmas de negócio tão voláteis. Em um mundo onde as tecnologias evoluem de maneira devastadora é impossível definir uma única solução correta para os problemas de negócio.
E como lidar com as rápidas mudanças tecnológicas e as diversas novas soluções que aparecem todos os dias? Como usar os conceitos de agilidade para que as pessoas se apoiem na descoberta e melhoria contínua?
O modelo tradicional já não é suficiente para os novos modelos de trabalho. Os próprios conceitos de agilidade nos mostram o caminho.
Aplicar processos rígidos só vai distanciar as pessoas da informação que precisam para tomar as melhores decisões.
Manter uma postura aberta sobre as opiniões dos times de tecnologia envolvidos com as demandas de negócio e interagir de forma transparênte para apoiar na priorização dos requisitos não funcionais que podem ser críticos para o cliente.
Ter milhares de padrões e documentações para que os times possam executar suas funções pode até dar a impressão de controle. Mas é fato que essas indas e vindas perdem o foco no que realmente importa. Um sistema funcionando para o cliente.
Aqui é muito importante salientar a palavra funcionando. O foco do arquiteto é mostrar através de dados e argumentos quais os cenários que podem levar o usuário a considerar que o sistema não funciona. (Disponibilidade, Consistência, Performance, Segurança ...)
É humanamente impossível conhecer todas as tecnologias e soluções do mercado. Como avaliar tudo?
A chave para esta resposta é Colaboração com os times de desenvolvimento. Dar flexibilidade para que testem novas ideias e tecnologias para solucionar os problemas é o primeiro passo para fomentar um ambiente de inovação. Inovação que permite que novos padrões e arquiteturas emerjam dos times.
A proximidade do Arquiteto para ajudar a identificar os requisitos não funcionais mais críticos é essencial nesse processo.
Definir uma arquitetura inicial completa (big design up front) e tentar seguir o plano não permite que as pessoas encontrem soluções diferentes para novos problemas.
O arquiteto precisa dar opções ao invés de direcionamentos. Por isso a colaboração com os diversos times é tão importante. Da inovação nascem novas opções para soluções futuras.
Esse é um caminho que algumas empresas tentam seguir. Considerando empresas de tamanho pequeno, de até 500 pessoas de tecnologia, essa pode ser uma saída. Mas logo a interação entre os times vai reduzir (com o foco em seus próprios projetos) e muito desperdício será gerado.
O arquiteto ágil é aquele que age como elo entre as soluções, fomenta o compartilhamento de informações e garante que os times tenham opções viáveis para solucionar seus problemas.