Especificação ArchiMate® 3.1: A Nova Versão do Padrão

postado em 9 de nov. de 2019 09:48 por Antonio Plais   [ 9 de nov. de 2019 09:53 atualizado‎(s)‎ ]
Originalmente postado por Marc Lankhorst*, no blog do The Open Group- Tradução e adaptação autorizados

No evento do The Open Group em Amsterdan, em 05 de novembro de 2019, foi lançada a mais recente versão da linguagem ArchiMate® para a modelagem da Arquitetura Corporativa. A Versão 3.1 é uma atualização da versão anterior 3.0 (lançada em 2016). Embora seja "apenas" uma pequena atualização, ela trás várias adições e melhorias importantes para os praticantes da Arquitetura Corporativa.

As três melhorias mais importantes são:
  • adição do elemento de Fluxo de Valor
  • introdução da notação direcional para Associação
  • maior formalização e refinamento das regras de derivação de relacionamentos

Fluxo de Valor

A mais importante e visível destas mudanças na Versão 3.1 é a adição de um novo elemento de Fluxo de Valor na camada de Estratégia. O padrão define isso como:

"Um Fluxo de Valor representa uma seqüência de atividades que criam um resultado global para um cliente, parte interessada ou usuário final."

Um Fluxo de Valor descreve como uma empresa organiza suas atividades para criar valor. Como descrito no TOGAF® Series Guide to Value Streams, um importante princípio dos fluxos de valor é que o valor é sempre definido a partir da perspectiva da parte interessada - o cliente, usuário final ou recebedor do produto, serviço ou entregável produzido pelo trabalho. A noção de Fluxo de Valor também aparece em outros lugares, como em métodos de Arquitetura de Negócio, como o Guide to the BIZBOK®, e em métodos ágeis como o Scaled Agile Framework (SAFe®). A definição do ArchiMate é genérica o suficiente para cobrir estas noções.

Fluxos de Valor são diferentes de processos de negócio. Este último está preocupado com o 'como', as tarefas realizadas por uma organização para produzir algum produto ou serviço concreto, enquanto fluxos de valor dizem respeito ao 'o que', o valor que é criado. O valor está no olhar do espectador; ele depende mais da percepção de valor da parte interessada sobre o valor do produto, serviço, resultado, ou entregável, do que do seu valor intrínseco (isso é, o custo do produto). Isso é modelado na linguagem ArchiMate usando o elemento de Valor (que já existia desde a especificação do ArchiMate versão 1.0).

Fluxos de valor são normalmente realizados por processos de negócio. Os estágios em um fluxo de valor fornecem uma estrutura para organizar e definir estes processos, mas diferentes partes da organização podem ter suas próprias implementações dos processos para realizar o mesmo estágio do fluxo de valor. Da mesma forma, um processo de negócio pode realizar vários estágios em um fluxo de valor.

Recursos podem ser atribuídos a fluxos de valor e capacidades podem servir (isso é, habilitar) um fluxo de valor. Isso suporta a técnica comum de mapeamento cruzado entre fluxos de valor e capacidades, onde você identifica quais capacidades e empresa precisa ou usa para suportar os estágios de um fluxo de valor. Um exemplo disso é mostrado na figura abaixo. Ela mostra um modelo do fluxo de valor de uma análise de dados para um estudo de caso de inteligência de negócio. Entre os estágios do fluxo de valor, vemos os fluxos de valor com o valor adicionado associado por cada estágio, e ao final o resultado de negócio de 'tomada de decisão bem fundamentada' que este fluxo de valor realiza para uma parte interessada em particular. Cada estágio no fluxo de valor requer várias capacidades, mostradas abaixo dos estágios e também mostrando como você pode usar o conceito de agrupamento melhorado para modelar eficientemente este mapeamento cruzado.


Exemplo de Fluxo de Valor

Adicionar este conceito de fluxo de valor criou uma perfeita simetria na linguagem. Fluxos de valor e capacidades refletem o modelo de negócio da empresa e a criação de valor de uma forma independente da sua organização, enquanto os processos de negócio e as funções de negócio refletem seu modelo operacional e são mais dependentes da organização. Nos seus respectivos níveis de abstração, fluxos de valor e processos de negócio representam a 'empresa em movimento', enquanto que as capacidades e funções de negócio descrevem a 'empresa em descanso'.

Associação Direcionada

A adição de um relacionamento de Associação direcionada é uma pequena melhoria com um grande potencial. Um caso de uso comum é para expressar a navegabilidade, por exemplo, que uma apólice de seguro se refere a um ativo segurado, e não o contrário.

Especialmente quando combinado com a noção de relacionamentos especializados do ArchiMate, e a notação de estereótipo relacionada (veja o capítulo sobre Mecanismos de Personalização no padrão), ela permite que você forneça mais significado para uma associação 'sem significado'. A figura abaixo mostra o relacionamento entre o sono de um aplicativo e o aplicativo que ele possui, usando uma associação direcionada estereotipada como essa.


Associação Direcionada com Estereótipo

Agora, você precisa exercitar alguma cautela ao usar esta funcionalidade. Ela não seria muito útil, por exemplo, para definir seus próprios relacionamentos se alguma coisa bastante próxima já é oferecida nativamente pelo padrão.

Derivação de Relacionamentos

Além das adições e melhorias mencionadas acima, a nova especificação também introduz regras refinadas para a derivação de relacionamentos. Este é um assunto mais especializado, que para a maiorias das pessoas fica escondido por trás das ferramentas de modelagem ArchiMate.

Estas regras de derivação permitem que você tire conclusões ou sumários sobre relacionamentos que podem (ou devem) existir entre dois pontos em uma cadeia de elementos conectados por vários tipos de relacionamentos. Por exemplo, se o seu Departamento de Serviço ao Cliente desempenha (é atribuído a, em termos ArchiMate) um processo de negócio Tratar Solicitação do Cliente, que por sua vez fornece (isso é, realiza) um Serviço de Helpdesk, você pode concluir que o Departamento de Serviço ao Cliente realiza o Serviço de Helpdesk.

Na nova versão do padrão, nós formalizamos estas regras (e as restrições que se aplicam a elas) para garantir que elas sejam bem entendidas e implementadas consistentemente. Isso agora se parece mais com uma especificação 'matemática', mas não entraremos em detalhes sobre isso aqui.

Nós também refinamos estas regras para fazer uma distinção entre derivações que devem ou podem ser verdadeiras. O primeiro tipo, chamado derivação 'válida', são necessariamente verdadeiras. Por exemplo, se A contém B, e B contém C, A por definição contém C (usando um relacionamento de composição). Esta derivação é sempre válida.


Derivação válida (em azul)

Também é possível tirar conclusões sobre relacionamentos que são apenas 'potenciais'; se eles existem ou não na realidade depende de fatores específicos da sua arquitetura. Por exemplo, se um serviço de aplicativo S serve um processo de negócio P, que consiste dos sub-processos Q e R, qualquer um destes sub-processos poderia (potencialmente) ser servido (ou seja, usar) o serviço S. Somente uma decisão do arquiteto, ou um exame detalhado de Q e R, poderia dizer qual é realmente o caso, mas os dois relacionamentos de servidão são corretos.



Derivações Potenciais (em vermelho)

Note que todos estes relacionamentos derivados são também permitidos na linguagem ArchiMate. Adicionar esta noção de relacionamentos 'válidos' e 'potenciais' aumentou a força analítica da linguagem e expandiu os relacionamentos possíveis, dando aos modeladores mais liberdade e opções.

Expectativas para o Futuro

Além das principais melhorias mencionadas acima, várias mudanças grandes e pequenas foram feitas nas definições dos conceitos na linguagem, tanto para torná-las mais claras como para melhorar o alinhamento com outros padrões como o TOGAF. A notação de ícone é agora permitida para todos os elementos que possuem uma notação 'caixa com ícone', e não apenas para um pequeno sub-conjunto aleatório. Finalmente, a exibição e a estrutura do metamodelo do ArchiMate foi melhorada em vários lugares. Isso não é algo que o usuário médio da linguagem notará, mas isso ajuda a compreender melhor o padrão.

Com estas recentes melhorias e adições, a cobertura da disciplina da Arquitetura Corporativa pela linguagem ArchiMate está bastante completa, pelo menos em termos dos domínios que ela pode descrever. assim sendo, não esperamos maiores extensões para o escopo da linguagem no futuro próximo. Existem, no entanto, alguns outros aspectos que poderiam ser objeto de melhorias. Por exemplo alternativas de notação que pareçam mais agradáveis para as partes interessadas de negócio, ou formas de usar a linguagem nos estágios iniciais do desenho arquitetural, quando as ideias ainda não estão cristalizadas. Mais ainda, podemos querer procurar formas de simplificar a estrutura da linguagem (naturalmente, sem reduzir a sua força expressiva).

Estas são, no entanto, ideias de longo prazo. Por enquanto, a Especificação ArchiMate 3.1 está pronta para uso e sem nenhum concorrente sério, enquanto sua base de usuários cresce continuamente. Se você tem ideias sobre o padrão e quiser contribuir para a sua evolução, ou simplesmente quer conhecer mais sobre ela, junte-se ao Fórum ArchiMate do The Open Group ou ao grupo ArchiMate (ou ArchiMate Brazil) no LinkedIn, onde acontecem discussões acaloradas sobre todos os aspectos da linguagem.

Você pode encontrar a Especificação ArchiMate 3.1 aqui (em breve, também em Português Brasileiro).



* 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.