System of Systems e os Sistema Complexo Adaptativos /ou: Arquitetura (Quase) Caótica...

Posted: 27 de jan de 2010 | . David Lojudice Sobrinho | tags: , ,

No último post eu descrevi como estamos pensando a plataforma de publicação e gerenciamento de conteúdo na Abril Digital e como o conceito de System of Systems (SoS) se aplica. Neste post quero discutir algumas características de um SoS.

Toda vez que penso nos conceitos de System of Systems (SoS), me vem a mente a imagem de uma grande revoada, aquela formação no ar por um monte de pássaros voando aparentemente sem rumo, que é caótica e concisa ao mesmo tempo. O que isso tem a ver com o SoS? Veremos...

O interessante sobre as revoadas é saber que os pássaros não têm um chefe dizendo para onde ir. Porém, o grupo se orienta no ar de forma organizada. Mas como isso é possível? O que acontece é que cada pássaro segue 3 regras básicas: evitar bater em um vizinhos ou obstáculos, alinhar vôo para coincidir com os vizinhos e voar uma distância média entre os vizinhos. Assim, um fenômeno emerge e temos a revoada. Ou seja, o que vemos é algo que parece ser criado, mas na verdade aquilo se manifesta daquela forma.

Será que conseguimos criar regras básicas para os sistemas e assim criar um SoS que se manifeste moldando as necessidade de negócio? Essa foi a pergunta que me fiz a alguns meses atrás e neste post estão algumas evidencias teóricas e práticas que dão suporte a idéia.

O fenômeno da revoada é estudado como um Sistema Complexo Adaptativo (Complex Adaptive System ou CAS), assim como outros sistemas complexos, que vão da economia a física, passando pela formação do cérebro ou a um time de scrum, "complexos no sentido de que são diversos e feitos de múltiplos elementos interconectados, e adaptativos porque têm a capacidade de mudar e aprender com experiências passadas". É aqui que o SoS se assemelha a revoada: diverso, interconectado e evolui.

Será isso mesmo? Vamos olhar o SoS através da idéia de um CAS e ver se conseguimos observar algumas propriedades semelhantes:

Emergência: Ao invés de ser prevista ou controlada, os agentes do sistema interagem de forma aparentemente aleatória. De todos esses padrões emergem interações que informa o comportamento dos agentes dentro do sistema e do comportamento do próprio sistema. Não há nenhum grande plano e o resultado apenas surge como resultado dos agentes seguirem algumas simples regras locais.

Mas o SoS não tem um grande plano? Não deve estar alinhado com a estratégia da empresa? Essa é a principal caracterisca que emerge! Ela não é controlada diretamente, assim como você não manda todos os pássaros voarem para um lado ou para outro. No entanto, acredito eu, existem mecanismos para direcionar essas características (veremos mais abaixo).

Além disso, como cada sistema é independente no SoS, eu não ficaria surpreso se um novo sistema criasse algo completamente novo, algo que simplesmente surge, emerge, juntando informações e funcionalidades de vários outros sistemas.

Co-evolução: Todos os sistemas existem dentro de seu próprio ambiente e eles também fazem parte desse ambiente. Portanto, conforme seu ambiente muda, eles precisam mudar para garantir melhor ajuste. Mas porque eles fazem parte do seu ambiente, quando eles mudam, mudam o seu ambiente também, e como ele mudou eles precisam mudar novamente, e assim por diante como um processo constante.

No SoS, isso é sutil. Imagine que um sistema foi alterado e agora ele aceita maior número de requisições. Isso vai fazer com que outros sistemas se conectem a ele e assim, alterando a configuração do SoS todo. O SoS ganha essa nova formação, que acaba por interferir em como os outros sistemas se conectam e assim por diante.

Poderíamos extrapolar para um outro exemplo, em que alguém do time de um sistema X foi trabalhar em um outro sistema ou saiu da empresa, deixando a evolução do primeiro mais lenta. Isso influencia não só no sistema X, mas também em como os outros times vêem aquele sistema, fazendo tomarem decisões se vão ou não conectar a ele. Novamente, a evolução de um sistema influenciou o conjunto que influenciou os sistemas e assim infinitamente...

Sub ideal: Um CAS não precisa ser perfeito para que prospere dentro do seu ambiente. Uma vez que um CAS atinge o estado de ser bom o suficiente, ele trocará eficiência por maior eficácia.

Pensar que um SoS não vai atingir seu estado máximo é perturbador. Mas quando se entende a complexidade de uma empresa, em todos os seus aspectos, o ótimo é inimigo do bom. Ter um SoS que evolua até chegar em seu estado quase perfeito é um grande conforto na verdade. Esperar que ele troque eficiência por eficácia é mais confortante ainda.

Variedade: Quanto maior a variedade dentro do sistema, mais forte ele é. Sistemas adaptativos complexos dependem de ambigüidade, paradoxo e contradições para criar novas possibilidades.

Não vejo problema, por exemplo, em ter dois ou mais sistemas com a mesma responsabilidade, mas que se diferenciam nos requisitos. Que ganhe o melhor! O SoS vai atrair um para o centro e o outro será expurgado. Ou não! Talvez os dois façam sentido e ganhem um número de conexões semelhantes um do outro. Assim como a evolução das espécies, só se consegue a evolução do SoS quando existe variedade.

Para estimular a variedade, não há regras explícitas (pelo menos do ponto de vista de arquitetura de sistemas) em como cada sistema deve ser construído, seja a linguagens, tecnologias ou design interno da aplicação. O importante é que o sistema se comporte bem dentro do SoS (ex.: se comunique usando HTTP e Atom/Hypermedia).

Auto-organização: Não existe uma hierarquia de comando e controle em um CAS. Não há planejamento ou gestão, mas há uma constante reorganização para encontrar o melhor ajuste com o ambiente.

O exemplo acima é válido aqui também. Quem diz se o sistema é bom ou não para o SoS é o próprio SoS. O modo dele expressar isso é a através de conexões que um sistema faz a outro sistema. Quanto mais conexões ele receber, melhor é o sistema para o SoS.

Conectividade: As maneiras pelas quais os agentes em um sistema se ligam e se relacionam entre si é fundamental para a sobrevivência do sistema, pois é a partir dessas conexões que os padrões são formados e o feedback disseminado. As relações entre os agentes são geralmente mais importante do que os próprios agentes.

Uma arquitetura baseada em serviços (SOA) tradicional não tem essa característica fundamental, que é a navegação entre os sistemas de forma transparente. No nosso caso estamos apostando no conceito de Hypermedia, no protocolo HTTP e no formato Atom para realizar essas conexões. As conexões são tão importantes para nós que estamos gastando um tempo considerável nesse problema.

Regras simples: CAS não são complicados. Os padrões emergentes podem ter uma rica variedade, mas, como em um caleidoscópio, as regras que regem a função do sistema são bastante simples.

Será que conseguiremos definir essas regras ou elas aparecerão como resultado da interação dos sistemas? A ser respondido. No entanto, acredito que parte da manipulação do comportamento emergente está aqui, ou seja, na definição prematura das regras. Assim, se as regras estiverem alinhadas com os conceitos básicos do negócio, o SoS não tem outra escapatória a não ser emergir com as características esperadas. Um desafio é definir as regras básicas de forma que elas também possam evoluir.

Sistemas Aninhados: A maioria dos sistemas está aninhados dentro de outros sistemas e muitos sistemas são sistemas de sistemas menores.

É normal que um time médio (de 6 ou 8 devs) designado para implementar um "módulo" do SoS implementem alguns sistemas/serviços, ao invés de apenas um, criando um subsistema dentro do SoS. Observar o que acontece nesses subsistemas é importante, pois talvez ali as regras do SoS não estão sendo aplicadas ou evoluções dessas regras apareçam.

À beira do caos: Teoria da Complexidade não é o mesmo que a Teoria do Caos, que é derivada da matemática. Mas o caos tem um lugar na Teoria da Complexidade em que os sistemas existem em um espectro que vai do equilíbrio para o caos. Um sistema em equilíbrio não tem a dinâmica interna que lhe permita responder ao seu ambiente e vai lentamente (ou rapidamente) morrer. Um sistema em caos deixa de funcionar como um sistema. O estado mais produtivo de se estar é à beira do caos, onde há máxima variedade e criatividade, levando a novas possibilidades.

Do ponto de vista de SoS, o caos deve ser administrado de forma a não extrapolar as expectativas e recursos da empresa. Isso não quer dizer que ele não deva existir! Evitar coisas como ESB, middlewares de governança ou qualquer forma de gerenciamento centralizado é uma maneira do SoS a evoluir e a se auto-organizar.

Fronteiras: A auto-organização implica que o sistema está rodeada por uma fronteira que o contém. Esta condição define o "auto" (self) que será desenvolvido durante o processo de auto-organização. [G. Eoyang & D.J. Conway, 1999]

A fronteira do SoS é definida quando se sabe o que é esperado dele do ponto de vista de negócio. Sem essa definição não existe como o SoS se auto-organizar, já que não existe o "auto". Além disso, é da definição da fronteira que será possível pensar as regras básicas, que deverão levar em conta até onde o sistema vai e onde é que ele termina.

Já gastamos um bom tempo definindo as fronteiras com as pessoas de negócio. Agora, o meu papel junto aos outros arquitetos da plataforma está na definição da comunicação dos sistemas e na definição das regras simples. Esperamos com essas definições criar uma terra fértil para os sistemas do SoS, deixando espaço para que eles cresçam e dêem frutos. Estamos regando diariamente!

Ah! Pensar arquitetura dessa forma traz implicações com as áreas de Infra-estrutura, Desenvolvimento e Scrum Office. Parte dessas implicações já apareceu e foram ou estão sendo resolvidas num trabalho em conjunto muito bacana e com idéias tão legais quanto. They got it!

0 comentários: