Get best of the week

Agile nos ensina o verdadeiro significado da arquitetura

imagem

O que é arquitetura? Não cidades ou edifícios, mas uma versão organizacional: arquitetura corporativa, arquitetura de soluções, arquitetura de aplicativos, arquitetura de software, arquitetura comercial, arquitetura de infraestrutura? Os pelos da minha cabeça começam a se mover quando nós, arquitetos, passamos a esse tópico da nossa chata torre de marfim, criada para a reflexão, que diverte nosso orgulho. Mas desta vez eu tenho que abordar essa questão, porque é um pré-requisito para considerar o tópico dívida e arquitetura (arquitetônica, técnica); todos juntos se tornarão uma história de três artigos.

Ágil e o que ele diz sobre Arquitetura


A arquitetura é mencionada oficialmente no Manifesto Ágil , que afirma que um dos princípios fundamentais é: "As melhores arquiteturas, requisitos e decisões de design nascem em equipes auto-organizadas".
As melhores arquiteturas, requisitos e projetos emergem das equipes auto-organizadas.
(De: Princípios do Manifesto Ágil )

O problema não é apenas o fato de não dar uma definição do que é arquitetura, mas apenas de onde vem, mas também de ser um tanto ingênuo .

O Agile possui não apenas apoiadores sérios (e eu me considero um deles), mas também uma parcela justa de fanáticos que tendem a acreditar (e às vezes forçam sua liderança a acreditar) que "trabalhar no agile" oferece a você algum tipo de capacidade infinita de mudar e que você pode fazer todos os tipos de alterações , incluindo grandes conversões. Temos até estruturas bastante grandes, como a Scaled Agile Framework (SAFe), que pode ser aplicada a alterações baseadas em princípios flexíveis para os mais altos níveis estratégicos.

Tais estruturas têm algo em comum com as estruturas abrangentes criadas anteriormente (FEAF, MODAF, TOGAF, etc.). Ninguém realmente usa a coisa toda. O escopo das estruturas geralmente não é facilmente compreendido por todos aqueles que trabalham em seu contexto restrito. Parece-me que os fundamentos das práticas de trabalho atuais foram extrapolados para criar uma estrutura completa. Embora o “preenchedor” nunca tenha sido testado, no entanto, tudo é vendido inteiramente como “melhores práticas”.

Vejamos o TOGAF e o SAFe, eles são firmemente baseados no mundo do desenvolvimento de aplicativos. Isso é evidente quando o TOGAF baseia uma de suas duas definições de arquitetura na definição de arquitetura de software ISO.
– , , .
(: ISO/IEC/IEEE 42010:2011)

Ou, quando o SAFe nos diz que existem recursos e capacitadores, e um dos capacitadores é a "infraestrutura" (embora você possa, é claro, abstrair esse conceito). As estruturas geralmente são um pouco pesadas em definições e detalhes, elas tentam ser abrangentes. Portanto, eles freqüentemente crescem com o tempo para definir e abraçar cada vez mais. Porém, estruturas grandes geralmente são usadas apenas parcialmente, porque a estrutura completa na maioria das situações é um excesso burocrático. O que é visto frequentemente na “doença da definição”, o desejo de criar definições estritas para tudo, inclusive para coisas que ignoram essas definições na realidade ( Ludwig Wittgenstein ).

Embora grandes estruturas possam ser vistas com um olhar crítico, o próprio conceito Agile (embora não seja novo) é de fato uma resposta muito prática (pelo menos em parte) à complexidade e, acima de tudo, à variabilidade. Agile é a reação à maioria das mudanças e transformações nas organizações complexas de hoje. Complexidade porque a TI permitiu ser complexa . Variabilidade, porque em comparação com fábricas cheias de equipamentos pesados, é muito fácil mudar a TI. Ainda é software e até hardwarenão possui uma vida útil, por exemplo, como as paredes de um edifício. Hoje, organizações complexas produzem mudanças mais autônomas que as organizações "de papel" do passado. A cascata com Big Up-Front Design (BUFD) tornou-se tão impraticável que, no mundo de hoje, com uma carga de TI, tornou-se quase impossível. Assim, obtemos evolução paralela em massa permanente em nossas organizações com base em muitas equipes (ágeis) trabalhando em paralelo.
, - . - , , , . - — , — .
( , )



Como eu disse acima, discussões sobre "O que é arquitetura" geralmente são um desperdício de energia; é melhor gastá-lo no desenvolvimento de boas soluções de design para sua organização. Existem muitas definições de arquitetura, indiquei as mais usadas acima. Há outra definição no Mastering ArchiMate, e admito que gosto parcialmente: a

arquitetura corporativa é sobre a compreensão de todos os diferentes elementos que compõem uma empresa e como esses elementos são interconectados.

Este é do Institute For Enterprise Architecture Developments. Não é que eu não concorde com tudo o que eles escrevem, mas ainda assim esse "O" não diz "Como" por algum motivo. E "Compreensão" é uma palavra igualmente escorregadia. Então, tudo isso não ajuda muito. Existem muitas outras definições, do MIT, do governo dos EUA, etc. Uma delas da Fundação ArchiMate: “Um conjunto de princípios, métodos e modelos acordados que são usados ​​no design e implementação da estrutura organizacional de uma empresa, processos de negócios, sistemas de informação e infraestrutura. "

Mas a definição que se encaixa nos meus próprios sentimentos foi que Martin Fowler, em seu amplamente conhecido artigo de 2003, " Quem precisa de um arquiteto?"" Lá, ele termina de definir arquitetura como “coisas difíceis de mudar”. Isso não difere da definição de Grad Buch, que disse:

Toda arquitetura é decisões de design, mas nem todas as decisões de design são arquitetura. A arquitetura representa decisões importantes que formam um sistema em que a importância é medida pelo custo da mudança.

(Nota: uma citação mais completa tem um bom ponto sobre “ciência e arte”). Também acredito firmemente que a arquitetura nada mais é do que decisões de design, e que o desejo de realmente separá-las vem em parte do “[desejo] de falar sobre decisões de design, mas [de querer] inflá-las para que eles pareciam importantes ”(Fowler). Então, no nosso mundo da arquitetura, podemos dizer:Arquitetura é decisões de design difíceis de mudar . Obviamente, é realmente difícil alterá-los somente quando foram implementados. O jornal suportará tudo e as cartas mudarão facilmente (a menos que você esteja em uma discussão infernal infernal de 6 meses). Mas a arquitetura, como uma medida da importância das decisões de design, é uma boa definição e muito melhor do que na ISO, ArchiMate, TOGAF, etc.

No entanto, há uma sutileza com a característica "difícil de mudar".

Suponha que você tenha uma solução de design que descreva para seus desenvolvedores como eles devem estruturar seu código Python. Se você tiver muito código, será necessário muito trabalho para alterar todo esse código de uma estrutura para outra. Em outras palavras, é difícil. Portanto, essa solução escolhida é “arquitetura”, neste caso, arquitetura de software. Mas um desenvolvedor pode facilmente ignorar essa decisão e escrever um código que faça as coisas de maneira diferente. No final, é fácil fazer "alterações" no software. Embora seja difícil alterar toda a arquitetura implementada, geralmente é fácil alterar apenas partes individuais nela (veja Ralph Johnson acima). A arquitetura, portanto, é algo "pesado" que consiste em muitos "leves". Você vê isso em todos os níveis, por exemplo,se sua decisão de design for usar apenas bancos de dados Oracle e, de repente, os bancos de dados PostgreSQL separados parecerem bastante fáceis de configurar e, portanto, aparecerem facilmente (o que torna seu cenário mais complexo, isso geralmente não é aprovado). Mas substituatodo o Oracle no PostgreSQL no seu cenário é pesado (e isso pode até não ser totalmente viável). Portanto, a seguinte definição é formada:

Arquitetura - decisões de design difíceis de remover completamente das implementações.

(Embora a contração de Fowler seja "difícil de mudar" na maioria dos casos). Outra observação em relação às “difíceis de mudar”, pode ser difícil removê-las devido à dependência de outras pessoas, portanto o significado da palavra “implementação” é amplo, por exemplo, alterando fabricantes e consumidores do serviço. “Pesado” sempre deve ser considerado da perspectiva da sua organização, um bom exemplo de por que a área da arquitetura geralmente é mais ampla que a área de uma solução, projeto ou produto.
Nota: 1) Esta definição não depende de TI. 2) Pode-se argumentar que desta maneira eu revelei o significado da palavra "fundamental" na definição de "Arquitetura" de acordo com a ISO.

Ágil e Arquitetura, diferentes extremos da mesma escala


Acontece uma relação muito interessante entre o mundo do Agile e o mundo da arquitetura. Agile é projetado para fazer alterações como possíveis quanto possível, para fazer alterações fácil (ou pelo menos não é difícil ). E por outro lado: a arquitetura, como vimos, é onde as mudanças são difíceis . Em outras palavras, eles estão nos extremos opostos do espectro, são um balanço fundamental em sua organização.

Apoio o Agile e declaro que essa é a melhor maneira de fazer alterações em nossos complexos cenários de negócios carregados de TI. Mas isso significa que tudo o que achamos difícil de alcançar usando abordagens ágeis é a "arquitetura" de fato. Então, o Agile nos ensina o que é Arquitetura .

Nota: É importante observar que o Agile retira muito do Lean, que foi baseado na abordagem da Toyota às plantas físicas. A Toyota queria tornar a produção mais flexível para lidar com a complexidade. Mas há muitos aspectos dessa configuração que não são facilmente traduzidos para o mundo do software. Por exemplo, a Toyota apoiou uma variabilidade muito limitada e a maioria das coisas não pôde mudar. No software, tudo pode mudar, e não é verdade, por definição, que um método que (ligeiramente, mas com grande efeito) sub-otimize o processo de produção física possa ser a base para outro processo de produção.

Então, onde encontramos a arquitetura, onde o Agile entra em problemas? Existem vários exemplos óbvios:

  1. feature/defect «», , . ( , , ESB ), . , . , , ( ), .
  2. Agile , , YAGNI (You Ain’t Gonna Need It) (just in time). SAFe Architectural Runway, features defects. SAFe , . SAFe « Runway», features «». YAGNI ( , «»). – , – . , , Agile , « , DevOps» (DRDC). , , Tomcat, JBoss, Session state storage , File sharing, Redis, MongoDB, MQ, IIS .. Lean ( ) YAGNI, , , «» («muda» « » Lean). , , , , ( «muru» «»). , , Runway , , .
  3. Agile , . , , , . , , Agile ( «muri» «»). , . Agile ( : ...) – .

Peço desculpas por usar livremente os termos em japonês aqui. Portanto, o Agile se concentra no fato de que a Arquitetura é um objeto, não uma prática, e a mente diz que:

Arquitetura é toda decisão de projeto implementada que torna o Agile difícil.

A escolha do que você coloca no seu "Plano de expansão da pista" depende de quão difícil será fazer a transformação: essa é a escolha da arquitetura. E você não pode deixar para os proprietários de produtos sob pressão dos usuários. A escolha também deve ser feita com a participação das partes interessadas da arquitetura, para que haja freios e contrapesos em relação a "bunkers" e "a curto prazo". Mais sobre arquitetura (como prática) na segunda parte desta minissérie de artigos.

Definir a arquitetura como uma combinação de "coisas pesadas" não é tudo o que precisamos. Porque, além de ser "difícil", precisamos de algumas recomendações sobre o que buscar com a arquitetura. Costuma-se dizer que a idéia da arquitetura é fornecer flexibilidade criando soluções flexíveis. De fato, Fowler afirmou que a tarefa do arquiteto é remover a arquitetura. Mas é simples demais. A flexibilidade é geralmente cara, e esses “custos” (tempo e dinheiro) não podem aumentar indefinidamente (veja Johnson acima). Todo mundo quer que as soluções sejam completamente flexíveis, mas não é barato (e ninguém quer pagar as contas), não é rápido e nem sempre é possível. Às vezes a situação é simples: você precisa fazer escolhas difíceis de mudar, não podesuporta todas as opções (por exemplo, escolhendo uma plataforma, você não pode oferecer suporte a tudo). Obviamente, se a escolha não for muito cara, escolha soluções flexíveis ou adie a opção pelo maior tempo possível (como sugere o SAFe: não limite suas opções). Mas, na prática, muitas vezes é preciso fazer uma escolha. Uma escolha que será difícil de mudar é uma escolha arquitetônica. A arquitetura busca minimizar a inflexibilidade desnecessária, porque é ingênuo pensar que haverá um mundo onde todas as mudanças serão fáceis e não haverá nada difícil. Há coisas não menos importantes e, mais frequentemente, ainda mais importantes que a flexibilidade. Eu acho que existem três deles: Confiabilidade, Eficiência e Flexibilidade - Robustez, Eficiência, Flexibilidade (REF).

Saiba mais sobre REF, prática de arquitetura e dívida.na segunda parte, mas lembrei do vídeo “Why enterprise architecture”, que criamos há muitos anos, no momento em que tornamos a arquitetura a mais flexível do mundo no BUFD:


Escute seu médico e advogado


E, em conclusão, arquitetura (como objeto) é aquela que é "pesada", mas você também pode dizer que "arquitetura (como prática) é pesada". Eles estão intimamente relacionados, a arquitetura (como prática) é difícil, porque a complexidade de hoje dificulta as mudanças e a inconstância de hoje torna as mudanças poderosas. É por isso que você precisa pagar bons arquitetos de megabytes. Bem, talvez não , mas você definitivamente deve ouvir bons arquitetos e levar seus conselhos muito, muito a sério. Resta apenas uma pergunta simples: como reconhecer um bom arquiteto?

More articles:


All Articles