Modelo de referência BIAN. Que novidade e útil para a arquitetura corporativa do banco oferece?



BIAN ... quão pouco há nesse som para o coração de um russo ... Sim, não foi por acaso que parafraseei o famoso clássico. A popularidade do modelo de referência BIAN ainda é baixa na Rússia, especialmente em comparação com o modelo Mapa de Operações de Telecomunicações Avançadas (eTOM), amplamente difundido no setor de telecomunicações, que está à frente de seu desenvolvimento. Enquanto isso, o modelo BIAN está se desenvolvendo, melhorando e ganhando popularidade fora da Rússia e na comunidade internacional do setor bancário.

Não vou mais distrair o leitor com digressões líricas, apenas direi que uma revisão do modelo BIAN e os documentos que acompanham o padrão estão no meu primeiro artigo no BIAN, tentarei explicar como o BIAN pode ser útil para gerentes de negócios, arquitetos de negócios, arquitetos corporativos, arquitetos de soluções, especialistas em TI e todas as outras pessoas interessadas em gerenciar toda a arquitetura de uma empresa financeira. E também sobre suas principais transformações úteis, na minha opinião.

O que há de novo e interessante?


BIAN tornou-se mais acessível



Uma das mudanças mais importantes e importantes que aconteceram com o modelo de referência da BIAN , na minha opinião, foi sua tradução para a notação do Archimate . Tornou-se mais fácil de ler. Os desenvolvedores do BIAN, aparentemente, não puderam deixar de reconhecer a necessidade de usar a notação padrão para descrevê-la , a fim de disseminá-la ainda mais nos círculos profissionais . O modelo de percepção tornou-se mais claro para os arquitetos, conforme descrito em uma linguagem compreensível para os arquitetos. Portanto, a versão do BIAN 8.0 é apresentada no idioma do ArchiMate 3 . O modelo está em domínio público . Ao se registrar no site www.opengroup.org , todos podemFaça o download de uma descrição do modelo BIAN e de todos os seus componentes na notação do Archimate.

Implementação de BIAN na API



Outro ponto importante que vale a pena mencionar é que a Associação Independente de Padrões sem fins lucrativos (BIAN ) mantém e atualiza o repositório de APIs para seus domínios comerciais de paisagem.
Os desenvolvedores do BIAN visam criar um repositório acessível de APIs e microsserviços de alta qualidade para ajudar os bancos a atualizarem de forma rápida e econômica.
Os arquivos de origem da API do repositório também são publicados e estão disponíveis para download após o registro no portal (se alguém tiver dificuldade em se registrar, tente se registrar no modo de navegação anônima do seu navegador).

A seguir, examinaremos mais detalhadamente o metamodelo BIAN na notação Archimate e sua implementação como uma API.

Metamodelo BIAN na notação Archimate


Nesta parte, proponho considerar a estrutura atual do cenário BIAN na notação Archimate com base em um documento do OpenGroup . Este documento oferece opções para o desenvolvimento flexível, enxuto e estável da arquitetura bancária, usando as linguagens ArchiMate e BIAN.

Então, vamos começar com a descrição do metamodelo BIAN.

Elementos da paisagem BIAN



Figura 1. Sobreposição do cenário de serviço BIAN no metamodelo

O cenário de serviço BIAN é formado hierarquicamente a partir dos seguintes componentes básicos principais:
  • Área de Negócios - Verde
  • Domínio de Negócios (Área de Negócios) - Laranja;
  • Domínio de Serviço - Azul.

A área de negócios em termos de arquimate é expressa pelo elemento de agrupamento . O domínio comercial e o domínio de serviço são refletidos no diagrama pelo elemento Capability .
De acordo com as regras da notação, o Capability é usado para representar em alto nível os recursos atuais e desejados da organização em relação à sua estratégia.

A Área de Negócios (Área de Negócios) está posicionada no nível mais alto da hierarquia do cenário da BIAN e é usada para destacar e agrupar blocos de áreas-chave de desenvolvimento em instituições financeiras.
O BIAN identificou as seguintes áreas de negócios no modelo de referência do BIAN:
  1. data de referência;
  2. vendas e serviços;
  3. operações e execução;
  4. riscos e conformidade (+ análise);
  5. suporte de negócios.


Os arquitetos das áreas bancárias (Domínios de Negócios) das empresas bancárias definem como a decomposição da empresa bancária em um conjunto mutuamente exclusivo, na sua totalidade esgotando completamente as oportunidades de negócios da empresa. As áreas de negócios determinam os segmentos bancários considerados pelos arquitetos do negócio bancário do ponto de vista funcional, arquitetônico e técnico.

Um Domínio de Serviço é um componente básico elementar ou atômico funcional no cenário BIAN.
Cada domínio de serviço oferece um conjunto de serviços (grupo de serviços). Este conjunto inclui operações de serviço. Um domínio de serviço é um conjunto de operações de serviço que juntas gerenciam todo o ciclo de vida de um ativo (Tipo de ativo).

2. BIAN

Functional Pattern, Asset Type Action Term


A principal técnica usada para "isolar" o domínio de serviço BIAN (ou seja, para isolá-lo como uma unidade atômica e indivisível da paisagem) é aplicar um Padrão Funcional ao recurso (Tipo de Ativo).
Se observarmos a definição de elementos do Archimate, veremos que a Interação comercial é usada para o padrão funcional e um objeto comercial é usado para o tipo de ativo .

Tipo de ativo - qualquer coisa tangível ou intangível sobre a qual o banco tenha direito de propriedade e / ou influência e tenha um ou mais usos ou propósitos integrais que criem valor comercial.
Padrão funcional- um comportamento ou mecanismo que pode ser aplicado a qualquer recurso na realização de atividades comerciais (por exemplo, projetar, dirigir, gerenciar, registrar etc.)

Figura 3. Modelos funcionais dedicados O

BIAN também definiu um conjunto padrão de ações ( Termo da ação ) caracterizando vários tipos de operações de serviço. Cada operação de serviço executa exatamente uma ação.
Uma lista completa dos Termos de Ação (representados como funções de negócios do ArchiMate) é fornecida abaixo.

Figura 4. Conjunto de ações padrão ( Termo de Ação )

Um conjunto de ações (Termo de Ação), que juntos formam um tipo de comportamento repetitivo, é chamado de modelo funcional.
O padrão BIAN fornece uma matriz muito conveniente e intuitiva de comunicação entre padrões funcionais e operações padrão:

Figura 5. Comunicação de padrões funcionais e operações padrão

Isso é qual é a ideia principal? Podemos projetar e implementar praticamente qualquer atividade bancária por meio de um conjunto limitado e limitado de operações!
Cada domínio de serviço ao mesmo tempo contém apenas um modelo funcional principal com um tipo de recurso. E obtemos um recurso ao qual podemos aplicar este ou aquele modelo. Além disso, o número de modelos também certamente não é muito grande em comparação com o número de domínios de negócios no cenário!
Além disso, vemos no metamodelo BIAN que um modelo funcional que agrega um determinado conjunto de operações padrão e implementa as operações de serviço (indicadas em roxo abaixo) incluídas no grupo de serviços que também implementa a funcionalidade do domínio de serviço:

Figura 6. Relação de padrões funcionais e operações de serviço
E, como já explicamos acima, um conjunto de operações de serviço controla conjuntamente todo o ciclo de vida de um determinado recurso ( tipo de ativo ).
No total, obtemos a conexão: Domínio do Serviço - domínio do serviço (a funcionalidade necessária para os negócios) -> Tipo de Ativo - o recurso especificado do domínio do serviço (com o qual trabalharemos para implementar nossa tarefa, por exemplo, empréstimo hipotecário) -> Padrão Funcional - modelo funcional (comportamento que caracteriza ações com nosso recurso). "

Artefato genérico e registro de controle


Agora considere outro grupo de elementos de metamodelo, indicado na figura abaixo, realçando.

Figura 7. Registro geral de artefato e controle O
modelo funcional é um nível bastante alto de abstração (também fica claro no metamodelo que ele é implementado por operações de serviço mais específicas, mas falarei sobre isso mais tarde quando considerarmos a conexão usando um exemplo específico).
E assim, o artefato que afeta diretamente também é abstrato. É chamado de artefato genérico ( Artefato Genérico ). Para cada modelo funcional, o BIAN identificou um artefato comum, como mostrado abaixo:

Figura 8. Um conjunto de artefatos comuns

Entrada de Controle ( Registro de Controle) são as informações necessárias para resolver os problemas internos do domínio de serviço. Esse é um tipo de log de informações sobre o ciclo de vida de um recurso que é acessado por um modelo funcional de acordo com uma instância de um artefato comum ou como resultado do qual ele é criado.
Se, por exemplo, o recurso for "conta corrente", o modelo funcional for " cumprimento " e o artefato comum associado for " Obrigação ", o registro de Auditoria específico será "Obrigação de cumprir (tarefas para) a conta atual".
O nome do registro de auditoria é uma combinação do nome o recurso e o nome do artefato comum.O domínio de serviço "conta corrente" fornecerá serviços relacionados à "organização da execução da conta atual".
Um registro de controle pode ser considerado como informação sobre o ciclo de vida de um "recurso qualificado", em que o qualificador é um artefato comum.

Figura 9. Exemplo de domínio " conta atual "

Operações de serviço


"Operação de serviço" é uma ação específica executada em um determinado recurso. Este é um serviço elementar.
No exemplo " conta atual " da conta de serviço , o domínio do serviço pode executar "intiateCurrentAccountFulfillment", "executeCurrentAccountFulfillment" etc., que são os termos de ação agregados no modelo funcional e aplicados ao registro de controle.
Essa. se sobrepormos grupos de serviços em uma matriz com operações, ficará claro quais ações precisamos executar com nosso recurso:

Figura 10. Exemplo de sobreposição de termo de ação em um grupo de
serviços As operações de serviço para executar uma “conta atual” são derivadas das condições do modelo funcional. As operações de serviço são organizadas em grupos de serviços.

Mensagem e Condição


As operações de serviço são possíveis apenas através de interfaces claramente definidas. Cada operação de serviço requer que um evento possa "prestar" o serviço. Este evento será um tipo de mensagem chamada Mensagem de entrada . Uma operação de serviço será implementada através de algum processamento interno, possivelmente delegando algumas tarefas a outras operações de serviço. Como resultado, o serviço emitirá uma resposta como uma mensagem de saída. Uma mensagem que é uma mensagem de entrada para uma operação de manutenção pode ser uma mensagem de saída para outra operação de manutenção.


Figura 11. Mensagens de entrada / saída e condições de execução do serviço

O domínio do serviço também descreve dependências existentes em outros domínios.
Em particular, um exemplo de uma lista de domínios de serviço dos quais esperamos receber uma mensagem de entrada:

Figura 12. Um exemplo de comunicação com outros domínios para o

total de “Conta corrente” , examinamos todos os elementos do metamodelo BIAN. E é hora de avançar para a implementação do modelo BIAN na API. Mas antes de fazer isso, quero chamar a atenção para o fato de o modelo conter muito mais representações de sua descrição. Existem descrição de objetos, diagramas de sequência, wireframes e outros.
Convido os leitores a se familiarizarem com eles por referência .
E também com uma comparação do modelo e estrutura do Togaf .

Implementando o modelo BIAN via API


Como mencionado acima, a comunidade de desenvolvedores BIAN desenvolve e reabastece regularmente o repositório de serviços REST que cumprem os princípios do padrão BIAN.
Para conhecimento, é necessário registrar-se no portal , acessar o repositório e fazer o download dos arquivos de origem ou acessar o console para familiarização.

Figura 13. Exemplo de navegação no API BIAN do repositório

No modo do console, pode ler a documentação no Swagger:

Figura 14. Exemplo do repositório BIAN da API de Navegação para o domínio de serviço da Conta Corrente
para trabalhar com o código:

Figura 15. Acesso ao BIAN de armazenamento de arquivos da API original

Para simplificação entendendo como usar as APIs, você pode ler o documento. Convido leitores e desenvolvedores a já dominarem essa parte do trabalho com a BIAN de forma independente ou a participar de um webinar, que será realizado em um futuro próximo, onde haverá uma oportunidade de obter informações em primeira mão e fazer perguntas no final do webinar .
O conteúdo principal será apresentado no webinar e as alterações, melhorias e extensões introduzidas no padrão BIAN na última edição serão destacadas.

Possível abordagem para a aplicação da norma


Descreverei a abordagem de nível superior do uso do modelo de referência BIAN:
A principal coisa que você deve prestar atenção é que o modelo sugere não usar uma abordagem de processo, mas uma abordagem de microsserviço.
  1. Essa. o cenário é um determinado conjunto de blocos de alto nível (domínios de serviço),
  2. cada domínio possui seu próprio conjunto de ferramentas (operações de serviço)
  3. para trabalhar com certos artefatos (recursos).

E já estamos montando o processo que precisamos desses tijolos. Mas também somos ajudados nisso pelo conjunto já projetado de diagramas de seqüência, wireframes, modelo de objeto.
Essa. através dessas representações para muitos processos de comunicação já foram projetados.

É possível para a empresa:
1. estudar a paisagem em detalhes, destacá-la visualmente (em cores, molduras ou de outra forma) os domínios necessários para sua finalidade funcional (é possível sobrepor e entender o nível do sistema em que sistemas os dados são duplicados, Por exemplo, esta é uma das questões difíceis, na minha opinião, que surgem ao projetar uma arquitetura de microsserviço, e o modelo BIAN sugere que pensemos nisso no nível de negócios).
2. Estude o metamodelo BIAN para entender como cada domínio funciona (espero que isso ajude minha revisão, o que fiz acima no metamodelo).
3. Faça o download das APIs necessárias no portal (ou primeiro verifique se o conjunto necessário já está presente).
4. Explore outras representações do modelo BIAN.
4. Desenhe um mapa de migração levando em consideração a arquitetura atual da empresa para sua transição para o microsserviço.

Arquiteto de sistemas,
© Irina Blazhina

All Articles