Os CFOs são responsáveis pelas finanças, o COO pelas operações, tudo isso é bastante claro.
Para a Enterprise Architecture, os CEOs geralmente são os responsáveis finais fora das funções formais de Chief Architect por exemplo.
Mas quem é claramente responsável por sua arquitetura da qualidade de software?
A “arquitetura” está presente transversalmente, levando a uma confusão constante: estamos falando de arquitetura corporativa, funcional ou técnica?
A criação de software é suportada por um sistema denominado SDLC – Software Development Life Cycle – que é arquitetado, intencionalmente ou não.
A arquitetura de qualidade de software é geralmente diluída nas organizações em diferentes funções, resultando em uma inclusão pobre e inconsistente.
Na verdade, onde está seu arquiteto de qualidade garantindo uma abordagem holística?
Os arquitetos tradicionais são pivôs com uma visão global dentro das organizações
Os arquitetos geralmente vêm com sua aura de mistério, o que eles estão fazendo na realidade?
No pivô entre o Negócio e a TI, costumam ter que articular perspectivas divergentes e transversais.
Os principais diferenciais são de identificar requisitos estruturantes funcionais e não funcionais, que teriam sido perdidos.
Isso envolve os arquitetos de serem multifuncionais e multidisciplinares em suas interações e perspectivas.
Eles não são necessariamente especialistas em vários campos, mas precisam de ter a capacidade de incluir de forma proativa diferentes visões.
Nas interações iniciais, eles precisam ser uma verdadeira esponja, capaz de fazer perguntas pertinentes.
A arquitetura da qualidade geralmente se perde na organização
Dependendo de seu âmbito, os arquitetos podem interagir mais ou menos com a qualidade do software.
Uma dificuldade real está no posicionamento dentro das organizações, que por design não é tão claro quanto um CFO, pois a sobreposição depende do contexto empresarial.
O seu CFO é dono das finanças, mas quem é o dono da qualidade do seu software?
Antoine Craske
Somando-se a essa configuração complexa de arquitetos, a qualidade do software em si não é suficientemente compreendida, perdendo o vínculo com os objetivos de negócios dentro das organizações.
Deixando de lado o diálogo entre desenvolvedores e operações conhecidas como DevOps, as equipas de qualidade não entraram tão rapidamente no band-wagon do DevQAOps.
Pessoalmente, acredito que acabamos em organizações confusas, com responsabilidades desconhecidas, com falta de clareza, levando a um baixo desempenho.
Diferentes tipos de arquitetos residem nas organizações
As funções do arquiteto tradicional podem ser diferenciadas a seguir, inspiradas em The Practice of Enterprise Architecture do Svyatoslav Kotusev.
Os arquitetos corporativos geralmente são pivôs entre o CEO, o conselho de administração e a estrutura, estratégia e evolução geral da organização.
Passando para a unidade operacional, podemos localizar os Arquitetos de Unidade de Negócios e Arquitetos de Domínio, garantindo o ecossistema dentro de seu perímetro.
Eles podem ser complementados por posições específicas, como arquiteto de soluções, arquiteto técnico e arquitetos na Cloud, dependendo das organizações.
As configurações dependem da maturidade da empresa, da sua capacidade e dos seus requisitos em termos de arquitetura. Em uma estrutura pequena, um arquiteto pode assumir as diferentes responsabilidades.
A qualidade de software é um sistema que requer arquitetura
Produzir software envolve um sistema completo e complexo.
Desde a idealização, concepção, implementação, operação e manutenção, vários atores estão envolvidos em seu ecossistema.
Geralmente lembramos o processo como o ciclo de vida de desenvolvimento de software (SDLC), pelo menos para o desenvolvimento do núcleo do software.
Processos complementares devem ser incluídos desde a priorização estratégica da iniciativa até a instância de governança de tecnologia, proporcionando proativamente os fundamentos necessários.
Mas o que acontece com a qualidade nesses vários processos?
A qualidade do software pode ser avaliada nas várias etapas e processos envolvidos.
Vamos assumir que o “Por que” para o software faz sentido para a organização, fazendo a transição para “O quê” e o “Como”.
Uma arquitetura qualitativa começa com requisitos bem definidos
A partir de sua concepção, os atributos de qualidade do produto de software devem ser identificados, mencionando os requisitos funcionais e não funcionais.
Ser capaz de identificá-los com clareza já é um desafio de qualidade de comunicação, formalização e priorização.
Aqui estão alguns atributos funcionais que devem ser considerados da ISO / IEC FCD 25010: integridade, completude, adequação.
Podemos percorrer um longo caminho com o resto da lista: desempenho, eficiência, compatibilidade, usabilidade, confiabilidade, segurança, facilidade de manutenção, portabilidade.
Os atributos de qualidade do software são perdidos em traduções entre organizações isoladas.
Antoine Craske
Voltando ao nosso problema: como pode garantir que esses requisitos sejam identificados?
Pode ser um processo doloroso se o arquiteto de domínio precisar trabalhar em alguns deles, deixando o resto para ser classificado pelas outras funções.
Não é raro ver uma vaga afetação de outros requisitos entre um arquiteto técnico, um engenheiro de devops, um gerente de automação de qa e um gerente de engenharia que raramente se sincronizam.
Sem uma organização clara, os vários requisitos acabam perdidos nos vários silos.
Uma perspectiva transversal é necessária para construir um sistema com desempenho
É aqui que julgo que alguém responsável pela arquitetura de qualidade pode fazer a diferença.
Podem ser responsabilidades e funções afetadas a uma função existente dentro da organização, um líder de QA ou um líder técnico, por exemplo.
A perspectiva do sistema afeta seu desenvolvimento geral.
A perspectiva do sistema de qualidade de software afeta o seu desenvolvimento geral.
Antoine Craske
As formigas são um exemplo muito profundo da dinâmica de sistema. Elas trabalharão em sincronia para otimizar o sistema em que estão envolvidas.
No dia em que seu nicho começar a se expandir com um outro, qualquer que seja sua afectação inicial, sua coordenação se expandirá para a otimização geral do sistema.
Devemos aprender com esses outros sistemas de desempenho.
Organizações são sistemas que serão otimizados de acordo com a sua perspectiva
Voltando ao mundo dos negócios, é o que tende a acontecer nas organizações.
Um CEO local é uma organização descentralizada otimizará os seus resultados locais, com base em seus objetivos e incentivos.
Casos positivos podem trazer benefícios para a organização local e global, mas isso não é garantido.
Se o CEO local precisa melhorar seu cash-flow, ele pode simplesmente encomendar mais itens no depósito central, resultando em um fluxo de caixa geral ruim para a empresa com estoque excedente.
No dia em que essa subsidiária for incorporada a um grupo maior ou passar para uma gestão centralizada, a sua perspectiva de otimização será bem diferente.
A chave é que um sistema pode ser melhorado levando em consideração o seu perímetro global, interfaces, objetivos, atores e dinâmica.
Otimizações locais são perigosas em sua avaliação de qualidade local
Todos nós conhecemos armadilhas e antipadrões de otimizações locais que se aplicam à indústria de software.
A pré-otimização local é uma das principais razões para o desperdício na qualidade do software.
Antoine Craske
Uma equipa de QA pode, do seu ponto de vista, investir em uma campanha de teste automatizado com uma cobertura alta de 80%, mostrando os resultados para as demais equipas.
Enquanto isso, os desenvolvedores garantem que seus testes unitários estejam cobrindo todos os casos de uso, adicionando testes de integração para proteger o seu desenvolvimento.
No final, ambas as equipas provavelmente terão trabalho sobreposto em termos de cobertura e testes, resultando em maiores custos de atraso, implementação e manutenção.
A equipa poderia ter economizado 50% de seu tempo com uma abordagem conjunta.
O arquiteto da qualidade deve ser o guardião da qualidade global do sistema
Os arquitetos da qualidade do software devem agir como arquitetos em suas raízes, focando em uma perspectiva transversal da qualidade.
Garantir a adequação do produto aos objetivos da organização e às necessidades dos clientes é o primeiro passo.
A sua próxima tarefa é de garantir os vários atributos dos requisitos, sendo funcionais e não funcionais.
O arquiteto de qualidade de software deve possuir uma perspectiva transversal de qualidade.
Antoine Craske
O seu trabalho não é necessariamente o de se responsabilizar por cada uma das áreas, mas sim garantir a sua integralidade, sendo responsável em geral.
Projetar o sistema de ponta a ponta para uma qualidade de software estrutural é a sua próxima tarefa.
É ele que deve ter a perspectiva global de todos os interesses locais, levando em consideração as restrições gerais do sistema.
O arquiteto de qualidade deve ser um “doer” envolvido com a equipa
Como todo arquiteto, ele deve ficar longe das ivory tower, sendo participativo e colaborativo.
Mover-se dos requisitos para as operações do software requer um envolvimento real da equipa com a arquitetura definida.
É por isso que os arquitetos de qualidade devem interagir com o resto da equipa para transformar a arquitetura em realidade.
Ele pode, por exemplo, ajudar na estruturação da matriz de teste, estratégia de teste e plataforma de automação que deve ser usada durante a implementação.
Complementarmente, sendo transversal, ele pode trabalhar com as equipas de engenharia, controle de qualidade e de plataforma para definir uma arquitetura de CI/CD com desempenho.
Uma visão combinada leva mais facilmente a práticas transversais, como quality gates, monitorização, feature-flags.
Quando temos a visão transversal, pensamos mais globalmente no resultado e impacto final.
O arquiteto de qualidade deve estar continuamente presente
O software é um produto vivo que evolui ao longo do tempo.
Um ator apenas temporariamente envolvido em um sistema tenderá a otimizar os seus objetivos na duração da sua participação.
Como em muitos assuntos, alcançar um equilíbrio é fundamental.
Tirando o presidente do país, em alguns países eles ficam lá por cerca de 4 a 5 anos e podem ser reeleitos duas vezes.
Não é perfeito, mas favorece os atores a produzirem resultados em vários termos para serem apreciados hoje, reeleitos amanhã e garantindo o seu futuro depois.
Mesmo que o software não tenha umavida longa hoje, eles também não têm a vida curta.
É por isso que alguns atores-chave devem estar continuamente presentes no desenvolvimento do sistema de software.
O arquiteto de qualidade deve obter o ciclo de feedback do produto
Este é o caso do arquiteto de qualidade de software.
É necessário fechar o ciclo de feedback até a experiência do cliente.
Será que o produto está atendendo aos requisitos funcionais e não funcionais originais?
Como os vários atributos de software foram traduzidos e são satisfatórios?
O que deve ser alterado para melhorar a qualidade do produto de software e, ao mesmo tempo, reduzir a sua architectural debt no tempo?
Obter o ciclo de feedback é o que permitirá um desempenho estruturante e uma adaptação.
Nós, humanos, não somos bons para integrar feedback loop com atrasado (por exemplo, consulte toda a literatura sobre perda de peso).
Esclareça quem é o arquiteto de qualidade de software em sua organização
As responsabilidades da arquitetura de qualidade de software devem ser claramente atribuídas, como para o CEO, CFO e COO.
Existem peças comuns e reaproveitadas da arquitectura tradicional, mas a ligação dos pontos e uma perspectiva holística da qualidade fará a diferença.
Com a evolução, complexidade e distribuição da equipa, não ficarei surpreso em ver arquitetos de qualidade surgindo em breve.
Onde está o seu arquiteto da qualidade de software?
Antoine Craske
Até então, é necessário uma clareza de responsabilidade dentro da organização: Arquiteto de Domínio, Head of QA, Quality Lead, Tech Lead?
A escolha é toda sua, deve ser clara e para uma qualidade de software holística.
O que acha de arquitetos de qualidade se tornando uma função por si só?