lluen

1. ADM (Architecture Development Method)

Definición (Examen): Es el corazón de TOGAF. Es un proceso cíclico e iterativo paso a paso para desarrollar, gestionar y mantener la Arquitectura Empresarial.

2. Metamodelo de Contenido (Architecture Content Metamodel)

Definición (Examen): Es la estructura que define los tipos de bloques de construcción (entidades) que se pueden usar en la arquitectura y cómo se relacionan entre sí.

3. Enterprise Continuum (Continuum Empresarial)

Definición (Examen): Es una forma de clasificar los activos de arquitectura (modelos, patrones, descripciones) desde lo más genérico hasta lo más específico para la organización.

4. Architecture Repository (Repositorio de Arquitectura)

Definición (Examen): Es el lugar físico o digital (base de datos, sistema de archivos, herramienta) donde se almacenan todos los artefactos, modelos y documentos de la arquitectura.

Vista Motivacional (Motivation View)

¿Qué representa? Representa el «POR QUÉ» de la arquitectura. Conecta las necesidades de los interesados (Stakeholders) con los objetivos del cambio. Muestra las razones detrás de las decisiones de diseño.

2. Vista Estratégica (Strategy View)

¿Qué representa? Representa el «QUÉ» a alto nivel. Define el rumbo de la empresa y las capacidades necesarias para lograr los objetivos. Es el puente entre la motivación y la operación real.

3. Vista de Procesos de Negocio (Business Process View)

¿Qué representa? Representa el «CÓMO» trabaja la organización. Muestra el flujo de actividades, quién las realiza y qué servicios ofrece la empresa a sus clientes.

4. Vista de Aplicación (Application View)

¿Qué representa? Representa el SOFTWARE que soporta al negocio.
Muestra qué sistemas existen, cómo se hablan entre sí (interfaces) y qué funciones realizan.

5. Vista de Tecnología (Technology View)

¿Qué representa? Representa el HARDWARE e INFRAESTRUCTURA física o virtual donde corre el software. Es la base técnica (servidores, redes, nube).

Pregunta: ¿Cuál es la relación entre TOGAF y ArchiMate?

Respuesta correcta (examen): TOGAF y ArchiMate son estándares complementarios mantenidos por The Open Group:

• TOGAF es el marco de trabajo (Framework) y método. Proporciona el proceso paso a paso (ADM) para desarrollar la arquitectura. Te dice QUÉ hacer y en qué orden.

• ArchiMate es el lenguaje de modelado. Proporciona la notación gráfica (iconos, formas, relaciones) para describir y visualizar la arquitectura. Te da las herramientas para dibujar el CÓMO.

Cómo se complementan (Explicación): El ADM de TOGAF requiere que generes «Artefactos» (diagramas y matrices) en cada fase. ArchiMate provee los símbolos estandarizados para crear esos diagramas.

SOLUCIÓN PARTE 2: CASO UNIVERSIDAD RICARDO PALMA

1. Vista Motivacional (0.5 pts)

Objetivo: Mostrar por qué estamos haciendo el proyecto. (Basado en la Fase A de TOGAF – Visión)

• Stakeholders (Interesados):

  • Estudiantes: Buscan facilidad y rapidez.

  • Autoridades URP: Buscan eficiencia operativa y prestigio.

  • SUNEDU: Ente regulador (Cumplimiento).

• Drivers (Impulsores):

  • Transformación Digital.

  • Competitividad en el sector educativo.

• Goals (Metas):

  • Meta 1: Incrementar satisfacción estudiantil (Asociado a Estudiantes).

  • Meta 2: Cumplir regulaciones de seguridad y datos (Asociado a SUNEDU).

  • Meta 3: Digitalizar el 100% de procesos de atención.

2. Vista Estratégica (0.5 pts)

Objetivo: Definir qué capacidades necesita la URP para cumplir las metas.

• Capabilities (Capacidades de Negocio):

  • Gestión de Matrícula Digital: Capacidad de procesar inscripciones sin papel.

  • Gestión Financiera Estudiantil: Capacidad de procesar pagos en tiempo real.

  • Atención al Estudiante Omnicanal: Capacidad de atender por App y Web.

• Resources (Recursos Estratégicos):

  • Plataforma Digital Integrada (Activo tecnológico).

  • Base de Datos Histórica de Alumnos (Activo de información).

3. Vista de Procesos de Negocio (0.5 pts)

Objetivo: Mostrar el cómo funcionan los procesos operativos. (Basado en la Fase B de TOGAF – Business Architecture)

• Actor de Negocio: Estudiante URP.

• Procesos (Flujos):

Proceso de Matrícula:

Logueo -> Selección de Cursos -> Validación de Prerrequisitos -> Confirmación.

Proceso de Pagos:

Consulta de Deuda -> Selección de Cuota -> Pago en Pasarela -> Emisión de Comprobante.

Proceso de Emisión de Certificados:

Solicitud de Constancia -> Validación Académica -> Generación de PDF firmado -> Envío al Estudiante.

4. Vista de Aplicación (0.5 pts)

Objetivo: Mostrar el software que soporta los procesos. (Basado en la Fase C de TOGAF – Information Systems)

• Componentes de Aplicación:

  • Portal Académico Web: Interfaz principal para escritorio.

  • App URP Mobile: Interfaz para smartphones.

  • Motor de Matrícula (Backend): Lógica de cursos y horarios.

  • ERP Financiero: Sistema que registra los pagos.

• Servicios de Aplicación:

  • Servicio de Inscripción de Cursos (Servido por el Motor de Matrícula).

  • Servicio de Consulta de Notas.

  • Servicio de Procesamiento de Pagos.

5. Vista de Tecnología (0.5 pts)

Objetivo: Infraestructura física/virtual. (Basado en ARQUITECTURAEMPRESARIAL_URP_SESION11v1.0.Pdf, diapositiva 3 – Ejemplo AWS)

Seleccionamos AWS como proveedor Cloud según tu PDF:

• Dispositivo (Device): Laptop del Estudiante / Smartphone.

• Red/Seguridad:

  • AWS WAF (Firewall de Aplicaciones Web) para seguridad perimetral.

• Cómputo (Server):

  • Amazon EKS (Kubernetes): Para alojar los microservicios del Motor de Matrícula.

• Datos (Database):

  • Amazon RDS: Para la base de datos relacional (alumnos, notas).

6. Diagrama Integrado (1.5 pts)

Objetivo: Unir las 3 capas principales (Negocio, Aplicación, Tecnología). Este es el esquema que debes dibujar o describir para ganar el puntaje máximo. Se lee de abajo hacia arriba.

[Nivel 3: Capa de Negocio]

• (Proceso) «Realizar Matrícula en Línea»

  • Relación: Es soportado por…

[Nivel 2: Capa de Aplicación]

• (Servicio) «Servicio de Inscripción»

  • Relación: Es realizado por…

• (Componente) «Motor de Matrícula» (Integrado con Portal Web)

  • Relación: Está hospedado en…

[Nivel 1: Capa de Tecnología]

• (Software de Sistema) «Contenedor Docker / K8s»

• (Nodo) «Amazon EKS Cluster»

• (Nodo Base de Datos) «Amazon RDS» (Guarda los datos de la matrícula).

SOLUCIÓN PARTE 3: EVALUACIÓN Y ALINEAMIENTO 

 1. Explica cómo el uso de vistas arquitectónicas permite alinear la estrategia institucional con las capacidades tecnológicas 

 Respuesta correcta (examen): Las vistas arquitectónicas (ArchiMate) actúan como un mecanismo de trazabilidad. Permiten visualizar claramente cómo un activo tecnológico (ej. «Servidor en AWS») soporta un componente de aplicación (ej. «Motor de Matrícula»), el cual automatiza un proceso de negocio (ej. «Matrícula»), contribuyendo directamente a una capacidad estratégica (ej. «Gestión Académica Digital») y, finalmente, cumpliendo una meta institucional (ej. «Satisfacción Estudiantil»).

Sin estas vistas, la tecnología y la estrategia estarían desconectadas (silos). Las vistas aseguran que cada inversión tecnológica tenga una justificación de negocio.

 2. Identifica dos riesgos de arquitectura en la solución planteada y cómo los mitigarías 

Respuesta correcta (examen):

• Riesgo 1: Fugas de información sensible (Datos de estudiantes/pagos).

  • Contexto: Al exponer servicios de matrícula y pagos en Internet, aumentamos la superficie de ataque.

  • Mitigación: Implementar seguridad en profundidad usando AWS WAF (Web Application Firewall) para proteger el perímetro y IAM (Identity and Access Management) para controlar quién accede a qué recursos, tal como se detalla en la arquitectura de referencia de nube.

• Riesgo 2: Complejidad en la integración con sistemas legados (Sistemas académicos antiguos).

  • Contexto: La URP seguramente tiene sistemas antiguos (Legacy) que son difíciles de conectar con la nueva App móvil.

  • Mitigación: Utilizar el patrón API-Led Connectivity mediante un API Gateway. El Gateway actúa como intermediario (capa de sistema), traduciendo los protocolos modernos (REST/JSON) de la App a los protocolos antiguos del sistema legado, desacoplándolos para evitar fallos.

 3. Menciona dos beneficios de aplicar TOGAF y ArchiMate en proyectos reales de transformación digital

Respuesta correcta (examen):

Lenguaje Común y Estandarizado: ArchiMate elimina la ambigüedad. Permite que tanto los desarrolladores (técnicos) como los gerentes (negocio) entiendan el mismo diagrama. Si usamos TOGAF, todos sabemos que la «Fase B» siempre es Negocio, lo que facilita la comunicación entre equipos multidisciplinarios.

Gobernanza y Reutilización (Enterprise Continuum): TOGAF permite gestionar el cambio de forma ordenada. Gracias al Enterprise Continuum y al Repositorio de Arquitectura, la universidad no tiene que «reinventar la rueda» en cada proyecto; puede reutilizar modelos (como BIAN o arquitecturas de referencia de Nube) para acelerar la implementación y reducir errores.

2. 1. ¿Qué es la Arquitectura Vendor-Neutral?

 Respuesta correcta (examen): Es un enfoque de diseño arquitectónico que no depende de un único proveedor de tecnología o fabricante. Su objetivo es evitar el «Vendor Lock-in» (quedarse atrapado con un solo proveedor).

3 Ventajas (Basado en PDF Sesíón 10)

Innovación («Best of Breed»): Puedes elegir el mejor servicio de cada proveedor. Por ejemplo, usar la Inteligencia Artificial de Google (GCP) pero las bases de datos corporativas de Microsoft Azure.

Agilidad y Escalamiento: Permite escalar horizontalmente (más instancias) o verticalmente (más potencia) aprovechando la capacidad combinada de varios proveedores para responder rápido al mercado.

Eficiencia Operativa (Costos): Permite optimizar costos («Low Cost») aprovechando ofertas específicas o modelos de precios más baratos en un proveedor para ciertas tareas, evitando depender de los precios de uno solo.

2 Desventajas (Información Externa / Inferida)

Complejidad de Gestión (Management Complexity): Tener que administrar 3 consolas diferentes, 3 modelos de seguridad (IAM) y 3 formas de facturación requiere un equipo mucho más capacitado y herramientas de gobernanza más complejas.

Latencia e Integración: Conectar una aplicación en AWS con una base de datos en Azure puede generar lentitud (latencia) en la red y costos adicionales por la transferencia de datos entre nubes (Data Egress fees)

SOLUCIÓN PARTE 5: DISEÑO DE ARQUITECTURA DIGITAL (3 Puntos)

2. Propuesta en Microsoft Azure (1 pto)

Usando la matriz de equivalencias de la Sesíón 10 (Pág. 15) y los diagramas de la Sesíón 11:

Frontend/Backend (Cómputo): Azure Kubernetes Service (AKS) para los microservicios y Azure App Service si se prefiere una opción PaaS más simple para el frontend.

Base de Datos: Azure SQL Database (Equivalente directo a RDS).

Almacenamiento (Archivos): Azure Blob Storage (Equivalente a S3 para guardar los contratos).

API Management: Azure API Management.

Machine Learning: Azure Machine Learning.

Seguridad: Azure Web Application Firewall (WAF) y Azure Active Directory (Entra ID) para identidad.

3. Propuesta en Google Cloud Platform – GCP (1 pto)

Usando la matriz de equivalencias de la Sesíón 10 (Pág. 15) y los ejemplos de «Google Cloud Project» de la Sesíón 11 (Pág. 11-12):

Frontend/Backend (Cómputo): Google Kubernetes Engine (GKE). Es el estándar de oro para contenedores en GCP.

Base de Datos: Cloud SQL (Gestionado para PostgreSQL/MySQL).

Almacenamiento (Archivos): Google Cloud Storage (Equivalente a S3/Blob para objetos).

API Management: Apigee API Management o API Gateway.

Machine Learning: Vertex AI (o AI Platform).

Seguridad: Cloud Armor (Seguridad perimetral/WAF) y Cloud IAM.

SOLUCIÓN PARTE 6: SEGURIDAD Y ESCALABILIDAD (1.5 Puntos)

1. Implementación de prácticas de seguridad (0.5 pts)

Usaremos AWS como ejemplo principal (siguiendo la línea de tus PDFs), pero los conceptos aplican a las tres nubes.

Control de Acceso Basado en Roles (RBAC):

Implementación: Se utiliza el servicio AWS IAM (Identity and Access Management). En lugar de dar permisos a usuarios individuales, creamos Roles (ej. «Rol-Desarrollador», «Rol-Auditor») con políticas JSON específicas. Los usuarios asumen estos roles para acceder a recursos como S3 o EC2.

Equivalente en otros: Azure Active Directory (Entra ID), Google Cloud IAM.

Cifrado en Reposo y en Tránsito:

En Tránsito: Se implementa forzando HTTPS/TLS en el Load Balancer o API Gateway (usando certificados SSL).

En Reposo: Se activa la opción de «Encryption» en servicios como Amazon S3 (S3-Managed Keys o KMS) y Amazon RDS (bases de datos), donde la nube cifra los datos en el disco automáticamente.

Auditoría y Monitoreo de Accesos:

Implementación: Se habilita AWS CloudTrail, que registra cada llamada a la API (quién hizo qué y cuándo). Para monitoreo en tiempo real, se usa Amazon CloudWatch para alertar sobre intentos de acceso fallidos.

2. Garantía de Alta Disponibilidad y Escalabilidad Automática (0.5 pts)

La alta disponibilidad (HA) y la escalabilidad se logran combinando tres componentes clave que trabajan juntos:

Balanceador de Carga (Load Balancer): Actúa como el guardia de tráfico. Recibe las peticiones de los usuarios y las distribuye equitativamente entre múltiples servidores o contenedores.

Ejemplo: AWS Application Load Balancer (ALB).

Grupos de Autoescalado (Auto Scaling Groups): Es el mecanismo que vigila la carga (CPU/RAM). Si la demanda sube, crea automáticamente nuevas instancias (Escalamiento Horizontal). Si la demanda baja, las elimina para ahorrar costos.

Ejemplo: AWS Auto Scaling Group o Kubernetes HPA (Horizontal Pod Autoscaler).

Despliegue Multi-Zona (Multi-AZ): Para garantizar disponibilidad, los recursos se despliegan en diferentes centros de datos físicos (Zonas de Disponibilidad) dentro de una misma regíón. Si un data center falla, el balanceador redirige el tráfico a los otros.

 3. Diferencia entre Servicios Serverless y Servicios Gestionados (0.5 pts)

Respuesta correcta:

Diferencia Principal:

Servicios Gestionados (Managed): El proveedor administra el hardware y el sistema operativo (parches, backups), pero tú aún debes configurar la capacidad (ej. Elegir el tamaño del servidor o clúster) y pagas por el tiempo que el recurso está «encendido», se use o no.

Servicios Serverless: Tú solo subes el código. No administras servidores ni eliges capacidad; el proveedor escala automáticamente de 0 a millones de peticiones y solo pagas por ejecución (si nadie usa tu app, pagas cero).

SOLUCIÓN PARTE 8: FUNDAMENTOS Y TEORÍA DE BIAN (1 Punto)

1. Explica los conceptos clave del marco BIAN (0.5 pts)

Basado en las diapositivas 7, 8, 9 y 10 de la Sesíón 12:

Business Área (Área de Negocio):

Definición: Agrupa un amplio conjunto de capacidades de negocio . Representan aspectos macro de la actividad comercial.

Cantidad: Son 5 áreas .

Cuáles son: Reference Data, Sales & Service, Operations & Executions, Analytics & Risk, Business Support .

Business Domain (Dominio de Negocio):

Definición: Definen una colección coherente de capacidades dentro de un Business Área .

Cantidad: Son 38 dominios.

Service Domain (Dominio de Servicio):

Definición: Es la unidad funcional autocontenida dentro del negocio bancario. Son los «bloques de construcción elementales» del Service Landscape.

Cantidad: Son 326 dominios de servicio.

Semantic API (API Semántica):

Definición: Es una interfaz estándar definida por BIAN para acceder a la funcionalidad de un Service Domain con una semántica clara y agnóstica a la tecnología (no depende de Java, .NET, etc.).

 1. Identificación de Service Domains (1 pto)

Para este caso de gestión de tarjetas, seleccionamos 4 dominios estándar del paisaje BIAN. (El primero es mencionado explícitamente en tu PDF como ejemplo clave).

Card Management (Gestión de Tarjetas)

Rol: Es el corazón del sistema para el «dispositivo». Se encarga del ciclo de vida físico y digital de la tarjeta.

Funciones del caso: Emisión, Activación, Bloqueo (por pérdida/robo) y Reemplazo.

Card Authorization (Autorización de Tarjetas)

Rol: Gestiona la aprobación o rechazo de transacciones en tiempo real.

Funciones del caso: Verifica si la tarjeta está activa (consultando a Card Management) y si tiene fondos/cupo suficiente (validando Límites de gasto).

Card Capture (Captura de Transacciones)

Rol: Registra y procesa los movimientos financieros realizados con la tarjeta.

Funciones del caso: Generar el Historial de uso que el cliente ve en la App.

Credit Card Facility (o Customer Arrangement)

Rol: Gestiona el contrato financiero y las condiciones del producto (tasas, fecha de corte, línea de crédito total).

Funciones del caso: Define los límites globales de crédito contra los cuales se validan los gastos.

SOLUCIÓN PARTE 10: APIs Y ARQUITECTURA ORIENTADA A SERVICIOS (1.5 Puntos)

1. ¿Qué carácterísticas tienen las APIs semánticas BIAN? (0.5 pts)

 Carácterísticas principales: Según la Sesíón 12, las APIs semánticas de BIAN se caracterizan por:

Agnósticas a la tecnología: Definen el «qué hace» el servicio (nivel de negocio) sin atarse a una implementación técnica específica (Java, .NET, etc.).

Estandarizadas: Proporcionan un lenguaje común (interfaz estándar) para que todos los sistemas bancarios se entiendan, usando definiciones precisas del Service Domain.

Enfoque Funcional: Se centran en exponer una capacidad de negocio única y discreta, no en exponer tablas de base de datos o lógica de aplicación interna.

¿Por qué son clave en la arquitectura bancaria moderna? Son fundamentales porque garantizan la interoperabilidad. En un entorno bancario moderno (con múltiples proveedores y nubes), usar APIs semánticas evita el «caos de integración» donde cada sistema habla un idioma diferente. Permiten conectar sistemas Legacy con canales digitales modernos de forma ordenada.

 2. Diseña un ejemplo de API RESTful semántica para “bloqueo temporal de tarjeta” (0.5 pts)

Usaremos el Service Domain Card Management (mencionado en tu PDF) y la estructura de URI estándar de BIAN (/ServiceDomain/Versión/Action o similar, visto en los ejemplos de Swagger).

Método HTTP: POST (Se utiliza para ejecutar una acción o cambio de estado que no es una simple actualización de campo).

URI: /card-management/v1/cards/{cardId}/lock/initiate (Nota: En BIAN, las acciones suelen ser sustantivos verbalizados como «initiate», «execute» o «evaluate» al final de la ruta).

Estructura de entrada (Payload JSON):
JSON
{

  «customerReference»: «CUST-889900»,

  «lockReason»: «LOST_CARD»,

  «channel»: «MOBILE_APP»,

  «comment»: «Bloqueo solicitado por cliente desde app»

}

Estructura de salida (Response JSON):
JSON
{

  «lockReferenceId»: «LOCK-112233»,

  «status»: «LOCKED»,

  «effectiveDate»: «2025-10-29T14:30:00Z»,

  «message»: «Tarjeta bloqueada temporalmente con éxito»

}

 3. Diferencia entre Service Domain y Microservicio (0.5 pts)

Esta respuesta está literal en la diapositiva 17 de la Sesíón 12:

Diferencia:

Service Domain (Dominio de Servicio): Es un concepto funcional de negocio (nivel lógico). Representa una capacidad única del banco (ej. «Gestión de Tarjetas»).

Microservicio: Es un componente técnico, pequeño, desplegable e independiente (nivel físico/implementación).

¿Pueden corresponderse 1 a 1? No necesariamente. La relación no es estricta. Un Service Domain es una definición lógica que podría implementarse técnicamente mediante uno o varios microservicios trabajando juntos. Sin embargo, el Service Domain suele inspirar la estructura y los límites de los microservicios

SOLUCIÓN PARTE 11: APLICACIÓN PRÁCTICA Y TRANSFORMACIÓN DIGITAL (1.5 Puntos)

1. ¿Cómo ayuda el modelo BIAN a lograr una arquitectura bancaria componible y orientada a eventos? (0.5 pts)

Respuesta: BIAN facilita una arquitectura componible al descomponer el banco en Service Domains (Dominios de Servicio), que actúan como «bloques de construcción elementales» y discretos. Al ser unidades funcionales autocontenidas (como «piezas de Lego»), el banco puede «componer» nuevos productos combinando estos dominios sin tener que construir todo desde cero.

Para la arquitectura orientada a eventos, BIAN define Functional Patterns (Patrones Funcionales) como Notify (Notificar). Esto permite que un dominio (ej. «Pagos») publique un evento cuando algo sucede, y otros dominios (ej. «Fraude» o «Notificaciones») reaccionen automáticamente, desacoplando los sistemas.

Ejemplo:

Componible: Para crear un producto de «Préstamo Digital», compones los dominios existentes: Consumer Loan + Credit Assessment + Party Reference Data.

Eventos: Cuando Card Authorization aprueba una compra (Evento), el dominio Customer Offer recibe la notificación y dispara una oferta de «Pago en cuotas» en tiempo real.

2. Integración de Fintech externa (Tarjetas Virtuales) con Banco Tradicional (0.5 pts)

Explicación del flujo: La Fintech no necesita conocer la complejidad del Core Bancario antiguo del banco (Legacy). El banco expone sus capacidades a través de una Capa de APIs Semánticas BIAN (gestionada por un API Gateway) .

La Fintech consume estas APIs estandarizadas. Por ejemplo, para crear una tarjeta, llama a la API del Service Domain Card Management definida por BIAN. El API Gateway traduce esta petición estándar al lenguaje propietario del sistema legacy del banco.

Uso de estándares (Contexto Externo y PDF):

APIs REST: BIAN utiliza especificaciones técnicas OpenAPI (Swagger) , lo que permite a la Fintech conectarse usando métodos HTTP simples (POST, GET) y JSON, como se ve en los laboratorios del curso.

Open Banking: BIAN provee el «diccionario» funcional para que las APIs de Open Banking sean consistentes (que «Saldo» signifique lo mismo para todos).

ISO 20022: Información externa: Aunque no se detalla en el PDF, BIAN basa sus modelos de datos (Control Récords) en los estándares ISO 20022 para asegurar que los formatos de pagos y mensajería sean compatibles internacionalmente.

3. Desafíos reales en la adopción de BIAN y cómo superarlos (0.5 pts)

Desafío 1: Complejidad del Mapeo Legacy (La «Torre de Babel»).

Problema: Los bancos tienen sistemas monolíticos antiguos que mezclan funciones (ej. Un sistema que hace pagos, clientes y contabilidad a la vez). Mapear ese «espagueti» a los 326 Service Domains limpios de BIAN es muy difícil.

Solución: No intentar cambiar todo a la vez. Usar el BIAN Service Landscape para identificar dominios prioritarios y aplicar una estrategia de «estrangulamiento» (Strangler Pattern), exponiendo primero las APIs más críticas mediante un Wrapper o API Gateway.

 Desafío 2: Curva de Aprendizaje y Cambio Cultural.

Problema: BIAN es extenso (Áreas, Dominios, Patrones) y requiere que los equipos de Negocio y TI hablen el mismo idioma, lo cual no es natural en bancos tradicionales.

Solución: Adoptar BIAN incrementalmente como marco de referencia para racionalización de TI y planificación, tal como sugiere el PDF al vincular BIAN con las fases del ADM de TOGAF (Fases A, B, C, D) para guiar la transformación paso a paso .