Architectural Design: Drivers & Arquitetura

Design: O Propósito

O propósito do design de um software representa o resultado de um conjunto de tomadas de decisão, dependentes de contexto e com saídas contendo impactos diretos tanto nos “requisitos/objetivos” quanto “constraints (negócio / técnicas)” de uma empresa. Estilos/padrões de arquitetura acompanham os drivers de arquitetura e evoluem com o passar dos anos, adaptando-se aos conjuntos de necessidades específicas relacionadas ao ambiente/meio aplicado, considerando suas limitações.

Drivers de arquitetura defendem um propósito exploratório, claramente alinhado aos objetivos de negócio da organização. A partir da análise do domínio e avaliação de novas tecnologias, acabamos consequentemente adotando maior agilidade nos feedbacks a partir dos processos de “life-cycle” durante a adoção de novas possibilidades, dando espaço ao aprofundamento nos quality attributes (escalabilidade, performance, failover, disponibilidade). Ao quebrarmos os elementos de arquitetura em fragmentos suficientemente detalhados, diluindo a complexidade apoiada em um propósito claro, facilmente acabaremos com “units-of-works” mais compreensíveis.

O processo de design precisa ser interpretado de acordo com o nível de complexidade pertencente ao domínio de negócio, considerando as circunstâncias onde a mitigação dos riscos se converterá na redução de incertezas, resultando em soluções menos imprecisas/variáveis. A documentação como parte do processo de arquitetura pode ser adotada como artefato de entrega, demonstrando a composição clara entre os os fundamentos conceituais e importância prática. Em maior ou menor grau, o propósito deve ser estabelecido de acordo com o nível de alinhamento entre as pré-etapas/direcionadores e o acordo de design permanente refletido na arquitetura de um projeto.

O processo estratégico de arquitetura/design de uma organização pode apontar em diversas direções, focando em distintas capacidades, desde o reuso e escalabilidade, passando por “continuous delivery” ou futuras extensões/adaptações de elementos existentes.

Evidentemente, a arquitetura existe para suportar a execução bem sucedida das capacidades de negócio, explorando o balanço entre as fontes envolvidas para atingir diferentes níveis de abstração em cada cenário. O propósito está vinculado aos “architectural drivers”, valendo-se dos fragmentos de design para estabelecer um canal de comunicação adequado, resultando em uma definição clara e propagação dos “propósitos/razões” a serem seguidos.

Design: Arquitetura de Software

O processo de design em arquitetura de software assemelha-se ao conceito de design de maneira geral, envolvendo decisões que atendam requisitos considerando as limitações (custos/riscos/trade-offs) de cada contexto. Como responsabilidade do arquiteto, estão tanto objetivos técnicos quanto não técnicos, configurando elementos para um bom design de arquitetura com implicações diretas no sucesso dos projetos.

Em geral, alterações imprevistas em atributos de qualidade do design de arquitetura podem refletir negativamente em outros atributos considerados na concepção. Ao empregarmos operações de rastreabilidade podemos prever impactos no ciclo de vida dos artefatos, entregando uma fundação sólida e consistente, evitando o comprometimento da estrutura.

“Toda a arquitetura refere-se a design, mas nem todo o design trata-se de arquitetura”. — Grady Booch

Hierarquicamente, o design de arquitetura precede o processo de “element interaction design”, por sua vez precedido pelo “element internals design”. De forma que, para que interações consigam ser estabelecidas, os próprios elementos dependentes para sua comunicação precisam estar previamente detalhados. Logicamente, o design entrega maior abstração se comparado a arquitetura. Decisões pertencentes a categorias “arquiteturais” impactam diretamente os “architectural drivers” influenciando a interação entre elementos, provocando efeitos nos “quality attributes” ao longo do sistema.

A considerar sua relevância ao negócio, além da gestão de complexidade e riscos existem realidades onde os elementos contrastam decisões de design, com sua composição estendendo-se entre diferentes categorias de drivers. As fases de um processo de definição arquitetural naturalmente envolvem features primárias e não primárias, caracterizadas a depender da sua relevância ao negócio.

Architectural Drivers

Drivers arquiteturais são considerações significantemente críticas para o sucesso de um sistema de software, dependentes de contexto e formalmente estabelecendo modelos para guiar o processo de design de arquitetura estendendo-se a todos os elementos pertencentes a sua composição.

Direcionadores de arquitetura promovem elementos de rastreabilidade com decisões sustentáveis ao menor custo, utilizados para justificar as “structural decisions” formatadas nas seguintes categorias: technical constraints, business constraints, quality attributes, functional requirements. Importante ressaltar a relevância da definição dos drivers adequados em estágios anteriores ao projeto, tornando tarefas relacionadas a mudanças estruturais mais complexas na medida em que um componente absorve avanços significativos em sua implementação.

Os “architectural drivers” apoiam-se nos business-drivers e ASRs (architecturally significant requirement) os quais influenciam as “early design decisions” a partir das capacidades do negócio e conhecimento do domínio de dados, facilitando os trade-offs e a identificação das forças a favor e contrárias ao artefato de design sendo confeccionado.

Embora em alguns casos seja negligenciado, designs de arquitetura possuem sua essencialidade representada através da necessidade de um rígido controle de life-cycle, introduzidas a partir da etapa de arquitetura da solução e acompanhando o processo até sua conclusão.

Atributos de Qualidade

Em grande parte, a maioria dos sistemas de software demonstram preocupação com a qualidade, indicando seu ranking de importância em entregar elementos mensuráveis e objetivos a partir do nível de satisfação do negócio. Atributos de qualidade podem ser subjetivos ao mesmo tempo em que tomadas de decisão críticas dependem de boas escolhas dos drivers relacionados à qualidade durante o processo de design.

Desta forma, existem técnicas bem conhecidas e largamente disseminadas: quality attribute workshop (QAW), mission thread workshop (MTW), the utility tree (TUT). Neste caso, tanto requisitos funcionais quanto não funcionais precisam estar vinculados aos atributos de qualidade de forma a dar visibilidade em relação a complexidade de implementação e trade-offs.

Para endereçarmos problemas atribuídos à subjetividade da qualidade presente nas funcionalidades de um sistema, a priorização dos “quality attributes” pode ser adquirida através da análise de um conjunto de cenários como mecanismo básico. Na prática, atributos de qualidade endereçam os cenários priorizados dos artefatos afetados, configurados de forma a responder aos estímulos a comportamentos em sistemas.

Independente da técnica adotada, nunca devemos iniciar um processo de descoberta dos “architectural drivers” ou design sem uma lista previamente priorizada referente aos “quality attributes”, exigindo na sequência um refinamento.

De acordo com o ranking de importância em relação aos cenários considerados, os atributos de qualidade podem ser distintos em duas dimensões: importância do cenário em relação ao sistema em geral e o grau de risco técnico associado ao cenário (mensurado pelo arquiteto) em avaliação. Mecanismos de avaliação, aos moldes da adoção da L/M/H (low/medium/high), podem ser empregados em ambas as dimensões, sendo classificados como decisórios durante a priorização dos cenários.

Requisitos Funcionais: Alto Nível

Conceitualmente, uma funcionalidade pode ser definida como a habilidade em executar os atributos, expressados em detalhes técnicos e de negócio, exatamente como pretendido em estágios iniciais. Opondo-se aos “quality attributes”, ao considerarmos somente funcionalidades observadas externamente corremos o risco de tornarem-se difíceis e custosas, apresentando diferença expressiva a partir da necessidade de modificações.

Boas arquiteturas são expressadas com o mínimo de elementos possível, facilitando sua composição e relacionamentos. Ao desenharmos uma arquitetura, alinhando capacidades de negócio e desafios técnicos, em geral as funcionalidades primárias/fundamentais representam a minoria porém com maior peso em relevância, como sendo as mais críticas para o funcionamento pleno do software.

Em termos de design arquitetural, será necessário pensar como uma funcionalidade pode ser distribuída entre os elementos/módulos, promovendo reusabilidade e conexão na medida em que encontram-se primariamente associados aos “quality attributes”. Mesmo não associadas a todos os atributos de qualidade, certas tomadas de decisão sobre funcionamento precisam navegar entre cenários conflitantes, necessitando de decisões explícitas/assertivas. Assim, a alocação das funcionalidades quando designadas incorretamente produzem débitos técnicos, revelando fragilidades pela ineficiência na abordagem selecionada para este “architectural driver”, resultando em impactos no projeto e média de progresso comprometida.

Independente dos motivos, procedimentos de “refactor” em softwares não passam de manutenções não programadas dos “quality attribute response”, procurando ressincronizar os “quality attributes” em relação às funcionalidades sem alterá-la.

Preocupações Arquiteturais: Gerais e Específicas

Em grande maioria, as decisões envolvendo os “architectural concerns” podem parecer óbvias para cenários onde não será necessário atender a requisitos particularmente específicos. As preocupações estão pulverizadas em todo o espectro, variando entre preocupações gerais e detalhes internos, demonstrando a relevância dos “architectural concerns” como insumo explícito durante o processo de design de arquitetura.

Preocupações referentes à arquitetura geralmente contemplam aspectos adicionais não expressados em um formato tradicional de requisitos, norteando decisões envolvendo limitações impostas pelas restrições específicas durante o percurso do projeto resultantes de arquiteturas de referência previamente selecionadas, exclusivas ao sistema ou derivadas do negócio.

Preocupações geralmente resultam na inclusão de novos “quality attributes” com cenários devendo ser priorizados, discriminando aspectos derivados entre “architectural concerns” e cliente.

Adicionalmente, não explícito na maior parte das vezes e podendo resultar de atividades “design review” ou “assessments”, tanto os requisitos internos quanto os “Issues” coexistem entre questões internas/técnicas ao sistema (exception management, dependency management, configuration, logging, authentication, authorization, caching) e gerais (funcionalidade por módulos, módulos por times, entrega e deployment).

Existem questões mais amplas pertencentes ao processo de definição de arquitetura (“General concerns”), podendo ser revelados postumamente, não participando do processo de design. Nesse caso, adicionados sua adição posterior poderá produzir uma visão geral/estrutural de um sistema impactando diretamente o ciclo de vida do desenvolvimento.

Constraints: Técnicas e Negócio

Absolutamente, existem tanto decisões técnicas quanto elementos impostos pelo negócio a serem contemplados no design. As restrições precisam ser identificadas e exploradas conforme o progresso do projeto, demonstrando significativa influência no artefato final de arquitetura produzido.

Como parte do processo de design arquitetural, as limitações precisam ser catalogadas/identificadas, desempenhando papel fundamental no contexto dos “architectural drivers” em ponderar pontos chave em relação à arquitetura. Como exemplo: a definição de tecnologias, interoperação entre sistemas, padrões elegíveis de comunicação, camadas de abstração, “deadlines” não negociáveis, retro compatibilidades entre versões, adoção de tecnologias “open-source” e assim por diante.

Constraints não devem ser alteradas e referem-se a decisões sob elementos os quais o arquiteto geralmente tem pouco ou nenhum controle, devendo formatar o melhor design a partir das limitações impostas.

Ao contrário das restrições técnicas, de difícil reversão, restrições de negócio (timing, budget, team) estão sujeitas a contra argumentos, podendo ser considerados passíveis de mudança e em alguns casos impactando diretamente o ambiente de trabalho a partir da experiência/limitações do time.

Considerações Finais

Na ausência de uma solução única, o processo de design poderá ser dividido em fases incluindo debates entre stakeholders e times, agregando elementos essenciais e mantendo o processo de arquitetura saudável em todo o ciclo. Decisões devem basear-se em diversas perspectivas, balanceando os drivers e desafios tanto de domínio técnico quanto negócio, em todos os casos adotando abordagens particulares que influenciam positivamente o design final do produto.

Mesmo sob a presença do “the hidden architectural driver”, precisamos avaliar cuidadosamente o impacto das nossas decisões relacionadas ao design de arquitetura, tratando-se de um procedimento vital para um projeto bem sucedido. Não existem arquiteturas ruins, existem trade-offs e contextos onde a construção do design baseia-se nos “architectural drivers”, moldando e influenciando a jornada em direção ao sucesso.