BIAN How To Guide Introduction To BIAN V6.0 Final V1.0

Machine Translated by Google
Industria Bancaria
Red de Arquitectura
BIAN
Como guiar
Introducción a BIAN
Introducción a BIAN V6.0 Guía práctica
Organización
Autores
Role Nombre Compañía

BIAN Arquitecto chico rackham BIAN
Estado
Estado Fecha Actor Comentario / Referencia
BORRADOR enero 2018 Reestructurar, Cifras
Aprobado Comité Arquitectónico
Versión
No Comentario / Referencia Fecha
6.0 Primera versión editada enero 2018
Página 2 de 24 © 2018 BIAN eV | Apartado de correos 16 02 55 | 60065 Fráncfort del Meno | Alemania
Derechos de autor
© Copyright 2018 por la Asociación BIAN. Reservados todos los derechos.
ESTE DOCUMENTO SE PROPORCIONA "TAL CUAL", Y LA ASOCIACIÓN Y SUS MIEMBROS NO OFRECEN
DECLARACIONES NI GARANTÍAS, EXPRESAS O IMPLÍCITAS, INCLUIDAS, ENTRE OTRAS, GARANTÍAS DE
COMERCIABILIDAD, IDONEIDAD PARA UN FIN DETERMINADO, NO VIOLACIÓN O TÍTULO; QUE LOS CONTENIDOS DE
ESTE DOCUMENTO SON APTOS PARA CUALQUIER FIN; O QUE LA IMPLEMENTACIÓN DE DICHOS CONTENIDOS NO
INFRINGIRÁ NINGUNA PATENTE, DERECHOS DE AUTOR, MARCAS COMERCIALES U OTROS DERECHOS.
NI LA ASOCIACIÓN NI SUS MIEMBROS SERÁN RESPONSABLES DE CUALQUIER DAÑO DIRECTO, INDIRECTO,
ESPECIAL, INCIDENTAL O CONSECUENTE QUE SURJA O ESTÉ RELACIONADO CON CUALQUIER USO O
DISTRIBUCIÓN DE ESTE DOCUMENTO A MENOS QUE DICHOS DAÑOS SEA OCASIONADOS POR MALA CONDUCTA
INTENCIONAL O NEGLIGENCIA GRAVE.
LA RENUNCIA ANTERIOR Y LA LIMITACIÓN DE RESPONSABILIDAD NO SE APLICAN A LAS DECLARACIONES Y
GARANTÍAS HECHAS POR LOS MIEMBROS A LA ASOCIACIÓN Y OTROS MIEMBROS EN CIERTAS POLÍTICAS
ESCRITAS DE LA ASOCIACIÓN, NI LAS ANULAN NI LIMITAN.
© 2018 BIAN eV | Apartado de correos 16 02 55 | 60065 Fráncfort del Meno | Alemania Página 3 de 24
Tabla de contenido
1 La guía práctica de BIAN ........................................... .................................................... .. 6
1.1 Introducción a BIAN ............................................... .................................................... 6
1.2 La guía práctica de BIAN: contenido ........................................... ............................... 7
1.3 Un enfoque diferente a un problema bien establecido ........................................... ....... 8
2 Guía práctica de BIAN Principios y técnicas de diseño ........................................... .....12
2.1 Introducción al documento ............................................... .............................................12
2.1.1 Particiones de capacidad empresarial ........................................... .............................12
2.1.2 Modelado de comportamientos del mundo real .................................. ..........................13
2.1.3 El estándar BIAN se puede interpretar en diferentes situaciones .........................14
3 Guía práctica de BIAN: desarrollo de contenido.................................... .......................dieciséis
3.1 Introducción al documento ............................................... ..............................................dieciséis
3.1.1 El estándar BIAN se captura en el marco SOA de BIAN ..........................17
3.1.2 El comportamiento empresarial se modela utilizando dominios de servicio ..........................17
3.1.3 Interacciones de dominio de servicio.................................... ..........................19
4 Guía práctica de BIAN: aplicación del estándar BIAN ....................................... ..........21
4.1 Introducción al documento ............................................... .............................................21
4.1.1 Uso de las especificaciones BIAN como un diseño de implementación de alto nivel ..........21
4.1.2 Elaboración de un modelo de empresa representativa........................................... 22
4.1.3 Un modelo empresarial es un marco para el análisis ........................................... 23
Tabla de Figuras
Figura 1: Comparación de la planificación comercial y urbana.................................... .............................
9 Figura 2: Edificio sin plano barrio marginal y cartera de aplicaciones ....... ....................... 10
Figura 3: Migración a un mapa de aplicaciones bien diseñado .................. ......................................10
Figura 4: Principios y técnicas de diseño ..... .................................................... ...........12 Figura 5:
Desarrollo de contenido ........................... .................................................... .....................16 Figura
6: Aplicación del estándar BIAN ........................... .................................................... ..........21
1 La guía práctica de BIAN
1.1 Introducción a BIAN
La Red de Arquitectura de la Industria Bancaria (BIAN) es una asociación de bancos, proveedores
de soluciones e instituciones educativas con el objetivo compartido de definir un estándar de
operación de servicios semánticos para la industria bancaria. La expectativa de BIAN es que una definición
estándar de las funciones comerciales y las interacciones de servicio que describen el funcionamiento
interno general de cualquier banco será un beneficio significativo para la industria. En comparación con
una proliferación de diseños patentados, dicho estándar de la industria proporciona los siguientes
beneficios principales:

permite el desarrollo y la integración más eficiente y eficaz de soluciones de software para
bancos
mejora la eficiencia operativa dentro de los bancos y brinda la oportunidad de una mayor reutilización
de soluciones y capacidades dentro y entre los bancos; apoya la adopción de modelos de

abastecimiento de servicios comerciales más flexibles y mejora la evolución y adopción de servicios
comerciales compartidos de terceros
BIAN se refiere a la colección de diseños que conforman su estándar industrial como BIAN Service
Landscape. El desarrollo de BIAN Service Landscape es iterativo y se basa en la contribución activa de
los participantes de la industria para generar consenso y fomentar la adopción. BIAN coordina la evolución
del panorama de servicios de BIAN en nombre de sus miembros con lanzamientos regulares de versiones
para la industria y busca comentarios para ayudar a expandir y refinar continuamente su contenido.
Los principales documentos BIAN que componen el estándar BIAN incluyen:
• El mapa de referencia BIAN de alto nivel: el panorama de servicios de BIAN (y
definiciones de dominio de servicio compatibles)
• La serie de guías prácticas de BIAN (una colección de documentos dirigidos a diferentes
audiencias) • El metamodelo de BIAN y la definición de apoyo • Definiciones de
escenarios comerciales de BIAN • Definiciones de dominios de servicios de BIAN y sus
operaciones de servicios semánticos • El vocabulario comercial de BIAN • El objeto
comercial emergente de BIAN Modelo
El estándar BIAN se publica en un repositorio UML, cuya versión HTML de solo lectura está disponible
gratuitamente en el sitio web de BIAN (https://bian.org/). Además, se mantiene y publica una colección de
documentos de respaldo con cada versión publicada del estándar BIAN, incluida esta serie de 'Guías
prácticas'.
Tenga en cuenta que los miembros a menudo se refieren a la colección de documentos de diseño de
BIAN como el "Panorama de servicios de BIAN". El nombre más formal es BIAN SOA Framework y se
describe más detalladamente en el segundo documento de BIAN 'How to Guide Developing Content'.
El siguiente proceso está en marcha para recibir y procesar sus comentarios:
1. Se alienta a los miembros de BIAN a proporcionar comentarios mediante el uso de BIAN
Wiki, al Comité Arquitectónico, al Equipo de Paisajismo de Servicio o a través de su
Representantes de grupos de trabajo
2. Se invita a los no miembros a publicar sus sugerencias utilizando nuestro sitio web
www.bian.org 3.
Los comentarios también se pueden publicar en howto.guide@bian.org
1.2 La guía práctica de BIAN Contenido
La Guía práctica de BIAN describe las prácticas de trabajo de BIAN. Se presenta como una serie de tres
documentos de referencia principales además de este documento de introducción y descripción general:
Guía práctica de BIAN: principios y técnicas de diseño : está destinada a arquitectos comerciales y
técnicos. Explica la teoría y las prácticas de diseño para aquellos que deseen comprender y revisar el
enfoque BIAN.
Guía práctica de BIAN: desarrollo de contenido : está destinada a los miembros del grupo de
trabajo de BIAN. Explica el enfoque de trabajo actual y las diversas herramientas y plantillas utilizadas
para capturar el contenido estándar de BIAN.
Guía práctica de BIAN: aplicación del estándar BIAN : está destinada a miembros y otras instituciones
financieras que deseen aplicar el contenido de diseño de BIAN en diversas situaciones de
implementación técnica.
Cada documento se dirige a un público específico. Esta introducción resume los objetivos del estándar BIAN y
proporciona un contexto general para revisar los documentos más detallados. También presenta un resumen de
los tres documentos principales de la serie para que diferentes audiencias puedan identificar el documento correcto
para revisar según sus necesidades particulares.
Con el lanzamiento de la versión 6.0, se ha publicado una guía relacionada adicional:
Guía práctica de la API semántica de BIAN : describe cómo se puede usar el estándar BIAN y el
contenido relacionado para proporcionar diseños de alto nivel para el desarrollo de la interfaz de
programación de aplicaciones (API). Se planea publicar una guía práctica para desarrolladores en breve.
Descargo de responsabilidad
La Guía práctica de BIAN es una colección de documentos de trabajo que BIAN mantiene para reflejar los
principios, técnicas y enfoques de diseño actuales que utilizan los miembros de BIAN. El contenido de la 'Guía
práctica' de BIAN se actualiza con cada versión principal a medida que se obtienen nuevos conocimientos y se
mejoran las prácticas de trabajo dentro de BIAN.
BIAN no certifica la exactitud o idoneidad de estos documentos para ningún propósito específico. Las
guías son documentos informales que se publican para respaldar y explicar el estándar BIAN y para
buscar comentarios/retroalimentación constructivos de la industria.
1.3 Un enfoque diferente a un problema bien establecido
Muchos participantes de la industria bancaria, incluidos los miembros fundadores de BIAN, han
observado con frecuencia un problema común y persistente: la complejidad excesiva en las carteras de
aplicaciones de la mayoría de los bancos. Esta complejidad da como resultado sistemas inflexibles/que
no responden, mejoras infladas, mantenimiento y costos operativos; y la incapacidad de aprovechar
soluciones, tecnologías, enfoques y modelos comerciales avanzados que evolucionan rápidamente.
BIAN se dispuso a abordar este problema mediante el desarrollo de un estándar industrial común
para definir particiones funcionales y operaciones de servicio que podrían usarse dentro de cualquier banco
con los beneficios anticipados ya señalados. Sin embargo, el objetivo de BIAN plantea una pregunta clave:
¿por qué el modelo y el enfoque de BIAN deberían ser mejores que los intentos anteriores de abordar la
complejidad de la cartera de aplicaciones?
En el centro de la propuesta de BIAN está la adopción de un enfoque orientado a la capacidad para
diseñar los sistemas que respaldan al banco. Este enfoque es fundamentalmente diferente de los diseños
predominantes 'centrados en el proceso'. Para subrayar esta diferencia crítica, se puede hacer una
comparación con las disciplinas arquitectónicas cuando se aplican al problema altamente tangible de
diseñar el diseño de una ciudad en oposición al diseño mucho menos tangible de una empresa comercial
como un banco.
Cualquier diseño es una combinación de los ingredientes que se utilizan y los comportamientos que el
diseño pretende respaldar. Los ingredientes se relacionan con cosas estáticas o persistentes que se
"despliegan" y los comportamientos se refieren a patrones más dinámicos de respuestas deseadas a
eventos anticipados o desencadenantes. Un arquitecto desarrolla un diseño general basado en la
comprensión de cómo deben configurarse los ingredientes para respaldar los comportamientos previstos.
En el caso del urbanista se trata de un plano urbanístico.
Los ingredientes que se ven en el plan de la ciudad son los edificios, los parques y la infraestructura de
comunicaciones que debe existir para respaldar los comportamientos previstos de los habitantes de la
ciudad. Estos comportamientos podrían rastrearse como viajes o 'días en una vida' en el plano de la ciudad.
La comparación de la arquitectura de edificios tal como la practica el planificador urbano y la
arquitectura comercial que podría usarse para diseñar las aplicaciones de un banco revela una
importante deficiencia en el arsenal de herramientas para los arquitectos comerciales. Esto se ilustra en
la siguiente figura.
'INGREDIENTES' 'COMPORTAMIENTOS'
Tipos de edificios Los arquitectos seleccionan los Trabajo y Educación

Parques y plazas ingredientes necesarios y los configuran Entretenimiento y Deportes
Transporte Servicios Compras Salud y
para respaldar los comportamientos
públicos etc… Servicios etc….
previstos para crear un "plan de ciudad".
3
ARQUITECTURA DEL EDIFICIO
Empleados, Socios, Sin una manera fácil de capturar y asociar Procesos de negocio

Clientes Activos los ingredientes con los comportamientos
Líquidos y Financiamiento
Edificios y Equipos
Conocimiento/Knowhow
? anticipados, no existe un 'plan empresarial'
equivalente
etc…
NEGOCIO
ARQUITECTURA
?
Figura 1: Comparación de planificación empresarial y urbana
Los ingredientes que componen el banco no son cosas tangibles como edificios y carreteras, son
las capacidades comerciales mucho menos tangibles que un banco debe establecer para poder ejecutar
negocios. Los comportamientos que se modelan como recorridos por la ciudad son los procesos de
negocio que soporta el banco. Los arquitectos de negocios tienen una amplia experiencia en el modelado
de procesos, pero solo de forma aislada. La brecha para el arquitecto comercial es definir los bloques de
construcción de capacidades genéricas que seleccionaría y configuraría para crear el plan de ciudad
equivalente para el banco. Estas capacidades, en diferentes combinaciones y secuencias, luego
respaldarían esos procesos más familiares.
El resultado de construir en una ciudad sin un plan urbanístico rector es un barrio de chabolas: los
edificios y las carreteras se construyen cuando se necesitan. Con el tiempo el caos es inevitable. Sin
un plan de ciudad para el negocio, los sistemas creados para satisfacer las necesidades inmediatas
de los procesos, tal como son hoy, eventualmente conducen al mismo caos inevitable en términos de
aplicaciones superpuestas y redundantes, como se muestra en la figura a continuación.
Figura 2: Edificio sin plano barrio marginal y cartera de aplicaciones
El problema de la complejidad de las aplicaciones va mucho más allá del problema obvio de la redundancia
en las aplicaciones superpuestas. Se agrava mucho cuando las aplicaciones tienen que interactuar entre
sí. Cada aplicación tiene su propio alcance y límite específicos y cada conexión punto a punto es única. A
medida que la cartera de aplicaciones crece a varios cientos de sistemas superpuestos, no sorprende que
agregar o mejorar cualquier sistema se convierta en un ejercicio para rastrear estas dependencias altamente
complejas.
Las particiones funcionales del estándar BIAN definen bloques de construcción de capacidad
comercial discretos que no se superponen. El panorama de servicios de BIAN busca identificar todas las
posibles particiones de capacidad empresarial 'elementales' que podrían constituir cualquier banco. Un
plan para una parte o la totalidad de un banco ensamblado con las particiones BIAN crea el mismo plan de
organización que el plan de la ciudad, eliminando superposiciones y definiendo conexiones estándar. La
siguiente figura muestra cómo BIAN anticipa que a medida que se establezca y adopte el estándar, los
bancos podrán racionalizar progresivamente sus carteras de aplicaciones para eliminar la redundancia y la
complejidad operativa asociada.
La visión La realidad El futuro
Figura 3: Migración a un mapa de aplicaciones bien diseñado
La serie 'Guía práctica' de BIAN explica en detalle el enfoque de BIAN para la arquitectura orientada
a servicios (SOA). En particular, explica cómo los bancos pueden adoptar un enfoque basado en
servicios de manera incremental, enfocándose en aquellas áreas donde la complejidad existente limita
más el negocio o donde se necesitan sistemas más flexibles y receptivos para explotar nuevas
oportunidades comerciales. Más recientemente, el estándar BIAN
y su perspectiva sobre una arquitectura orientada a servicios se ha considerado en el contexto de la
especificación de interfaces de programación de aplicaciones (API) estándar y la adopción de
arquitecturas de microservicios.
2 Guía práctica de BIAN Principios y técnicas de diseño
2.1 Introducción al documento
BIAN ha desarrollado un enfoque para el diseño de la arquitectura empresarial que identifica las
particiones de capacidad empresarial y las operaciones de servicio asociadas que se pueden seleccionar y
ensamblar para modelar cualquier banco (o institución financiera). Los diseños de BIAN son 'canónicos', lo
que significa que cualquier banco puede interpretarlos de forma consistente en muchas situaciones de
implementación diferentes. Para definir diseños canónicos, el enfoque BIAN debe ser fundamentalmente
diferente de las técnicas más tradicionales que adoptan diseños orientados a procesos. BIAN utiliza un tipo
específico de Arquitectura Orientada a Servicios (SOA)
Este documento describe los conceptos clave de diseño y las técnicas empleadas en el
enfoque BIAN como se establece en la siguiente figura:
BIAN ha definido un enfoque novedoso para
definir los estándares SOA canónicos
El enfoque aísla capacidades comerciales Las definiciones de dominio de servicio se Hay un camino claro para aplicar los

discretas y elementales denominadas prueban usándolas para modelar diseños específicos de BIAN en la
dominios de servicio BIAN. situaciones comerciales del mundo real. práctica
1 – de BIAN 3 – Las particiones BIAN 3 – Todo el servicio 3 – Un plan de

1 – Todos los servicios 1 – El modelo específico
El enfoque orientado a la deben definirse a un nivel de BIAN puede ser negocios de BIAN admite
El dominio tiene un los intercambios se
capacidad difiere de los elemental para ser canónicas muchos análisis: 3.1
patrón de trabajo estándar definen en términos asignado a otras vistas
modelos de procesos arquitectónicas Desempeño 3.2 Cobertura
semánticos
convencionales . 3.3. Atribución
2 – UN BIAN 2 – Los diseños
2 – Todo negocio
pueden estar
partición de capacidad la actividad se puede
relacionados con diferentes técnicas
combina un tipo de 'activo' representar utilizando
con un 'patrón' específico entornos de
intercambios de servicios implementación
de uso entre Service
2.1 Core/Host/
Dominios
Legacy 2.2 ESB
habilitado
2.3.Cloud/Microservi
ce
Figura 4: Principios y técnicas de diseño
Como se muestra en esta figura, los principios y técnicas de diseño de BIAN se explican en tres secciones
principales:
2.1.1 Particiones de capacidad comercial El enfoque
de BIAN se basa en dividir toda la actividad bancaria en una colección de bloques de construcción de
capacidad comercial discretos llamados dominios de servicio BIAN. La colección de dominios de servicio de
BIAN pretende ser integral para que todas y cada una de las actividades comerciales puedan ser respaldadas
por una selección adecuada de dominios de servicio que interactúen a través de sus operaciones de servicio
asociadas. Esta sección tiene tres subsecciones para explicar completamente el concepto de dominio de
servicio BIAN:
1. Comparación de la vista de capacidad de BIAN con una representación de procesos : más
los modelos comerciales convencionales utilizan una descripción de proceso de la actividad. Una
vista de proceso representa la actividad comercial como una serie vinculada de pasos (predefinidos) o
tareas que se resuelven para llegar a un objetivo específico. BIAN modela la misma actividad
comercial mediante la identificación de bloques de construcción de capacidad comercial discretos
que deben participar sin prescribir ninguna secuencia específica de interacción.
Se puede hacer una analogía considerando la ruta y la planificación urbana de una ciudad. Un
proceso comercial es similar a trazar una ruta a través de la ciudad. Los bloques de construcción
de capacidad empresarial de BIAN son equivalentes al plano de la ciudad que muestra todos los
diferentes tipos de edificios e infraestructura que serían 'visitados' o 'involucrados' en este (y de
hecho cualquier posible) viaje.
2. Un dominio de servicio BIAN combina un activo y un uso : la técnica utilizada para aislar un
dominio de servicio BIAN define su función comercial asociada como la combinación de un
tipo de acción o uso aplicado a un tipo de activo o entidad. BIAN ha identificado una lista
estándar de usos (llamados patrones funcionales) y ha desarrollado una descomposición
jerárquica de los activos o entidades (tangibles e intangibles) que pueden constituir cualquier
banco. Cada dominio de servicio combina un único patrón funcional principal (por ejemplo:
'mantener detalles de referencia', 'definir y ejecutar un plan') con un activo o tipo de entidad (por
ejemplo, 'una pieza de equipo', 'una relación con el cliente').
3. Los dominios de servicio BIAN tienen un alcance elemental : para definir
Capacidades canónicas Cada dominio de servicio debe cumplir una función comercial única/
elemental. Si un dominio de servicio cubre múltiples funciones, se podrían aplicar diferentes
combinaciones en diferentes situaciones de implementación y los comportamientos dejarían de
ser canónicos/estándar. Los patrones funcionales y la descomposición de activos mencionados
en la sección anterior ayudan a identificar los roles comerciales "elementales". Se incluyen algunas
consideraciones adicionales que son necesarias para garantizar que los diseños sean realmente
canónicos para algunas actividades bancarias específicas.
2.1.2 Modelado de comportamientos del mundo real
La especificación de los dominios de servicio BIAN se prueba y refina mediante el modelado de
comportamientos comerciales para verificar que la función comercial que cada uno realiza esté realmente
bien definida y sea discreta y para revelar las interacciones entre los dominios de servicio (el 'servicio
semántico'). operaciones').
1. Los dominios de servicio BIAN comparten una estructura común : todos los dominios de servicio
cumplen un propósito comercial único que actúa como un "centro de servicio" que brinda acceso
a su funcionalidad comercial a través de las operaciones de servicio ofrecidas y recurre a los
servicios de otros dominios de servicio según lo requieran. Cada Dominio de Servicio tiene un
patrón operativo caracterizado por el manejo de su 'Registro de Control'.
El registro de control refleja la combinación del patrón funcional del dominio de servicio
que se aplica a su tipo de activo/entidad asociado. Debido a que el patrón funcional toma la
forma verbal que describe un comportamiento, BIAN asocia un artefacto genérico con cada
patrón funcional. El artefacto genérico se refiere a algo más tangible que representa mejor el
registro de control.
Por ejemplo, para el patrón funcional 'Diseño', el artefacto asociado es una 'Especificación'.
Se crea una instancia de registro de control cada vez que un servicio
El dominio cumple su función y persiste desde el inicio hasta su finalización. El dominio de
servicio con el patrón funcional 'diseño' que crea y mantiene diseños para productos tiene el
registro de control "Especificación del producto". Mantendrá una instancia de registro de control
detallando la especificación de cada producto válido durante el tiempo que se encuentre en uso en
el banco.
Con la versión 6.0, BIAN ha introducido un nivel adicional de detalle en la especificación
del dominio de servicio. El mecanismo utilizado es la definición de 'tipos de calificadores
de comportamiento' que desglosan las características de comportamiento del patrón funcional del
dominio de servicio.
Este detalle adicional se utiliza para ampliar la descripción de la información comercial
regida y a la que se accede a través de las operaciones del servicio que ofrece. También se utiliza
para definir un propósito/definición más preciso para aquellas operaciones de servicios ofrecidos
individuales cuando sea necesario.
2. La actividad comercial se modela como interacciones de dominios de servicio : todo lo que sucede
en un banco se puede representar utilizando una selección adecuada de dominios de servicio y
capturando el patrón de interacciones de servicio entre ellos. La representación del modelo
principal captura la actividad transaccional utilizando el Escenario empresarial BIAN, similar en
propósito a un proceso empresarial de alto nivel. El Business Scenario es una representación
esquemática simple de los dominios de servicio involucrados y el flujo arquetípico de las
interacciones de servicio involucradas en el manejo/respuesta a un evento comercial.
Con la versión 6.0, BIAN se basa en el uso de modelos alámbricos que capturan las conexiones
de servicio conocidas/establecidas entre dominios de servicio. Un evento empresarial específico
puede desencadenar una serie de subprocesos de actividad paralelos o simultáneos, cada uno
de los cuales puede capturarse como escenarios empresariales que se resuelven de forma asincrónica.
Estos escenarios de negocio se pueden trazar como flujos a través de un modelo de
estructura alámbrica adecuado. Esta visión más interconectada de la actividad comercial se
explica con más detalle en secciones posteriores de la guía.
3. Las operaciones de servicio se definen en términos semánticos : las interacciones entre los
dominios de servicio representan el núcleo del estándar de la industria BIAN. Se describen
en términos semánticos, cubriendo los principales conceptos comerciales involucrados en la
interacción con suficiente detalle para proporcionar una definición inequívoca que se puede
interpretar de manera consistente en la implementación.
2.1.3 El estándar BIAN se puede interpretar en diferentes situaciones El estándar BIAN proporciona
una vista dividida de la funcionalidad comercial que se puede capturar en diferentes notaciones técnicas
y aplicar/interpretar en diferentes entornos de implementación técnica. El estándar BIAN se puede utilizar
de dos formas amplias: una como una especificación de diseño de alto nivel para la implementación de
soluciones específicas, la otra para definir un modelo estable de la empresa para las actividades de
análisis y planificación comercial y técnica.
1. BIAN es una vista de modelo de negocio que se puede mapear : se define en el
nivel de arquitectura de negocios el panorama de servicios de BIAN sirve de puente entre el
modelo/estrategia de negocios de alto nivel y las muchas vistas arquitectónicas de nivel de
implementación subyacentes. Las operaciones de servicios semánticos de Service Landscape
de BIAN se pueden asignar consistentemente a los estándares de mensajería establecidos de la
industria y definiciones de mensajes patentadas. El funcionamiento y la función del dominio de
servicio BIAN también se pueden relacionar con las vistas arquitectónicas de nivel de
implementación convencional, como los modelos de procesos y datos.
2. Aplicación de diseños BIAN en diferentes entornos técnicos : el dominio de servicio BIAN y las
operaciones de servicio asociadas definen las particiones funcionales comerciales y las interfaces
entre ellas. Esta especificación de alto nivel del comportamiento empresarial puede interpretarse
como un diseño de alto nivel para una variedad de entornos técnicos. Se consideran tres entornos
principales:
o Como marco para estructurar/alinear mejor las tecnologías heredadas
'monolíticas'. o Como un diseño para aplicaciones comerciales que
habilitan servicios que utilizan tecnologías como un bus de servicios
empresariales (ESB) o Como un esquema para particiones habilitadas para
servicios de tipo 'contenedor' para tecnologías de tipo 'nube' altamente distribuidas y, más
recientemente, una interpretación de microservicio arquitectura
3. Uso de BIAN para definir un plan empresarial : uso de los dominios de servicio de BIAN como
componentes básicos de un plan empresarial. Una propiedad clave del Dominio de servicio es
que su propósito/función comercial no cambia con el tiempo. La forma en que un dominio de
servicio funciona o logra su propósito puede cambiar a medida que evolucionan las prácticas y las
soluciones habilitadoras, pero su propósito comercial principal es estable. Como resultado, un plan
de negocios definido mediante Service Domains también es muy estable y se adapta a diferentes
tipos de análisis. Se definen tres categorías generales: o Configuración y seguimiento del
rendimiento o Mapeo y evaluación de la cobertura o Asociación de atributos de comportamiento
para especificar mejor los requisitos.
3 Guía práctica de BIAN: desarrollo de contenido
BIAN ha establecido una organización interna con funciones centrales de supervisión y apoyo, y una
colección de grupos de trabajo especializados que desarrollan el contenido estándar de BIAN. Para
mantener la coherencia, se utiliza un enfoque común para el desarrollo de contenido en todos los
equipos. Este segundo documento de la serie de guías prácticas describe
el enfoque BIAN, directrices, plantillas de apoyo y herramientas. Se establece como se resume en la
siguiente figura:
BIAN cuenta con Normas de Organización, Enfoque y Especificación para el
desarrollo de contenidos
El comportamiento empresarial se
El contenido de BIAN se captura en el Las interacciones del dominio de servicio
marco BIAN SOA. Esto ahora se mantiene modela utilizando dominios de servicio
se especifican además como operaciones
para confirmar su rol y refinar su definición
en un repositorio UML de servicio semántico
(Escenarios de Negocios)
1 – UN BIAN 3 – La actividad
1 – ¿Cuál es el 3 – El contenido de BIAN 1 – Las definiciones 3 – Las operaciones del
El grupo de trabajo arquetípica se modela
propósito de una se desarrolla utilizando una de operación de servicio servicio semántico BIAN se
confirma el propósito/ usando Business
Arquitectura Orientada variedad de herramientas e predeterminadas de asignan a las
rol comercial , el escenarios,
a Servicios (SOA) y qué instalaciones BIAN se están especificaciones del
alcance funcional y Wireframes e
define a la BIAN SOA? (MS, Dibujo Mágico, actualizando con mensaje del nivel de
rige una colección de intercambios de
Banco de trabajo BIAN, contenido más detallado implementación
operaciones de servicios
herramientas CASE) y específico
Dominios de servicio
2 – El Marco BIAN 2 – Especificación de la
SOA 2.1 Panorama de operación del servicio:
2 – Servicio
Servicios 2.2 Escenarios 2.1. Vocabulario
Se caracterizan los
de Negocios 2.3 específico de BIAN 2.2
Dominios de Servicios tipos de intercambio BIAN BOM
de operaciones de
servicios de dominio y
los estados del ciclo de
vida
Figura 5: Desarrollo de contenido
Los equipos principales que brindan supervisión central y apoyo para el desarrollo de contenido.
Los grupos de trabajo son:
1. Architecture Framework & Foundation (AF&F) : es una unidad responsable de
definir las técnicas de diseño, las pautas, las convenciones de nomenclatura y los términos
estándar utilizados por los Grupos de trabajo de definición de contenido. Un equipo dentro de la
unidad AF&F es responsable de desarrollar herramientas basadas en UML y soporte de repositorio
para la captura de contenido. Un segundo equipo de AF&F está desarrollando el modelo de objetos
comerciales (BOM) BIAN y vinculándolo con otros estándares de la industria, en particular ISO20022.
2. Service Landscape : es una unidad que supervisa el diseño general de la parte superior
nivel Service Landscape y asigna definición y derechos de acceso a los Dominios de Servicio
para los Grupos de Trabajo. En este momento, el equipo de Service Landscape se ha combinado
con el equipo de AF&F
3. Comité de Arquitectura – además de una gama de arquitectura general
responsabilidades de supervisión, el Comité de Arquitectura se coordina con las dos unidades
nombradas anteriormente para aprobar la definición de nuevas y cualquier actualización de las existentes.
Dominios de servicio en el panorama de servicios de BIAN
Como se muestra en la figura anterior, el enfoque de desarrollo de contenido de BIAN se explica en tres
secciones principales:
3.1.1 El estándar BIAN se captura en el marco SOA de BIAN Hay razones comunes para adoptar
una arquitectura orientada a servicios (SOA).
BIAN ha desarrollado un enfoque específico para SOA que se necesita para definir diseños canónicos
(diseños que cualquier organización puede interpretar de manera consistente). Los diseños de BIAN se
ensamblan en un marco utilizando una variedad de herramientas e instalaciones de apoyo.
1. ¿Cuál es el propósito de SOA y cómo la ha aplicado BIAN? Las Arquitecturas Orientadas a
Servicios modelan la actividad comercial de una manera particular que pretende aprovechar
los enfoques y tecnologías operativos basados en servicios.
BIAN ha ampliado el concepto general de diseño de SOA para identificar particiones de
capacidad genérica que pueden ser habilitadas para el servicio y, lo que es más importante, que
representan los componentes básicos de cualquier banco, según sea necesario para establecer un
estándar de la industria.
2. El marco BIAN SOA : los diseños de BIAN se capturan en un marco que consta de un panorama
de referencia de alto nivel que captura todas las capacidades comerciales genéricas denominadas
dominios de servicio BIAN. El marco también registra la naturaleza de los intercambios de
servicios entre dominios de servicio definidos como operaciones de servicio que se requieren para
respaldar la ejecución comercial. Una técnica de modelado denominada Escenario empresarial
BIAN es un mecanismo utilizado para identificar y especificar los dominios de servicio involucrados
y las operaciones de servicio asociadas. En versiones más recientes, la vista Business Scenario se
ha ampliado con estructuras de BIAN que muestran las conexiones de servicio establecidas entre
agrupaciones de dominios de servicio.
3. El desarrollo de contenido está respaldado por herramientas e instalaciones: el desarrollo
de contenido originalmente realizado en herramientas de productividad como Excel y
PowerPoint ahora se captura en un repositorio UML interactivo. BIAN utiliza una herramienta
de 'banco de trabajo' patentada para ayudar a capturar contenido y está haciendo un uso cada vez
mayor de las herramientas de exportación a CASE para ayudar en el desarrollo y la presentación
del contenido de BIAN.
3.1.2 El comportamiento empresarial se modela utilizando dominios de servicio Los
comportamientos generales que se pueden encontrar en cualquier banco se utilizan para refinar la
definición de dominios de servicio y las interacciones entre ellos. Es importante tener en cuenta que los
modelos de comportamiento desarrollados (Escenarios de negocios) y los wireframes asociados son
arquetípicos y solo se usan para aclarar el funcionamiento de los dominios de servicio.
No pretenden representar comportamientos deseados y no forman parte del estándar BIAN.
1. Los grupos de trabajo gobiernan los dominios de servicio: cada grupo de trabajo tiene un área
asociada de experiencia comercial. El alcance cubierto por los Grupos de Trabajo individuales
se define en sus estatutos, de modo que los Grupos de Trabajo colectivamente cubran todo el
panorama sin superposiciones entre ellos. (Tenga en cuenta que hay algunas áreas del entorno
asignadas a grupos de trabajo que no están actualmente activas). La gobernanza para la
especificación de dominios de servicio dentro de un área comercial se asigna a un grupo de trabajo.
El grupo de trabajo es entonces responsable del diseño inicial y de cualquier actualización posterior
de su colección de dominios de servicio.
2. Las acciones y los estados estándar están asociados con el dominio del servicio
Intercambios : todos los dominios de servicio tienen un comportamiento operativo común: realizan
una sola función dominante para las ocurrencias de un solo tipo de activo o entidad; por ejemplo,
uno podría manejar la 'operación' de una 'pieza de equipo'.
Una instancia de un Dominio de servicio que cumple con su función comercial asignada de
principio a fin se administra mediante un patrón o estructura denominado "Registro de control".
El enfoque de diseño se describe detalladamente en la 'Guía práctica: principios y técnicas de
diseño'. En este documento, se utilizan varios estándares/elementos de la lista de verificación para
definir el comportamiento de los dominios de servicio:
2.1 Estados del dominio de servicio: se definen los estados operativos generales basados
en el funcionamiento del dominio de servicio
2.2 Tipos de acción de operación de servicio: se puede asociar una gama
estándar de tipos de intercambio de servicio o 'acciones' con las operaciones de
servicio
3. La actividad arquetípica se modela utilizando Business Scenarios y
Estructuras alámbricas : el principal mecanismo utilizado para modelar interacciones y aclarar la
naturaleza de los intercambios de servicios entre dominios de servicio es el escenario empresarial.
Esta sencilla técnica identifica los dominios de servicio involucrados y los intercambios de
operaciones de servicio asociados con el manejo de algún tipo de evento o transacción comercial.
El flujo modelado es arquetípico utilizando un ejemplo representativo para aclarar las funciones de
los dominios de servicio. Un Business Scenario no pretende definir un proceso estándar, sino que
es simplemente un ejemplo viable de un posible comportamiento. Tampoco pretende ser
necesariamente exhaustivo o completo, simplemente debe incluir suficiente contexto para exponer
las acciones específicas de los dominios de servicio que se están considerando. Los escenarios a
menudo necesitarán hacer referencia a dominios de servicio que son manejados por otros grupos
de trabajo y la administración central de BIAN ayuda a coordinar estas dependencias para garantizar
que las operaciones de servicio a las que se hace referencia sean desarrolladas por sus respectivos
grupos de trabajo anfitriones.
Con la versión 6.0, se ha incrementado el uso de Wireframes BIAN que capturan los patrones de
conexiones de servicio establecidas entre colecciones de dominios de servicio. El wireframe
proporciona un marco estable para varios tipos de análisis de requisitos. Los escenarios
comerciales individuales se pueden rastrear como flujos que atraviesan las conexiones en un
modelo alámbrico. La vista de estructura alámbrica es
útil para mapear/explorar desarrollos de sistemas existentes y planificados. También es útil para
modelar eventos comerciales que dan como resultado cascadas de actividad potencialmente
asincrónica que se pueden capturar como una colección relacionada de escenarios comerciales
que se pueden rastrear a través de la estructura alámbrica, en lugar de rastrear los viajes en un
mapa.
Además de las interacciones transaccionales, existe una coordinación de fondo entre algunos dominios
de servicio que pueden no representarse fácilmente mediante escenarios comerciales. BIAN está
considerando técnicas para capturar este tipo de tráfico de operación de servicio de 'coherencia
referencial'.
3.1.3 Interacciones de dominio de servicio
Finalmente, la especificación de los intercambios de operaciones de servicio entre Service
Los dominios se desglosan a un nivel de detalle que define inequívocamente la interacción y
que es suficiente para coincidir con los intercambios de mensajes del sistema subyacente cuando
corresponda.
1. Un marco define el contenido del intercambio : cada dominio de servicio tiene un conjunto
predeterminado de operaciones de servicio candidatas. Los valores predeterminados
seleccionados de una lista estándar de 'términos de acción' que caracterizan cada uno un tipo
de operación de servicio. La selección predeterminada se basa en el patrón funcional específico
del dominio de servicio. Las descripciones generales de la operación del servicio se generan en
función de las propiedades del dominio del servicio, en particular, su registro de control.
Las versiones anteriores de BIAN Service Landscape usaban una plantilla estándar para definir
tipos genéricos de parámetros de entrada y salida para proporcionar una descripción básica de
las operaciones del servicio. Como se señaló, la plantilla utilizaba conceptos empresariales
deducidos del registro de control del dominio de servicio.
Con la última versión V6.0, BIAN ha comenzado a desarrollar definiciones más detalladas
específicas para los dominios de servicio individuales junto con el desarrollo de un
modelo de objetos comerciales de BIAN. Estas especificaciones más detalladas se están
utilizando para reemplazar progresivamente las descripciones generales de las operaciones
de servicio en todo el panorama de servicios de BIAN. El contenido actualizado de la
operación del servicio es ratificado por una combinación de análisis de datos comerciales y
modelado de escenarios comerciales por parte de los Grupos de Trabajo de BIAN.
2. Un vocabulario para todos los términos específicos de BIAN : el estándar BIAN ha definido muchos
términos. Ya se mencionaron los patrones funcionales BIAN y los términos de acción de operación
del servicio. Todos los términos específicos de BIAN, incluidas las definiciones de dominio de
servicio, se definen y registran en un vocabulario comercial de BIAN. Esto está integrado con el
repositorio de contenido basado en UML y las herramientas de presentación.
El vocabulario de los términos de BIAN está separado del modelo de objetos comerciales de
BIAN que se está desarrollando. El BOM BIAN detalla la información comercial regida por los
Dominios de Servicio e intercambiada en el servicio
operaciones. Está informado por el BOM ISO20022 como se describe con más detalle en la guía
correspondiente.
3. La operación del servicio semántico se puede asignar a los mensajes : la intención detrás de la
operación del servicio semántico es que se pueda asignar a las especificaciones del mensaje
subyacente para las interacciones de máquina a máquina y de persona a máquina donde se han
definido. Las operaciones del servicio BIAN se asignan de manera diferente según el entorno
técnico y la naturaleza de los propios mensajes.
4 Guía práctica de BIAN: aplicación del estándar BIAN
Los estándares BIAN definen particiones de capacidad empresarial genéricas (dominios de servicio) y sus
operaciones de servicio semántico. Para asignar estos diseños estándar a una organización específica,
deben seleccionarse, adaptarse y ensamblarse para que coincidan con el alcance operativo y la estructura
de la organización. Las definiciones conceptuales de alto nivel de BIAN se pueden asignar a diseños
técnicos de nivel de implementación más detallados para respaldar el desarrollo de soluciones. Los
dominios de servicio de BIAN también se pueden utilizar como componentes básicos para ensamblar el
"modelo" comercial de una empresa que se puede utilizar para una amplia gama de usos de planificación
y análisis. Este tercer documento de la 'Guía práctica' de BIAN presenta las pautas iniciales para aplicar
los diseños de BIAN, como se resume en la siguiente figura:
Se están definiendo enfoques y técnicas para
aplicar el estándar BIAN a cualquier empresa
Utilice el modelo BIAN como un diseño de
Se crea un plan empresarial Utilice el modelo como marco de
implementación de alto nivel para diferentes
representativo con BIAN Service planificación y análisis para usos
entornos técnicos y como puente entre
Dominios como bloques de construcción comerciales y técnicos.
ellos.
1 – Seleccione el 1 – Agregar 3 – Utilice el

1 – Traducir 3 – Especificar los 3 – Distribuya y duplique
Servicio BIAN detalles al modelo marco para
Diseños semánticos de requisitos de la las capacidades comerciales
alto nivel de BIAN para solución puntual y la API
Dominios que se BIAN, mapear a superponer recursos
en un 'modelo' organizacional
semántica necesitan otros estándares/ actuales y candidatos
requisitos de nivel de
modelos y agregar Servicio para identificar
implementación diseños
Atributos de dominio deficiencias/
2 – Desarrollo de oportunidades
especificaciones 2 – Adaptar los
técnicas. 3.1 Núcleo/
diseños genéricos
Host/Legacy 3.2 ESB de BIAN según sea
2 – Utilice el
Habilitado 3.3.Nube
necesario (especializar, modelo para definir y
y Microservicios
realizar un seguimiento
copiar/ combinar Servicio
del rendimiento empresarial
dominios) y de los sistemas
Figura 6: Aplicación del estándar BIAN
Las pautas presentadas en este documento se ampliarán y refinarán continuamente en función de las
experiencias y los comentarios de los miembros de BIAN y otros profesionales de la industria. Como se
muestra en la figura anterior, el enfoque evolutivo para aplicar el estándar BIAN se explica en tres
secciones principales:
4.1.1 Uso de las especificaciones de BIAN como un diseño de implementación de alto nivel Los diseños
conceptuales de BIAN proporcionan un punto de partida para definir los requisitos de los sistemas. Esto
se puede utilizar para rediseñar/realinear sistemas existentes, para seleccionar y configurar paquetes
comerciales o para desarrollar soluciones a medida. Los diseños conceptuales de BIAN deben interpretarse
de manera diferente según el entorno técnico de destino. Se proporcionan pautas generales para tres
situaciones discretas:
1. Traducir los diseños semánticos de alto nivel de BIAN en software
especificaciones: los diseños semánticos de alto nivel deben ampliarse en detalle para
proporcionar definiciones de requisitos que puedan guiar el desarrollo de soluciones
2. Tratar con diferentes entornos técnicos: los diseños de BIAN se interpretan de manera
diferente para diferentes tipos de entornos técnicos que representan, en términos generales,
etapas de evolución hacia la habilitación del servicio.
2.1 Racionalización de estructuras de host centrales/heredadas: se aplica típicamente
a soluciones de mainframe de host establecidas
2.2 Aplicaciones host de habilitación de servicios que utilizan un ESB : se aplica a
entornos de soluciones de ensamblado de proceso/orquestación de aplicaciones que a
menudo envuelven sistemas host heredados
2.3 Tratar con entornos altamente distribuidos : se aplica a las soluciones creadas
utilizando las tecnologías de nube e Internet en rápida evolución y, más recientemente, las
arquitecturas de microservicios.
3. Especificación de soluciones puntuales: en primer lugar, un enfoque general para utilizar los
diseños de BIAN para especificar una solución específica/puntual mediante el uso de
aplicaciones comerciales existentes, nuevos desarrollos e integración de paquetes
comerciales, según corresponda. Además de este enfoque de proyecto más general, BIAN
ha desarrollado una guía que aborda específicamente el uso de BIAN para especificar
interfaces de programas de aplicación (API). Esta guía se presenta como un documento separado.
Tenga en cuenta que al alinear las soluciones con un plan empresarial, no solo es posible respaldar
el desarrollo en una variedad de entornos técnicos, sino también integrar mejor las soluciones creadas en
diferentes entornos técnicos que están alineados con el mismo modelo.
4.1.2 Ensamblar un plan de empresa representativo El panorama de servicios de
BIAN contiene uno de cada dominio de servicio identificado organizado en un marco de referencia.
La cobertura del panorama pretende incluir todas y cada una de las capacidades que se requieran en
cualquier banco. El panorama no presenta los dominios de servicio para representar la estructura organizativa
de ninguna empresa específica. En particular, normalmente será necesario duplicar muchos dominios de
servicio para admitir diferentes ubicaciones y/o líneas de negocio de una empresa. Para interpretar el
estándar BIAN para algunos tipos de análisis, puede ser útil ensamblar primero un "modelo" de la
organización utilizando los dominios de servicio BIAN como componentes básicos.
1. Seleccionar dominios de servicio que coincidan con la actividad de la empresa : el primer paso
consiste en filtrar los dominios de servicio que admitan capacidades que la empresa objetivo no
necesita (por ejemplo, excluir algún tipo de capacidad de producto/servicio o alguna actividad
específica del canal).
2. Adapte las especificaciones generales de BIAN según sea necesario : las especificaciones del
dominio de servicio de BIAN cubren las acciones básicas/generales realizadas. Es posible que
sea necesario adaptar estas especificaciones para reflejar la situación prevaleciente en un banco
específico. Es posible que las características del dominio de servicio (y sus operaciones de
servicio) deban especializarse para reflejar consideraciones geopolíticas, consideraciones de
escala/rendimiento específicas de la empresa o para manejar comportamientos avanzados/
diferenciadores únicos. Además, es posible que sea necesario ajustar las decisiones de alcance
aplicadas para definir el registro de control de un dominio de servicio (y la "granularidad" de su
funcionamiento) combinando o duplicando y especializando dominios de servicio.
3. Reúna los dominios de servicio en una estructura que coincida con la empresa : el paso final y
más complicado para ensamblar el plan empresarial consiste en organizar los dominios de
servicio en una estructura que coincida con la estructura operativa de la empresa (actual o de
destino). Esto implica manejar consideraciones como el reconocimiento de actividades
comerciales paralelas (por ejemplo, múltiples líneas de negocios), capturar operaciones/
actividades centralizadas y reflejar la entidad legal/estructura de informes.
4.1.3 Un modelo empresarial es un marco para el análisis Las funciones que
desempeñan los dominios de servicio tienden a ser muy duraderas. Como resultado, una vista
empresarial creada con ellos también es muy estable. Dicho plan puede utilizarse como marco para una
amplia gama de actividades de análisis y planificación comercial y técnica. Esta representación se
conoce como el modelo M4Bank dentro de BIAN y es un área de desarrollo futuro. (El '4' en el título se
refiere a las diferentes dimensiones organizacionales manejadas en el modelo como se describe en la
guía)
1. Las especificaciones de BIAN se pueden aumentar : los diseños conceptuales de alto
nivel de BIAN se pueden aumentar para definir un modelo de "estado objetivo" que
retenga el marco organizativo de las particiones de capacidad del dominio de servicio y sus
operaciones de servicio. BIAN está desarrollando técnicas de mapeo repetibles y tiene ejemplos
que vinculan los diseños de BIAN con estándares industriales de nivel de implementación
establecidos (por ejemplo, para mensajería: ISO 20022).
Otro uso importante del modelo empresarial es asociar una amplia gama de atributos de
comportamiento con dominios de servicio, por ejemplo, costo comparativo, requisitos de seguridad,
criticidad operativa. El rango de posibles atributos es prácticamente ilimitado. En combinación, las
atribuciones brindan información sobre la planificación y evaluación comercial y técnica.
2. Realizar un seguimiento del rendimiento comercial y técnico : un plan empresarial proporciona
una vista estable y completa de las partes constituyentes de una organización (resueltas
en capacidades de dominio de servicio individuales). Este marco se puede utilizar
posteriormente para establecer objetivos y realizar un seguimiento del rendimiento comercial
y técnico.
3. Superposición de recursos para identificar deficiencias : dado que el modelo empresarial
proporciona una vista que no se superpone de las capacidades que componen una
organización, se puede utilizar para superponer recursos (como asignaciones de personal,
aplicaciones de producción) para identificar deficiencias en la cobertura, por ejemplo,
brechas, duplicación, desalineación.

BIAN How To Guide Introduction To BIAN V6.0 Final V1.0

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

BIAN How To Guide Introduction To BIAN V6.0 Final V1.0

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

Role Nombre Compañía

Estado Fecha Actor Comentario / Referencia

BORRADOR enero 2018 Reestructurar, Cifras

6.0 Primera versión editada enero 2018

Tipos de edificios Los arquitectos seleccionan los Trabajo y Educación

Empleados, Socios, Sin una manera fácil de capturar y asociar Procesos de negocio

La visión La realidad El futuro

El enfoque aísla capacidades comerciales Las definiciones de dominio de servicio se Hay un camino claro para aplicar los

1 – de BIAN 3 – Las particiones BIAN 3 – Todo el servicio 3 – Un plan de

1 – Seleccione el 1 – Agregar 3 – Utilice el

También podría gustarte