Prima AFP es una entidad encargada de administrar los fondos de pensiones de sus clientes bajo el

régimen del sistema privado de pensiones (SPP) que cuenta con el respaldo de Credicorp (BCP).
Para ello permite a sus afiliados los servicios de trámites digitales (registro y seguimiento),
apertura y manejo de cuentas sin fin provisional y módulo de EECC (visualización y descarga).
Actualmente, a nivel tecnológico existe un sistema implementado en PHP con patrón MVC,
desplegado en un servidor apache 2.0 y una base de datos MySQL encargado de soportar los
servicios descritos anteriormente. Delante del servidor de aplicaciones se tiene un firewall de cara
a internet.

Debido a que el año 2020 ocurrió la época de pandemia en donde las diferentes AFPs comenzaron
a trabajar de forma remota para continuar brindando sus servicios a los afiliados, y a la vez poder
mejorar estos. Sin embargo, en Prima AFP al pasar a este periodo de pandemia, a medida que
pasaba el tiempo, se mostraron una serie de falencias las cuales afectaron a los servicios que se
brindaban a sus afiliados.

Por ejemplo, a medida que los requerimientos han ido creciendo se ha hecho bastante complicado
el mantenimiento de este aplicativo ya que los cambios e instalación de cambios pequeños podían
afectar el sistema por completo. Asimismo, afectaba constantemente el funcionamiento del
aplicativo que debe estar disponible 24x7. Añadiendo a esto, ingresaban afiliados cada semana
terminando de degradar el funcionamiento del sistema.

Por otro lado, cuando un afiliado ingresaba al aplicativo visualizar su EECC se producía una demora
de 5 minutos y en la descarga un tiempo de 10 minutos lo cual causaba molestias y la tasa de
abandono de ambos procesos incrementaba.

Por último, a nivel de la seguridad esta se ha visto vulnerada debido a los débiles controles y
mecanismos de seguridad como por ejemplo el uso único de usuario y clave de 4 dígitos, la cual
por medio de un ataque de fuerza bruta se podría obtener fácilmente e ingresar al aplicativo
permitiéndole ver información sensible y trámites críticos.

Debido a estos problemas se le contrata como Arquitecto de Software para que se pueda diseñar
una arquitectura propuesta que satisfaga las preocupaciones de la organización, así como las
nuevas funcionalidades. Como parte de los lineamientos y/o requerimientos adicionales del
sistema desarrollado se menciona lo siguiente:

 El sistema debe encontrarse en la nube de Microsoft Azure

 El motor de base de datos debe migrarse a la nube, pero mantener la tecnología.
 El módulo de seguridad debe implementarse en un lenguaje / tecnología diferente a PHP.

Entre las preocupaciones que tiene el negocio son que estos diferentes módulos pueden ser
implementados por diferentes equipos de trabajo, los cuales entran en conflicto. Así como otra
preocupación que estos diferentes módulos pueden estar en lenguajes diferentes y cuando se
realicen cambios en algún modulo del sistema no debe afectar a otro.
Historias Usuario / Casos de uso primarios

ID Nombre
HU01 Registro y seguimiento de tramites digitales

HU02 Visualización y descarga de EECC

HU03 Apertura y manejo de cuentas sin fin

provisional

1.- Realizar el diagrama AS-IS.

2.- Identificar los atributos de calidad (4 al menos), proponer un escenario por cada uno y
priorizarlos

1. Seguridad: Debido al giro de negocio de la empresa que maneja información sensible de

los afiliados (datos personales, montos, etc.) se considera prioritario la seguridad.

QA-1: Cuando un afiliado ingresa sus credenciales incorrectas por tercera vez, se
muestra un mensaje informando que la cuenta ha sido bloqueada temporalmente no
permitiendo el ingreso del usuario a la plataforma durante 6 horas y a la vez enviando
un correo al afiliado sobre el problema.
2. Disponibilidad: Debido a que nos encontramos en la virtualidad y los afiliados desean
trabajar con el sistema en todo momento del día (24x7) ya sea para aperturar cuentas,
hacer trámites y ver EECC.

QA-2: Cuando un gestor registra nuevos afiliados exitosamente en la base de datos, en

caso de una caída la disponibilidad del sistema debe estar disponible 95% de forma
mensual.

Un gestor de operaciones instala un nuevo cambio en el sistema el cual produce una caída
y lo deja inoperativo. En caso de este hecho, el RTO (Recovery time objetive) debe ser no
mayor a 15 minutos.

3. Rendimiento / Perfomance: Debido a que los afiliados están requiriendo que los procesos
de descarga y visualización sean más rápidos ya que tienen tiempos muy largos de demora
y esto causa abandono en el uso de la plataforma.

QA-3:

Un afiliado ingresa al sistema y desea hacer un trámite de registro de cuentas. Luego de

realizado el trámite, le muestra un mensaje que ha sido realizado con éxito. El trámite,
se registra en menos de 30 segundos.

Muchos de los afiliados ingresan al portal para visualizar su EECC un fin de mes con 200
usuarios conectados en simultaneo aprox., como resultado la información se le mostrará
a cada afiliado en menos de 10 segundos

Cuando un afiliado realiza la descarga de su EECC este culmina de manera exitosa y dicha
descarga se realiza en menos de 10 segundos.

4. Mantenibilidad: Debido a que el sistema al encontrarse en crecimiento porque todos los

procesos están pasando a ser digitales, se requiere mejorar el grado de mantenibilidad
para que pueda contribuir o facilitar el desarrollo de nuevos requerimientos, reutilización
de esto y rápida atención a posibles fallos e incidencias.

QA-4:

Debido a que el gerente de tramites solicita modificaciones en la funcionalidad

existente de registro de trámite, estos cambios se implementarán de manera
satisfactoria y no deben demorar más 48 horas de desarrollo y que a su vez no
implique hacer dicho cambio desde cero.

 Escalabilidad

QA-5:
 Cuando el administrador de operaciones decida adicionar un microservicio / módulo
adicional, llegado el momento sacar al mercado un nuevo producto, el sistema debe ser
capaz de soportar exitosamente este incremento de módulos, de tal modo que el
funcionamiento de la aplicación no se degrade ni se ralentice su tiempo de respuesta.

 Extensibilidad

QA-6:

Cuando un product owner desee agregar nuevas características a la aplicación, en el

momento que se perciba la necesidad de evolución, los cambios que se pretendan hacer
para aumentar las funcionalidades de algún componente del sistema, no deben requerir
más de 20 horas de desarrollo. La arquitectura del sistema debe estar diseñada de tal
forma que el incrementar las funcionalidades no implique codificar desde cero debido a
que se cuenta con porciones de código reutilizables.

 Desplegabilidad

QA-7:

Cuando un personal devops necesite realizar el pase del aplicativo completo a un

ambiente de QA o producción el sistema una vez instalado debe funcionar sin fallos en el
nuevo ambiente

3.- Realizar el TO-BE usando ADD

Escenarios de atributos de calidad

Código Escenario Atributo Descripción HU Asociado

QA-1 Seguridad Cuando un afiliado Todos
ingresa sus
credenciales
incorrectas por
tercera vez, se
muestra un mensaje
informando que la
cuenta ha sido
bloqueada
temporalmente no
permitiendo el
ingreso del usuario a
la plataforma
durante 6 horas y a
 la vez enviando un
correo al afiliado
sobre el problema.
QA-2 Disponibilidad Un gestor de Todos
operaciones
instala un
nuevo cambio
en el sistema
el cual
produce una
caída y lo deja
inoperativo.
En caso de
este hecho, el
RTO
(Recovery
time objetive)
debe ser no
mayor a 15
minutos.

QA-3 Rendimiento Un afiliado HU1

ingresa al
sistema y
desea hacer
un trámite de
registro de
cuentas.
Luego de
realizado el
trámite, le
muestra un
mensaje que
ha sido
realizado con
éxito. El
trámite, se
registra en
menos de 30
segundos.
QA-4 Mantenibilidad Debido a que el HU1
gerente de tramites
solicita
modificaciones en la
funcionalidad
existente de registro
de trámite, estos

Paso 1: Entradas
Propósito del Diseño
Requerimientos funcionales primarios
Escenarios de atributos de calidad
Restricciones
Preocupaciones arquitecturales
cambios se
implementarán de
manera satisfactoria
y no deben demorar
más 48 horas de
desarrollo y que a su
vez no implique
hacer dicho cambio
desde cero.
Elaboración de una nueva arquitectura que
pueda soportar los requerimientos del
negocio, así como sus restricciones.
Ver tabla de casos de uso
Ver tabla de escenarios de atributos calidad
R1- El sistema debe encontrarse instalado en
la nube de Microsoft Azure
R2 - El motor de base de datos en la nube
debe mantener con MySQL.
R3 - El módulo de seguridad debe
implementarse en un lenguaje / tecnología
diferente a PHP.
CRN001: Los diferentes módulos de la
aplicación pueden ser implementados por
diferentes equipos de trabajo y estas
implementaciones de estos equipos no deben
entrar en conflicto.
CRN002 – Los diferentes módulos
implementados puedan tener la posibilidad de
encontrarse en diferentes lenguajes de
programación.
CRN003 – El conocimiento de los
desarrolladores para implementar el módulo
de seguridad en el nuevo lenguaje.
CRN004 – Establecer una nueva arquitectura
en la nube que permita soportar los nuevos
requerimientos siguiendo arquitecturas de
 referencia.

ITERACIÓN 1

Paso 2: Establecer el objetivo de la iteración por medio de la selección de drivers

Objetivo: Elaborar la nueva arquitectura del sistema de Prima AFP de manera que permita
soportar nuevos módulos y/o requerimientos cumpliendo con los atributos de calidad
identificados.

Drivers: Para ello tomaremos como base las preocupaciones CRN1, CRN2, CRN3 y CRN4 sin dejar
de lado tanto las restricciones (R1, R2, R3) como los escenarios de atributo de calidad identificados
(QA1, QA2, Q3, Q4).

Paso 3: Escoger uno o más elementos del sistema para ser refinados

Como vamos a migrar y la vez mejorar toda la arquitectura que va a la nube de Azure, no se
escoge un elemento en particular. Todo el sistema sería el objetivo.

Paso 4: Escoger uno o más conceptos de diseño para satisfacer los drivers seleccionados

Decisiones de diseño Rationale

Arquitectura de Microservicio La arquitectura de microservicios nos permite
manejar nuestros módulos de manera
independiente de forma que si se realiza un
cambio en algún componente el impacto por
dicho cambio sea mínimo (CRN001, CRN-004
QA-4). Además, en caso de alguna falla en
algún módulo el aplicativo seguiría operativo a
excepción de dicho módulo (QA-2). Cada
microservicio podría corresponder a cada área
/módulo (tramites, eecc, aperturas, etc.) y
estos podrían ser implementados en lenguajes
diferentes (CRN002)
ReactJS Librería de Javascript que nos permite
elaborar los componentes de Frontend de
manera rápida y sencilla (QA-4). A su vez, al
manejar un esquema de renderizado DOM
Virtual nos beneficia en la performance (QA-3)

Otras opciones que se manejaron son:

Angular: Se descarto este framework debido a

que los desarrolladores de la organización
tendrían mayor dificultad de aprendizaje. A su
vez porque optamos por mejorar la velocidad
 en el renderizado del frontend.

VueJS: Se descarto este framework debido a

que los desarrolladores de la organización
tendrían mayor dificultad de aprendizaje,
además que en la mantenibilidad a largo no
existen muchos desarrolladores con dicho
conocimiento y falta de documentación. A su
vez porque optamos por mejorar la velocidad
en el renderizado del frontend.

Docker Mecanismo que permite el empaquetado de

nuestros microservicios como si estuvieran en
un sistema operativo. Esto nos ayuda a
mejorar la mantenibilidad de nuestros
microservicios, así como la facilidad para el
despliegue de ellos tanto en tiempo como en
complejidad y disponibilidad (QA-4, QA-2, qa-
5, qa-6)
Kubernetes Gestor u orquestador de contenedores que
permite el autoescalado de los microservicios
cuando sea necesario, así como garantiza alta
disponibilidad por medio de dicha gestión y la
facilidad para despliegue (QA-2, QA-3, qa-5,
qa-6)
MFA (Multi-factor authentication) Mecanismo que nos permite manejar doble
factor para la autenticación de aplicaciones
con operaciones críticas (QA-1)
Spring Security Framework para Java que nos permite
manejar tanto la autenticación como la
autorización de nuestro aplicativo (QA-1). Este
framework puede implementarse en un
microservicio. (CRN2, CRN3, R3)
Azure WAF / Azure DDOS Mecanismos o elementos de la nube de azure
que nos permiten protegernos frente ataques
cibernéticos como DDOS, XSS, SQL Injection.
Esto nos ayuda con los requerimientos de
Seguridad (QA-1)
Api Gateway Elemento o puerta de enlace hacia los
microservicios del aplicativo el cual nos
permite enrutar la solicitud al microservicio
correspondiente, así como filtrar el tráfico
incorrecto y proteger la exposición de
nuestros microservicios de manera pública
(QA-1)
REST Protocolo que nos permite la comunicación a
través de nuestros microservicios. Al contar
con un formato más sencillo y ligero nos ayuda
 a ganar en la performance del aplicativo (QA-
3)

Entre otras opciones se tienen:

GraphQL: Se descarta debido a que no se

tienen conocimiento de los desarrolladores en
esta tecnología

SOAP: Si bien es cierto que SOAP es un

protocolo más seguro, nos agrega dificultades
en la performance al ser un formato más
pesado por lo que se descarta.

Manejo de cluster primario-secundario en Al usar este patrón o esquema para la base de

base de datos datos vamos a tener un nodo primario el cual
se encuentra activo para el funcionamiento y
un nodo secundario el cual en caso de fallas en
el primario este comience a funcionar. (QA-2)
Principios SOLID Dichos principios nos ayudan a mejorar la
mantenibilidad del sistema asignando las
responsabilidades de cada módulo de manera
correcta y reduciendo el grado de
dependencias (+ cohesión – acoplamiento)
Paso 5: Instanciar los elementos arquitecturales, asignar responsabilidades y definir interfaces
Decisiones de diseño
Establecer Azure Cloud como proveedor de
nube
Establecer ReactJS como tecnología para el
componente frontend
Uso de formato JSON para el transporte de
datos
Uso de protocolo REST para los microservicios
Despliegue de los microservicios en Docker-
Kubernetes
Uso del servicio AKS para la implementación
de Kubernetes
Establecer microservicio de seguridad con
Spring Security
Establecer un microservicio para cada módulo
Establecer cluster primario y secundario en la
base de datos MySQL
Establecer servicio de Azure API Management
como el API Gateway de nuestra aplicación
Rationale
Debido al R1 se establece azure como nube de
trabajo y se hará uso de sus servicios.
Para nuestro componente frontend vamos a
implementar con ReactJS por los motivos
descritos en el paso 4
Debido que nuestros microservicios se
encuentran en REST, vamos a manejar el
formato JSON para el transporte de la
información, el cual al ser ligero nos ayuda en
la velocidad de las transacciones.
Los servicios o endpoints de los diferentes
módulos serán implementados con REST por
lo mencionado en el paso 4
Los diferentes microservicios serán
desplegados en Docker y a su vez estos serán
gestionados por Kubernetes.
Al estar en la nube de Azure, se usará el
servicio de AKS para trabajar con Kubernetes
Como se menciono en el paso 4,
implementaremos el framework Spring
security en java para parte de la seguridad de
nuestra aplicación para establecer
mecanismos de seguridad como JWT (JSON
Web Token) para la autorización de nuestros
microservicios y MFA para la autenticación
multi factor.
Siguiendo el principio SOLID y el principio de la
arquitectura microservicio, cada módulo será
un microservicio de la siguiente manera:
 MS de Tramites
 MS de EECC
 MC apertura sin provisional
Se implementará este patrón para manejar
una mayor disponibilidad a nivel de base de
datos
Al hacer uso de la nube azure, el servicio API
management nos ayudará a cubrir con las
tareas descritas por el elemento API Gateway.
Paso 6: Definir bocetos

Elemento Responsabilidad
MS Seguridad Microservicio orientado a la seguridad del
aplicativo que implementa los diferentes
mecanismos de seguridad.
MS Tramites Microservicio orientado a los tramites digitales
MS EECC Microservicio orientado a la visualización y
descarga de EECC
MS Apertura Cuenta Microservicio orientado apertura de cuenta
sin fin provisional
BD Seguridad primaria Base de datos primaria de seguridad
BD Seguridad secundaria Base de datos secundaria de seguridad en caso
falle el nodo primario
BD Tramites primaria Base de datos primaria de tramites
BD Tramites secundaria Base de datos secundaria de tramites en caso
falle el nodo primario
BD Apertura primaria Base de datos primaria de apertura de cuenta
sin fin provisional
BD Apertura secundaria Base de datos secundaria de apertura de
cuenta sin fin provisional en caso falle el nodo
primario
AKS Service Servicio de azure que trabaja como
kubernetes para la gestión de escalamiento de
las instancias de los microservicios
Api Management Servicio de azure que trabajaría como API
Gateway para la gestión de las solicitudes
 dadas por el frontend
Frontend Componente donde se implementa la interfaz
de usuario hecha con la librería javascript
ReactJS
WAF Elemento de azure que actúa como Firewall
para proteger el aplicativo de ataques
Azure DDOS Elemento de azure que protege el aplicativo
de ataques DDOS.

Paso 7: Review Iteración

No Parcialmente Completamente Decisiones de diseño durante la

realizado realizado realizado iteración
Se tiene bosquejado el
HU-1 microservicio de tramites en la
arquitectura para realizar los
requerimientos.
Se tiene bosquejado el microservicio de
HU-2 EECC en la arquitectura para realizar
los requerimientos.
Se tiene bosquejado el
HU-3
microservicio de apertura de cuenta
en la arquitectura para realizar los
requerimientos.
Se cumple el atributo con la
QA-1 implementación de microservicio de
spring security así como controles como
el API Gateway, DDOS y WAF
La arquitectura de microservicios nos
ayuda a mantener la disponibilidad en
QA-2 gran medida de nuestro aplicativo, así
como el escalamiento a través de AKS
El uso de servicios REST y REACT en
QA-3 el frontend nos ayudan a mejorar la
performance en nuestro aplicativo
QA-4 La arquitectura de microservicios nos
brinda el beneficio de poder hacer
nuestros módulos mantenibles sin que
los cambios de uno afecten a otro
QA-5 El uso de Docker-kubernetes nos ayuda
a escalar nuestra solución de nuestros
microservicios.
QA-6 El uso de la arquitectura microservicios
nos ayuda adicionar nuevos módulos sin
impactar a otros
QA-7 El uso de la arquitectura microservicios
nos ayuda a la desplegabilidad de las
soluciones al poder cambiar los
módulos de forma independiente.
CRN-001 La arquitectura microservicio nos
CRN-002 ayuda a cumplir estos puntos gracias a
CRN-003 su capacidad de ser modular y versátil.
CRN-004
R1

R2

R3