Sobre Camadas e Níveis de Abstração na Linguagem ArchiMate
Postado em 14 de jan de 2022 por Antonio Plais
Originalmente postado por Marc Lankhorst*, no blog da BiZZdesign – Tradução autorizada
Uma postagem anterior sobre níveis de abstração em modelos de arquitetura resultou em uma intensa discussão no LinkedIn. Como parte dessa discussão, a noção de estratificação foi questionada e, em particular, as camadas que estão construídas na linguagem ArchiMate. Nessa postagem gostaríamos de clarear o pensamento por trás da estrutura da linguagem.
A principal razão para a introdução de camadas e níveis em geral é reduzira complexidade do mundo que estamos descrevendo. Tais camadas são uma maneira conveniente de particularizar alguma dimensão que pode ser (quase) contínua. Dividir um espectro gradual de possibilidades em partes discretas torna mais fácil compreender o que está acontecendo. Em geral, isso é o que as pessoas fazem: nós classificamos o mundo em categorias compreensíveis, identificando, por exemplo, móveis como mesas ou cadeiras, mesmo que possa haver mesas onde você pode se sentar e cadeiras onde você pode comer.
Na nossa disciplina da arquitetura corporativa você vê isso, por exemplo, no Contínuo Corporativo do TOGAF (TOGAF Enterprise Continuum), que é particularizado em quatro níveis. O ArchiMate também foi influenciado por abordagens de arquitetura estratificada tais como o modelo OSI centrado em torno da noção de ‘serviços’ em diferentes níveis de abstração (no caso do OSI, sete níveis). Essa é uma das razões para a proeminência do conceito de serviços no ArchiMate e para as maneiras como suas camadas centrais são conectadas.
Agora, existem muitas dimensões diferentes ao longo das quais você pode posicionar os modelos da sua arquitetura (ou do mundo em geral): genérico vs específico, abstrato vs concreto, granularidade alta vs baixa, aproximado vs preciso, funcional vs construcional, independente de implementação vs específico, descritivo vs prescritivo, incerteza vs certeza, intenção vs efeito, e muito mais. Em teoria todas estas dimensões deveriam ser tratadas como independentes e ortogonais (a não ser quando provado o contrário). No entanto, isso nos daria um hipercubo multi-dimensioinal como um framework para a nossa abordagem de modelagem, o que seria simplesmente muito complicado para ter qualquer uso prático.
Mais ainda, na prática você vê que muitas dessas dimensões são correlacionadas: todo desenho usualmente progride de uma ideia de nível mais alto, abstrato, genérico, aproximado, independente de implementação, para uma especificação e realização mais concreta, detalhada, específica e precisa. Assim, mesmo que em teoria estas dimensões sejam ortogonais, nem todas as combinações acontecerão na prática.
Framework Zachman
Por estas duas razões – simplicidade e correlação – abordagens como o ArchiMate fundem algumas dessas dimensões e as particularizam em níveis fixos. Você pode ver isso muito explicitamente no framework Zackman, por exemplo, que identifica as dimensões de duas formas: tanto com níveis de abstração quanto com a intenção das partes interessadas, sendo a suposição subjacente a de que certas partes interessadas só têm interesse em certos níveis de abstração.
Essa fusão de dimensões pode não ser correta em um sentido formal, mas frequentemente é boa o bastante para uso prático. Mais ainda, de qualquer forma um modelo só pode ser uma aproximação da realidade; como George Box uma vez declarou, “todos os modelos estão errados, mas alguns são úteis”. Então, o que realmente conta é se o conjunto de abstrações em uma abordagem em particular é adequada para os nossos propósitos, permitindo que criemos modelos que são ‘próximos o suficiente’ para serem úteis.
Finalmente, em uma disciplina de arquitetura corporativa que tem um foco forte em TI, a progressão ao longo dessas dimensões é, frequentemente, em direção à implementação de TI. O ArchiMate foi desenhado para a prática geral e também para se alinhar com outras metodologias da área (como o TOGAF), razão pela qual algumas vezes também demonstra um viés em direção à TI (embora menos nas versões mais recentes da linguagem). Você poderia argumentar que a ‘verdadeira’ arquitetura corporativa deveria focar na empresa inteira e não apenas nos aspectos relacionados com a TI (e nós somos simpáticos a essa posição), mas ao desenhar uma linguagem nós não pretendemos mudar o escopo da disciplina.
Essa progressão em direção a implementações de TI é visível nos modelos ArchiMate onde você se move dos elementos de Motivação (e.g. partes interessadas e suas metas) através da camada de Estratégia (e.g. capacidades e recursos), para a camada de Negócio (serviços e processos de negócio, estrutura organizacional), a camada de Aplicativo que suporta a camada de Negócio (e.g. serviços e componentes de aplicativo) e a camada de Tecnologia que sustenta estes aplicativos. Note que o ArchiMate permite que você modele aspectos que não são relacionados com a TI, tanto do lado organizacional como do mundo físico (este último desde a versão 3.0), mas a maioria dos praticantes está no mundo da TI e usam a linguagem para propósitos relacionados com a TI.
Acima mencionamos a progressão ao longo do tempo desde o desenho até a implementação. Nós podemos posicionar a linguagem ArchiMate neste continuum desde as ideias de mais alto nível até a solução realizada. Nenhuma abordagem de modelagem única cobrirá tudo isso na sua totalidade, e métodos diferentes têm posições diferentes. O ArchiMate está posicionado atualmente um pouco mais à esquerda do que a UML e o BPMN neste eixo, mas ainda em direção ao ponto onde os desenhos já estão de alguma forma cristalizados. Uma visualização interessante é dada pelo Rabisco de Desenho de Processos de Damien Newman.
Nós podemos querer estender a linguagem para suportar mais os primeiros estágios exploratórios, indo mais para a esquerda na figura. Em linha com o que mencionamos acima sobre a progressão dos desenhos, isso significaria estender a linguagem para conceitos ou mecanismos mais genéricos. Isso requere uma análise profunda e séria, uma vez que uma extensão como essa não deveria aumentar a complexidade para os usuários, deveria estar um linha com a estrutura e os princípios atuais da linguagem, e ter compatibilidade retroativa com as versões anteriores para permitir um caminho de atualização suave. Desde que a versão 3.1 da linguagem ArchiMate foi lançada (uma atualização pequena da linguagem), nós começamos a pensar sobre melhorias e extensões maiores como esta. Gostaríamos muito de ouvir a sua opinião sobre isso.
* Mark Lankhorst é Gerente de Consultoria & Evangelista-Chefe de Tecnologia da Bizzdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.
eBook
ArchiMate: da Teoria à Prática
Inovação, regulações em constante mudança, novas possibilidades tecnológicas, uma nova direção estratégica; estas são algumas das razões pelas quais muitas organizações estão em constante movimento. Este livro apresenta as melhores práticas dos autores, fruto da experiência do uso da linguagem ArchiMate em dezenas de projetos reais, em clientes dos mais diversos ramos de negócio. Uma […]