UMA Modesta Arquitetura

Modesta: moderada, sem afetação, sem exagero.

Arquitetura¹: concebida com o propósito primordial de organizar espaço para determinada finalidade e visando a determinada intenção.

Este artigo é uma modesta provocação. E uma tentativa de transcrever a palestra “Arquitetura do Negócio: Enxuta & Ágil” que apresentei no último Agile Vale. É que alguns assuntos pedem para ser espalhados. Se você se interessa por arquitetura corporativa, arquitetura de negócios, arquitetura de software, DDD, DSL, métodos ágeis e pensamento enxuto (lean), talvez encontre algo de útil no meio deste longo texto.

∞

Peço sua atenção para a definição de arquitetura acima. Particularmente para os termos espaço, finalidade e intenção. Quando arquitetamos algo, nós “organizamos um espaço para determinada finalidade visando a determinada intenção”. Preciso voltar também para um conceito que já apresentei aqui no {finito}, a Tríade Vitruviana. Ela fixa três critérios fundamentais para avaliação de uma arquitetura:

• Firmitas: a construção é estável, robusta e sustentável;
• Utilitas: a arquitetura é funcional; e
• Venustas: é bela.

A área de TI gosta de adotar termos de outras áreas de conhecimento. Seria legal se, além dos nomes, adotássemos também os conceitos básicos. Já tem um tempinho que acolhemos o termo “arquitetura”. Recentemente, passamos a falar bastante sobre Arquitetura Corporativa. Acho que indicamos que através dela “organizamos espaço para determinada finalidade e visando a determinada intenção”. Qual espaço?

TI organiza dois espaços, a saber: i) Arquitetura Tecnológica – hardware, infraestrutura de rede e software básico. Significa o que a organização possui; ii) Arquitetura de Informações – bases de dados e repositórios de informações não estruturadas. Indica o que a organização sabe. Esses espaços são organizados “para determinada finalidade”. Qual finalidade?

TI atende a ou oferece um sem número de finalidades, de funcionalidades. O faz através de sua Arquitetura de Sistemas, que representa todas as aplicações, ou seja, o que a organização faz. E faz esse tanto de coisa porque está “visando a determinada intenção”. Que intenção?

Chegamos naquela parte da tal Arquitetura Corporativa que justifica tudo, inclusive a própria existência de TI. É a Arquitetura do Negócio, aquela que explica a intenção – para quem e porque a organização faz (oferece sistemas), sabe (informações) e possui (aquele tanto de ferro e software básico). No longínquo mundo ideal, não deveria haver um único centavo gasto em qualquer das três camadas inferiores que não fosse rastreável até a arquitetura do negócio, comprovando um benefício real e mensurável. Sendo assim, é factível supor que tudo começa (e deveria terminar) aqui, na Arquitetura do Negócio. Do que ela consiste?

Todo e qualquer negócio, independente do porte ou ramo de atividade, é formado por quatro elementos básicos: Objetivos, Recursos, Processos e Regras. Mas estamos falando de Arquitetura do Negócio, o que nos leva novamente para a preocupação de “organizar espaço para determinada finalidade visando a determinada intenção”. O espaço que organizamos é a estrutura da empresa – as pessoas, instalações, móveis, veículos, enfim, todos os seus recursos². A finalidade é representada por todo o seu conjunto de processos, por toda a sua parte dinâmica. Finalmente, a intenção é o grupo de objetivos da organização. Colocando de outra maneira: organizamos os recursos (espaço) de uma empresa de forma que os permita executar ou viabilizar a execução de processos (finalidade) visando a alcançar determinados objetivos (intenção).

Ao representar a arquitetura de um negócio, mesmo sem querer, sempre utilizamos três visões ou combinações entre elas. A visão do negócio trata dos objetivos, da intenção. A visão da estrutura nos mostra os recursos, o espaço. E a visão dos processos nos dá a finalidade. As representações podem ser ultrasofisticadas ou de uma simplicidade risível. Não é minha intenção debatê-las aqui, agora. Mas, para fins ilustrativos, entenda que um organograma é parte da visão da estrutura, enquanto um fluxograma pode compor a visão dos processos. Balanced Scorecards ou simples listas de objetivos representam a visão do negócio. O que nos interessa neste ponto é a “organização do espaço para determinada finalidade visando a determinada intenção”. Hora de agitar o coreto.

Muito falamos sobre a dinâmica, a velocidade das mudanças, e a complexidade do atual mundo dos negócios. O que muda tanto? E o que é complexo? Será que tudo?

Jurgen Appelo, no livro “Management 3.0” e falando sobre a teoria da complexidade, sugere um modelo para estudos: o modelo da Estrutura-Comportamento³. Ele escreveu que nos equivocamos quando intercambiamos os termos “complexo” e “complicado”. E afirma que o que é complexo não é passível de simplificação. Me esforçarei para deixar o papo menos maluco (e menos abstrato).

Quando tratamos de uma estrutura, o que está em jogo é nossa habilidade para entendê-la. Portanto, uma estrutura pode ser simples ou complicada. Neste sentido um casamento, por exemplo, é uma estrutura simples. Ele envolve, na teoria e em seu início, apenas dois elementos. Por outro lado, uma empresa ou uma cidade possuem uma estrutura complicada – difícil de entender.

Em outra dimensão está o comportamento e o que é exigida é nossa capacidade de prevê-lo. Um relógio, por complicado que seja (em sua estrutura), tem comportamento bastante previsível. Dizemos que seu comportamento é ordenado. Diferente do casamento, que apesar da estrutura simples, pode resultar em comportamentos bastante complexos. Nesta dimensão temos ainda uma terceira “ordem de grandeza”, o caos. O trânsito de nossas grandes cidades, por exemplo, tem comportamento caótico – ele é praticamente imprevisível. E, só para fechar o exemplo, a estrutura destinada para esse mesmo trânsito não tem nada de simples. Ela é complicada. Uma estrutura é passível de simplificação. Já o comportamento, com certa dose de boa-fé, poderia ser linearizado (o que é complexo ou caótico poderia ser ordenado).

Coreto devidamente agitado? E o que esse papo sobre complexidade tem a ver com arquitetura? Tudo!

A “estrutura” do papo acima é o espaço que organizamos. Voltando para a arquitetura do negócio, trata-se exatamente da visão da estrutura, de todos os recursos utilizados por uma organização. E a dimensão do comportamento representa a finalidade da arquitetura, as ações que ali devem ocorrer. No domínio (!) do negócio, refere-se à visão dos processos.

Um negócio, qualquer negócio, é um Sistema Adaptativo Complexo. O modelo proposto por Appelo nos ajuda a estudá-lo. Sistemas de informação são igualmente adaptativos e complexos. O modelo “Estrutura – Comportamento” nos ajudaria a arquitetá-los? No mínimo, como tentarei mostrar abaixo, justificaria uma “nova” maneira de pensar.

Quando falamos, geralmente reclamando, sobre a dinâmica dos negócios, devemos entender que o grande volume de mudanças ocorre na dimensão comportamental, ou seja, nos processos. Posso apelar para Pareto? Então vamos fixar que 80% das “mudanças organizacionais” (sic) referem-se às alterações na forma de trabalhar, nos processos de negócios. O restante significa, de fato, alteração na estrutura (demissões, remanejamentos, fusões & aquisições etc).

Acima eu escrevi que também vivemos reclamando da complexidade dos negócios. Novamente o modelo proposto pelo Appelo nos ajuda a separar o joio (estrutura, no máximo complicada) do trigo (processos, de fato complexos ou até mesmo caóticos). Fiquei com vontade de usar outra metáfora.

Ao desenhar sua casa, você separou generoso espaço (!) para montar seu sonhado home office (finalidade!). Mobiliou-o com tudo de bom e do melhor e ficou realmente mais produtivo (intenção!) naquela zona (no bom sentido) de conforto (no melhor sentido possível). Mas eis que vem a notícia de um filhinho não planejado e lá se vai o querido escritório de volta para a garagem. Aquele generoso espaço ganhará nova finalidade. Ele mudou? A menos que você tenha derrubado paredes e redimensionado outros cômodos, você não mexeu no espaço – na estrutura da casa. Foi só a finalidade daquele espaço que mudou.

Uma estrutura, mesmo quando mal e porcamente concebida, é mais estável que o comportamento. Ou, colocando de outra forma, a estrutura é menos instável que os processos. Então, por que será que nossos sistemas de informação raramente refletem essa separação? Até que ponto nossa indisciplinada mistura de forma (espaço) e funcionalidade (finalidade) é responsável pelos altíssimos custos de manutenção e pela dificuldade de adaptação dos sistemas ditos “legados”? Prometo parar por aqui com as questões retóricas. O que vem a seguir é uma proposta para pensar arquitetura de sistemas de uma maneira diferente.

Arquitetura Enxuta & Ágil

Se não ficou claro, apesar (ou exatamente por causa) de minha verborragia, nosso objetivo é fazer com que um sistema reflita e respeite a separação entre estrutura e comportamento. Vamos diferenciar o que o sistema é do que o sistema faz.

Já tem um tempinho que utilizamos classes para representar coisas do mundo real. Apesar de chamarmos isso de “Orientação a Objetos”, o fato é que nossa programação é mesmo orientada a classes. Não importa. Aprendemos nas escolas da vida que um objeto deveria encapsular sua estrutura (atributos) e comportamento (métodos). Temos outro probleminha aqui. Se desejamos representar elementos da estrutura do negócio, então deveríamos esquecer todo esse papo de encapsular comportamento. Essas classes e respectivos objetos que definem o que o sistema é devem ser ignorantes em relação a tudo o que se refira a ação. Quando muito, sabem um CRUDzinho básico. O cliente Mané, por exemplo, não sabe o que é comprar livro ou colocar livro no carrinho de compras. O Mané não sabe nada! Mas pode aprender!!

Todas as ações, serviços ou funcionalidades, compõem o que o sistema faz. No diagrama ao lado, todas essas interAÇÕES são representadas por papéis (roles). Existem dois tipos: aqueles que sabem o que fazer (methodful roles) e aqueles que só fingem que sabem (methodless roles). A distinção entre os papéis que sabem (methodful) daqueles que fingem saber (methodless) é muito importante. Os últimos funcionam apenas como interfaces. E nós esperamos que as interfaces sofram bem menos alterações do que os métodos propriamente ditos. Novamente a intenção é separar nitidamente aquilo que muda com mais frequência daquilo que pouco se altera no decorrer do tempo. Mas, afinal de contas, do que tratam esses papéis? Simples, são eles que sabem comprar livro ou colocar livro no carrinho de compras, por exemplo.

Pronto! Agora temos atores (classes e objetos dispostos no lado esquerdo do diagrama) e papéis. Falta dar-lhes um roteiro.

Peraí Paulo: ou seu exemplo não é lá essas coisas ou então o papo é bem furado mesmo. Afinal, comprar livro ou colocar livro no carrinho de compras não são ações extremamente simples?

Ações ordenadas ou bastante previsíveis, você quis dizer, certo? Vamos lá: imagine que nosso querido Mané, apresentado ali em cima, seja um cliente preferencial. Como tal, ele tem direito a descontos em todas as compras. Quando ele vê um livro, já sabe seu preço normal e o desconto que merecerá. Ao mesmo tempo, a loja já sabe que o Mané prefere pagar com cartão de crédito. O que significa, além de outras coisas, um prazo menor de entrega. Já o cliente (objeto) José é bem diferente: mal se identificou (a loja ainda não sabe nada sobre suas preferências) e está prestes a fazer sua primeira compra. Os ROTEIROS que Mané e José seguirão são consideravelmente diferentes. Apesar de ambos apenas desejarem comprar o último best-seller da Bruna Surfistinha.

Ok, o exemplo continua meia-boca. Mas espero que você tenha entendido o fundamental: interAÇÕES bem distintas acontecerão em ambos os casos. Os atores José e Mané desempenharão papéis diferentes.

Primeiro ponto, aquele que ficou aberto seis parágrafos acima: como Mané e José “aprenderão” a comprar livro ou colocar livro no carrinho de compras? Primeira “mágica”: aquele conhecimento (comprar ou colocar) será INJETADO nos dois clientes (objetos). O termo injetado é muito bom. Lembra-se como Neo, no filme Matrix, aprendeu a lutar kung-fu? Pois é, o conhecimento foi injetado na nuca! É mais ou menos o que estamos fazendo aqui, ensinando (em tempo de execução!) um elemento da estrutura a executar determinada ação.

Não disponho de tempo, espaço e nem competência para entrar em detalhes técnicos desta sugestão. Só me cabe dizer, por enquanto, que tal “mágica” é possível tanto em linguagens OO mais antigas (como C++) quanto em modernosos dialetos mais dinâmicos (como Ruby). Já já te falo onde encontrar exemplos de código, se isso te interessa.

De interesse mais geral deve ser nosso segundo ponto, gritado quatro parágrafos acima: o ROTEIRO. Agora ele merecerá outro nome, um pouquinho mais técnico: Caso de Uso. Estranho como algumas pessoas perdem o sentido da palavra “caso”. Gosto de provocá-las usando um termo caipirão, “causo”. Um “causo” é uma história curta, enxuta. Para nós, é uma história de interAÇÕES, sobre o USO de alguma coisa, sobre FUNÇÕES executadas. Portanto, nosso roteiro (ou script) é redigido na forma de uma especificação de caso de uso. E, em tempo de execução, este mesmo roteiro se transforma em um objeto. Objeto que tem um nome bem especial: CONTEXTO. Mané e José, nossos honoráveis clientes (objetos), desempenharão alguns papéis diferentes e outros semelhantes dependendo do Contexto.

Tempo para uma breve releitura. Você ainda está aqui? Puxa, muito obrigado. Vamos lá:

Mané e José mudarão muito pouco no decorrer do tempo. Alguns de seus atributos, como endereço ou telefone, podem ser alterados. Sua idade, com certeza, mudará a cada ano. Mas isso não significará nenhum tipo de mudança em sua forma. Já os papéis, as interações ou processos de negócios, podem sofrer mudanças com grande frequência. A porção mais volúvel de um negócio, suas regras, estariam praticamente todas concentradas nos papéis com real conhecimento (methodful roles). Assim, ao contrário do que vemos em grande parte dos sistemas de hoje (ou seria de ontem?), as mudanças ficam concentradas em um só lugar. Elas não gerarão impactos em um sem número de classes e outros elementos. Neste desenho, podemos agregar novas funcionalidades sem gerar praticamente nenhum impacto nos elementos já constituídos. Um novo cenário em um caso de uso é só isso, um novo roteiro – que costura e direciona como os atores desempenharão seus papéis em um novo contexto.

Hora de dar nome e crédito à proposta apresentada acima. DCI, de Data, Context and Interaction, é o nome da criança. Criança mesmo, que mal tem cinco anos de vida. A primeira parte, Data (Dados), representa a estrutura (o espaço). Já as Interações representam as finalidades, a arquitetura funcional. E o Contexto, por fim, junta tudo. Este paradigma foi sugerido por Trygve Reenskaug, sujeito que tem em seu currículo outro padrão arquitetônico, amplamente conhecido e aceito: o MVC (Model-View-Controller). Já havia apresentado o tema aqui, quando comentei o livro “Lean Architecture“, de James Coplien e Gertrud Bjørnvig. Para você que quer ver e experimentar um pouco de código, creio que este livro seja o melhor ponto de partida.

UMA Arquitetura

Muito provavelmente é pura burrice de minha parte, mas quando vejo (de soslaio) altos papos sobre DDD (Domain-Driven Design), DSL’s (Domain-Specific Language) e afins, enxergo pouco ou nenhum NEGÓCIO. Eu sei, os conceitos são amplos demais e não pretendem apenas tratar de sistemas para negócios. Mas eu desconfio que um pouquinho de proximidade não faria mal nenhum, muito pelo contrário. Por isso o DCI, particularmente da forma como foi trabalhado por Coplien e Bjørnvig, me chamou tanto a atenção. Percebi ali uma nítida preocupação com o domínio, a complexidade e a dinâmica dos negócios. Mais que isso, vi naquela proposta uma extensão lógica e natural – o que tentei demonstrar aqui. Arquitetura do negócio e de sistemas podem ser vistas como UMA única arquitetura. É certo que estou sendo tendencioso e otimista demais. Se DCI demorar tanto quanto o MVC para “pegar”, com certeza não estarei por aqui para ver o resultado. O MVC é de 1978!

Mas eu sou um incurável otimista. Ao testemunhar como ideias “agile” e “lean” se espalham, fico na esperança de ver mais conversas práticas e pragmáticas ganharem espaço nas agendas de todos os envolvidos com sistemas de informação. Preciso achar espaço para registrar uma preocupação. Será aqui mesmo: não basta ser “ágil” pra caramba e entregar na metade do tempo aquele maravilhoso produto, realizando um pseudo e imediatista valor. Teu ROI (sic), prezada(o) leitora, derretará mais rápido que bolsa de valores em tempos de crise se:

1. Teu rebento, aquele produto, exigir mudanças estruturais toda vez que o negócio evoluir;
2. O tempo tornar seu produto ilegível e incompreensível para os olhos de outrem;
3. Seu produto pedir por duas ou três iterações toda vez que um novo cenário ou papel for necessário.

É curioso e divertido acompanhar como a combinação dos termos “agile” e “lean” tem evoluído. Enquanto algumas dicotomias caem por terra, surgem novos confrontos e contradições. Coplien e Bjørnvig não hesitaram ao colocar várias lenhas nesta estimulante fogueira. Por exemplo:

• Pensar antes não significa FAZER antes. E se você é realmente “lean”, você PENSA antes de fazer;
• Pensar arquitetura != BDUF (Big Design Up Front).
• Esse papo de postergar uma decisão para o último momento (responsável) é perigoso. Porque é difícil descobrir que momento é esse. Mais lógico é decidir na hora em que a decisão é realmente necessária e pronto.
• Lean é baseado em “uma cultura de parar ou desacelerar de forma a obter qualidade no primeiro momento e maior produtividade no longo prazo.” (Jeffrey Liker, em “The Toyota Way” – McGraw-Hill, 2004);
• Pensar “lean” é ver o todo – daí minha preocupação que acabou tornando este artigo um recorde pessoal (2.730 palavras até aqui!). Tentei mostrar como Arquitetura do Negócio e Arquitetura de Sistemas compartilham fundamentos (Espaço, Finalidade) e, principalmente, Intenção;
• Pensar “lean” é ser sustentável – é ter sincera preocupação com o amanhã, com a evolução de um sistema que responde sem ressalvas nem soluços à dinâmica do negócio;
  
• E ser “ágil”, nos ensina o Manifesto, é “responder a mudanças” (além de outras coisas, claro);
  
• “TDD (Test-Driven Development) pode deteriorar a arquitetura”; e
• Como sou um chato incorrigível, vou citar até uma lenha aparentemente menor: o que é mais fácil administrar e entregar, 300 e tantas histórias (User Stories) ou 20 e tantos casos de uso?

∞

Céus, quase três mil palavras e você ainda está aqui? Espero que de fato aproveite alguma coisa no meio de tanta prosa. Sabe o que é pior? A sensação de mal ter explorado todas as possibilidades do tema. Pior ainda? Aceitar o fato de que minha contribuição não irá muito além disso aqui. Não vou codificar exemplos e é pouco provável que eu participe, mesmo que como observador, do desenho de uma arquitetura conforme sugerida por Reenskaug, Coplien e Bjørnvig. Resta te pedir que me avise sempre que perceber qualquer coisa parecida passando por perto, ok? Tks!

Observações:

1. Trecho da definição de arquitetura proposta por Lúcio Costa e surrupiada da Wikipédia.
2. Não é lá muito “ágil” esse negócio de chamar pessoas de recursos. É feio, eu admito. Mas, por favor, entenda que no frio da teoria uma pessoa pode ser sim um RECURSO utilizado por uma empresa para determinada finalidade e visando a determinada intenção. O que deveria de fato importar é que a empresa não trate uma pessoa da mesma maneira como trata uma mesa ou um carro enguiçado. Mas tem gente que gosta de briga e não será um recurso nunca! Nem no melhor sentido da palavra.
3. Por uma questão de brevidade (haha!) me limitei a citar o modelo Estrutura-Comportamento proposto por Jurgen Appelo. Saiba que ele compara sua sugestão com dois modelos um pouco mais conhecidos, o Cynefin proposto por David Snowden e o modelo da Concordância & Certeza (Agreement & Certainty) proposto por Ralph Stacey. Jurgen insiste para que recebamos todas essas propostas sempre com um pé atrás: “todas estão erradas… mas algumas são úteis”.
4. “Spil-skitse-tegning” é o cartoon que aparece lá no longínquo topo do artigo. Pra variar, é do HikingArtist.
5. Ah sim, caso interesse, está aqui a apresentação utilizada no Agile Vale 2011. Como alertei a amiga Simone, ela deve ser ininteligível se não acompanhada da prosocopeia acima.