🙏🏻 👨🏿‍🚒 👰🏾 Modelo de referencia BIAN. ¿Qué novedades y útiles para la arquitectura corporativa del banco ofrece? 😺 💣 👨🏾‍🏫

BIAN ... qué poco hay en este sonido para el corazón de un ruso ... Sí, no fue por casualidad que parafraseé el famoso clásico. En Rusia, la popularidad del modelo de referencia BIAN sigue siendo baja, especialmente en comparación con el modelo de Mapa de Operaciones de Telecomunicaciones Mejoradas (eTOM), que está muy extendido en la industria de las telecomunicaciones, que está por delante de su desarrollo. Mientras tanto, el modelo BIAN se está desarrollando, mejorando y ganando popularidad fuera de Rusia y en la comunidad de la industria bancaria internacional.

Ya no distraeré al lector con digresiones líricas, solo diré que una revisión del modelo BIAN y los documentos adjuntos de la norma se encuentran en mi primer artículo sobre BIAN, aquí trataré de decir cómo BIAN puede ser útil para gerentes de negocios, arquitectos de negocios, arquitectos corporativos, arquitectos de soluciones, especialistas de TI y todas las demás personas interesadas en administrar toda la arquitectura de una empresa financiera. Y también sobre sus transformaciones útiles clave, en mi opinión.

¿Qué hay de nuevo e interesante?

BIAN se ha vuelto más asequible

Uno de los cambios más importantes y cardinales que sucedió con el modelo de referencia BIAN , en mi opinión, fue su traducción a la notación Archimate . Se ha vuelto más fácil de leer. Los desarrolladores de BIAN, al parecer, no pudieron evitar reconocer la necesidad de utilizar la notación estándar para describirla y poder difundirla en círculos profesionales . El modelo de percepción se ha vuelto más claro para los arquitectos, ya que se describe en un lenguaje que es comprensible para los arquitectos. Por lo tanto, la versión de BIAN 8.0 se presenta en el lenguaje de ArchiMate 3 . El modelo es de dominio público . Al registrarse en www.opengroup.org , todos pueden independientementeDescargue una descripción del modelo BIAN y todos sus componentes en notación Archimate.

Implementación de BIAN en API

Otro punto importante que vale la pena mencionar es que la Asociación de Normas Independientes sin Fines de Lucro ( Banking Industry Architecture Network (BIAN) ) mantiene y actualiza el repositorio de API para sus dominios comerciales de paisaje.
Los desarrolladores de BIAN tienen como objetivo crear un repositorio asequible de API y microservicios de alta calidad para ayudar a los bancos a actualizar de manera rápida y rentable.
Los archivos de origen para la API del repositorio también se publican y están disponibles para su descarga después del registro en el portal (si alguien tiene dificultades para registrarse, intente registrarse en el modo de incógnito de su navegador).

A continuación, examinaremos con más detalle el metamodelo BIAN en notación Archimate y su implementación como API.

Metamodelo BIAN en notación Archimate

En esta parte, propongo considerar la estructura actual del paisaje BIAN en notación Archimate basada en un documento de OpenGroup . Este documento ofrece opciones para un desarrollo flexible, ágil y estable de la arquitectura bancaria utilizando los lenguajes ArchiMate y BIAN.

Entonces, comencemos con la descripción del metamodelo BIAN.

Elementos del paisaje BIAN

Figura 1. Superposición del paisaje de servicio BIAN en el metamodelo

El paisaje de servicio BIAN se forma jerárquicamente a partir de los siguientes componentes básicos clave:

Área Comercial - Verde
Dominio Comercial (Área Comercial) - Naranja;
Dominio de servicio: azul.

El área de negocio en términos de Archimate se expresa mediante el elemento Agrupación . El dominio de negocio y el dominio de servicio se reflejan en el diagrama mediante el elemento de capacidad .
De acuerdo con las reglas de notación, la capacidad se utiliza para representar a un alto nivel las capacidades actuales y deseadas de la organización en relación con su estrategia.

El área de negocios (Área de negocios) se posiciona en el nivel más alto de la jerarquía del paisaje BIAN y se utiliza para resaltar y agrupar en bloques de áreas clave de desarrollo en las instituciones financieras.
BIAN identificó las siguientes áreas de negocio dentro del modelo de referencia de BIAN:

dato de referencia;
ventas y servicio;
operaciones y ejecución;
riesgos y cumplimiento (+ análisis);
soporte empresarial.

Los arquitectos de áreas de negocio (Business Domains) de empresas bancarias definen como la descomposición del negocio bancario en un conjunto de negocios mutuamente excluyentes, en su totalidad agotando por completo las oportunidades comerciales de la empresa. Las áreas de negocio determinan los segmentos bancarios considerados por los arquitectos del negocio bancario desde un punto de vista funcional, arquitectónico y técnico.

Un dominio de servicio es un bloque de construcción funcional elemental o atómico dentro del paisaje BIAN.
Cada dominio de servicio ofrece un conjunto de servicios (Grupo de servicio). Este conjunto incluye operaciones de servicio. Un dominio de servicio es un conjunto de operaciones de servicio que juntas administran el ciclo de vida completo de un activo (Tipo de activo).

2. BIAN

Functional Pattern, Asset Type Action Term

La técnica principal utilizada para "aislar" el dominio de servicio BIAN (es decir, distinguirlo como una unidad atómica e indivisible del paisaje) es aplicar un Patrón Funcional a un recurso (Tipo de Activo).
Si observamos la definición de elementos Archimate, veremos que Business Interaction se usa para el Patrón Funcional , y un objeto comercial se usa para el Tipo de activo .

Tipo de activo : cualquier cosa tangible o intangible sobre la cual el banco tiene el derecho de propiedad y / o influencia, y tiene uno o más usos o propósitos integrales que crean valor comercial.
Patrón funcional- un comportamiento o mecanismo que se puede aplicar a cualquier recurso en la realización de actividades comerciales (por ejemplo, diseñar, dirigir, administrar, registrar, etc.)

Figura 3. Plantillas funcionales dedicadas

BIAN también definió un conjunto estándar de acciones ( Término de acción ) caracterizando varios tipos de operaciones de servicio. Cada operación de servicio realiza exactamente una acción.
A continuación se proporciona una lista completa de los términos de acción (representados como funciones comerciales de ArchiMate).

Figura 4. Conjunto de acciones estándar ( Término de acción )

Un conjunto de acciones (Término de acción), que juntas forman un tipo de comportamiento repetitivo, se denomina plantilla funcional.
El estándar BIAN proporciona una matriz muy conveniente e intuitiva de la relación de patrones funcionales y operaciones estándar:

Figura 5. Relación de patrones funcionales y operaciones estándar

Es decir ¿Cuál es la idea principal? ¡Podemos diseñar e implementar casi cualquier actividad bancaria a través de un conjunto limitado de operaciones!
Cada dominio de servicio al mismo tiempo contiene solo una plantilla funcional principal con un tipo de recurso. Y obtenemos un recurso al que podemos aplicar esta o aquella plantilla. ¡Además, la cantidad de plantillas tampoco es muy grande en comparación con la cantidad de dominios comerciales en el panorama!
Además, vemos en el metamodelo BIAN que una plantilla funcional que agrega un cierto conjunto de operaciones estándar e implementa las operaciones de servicio (indicadas en púrpura a continuación) incluidas en el grupo de servicio que también implementa la funcionalidad del dominio de servicio:

Figura 6. Relación de patrones funcionales y operaciones de servicio
Y, como ya explicamos anteriormente, un conjunto de operaciones de servicio controlan conjuntamente el ciclo de vida completo de un determinado recurso ( Tipo de activo ).
En total, obtenemos la conexión: Dominio de servicio: dominio de servicio (la funcionalidad que necesitamos para los negocios) -> Tipo de activo: el recurso especificado del dominio de servicio (con el que trabajaremos para implementar nuestra tarea, por ejemplo, préstamo hipotecario) -> Patrón funcional - plantilla funcional (comportamiento que caracteriza las acciones con nuestro recurso) ".

Registro genérico de artefactos y control

Ahora considere otro grupo de elementos de metamodelo, indicado en la figura a continuación resaltando.

Figura 7. Artefacto general y registro de control La
plantilla funcional es un nivel bastante alto de abstracción (también está claro por el metamodelo que se implementa mediante operaciones de servicio más específicas, pero hablaré de esto más adelante cuando consideremos la conexión usando un ejemplo específico).
Y así, el artefacto que afecta directamente también es abstracto. Se llama artefacto genérico (artefacto genérico ). Para cada plantilla funcional, BIAN identificó un artefacto común, como se muestra a continuación:

Figura 8. Un conjunto de artefactos comunes

Entrada de control ( Registro de control) es la información necesaria para resolver los problemas internos del dominio de servicio. Este es un tipo de registro de información sobre el ciclo de vida de un recurso al que se accede mediante una plantilla funcional de acuerdo con una instancia de un artefacto común o como resultado de lo cual se crea.
Si, por ejemplo, el recurso es "cuenta corriente", la plantilla funcional es " cumplimiento " y el artefacto común asociado es " Obligación ", entonces el registro de Auditoría específico es "Obligación de cumplir (tareas para) la cuenta corriente".
El nombre del registro de auditoría es una combinación del nombre el recurso y el nombre del artefacto común. El dominio de servicio "cuenta corriente" proporcionará servicios relacionados con la "organización de la ejecución de la cuenta corriente".
Un registro de control se puede considerar como información sobre el ciclo de vida de un "recurso calificado", donde el calificador es un artefacto común.

Figura 9. Ejemplo de dominio " cuenta corriente "

Operaciones de servicio

La "operación de servicio" es una acción específica realizada en un recurso dado. Este es un servicio elemental.
En el ejemplo de " cuenta corriente " de la cuenta de servicio, el dominio de servicio puede ejecutar "intiateCurrentAccountFulfillment", "executeCurrentAccountFulfillment", etc., que son los términos de acción agregados en la plantilla funcional y aplicados al registro de control.
Aquellos. si superponemos grupos de servicios en una matriz con operaciones, quedará claro qué acciones debemos realizar con nuestro recurso:

Figura 10. Ejemplo de superposición de un término de acción en un grupo de
servicios Las operaciones de servicio para ejecutar una "cuenta corriente" se derivan de las condiciones de la plantilla funcional. Las operaciones de servicio se organizan en grupos de servicio.

Mensaje y condición

Las operaciones de servicio solo son posibles a través de interfaces claramente definidas. Cada operación de servicio requiere un evento para poder "entregar" el servicio. Este evento será un tipo de mensaje llamado Mensaje entrante . Una operación de servicio se implementará mediante algún procesamiento interno, posiblemente delegando algunas tareas a otras operaciones de servicio. Como resultado, el servicio emitirá una respuesta como mensaje saliente. Un mensaje que es un mensaje de entrada para una operación de mantenimiento puede ser un mensaje de salida para otra operación de mantenimiento.

Figura 11. Mensajes entrantes / salientes y condiciones de ejecución del servicio

El dominio de servicio también describe las dependencias existentes en otros dominios.
En particular, un ejemplo de una lista de dominios de servicio de los cuales esperamos recibir un mensaje entrante:

Figura 12. Ejemplo de comunicación con otros dominios para el

total de "Cuenta corriente" , examinamos todos los elementos del metamodelo BIAN. Y es hora de pasar a la implementación del modelo BIAN en la API. Pero antes de hacer esto, quiero llamar la atención sobre el hecho de que el modelo contiene muchas más representaciones de su descripción. Hay descripciones de objetos, diagramas de secuencia, estructuras de alambre y otros.
Invito a los lectores a familiarizarse con ellos por referencia .
Y también con una comparación del modelo y marco de Togaf .

Implementación del modelo BIAN a través de API

Como se mencionó anteriormente, la comunidad de desarrolladores de BIAN desarrolla y repone regularmente el repositorio de servicios REST que cumplen con los principios del estándar BIAN.
Para conocerlo, es necesario registrarse en el portal , ir al repositorio y descargar los archivos de origen o ir a la consola para familiarizarse.

Figura 13. Ejemplo de navegación a través del repositorio API BIAN

En modo consola puede leer la documentación en Swagger:

Figura 14. Ejemplo de repositorio API BIAN de navegación para el dominio de servicio Cuenta corriente
para trabajar con código:

Figura 15. Acceso al almacenamiento original del archivo API BIAN

Para simplificar entendiendo cómo usar las API, puede leer el documento. Invito a los lectores y desarrolladores a que dominen esta parte del trabajo con BIAN de forma independiente, o que participen en un seminario web, que se realizará en un futuro cercano, donde habrá una oportunidad de obtener información de primera mano y hacer preguntas al final del seminario web .
El contenido principal se presentará en el seminario web y se resaltarán los cambios, mejoras y extensiones introducidos al estándar BIAN en la última edición.

Posible enfoque para la aplicación de la norma.

Describiré el enfoque de nivel superior del uso del modelo de referencia BIAN:
Lo principal a lo que debe prestar atención es que el modelo sugiere no usar un enfoque de proceso, sino uno de microservicio.

Aquellos. el panorama es un cierto conjunto de ladrillos de alto nivel (dominios de servicio),
cada dominio tiene su propio conjunto de herramientas (operaciones de servicio)
para trabajar con ciertos artefactos (recursos).

Y ya estamos armando el proceso que necesitamos de estos ladrillos. Pero también nos ayuda en esto el conjunto ya diseñado de diagramas de secuencia, estructuras alámbricas y modelo de objetos.
Aquellos. a través de estas representaciones para muchos procesos de comunicación ya se han diseñado.

Es posible que la empresa:
1. estudie el paisaje en detalle, resalte visualmente (en color, marcos o de otra manera) aquellos dominios que necesita para su propósito funcional (es posible superponer y comprender el nivel del sistema en el que se duplican los datos, Por ejemplo, esta es una de las preguntas difíciles, en mi opinión, que surge al diseñar una arquitectura de microservicio, y el modelo BIAN sugiere que lo pensemos a nivel comercial).
2. Estudiar el metamodelo BIAN para comprender cómo funciona cada dominio (espero que esto ayude a mi revisión, que hice anteriormente en el metamodelo).
3. Descargue las API necesarias del portal (o primero asegúrese de que el conjunto requerido ya esté presente).
4. Explore otras representaciones del modelo BIAN.
4. Dibuje un mapa de migración teniendo en cuenta la arquitectura actual de la empresa para su transición al microservicio.

Arquitecto de sistemas,
© Irina Blazhina

Modelo de referencia BIAN. ¿Qué novedades y útiles para la arquitectura corporativa del banco ofrece?