Construindo grandes ecossistemas: Parte 1

Confesso que quando comecei a ideia maluca de escrever um livro, fiz isso muito mais pelo incentivo de alguns amigos que achavam que a minha loucura podia ser reaproveitada e de alguma forma (que eu sinceramente não tenho ideia até hoje), ajudar outras pessoas a não terem que passar pelos mesmos "perrengues" que a gente, a ideia era maluca, mas, por que motivos não? O pior que poderia acontecer era eu jogar tempo fora (risos). Mas, sobre o que escrever? Acredito que já tenham bons e suficientes livros sobre linguagens, sobre gerenciamento de projeto, e metodologias e modelos de arquitetura. Eu definitivamente, não queria gastar muito tempo falando mais do mesmo.

Mas, uma coisa me chamou muito a atenção desde o momento que comecei a estudar arquitetura, até o momento em que comecei escrever minhas ideias e a compartilhar com vocês, nossa área é puramente pautada no que chamamos na matemática de: análise criteriosa, ou em bom mineirês: uma indicação subjetiva baseada em experiencias e preferencias de atuação. Não fiquem bravos, vocês sabem que é verdade, olhamos para nossa experiencia e para o mercado em que atuamos, e baseado nisso, e nas nossas preferencias e zonas de conforto nós (os arquitetos) inferimos que aquele determinado padrão ou proposta de arquitetura é a melhora para o problema. Vai dizer que estou errado? Você pode querer justificar que não, que você é diferente, mas, você ó lírio do campo, sabe que não é. Ninguém é, e muitas vezes recorro a olhar pro passado pra projetar o futuro - (falei bonito não é mesmo?), não é que exista um problema por trás disso em dimensões de curto prazo e escala, mas a medida que ambos aumentam, notamos que os desperdícios aumentam, e quando menos esperamos, anos se passaram e temos um ecossistema doente, precisando de milhares de refatorações e processos de rearquitetura.

Após validar isso das formas mais criativas que vocês possam imaginar, entendi que era esse o tema que eu queria estudar e entender melhor! Como eu, enquanto arquiteto, posso criar um ecossistema/plataforma saudável, do ponto de vista de redução de desperdicios e que a medida que o tempo passasse, a arquitetura de tecnologia se adaptasse as mudanças do modelo de negócio da organização. De forma que pudéssemos eliminar partes obsoletas e que já não fizessem mais sentido naquele momento, bem como construir outras partes, sem causar uma mudança estrutural tão profunda, e além disso possibilitasse que a estratégia de tecnologia fosse catalisadora da estratégia de negócio da organização em que eu estivesse inserido naquele momento. Ambicioso não? Muitos anos de estudo, testes, falhas e sucessos, consegui estabilizar um modelo que já foi inclusive implementado em grandes empresas do varejo, setor de alimentos e financeiro. Gostaria de compartilhar nesse e nos próximos artigos, o que denomino como os princípios fundamentais do meu framework: Ecossistemas orientados a dimensões.

1- Princípio da evolução dos modelos de negócio.

Todo modelo de negócio evolui. Embora essa afirmação possa parecer clichê, indica uma verdade fundamental. Desde o momento em que temos uma ideia — seja ela disruptiva ou mais conservadora — até que a transformemos em um produto, criando um modelo de negócio e expondo nossa ideia ao mercado, aquela ideia inicial passa por inúmeras transformações. E na grande maioria das vezes só carrega a essência daquela oportunidade que enxergamos no início de nossa jornada. Quando finalmente chega ao mercado, inicia-se a fase de lapidação. Em sua obra The Lean Startup, Eric Ries (2011, p. 20), discute o ciclo de desenvolvimento e adaptação contínuos: "As startups que têm sucesso são aquelas que conseguem iterar o suficiente antes de ficarem sem recursos". A velocidade de modificação do modelo de negócio tende a desacelerar gradualmente. No entanto, essa desaceleração é apenas momentânea. Nessa fase, geralmente ocorrem descobertas de novas necessidades, mudanças macro e microeconômicas que afetam o mercado, além de transformações geracionais, culturais e nos padrões de consumo. Todos esses fatores desencadeiam um novo período de instabilidade. Essas variáveis podem provocar grandes mudanças no modelo de negócio, como também podem levar a uma completa redefinição de toda a cadeia estratégica.

Gosto de usar um conceito matemático para pensar sobre a evolução de modelos de negócio e suas transformações: o das soluções gerais e particulares de uma equação diferencial. Não se preocupe, não nos aprofundaremos tanto na matemática. Imaginemos, por um momento, um fenômeno do nosso cotidiano: o desafio de incentivar as pessoas a se exercitarem. Existem diversas formas de abordar esse problema — podemos levá-las a parques, praças, ou criar programas de incentivo. As possibilidades são praticamente infinitas. Entretanto, cada solução acaba atendendo apenas às necessidades de um pequeno grupo de pessoas. Afinal, tem quem não goste de se exercitar ao ar livre, assim como aqueles que não gostam ser obrigados a fazê-lo. Cada grupo tem suas particularidades e, por isso, cada solução que criamos é, por dedução óbvia, uma solução particular. Uma solução geral seria aquela que englobasse todas as particularidades de todas as pessoas (um conjunto universal, tal como definimos no início desse trabalho). Pensando em um modelo de negócios, isso é impossível.

Pense bem: se nossos modelos de negócio são soluções particulares para um problema que queremos resolver, então a menor mudança nas regras que governam essas particularidades também alterará nosso escopo de solução, certo? É aí que nós, profissionais de tecnologia, entramos. Normalmente, tentamos escrever uma solução sistêmica que corresponda à necessidade inicial. Usamos os melhores padrões, práticas e processos, mas frequentemente não nos preocupamos com o aspecto fundamental de que estamos escrevendo uma solução que captura essencialmente as características e particularidades do escopo inicial do modelo de negócio. Definimos de forma rígida como cada componente será escrito, justificando que é apenas um protótipo ou MVP. Ou então, nos apegamos a um mantra quase unânime que todos nós costumamos bradar: "Esse sistema terá que ser reescrito daqui a alguns anos".

Nesse aspecto, a modularidade que sempre pregamos acaba se tornando um verdadeiro diferencial, permitindo que nossos ecossistemas se adaptem rapidamente às mudanças do mercado e às novas necessidades das pessoas. Um exemplo perfeito para nosso caso éo o da AWS, da Amazon. Onde a plataforma provê um conjunto de serviços na nuvem — tais como armazenamento, processamento, virtualização, entre outros diversos — que funcionam de forma independente e com o objetivo de ajudar seus clientes a rapidamente criar novas soluções.

Por outro lado, imagine sistemas altamente integrados, onde qualquer ajuste requer uma reformulação completa. Esses exigem mais tempo e trabalho para se adaptarem, tornando o processo mais lento e custoso. No fim das contas, exemplos como Android e AWS demonstram como pensar no design modular desde o início pode fazer toda a diferença. Isso permite que as plataformas se mantenham competitivas e flexíveis, prontas para enfrentar um mercado em constante mudança.

Devemos encarar uma solução arquitetônica, assim como o modelo de negócio, como um organismo vivo capaz de evoluir, remover ou adicionar partes e realizar modificações estruturais. Essa solução deve reagir ao ambiente (mercado) em que está inserida. Com base nessas premissas, podemos estabelecer o axioma que serve como nosso princípio fundamental:

O ecossistemas deve ser projetado com foco em modularidade e flexibilidade, de maneira que viabilize a evolução contínua do modelo de negócio. Minimizando a necessidade de grandes mudanças estruturais, facilitando assim, a criação, a atualização e a substituição de seus componentes.

Este princípio, mesmo que de forma abrangente, se aplica a todas as mais diferentes fases do desenvolvimento de um ecossistema. Esteja ele em fases iniciais, ou nos estágios mais avançados e de tração. Em um MVP, por exemplo, a aplicar nosso o Princípio da evolução dos modelos de negócio, significa iniciar o desenvolvimento dos ecossistemas com serviços mínimos e modularizados, em um modelo que permita realizar ajustes rápidos e com baixo impacto. À medida que o ecossistema tende crescer, um modelo de arquitetura modular e composicional facilitará a adição de novos serviços e capacidades sem precisar revisar tudo o que já existe. Em uma fase mais madura, essa modularidade permitirá dividir a o ecossistema em “domínios de negócios” (ou pegando emprestado do Domain Driven Design, Domínios de Conhecimento), voltados para necessidades específicas, o que promovendo escalabilidade e ajudando a reduzir os custos de operação e manutenção a médio/longo prazo. Em cada fase, passamos a usufruir cada vez mais da facilidade e adaptabilidade do modelo.

Isso pode parecer algo utópico, mas, atualmente, diversas organizações têm adotado um modelo mais modular e composicional. Em um futuro não muito distante, os ecossistemas das grandes organizações tendem a se tornar mais próximos de plataformas que apoiam seus modelos de negócio, com células cada vez mais autônomas e especializadas nas soluções dos problemas referentes ao modelo de negócio da organização. O ponto aqui não é gastar anos pensando em como criar uma arquitetura perfeita, mas sim considerar cada solução como parte de um organismo vivo, e em constante evolução, focando apenas nas premissas que realmente importam naquele momento. Vocês vão encontrar diversos artigos, livros e palestras bradando que a concepção do software deve sempre acompanhar o "time to market", ou que deveríamos sempre utilizar o princípio KISS (Keep It Simple, Stupid) na concepção de nossas soluções.

Concordo e gosto dessa abordagem, mas gostaria de embasar este princípio que estamos definindo em algo um pouquinho mais antigo e que sobreviveu ao teste do tempo. Vamos voltar um pouco no tempo, para o período entre o final do século XIII e início do século XIV, em que o filósofo Guilherme de Ockham estava publicando o que seria conhecido posteriormente como a "Navalha de Ockham", que é um princípio da filosofia que nos diz o seguinte: para um conjunto qualquer de soluções de um problema, a melhor solução sempre será aquela que possui o menor número de premissas para sua execução — ou, em bom português: o mais simples geralmente atende mais rápido e melhor.

Veja bem, estamos inseridos num contexto dinâmico, o mercado muda constantemente, em reação a isso, o modelo de negócio evolui e se adapta ao mercado, partindo do pilar de que o modelo de negócio de uma empresa é uma solução particular para um problema de mercado. Podemos dizer então que suas variáveis de contorno (escopo), ou melhor dizendo, suas premissas, tendem a mudar proporcionalmente ao tamanho da mudança do mercado. Em vez de tentar criar o sistema que prevê isso, basta que criemos um que se atenha as premissas naquele instante e seja modular o suficiente para evoluir de acordo com o que for necessário, evoluindo, transformando, e até mesmo descartando as partes que já não atendem a premissas do negócio.

Ao criarmos um ecossistema como um organismo adaptável — que pode evoluir para uma plataforma — conseguimos responder às demandas do mercado de uma forma mais sustentável, sem comprometer a qualidade daquilo que é entregue ao cliente. Nos posicionamos para evoluir não só rapidamente, mas também de maneira mais segura, e menos suscetível a grandes refatorações a longo prazo. Além disso, possibilitamos que nossos times a mantenham sua criatividade e potencial de inovação, sempre alinhados às premissas do modelo de negócio, à visão, aos valores e aos princípios de governança da organização.