Design orientado a dimensões — Uma proposta de ordem em meio ao caos! [PARTE 3 — Fundamentos]

Vou iniciar este capítulo sendo um pouquinho polêmico: a esmagadora maioria de nós arquitetos, desenvolvedores e gerentes de tecnologia, realiza escolhas técnicas de forma completamente empírica, nós testamos um determinado design/arquitetura, muitas das vezes guiados por hype ou experiências passadas, utilizando uma prova de conceito que, em grande parte das vezes não reflete nada do cenário real, e por afinidade, e/ou pressão de prazos, inferimos que aquele é o modelo a ser adotado ao cenário. Mas qual o problema em fazer dessa forma? Eu diria que para a maioria dos casos, nenhum. Ao menos, não a curto prazo. Diria inclusive, que isso funciona razoavelmente bem em cenários onde o projeto não atinge sua maturidade completa.

Mas, eu gostaria de trazer uma breve reflexão: imagine que você e a pessoa mais importante da sua vida estão em uma viagem. No decorrer da viagem, ela passa por uma ponte que está sob um gigantesco penhasco (uma queda ali significa morte certa), sabendo que essa ponte foi construída, de forma que os materiais e métodos empregados ali, foram escolhidos com os mesmos padrões e critérios empíricos que você usa para realizar a definição de design ou de arquitetura do ecossistema de sua companhia. Dito isso, você passaria pela ponte? Ou voltaria e procuraria outro caminho? Quando paramos para observar e refletir, percebemos que quando nos aprofundamos no campo da arquitetura dos sistemas, passamos a conviver bastante os famosos “ility’s” (scalability, observability, confiability, disponibility, entre tantos outros), e essas grandezas, direcionam literalmente todas as nossas ações em termos de dimensionamento de infra, cenários de catástrofe, investigação de erros, entre outros.

É de certa forma engraçado pensar que com tantas métricas, ainda assim, quando vamos definir a arquitetura de uma api, ou do ecossistema de serviços que nossas organizações possuem, acabamos sempre optando pela qual temos maior afinidade, seja por termos experiência, seja por impulso de alguma “hype”, seja por casos de sucesso de alguma bigtech. Olhamos de forma quase espiritual, para algo que deveria ser puramente analítico, afinal de contas, um problema de negócio pode ser percebido semelhante a uma equação diferencial, em que dadas suas condições iniciais, nós arquitetos, temos o trabalho de encontrar uma solução particular que melhor atende o modelo de negócios a ser criado. Ou estou muito errado?

Não estou dizendo que a forma como fazemos as coisas está errado ou que não funciona, muito pelo contrário, funciona tão bem que hoje temos uma infinidade de formas de projetar um tipo qualquer de solução, são tantas que inúmeras vezes nos sentimos perdidos em meio ao extenso cardápio. O design orientado a dimensões visa obter um modelo evolutivo, em que dado um conjunto de condições de contorno, nos forneça uma visão detalhada de que, caso exista uma variação das condições de contorno, qual a melhor arquitetura para um serviço (ou ecossistema), em período qualquer do ciclo de vida do modelo de negócios de um produto. Até aqui entendemos alguns dos fundamentos pelos quais nosso trabalho é guiado. Deste ponto em diante, vamos nos aprofundar nos princípios que regem nossa proposta, e em como determinamos os nossos maiores aliados: os valores de contorno do modelo.

Princípio da localização:

Veja bem, um dos conceitos fundamentais com o qual nos deparamos, é o de localização, ou melhor dizendo, o conceito de endereço, desde sempre exploramos e abordamos questões sobre o devido lugar das coisas e das não coisas. Agrupamos, organizamos, classificamos, e modelamos tudo em função do endereço de algo, seja este endereço a origem ou o destino desse algo. Já discutimos os conceitos fundamentais dos quais o modelo orientado a dimensões é baseado. Dito isto, entendemos que todo e qualquer modelo de negócio pode ser descrito como um espaço n-dimensional, e que está contido em um universo, e este por sua vez, representa o conceito de uma organização qualquer. Temos ainda, que dentro de cada espaço, é possível observar a existência de estruturas, e estas, representam para nós, cada um dos sistemas e/ou grupamento de sistemas, que sustenta a organização. O princípio da localização trata exatamente do processo de modelagem dessas estruturas, em função das dimensões que as compreendem, para chegar a um modelo de fácil compreensão do endereço de cada estrutura dentro de um espaço, e respectivamente, dentro do universo ao qual pertence.

Você se lembra de uma disciplina chamada geometria analítica? Não? Alguns de vocês vão se lembrar vagamente, mas, a maioria dos que se lembrarem, não lembrarão com muita felicidade em seus corações. E de uma outra disciplina chamada álgebra linear? Também não? Ambas as disciplinas eram conhecidas por serem bem “dolorosas” em nossas graduações (mesmo eu odiava a primeira, já na segunda — algebra linear — tive uma ótima professora e só aí, fui começar a me interessar pela área). Nas duas disciplinas, você terá conceitos que tratam de um assunto muito comum, o endereço (coordenadas) das coisas e não as coisas. Em ambas você terá que entender a posição de algo num determinado espaço, seja esse algo, um vetor, um ponto, ou um corpo.

Recordo-me de ler em algum livro que certa vez Johannes Kepler disse:

“A Geometria existe por toda a parte. É preciso, porém, olhos para vê-la, inteligência para compreendê-la e alma para admirá-la”.

Profundo não é mesmo? Vou recapitular com vocês alguns conceitos importantes (eu juro que são muito importantes para o entendimento do todo).

Vamos utilizar o conceito de ponto para identificar uma estrutura ou sistema, que por sua vez possui coordenadas as quais sempre vão indicar a posição da nossa estrutura no espaço do modelo de negócios.

Quando essa estrutura sofre uma alteração, ela sai da posição P e vai para a posição P”, esse deslocamento possui um módulo, uma direção e um sentido. Ou seja, o deslocamento PP” pode ser representado por um vetor.

Quando o espaço sofre uma deformação por uma mudança nas regras de negócio da companhia, isso faz com que tenhamos uma mudança na posição de todas as estruturas contidas nesse espaço. Se a trajetória adquirida por cada estrutura contida no espaço, pode ser representada por um vetor, então a função vetorial que associa cada ponto do espaço a um único vetor contido no espaço (lembrem-se do conceito de fluxo), essa função vetorial pode então ser entendida como um campo vetorial.

Por fim, a coleção de trajetórias de cada estrutura, que está contida no espaço do modelo de negócio, é denominada espaço vetorial do modelo de negócios. Refresquei um pouco da sua memória? Muito bem, não se preocupe, não vamos focar na matemática do processo por enquanto, apenas quis lembrar alguns conceitos importantes para o desdobramento de nossas ideias. Agora que já relembramos alguns conceitos matemáticos que regem nosso modelo, você já deve ter uma noção de como funciona o princípio da localização, de uma maneira um pouco mais formal, o princípio da localização se dá pelo seguinte teorema:

“Todo sistema pode ser representado por um ponto contido em um espaço do modelo de negócios de um universo organizacional, tal que, suas coordenadas são dadas pelo número de componentes relacionados a cada dimensão que delimita o espaço do modelo de negócios”

Veja bem, imagine que você está construindo uma api de produtos, ela não traz nenhuma feature de preço, nenhum item relacionado à operação de venda desse produto, tão pouco a pessoa que se relaciona com ele, menos ainda com os sistemas de comunicação da empresa. Essa api, simplesmente traz dados do produto. Podemos então representar esta api no espaço do modelo de negócios como:

Supondo que a arquitetura escolhida para esta api seja a de um monolito, à medida que a estrutura da api de produtos é alterada para atender o negócio e ter também features de precificação e promoções, as quais são relacionadas diretamente com a dimensão do financeiro, temos que nossa api sofre um deslocamento tal como:

À medida que nossas organizações evoluem/modificam-se, os modelos de negócio da organização sofrem mutações, podendo alterar completamente a topologia dos sistemas contidos no espaço do modelo de negócio. Quando isso ocorre a cada período t, de tempo, temos que cada sistema contido no espaço do modelo de negócio passa a carregar uma nova propriedade, a taxa de modificação. Que nada mais é, senão uma grandeza vetorial que denota a velocidade com que um determinado sistema muda. Essas mudanças tendem a ser muito frequentes, no início do ciclo de vida da aplicação, mas, com o passar do tempo, elas tendem sempre a zero. Isso pode nos dizer duas coisas, sendo a primeira que esse sistema chegou à estabilidade, e a segunda é que este sistema pode ter entrado na fase legada. Sendo pouca ou nenhuma modificação necessária para sua operação.

Veja bem, até aqui, com os conhecimentos que desenvolvemos somos capazes de entender a topologia formada pelo nosso ecossistema de aplicações, conseguimos extrair os vetores de trajetória do sistema, ou seja, sabemos sua origem e para onde ele tende a ir. Conseguimos de presente um indicador que junto a outros, consegue nos mostrar a maturidade de cada sistema. E uma das coisas mais importantes, temos um modelo padrão e sólido de como organizamos nosso ecossistema em função do modelo de negócio. Vamos avançar um pouco mais. Imagine agora que todo o ecossistema de sua organização sofreu uma modificação em função de um ajuste no modelo de negócio para atender uma nova demanda de mercado. Você deve estar imaginando algo parecido com um fluxo de um fluido. Nesse caso todo o ecossistema sofreu um deslocamento, variando sua posição em função do tempo. Ignorando os fatores que causaram a variação, e olhando apenas para o fenômeno de deformação da topologia do ecossistema. Temos que o campo vetorial resultante é dado pela taxa de modificação do ecossistema.

Mas por qual motivo isso é importante? O gradiente nos fornece uma noção de como nosso ecossistema tem se comportado em relação às mudanças do espaço, ou seja, modelo de negócio. Isso faz com que agora seja possível entender os nossos ecossistemas de api’s não só, como grandes estrelas da morte ou monólitos, mas sim como um sistema dinâmico, mutável, evolutivo. Viram como é interessante? Mesmo na área de TI, o ato de projetar e desenhar um modelo arquitetônico pode ser reduzido a um problema de localização!

Vocês devem se lembrar que no nosso primeiro capítulo eu descrevi que a escolha de um modelo de arquitetura de um ecossistema é análoga a solução particular de uma equação diferencial, com o princípio da localização, conseguimos levantar o primeiro indício de que todo modelo arquitetônico é uma solução particular válida somente para um conjunto de valores de contorno, desde que este não sofra nenhuma modificação. Consequentemente, agora fica um pouco mais clara a necessidade de adotarmos modelos analíticos e evolutivos, de modo a suprir as necessidades e mudanças do negócio.

Entendo que a cabeça de todos deve estar um pouco chacoalhada com a mudança de conceitos, antes, víamos uma certeza muito frágil em relação ao motivo de adotar determinado modelo de arquitetura. Agora, já possuímos um modelo de organização claro e sólido em relação às diversas variações que o mercado pode causar nos modelos de negócio de nossas organizações. Por estarmos no modelo de artigo, acabo abstraindo grande parte da matemática associada ao modelo, mas, assim que finalizarmos essa série, irei disponibilizar todo o modelo associado, na forma de um artigo bônus um pouco mais didático para os curiosos e amantes dos números.

O meu muitíssimo obrigado pela atenção de vocês! E se você não concorda com algo neste texto, deixo aberto para todo e qualquer tipo de feedback. Sua opinião é muito importante para o desenvolvimento deste trabalho! Afinal, estamos criando essa ferramenta exatamente para auxiliar cada profissional da área de tecnologia a tomar decisões melhores e adotar não a melhor arquitetura, mas sim, um modelo evolutivo mais adequado a sua organização, a sua realidade, sua cultura, e a planejar o futuro do ecossistema. Um muito obrigado e até a próxima!