Colocar um sistema em produção implica bem mais do que simplesmente escrever código e fazer uso correto da infraestrutura. Há sempre restrições e acordos que precisam ser explicitados e observados.
— Dev (sem Ops): Preciso fazer o deploy dessa aplicação em produção.
— SysAdmin: Mas, não temos ambiente para publicar esse tipo de tecnologia, ela nem ao menos consta na nossa lista de tecnologias aprovadas.
— Dev (sem Ops): Como assim?
— SysAdmin: Nós temos na empresa uma relação de todas tecnologias que suportamos e que podem ser utilizadas na construção dos sistemas. E essa não é uma delas. Seu sistema não pode ir para produção desse jeito.
— Dev (sem Ops) E agora?
As restrições impostas a um sistema podem alterar completamente a forma de uma solução ser construída. Como arquitetos, é nosso papel compreender preliminarmente as restrições de um projeto, contorná-las e, as vezes, desafiá-las.
Coopere com o inevitável (Dale Carnegie)
Recomendamos três iniciativas:
- Explicite as restrições (ASAP)
- Envolva os Stakeholders
- Priorize, negocie e respeite as restrições
Explicite as restrições (ASAP)
Algumas restrições são evidentes, como prazo e custo, comuns em praticamente qualquer projeto de software. Todavia, existem alguns tipos de restrições que não tão explícita. Segue alguns exemplos:
Restrições relacionadas a adoção de novas tecnologias
Nível de maturidade: Algumas empresas não estão dispostas a correr o risco de ser um early adopter de uma tecnologia inovadora e optam por exigir um nível de maturidade do que pode ser adotado.
Tipo de licenciamento: As vezes tecnologias open source são bloqueadas a não ser que exista uma grande empresa por trás.
Sistema operacional: O ambiente de produção pode ser restrito a algum tipo de servidor e as tecnologias precisam ser adequadas a esse ambiente.
Restrições relacionadas ao usuário
Compatibilidade com ambiente: Os usuários podem utilizar um browser em uma versão específica e que o sistema precisa manter retrocompatibilidade.
Acessibilidade: Os usuários podem ser portadores de necessidades especiais que exijam que sua aplicação seja adaptada.
Restrições relacionadas as pessoas
Política: Pode existir uma força política na empresa que impõe o uso de determinada tecnologia
Time: Maturidade, tamanho e competência técnica do time pode restringir as opções de arquitetura.
Essa lista está longe de ser exaustiva e não recomendamos que seja utilizada como única referência. Entretanto, é suficiente para que sustentemos nosso posicionamento.
Defendemos que toda possível restrição seja amplamente debatida e comunicada de maneira explícita a todos. Combinado não sai caro, nem barato.
Envolva os steakholders
Muitas restrições não emergem naturalmente quando consultamos apenas desenvolvedores, por essa razão é fundamental trazer para a mesa todos os envolvidos no projeto direta e indiretamente. É importante consultar seu time de segurança, ops, gerentes, especialistas de negócio, clientes, usuários, DBAs, etc.
[tweet]O bom arquiteto é, acima de tudo, um orquestrador.[/tweet]
Priorize, negocie e respeite as restrições
Certamente algumas restrições terão mais peso que outras e, portanto, devem ser priorizadas e negociadas. Por exemplo, para atender o prazo pode ser negociado, podemos negociar a utilização de uma tecnologia ainda não aprovada.
Por mais que, por padrão, as restrições sejam um impeditivo a ser contornado, colocá-las em constraste é importante para formação de argumentos em uma eventual negociação.
Apesar de você, amanhã há de ser outro dia. (Chico Buarque)
Dicas práticas
Para consolidar nossa posição, segue uma lista de recomendações práticas que recomendamos a todos os arquitetos:
- Certifique-se de manter as restrições documentadas de maneira formal, acessível para todos os envolvidos;
- Em arquiteturas evolutivas, certifique-se de ter fitness functions que assegurem que as restrições estão sendo respeitadas;
- Assinale e evidencie restrições que não estão sendo observadas e acorde um plano de “pagamento” dessa dívida técnica;
- Certifique-se de que o patrocinador do projeto (financeiro e executivo) esteja informado e de acordo com todas as restrições;
- Esteja preparado para apresentar uma lista sistemática de prós e contras de respeitar ou não uma restrição;
- Não assuma o risco de não respeitar uma restrição sem uma ótima justificativa e, principalmente, sem apoio;
- Não “finja ignorância” das políticas corporativas;
- Coopere com o inevitável.
- Lembre-se que o pleno e o sênior sabem fazer o certo. Mas, apenas o sênior sabe quando é certo fazer errado.
Alguma recomendação adicional? Alguma história de restrição (com ou sem sentido óbvio) para compartilhar?
