BT

A sua opinião é importante! Por favor preencha a pesquisa do InfoQ!

Business Architecture: do negócio à TI, e não vice-versa

| por Geraldo Coen Seguir 0 Seguidores em 05 set 2017. Tempo estimado de leitura: 6 minutos |

Para melhorar a experiência das pessoas que acessam o InfoQ Brasil, nós criamos uma série de funcionalidades que te permitem ficar pode dentro das últimas tendências e das novidades de seu interesse, sem que você seja incomodado por coisas irrelevantes. Receba e-mails periódicos e notificações sobre seus tópicos favoritos!

Microservices e Modularidade, de Mark Little, aborda de frente a questão de utilizar ou não microservices. O texto gira em torno do conceito de modularidade, e discute como obter modularidade em uma arquitetura baseada em microservices. Em sua publicação, Mark também menciona outros autores, como Gene Hughson e Simon Brown, que afirmam que a modularidade, por si só, não justifica essa escolha arquitetural.

De fato, a modularidade somente não justifica, nem deve ser considerada em uma abordagem com microservices. Modularidade, com uma base teórica muito clara significa decompor um sistema em módulos com função claramente definida, e reutilizáveis em diversas áreas de uma solução. Um conceito amplamente aplicado a software, mas também à arquitetura, onde surgiu o conceito, e a engenharia em geral.

Microservices, por sua vez, é um conceito bem diferente, a ser usado em arquitetura de sistemas, de aplicações, e não na decomposição de programas em módulos. Além disso, microservices quando bem utilizados tendem a facilitar a estruturação, o desenvolvimento e, principalmente, a evolução de uma aplicação complexa.

Em sua publicação, Mark Little começa analisando a opção monolitos versus uma arquitetura orientada a microservices. No decorrer do texto, Mark defende, acertadamente, que tanto em sistemas monolíticos quanto em uma abordagem com microservices, é necessário estruturar a solução de forma a minimizar a complexidade, e essa é a tarefa da arquitetura de sistemas. Se mal feita, o resultado será uma estrutura em microservices tão complicada quanto um monolito. Por outro lado, é possível desenhar um monolito bem estruturado, reduzindo a complexidade e não chegando naquilo que ele chama de "grande bola de lama". Mark Little finaliza afirmando que microservices também podem transformar uma aplicação numa "grande bola de lama" se não forem bem pensados, independentes, com interface claramente definida e realizando uma só função da aplicação.

Mark menciona Hughson ao dizer que distribuição, uma das características de microservices, não é necessariamente uma forma de chegar a modularidade. Ou seja, a distribuição ‒ que pode chegar a ter microservices rodando em clouds separados, comunicando pela Internet via um protocolo como REST ‒ não leva necessariamente a modularidade. Um mau desenho pode levar a microservices distribuídos que interagem entre si, formando gargalos, quebrando o princípio de independência entre microservices. Ou a uma aplicação lenta, travada pelas inúmeras solicitações através da Internet.

Little menciona Posta quando este diz que a gestão de dados pode ser a parte mais difícil de um desenho de uma arquitetura baseada em microservices. De fato, conseguir que os dados sejam tratados independentemente por cada microservice, sem porisso travar outro microservice que precise acessar os mesmos dados, é duro. Aplicar soluções como definir um microservice que gerencia os dados para todos os outros pode criar um gargalo seriíssimo. O que deve ser feito é mudar para uma arquitetura de dados adequada para microservices, quebrando o paradigma antigo de banco de dados único e rígido. Não é fácil conseguir isso.

Posta continua apontando para a solução geralmente recomendada para microservices: DDD (Domain Driven Design). Encontrar domínios claramente definidos e fechados da aplicação (bounded context). Definir um modelo de dados para cada domínio. Dentro do domínio, cada contexto corresponderá a um microservice. Fica claro que o decisivo é o desenho, é a arquitetura da aplicação. A partir dela, definindo contextos claros, é que se chega à arquitetura de microservices, evitando dependências entre microservices.

O segredo disso está claro na definição básica de microservices por Martin Fowler:

"a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data."

Vale destacar o trecho "uma forma específica de desenhar aplicações como uma série de serviços independentes", bem como as características elencadas por Martin: organização a partir das aptidões do negócio, deployment automático, inteligência nas pontas e controle descentralizado de linguagens e dados.

Este é o ponto fundamental, que acredito ter faltado no artigo de Little: é necessária uma mudança total de atitude quando se desenha uma aplicação. O desenho deve partir do negócio e não da TI. Decompor um sistema em módulos é trabalho da TI, do arquiteto de software. Já decompôr uma aplicação em microservices é trabalho do arquiteto da aplicação. Melhor: do arquiteto do negócio.

A acertada escolha de DDD como método aponta para uma solução: uma radical mudança de ponto de vista, e de lugar na estrutura da empresa. Esta mudança radical tem atualmente um nome e um método: Business Architecture.

A Business Architecture , como todos as metodologias, teve uma evolução longa, passando por várias etapas e chegando recentemente à maturidade. Em junho, no Business Architecture Summit , foi possível verificar esta maturidade nos vários cases, modelos e progressos apresentados: ABN-Amro Bank, Boeing, Lloydś, Maersk Line, Nordea Life, United Airlines entre outras empresas que utilizam a Business Architecture.

Business Architecture consiste em modelar o funcionamento de uma empresa, usando uma série de métodos próximos do desenho de arquitetura ou engenharia (blueprints) e de conceitos fundamentais: capability (identificar o que uma empresa sabe fazer), value streams (como a empresa agrega valor - não confundir com processo), informação, e organização (como a empresa se organiza e como trata a informação).

No que diz respeito ao sinal de maturidade, os diversos métodos utilizados para modelar um negócio convergiram para Business Architecture e chegaram a uma definição comum, adotada pela Federation of Enterprise Architecture Professional Organizations (FEAPO), que congrega OMG, IEEE Computer Society, The Open Group e outras. Esta é a definição adotada:

Business architecture represents holistic, multidimensional business views of: capabilities, end-to-end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders.

Business Architecture representa um visão completa e multidimensional do negócio através de: aptidões, entrega de valor de ponta a ponta, informação e estrutura organizacional; inclui o relacionamento entre estas visões do negócio e estratégias, produtos, políticas, iniciativas e stakeholders.

A mudança radical de ponto de vista consiste em partir do negócio, modelá-lo com a Business Architecture, e a partir deste modelo criar a Arquitetura da TI (IT Architecture). A consequência é que a TI "cola" no negócio e acompanha sua arquitetura. A consequência seguinte é que mudanças no negócio são refletidas por mudanças na TI de uma forma natural. O "change management", o processo ITIL mais temido por gestores de TI, passa a fluir melhor e a atender adequadamente o negócio, tanto em prazo quanto em funcionalidades.

Estas funcionalidades são o que definirão os microservices, como módulos que efetuam uma função do negócio identificada nos modelos da Business Architecture. A dificuldade será, daqui para a frente, conseguir mudar a perspectiva: partir do negócio para a TI, não vice-versa.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Faça seu login para melhorar sua experiência com o InfoQ e ter acesso a funcionalidades exclusivas


Esqueci minha senha

Follow

Siga seus tópicos e editores favoritos

Acompanhe e seja notificados sobre as mais importantes novidades do mundo do desenvolvimento de software.

Like

Mais interação, mais personalização

Crie seu próprio feed de novidades escolhendo os tópicos e pessoas que você gostaria de acompanhar.

Notifications

Fique por dentro das novidades!

Configure as notificações e acompanhe as novidades relacionada a tópicos, conteúdos e pessoas de seu interesse

BT