Arquitectura técnica

La arquitectura técnica se refiere al diseño de la aplicación en sí misma. Una de las ventajas clave de desarrollar con Pega Platform™ es la capacidad de diseñar su aplicación y reutilizar componentes clave en varios Microjourneys^™ y canales, incluso otras aplicaciones. Con esta flexibilidad, cuando llega el momento de modificar algo, puede hacerlo una sola vez. Se recomienda aprovechar las funciones de Pega Platform en el diseño técnico de su aplicación.

El diseño técnico comienza en la fase de preparación y se refina durante la fase de desarrollo. El Lead System Architect (LSA) conduce la actividad del diseño técnico para asegurarse de que la aplicación que se desarrolla aprovecha de la mejor manera las funciones listas para usar y la reutilización. El LSA se concentra en establecer un diseño técnico de alto nivel y en implementar los componentes fundamentales de la solución.   

Entre los componentes fundamentales, se incluye crear la definición inicial de tipos de caso, Personas y objetos de datos para cualquier Microjourney con prioridad dentro del lanzamiento.

El LSA trabaja con el Product Owner, el Business Architect, el diseñador de la experiencia de usuario y los arquitectos técnicos del cliente para acordar un diseño de alto nivel que cumpla las metas de negocio (actuales y futuras) y se alinee con la infraestructura técnica existente del cliente. 

Como parte de la actividad de diseño de la aplicación, el LSA asegura la implementación de prácticas recomendadas en estas áreas:      

• Estructura de la aplicación 
• Modelo de datos
• Diseño de casos
• Seguridad y acceso del usuario 
• Integración
• Implementación y DevOps
• Creación de reportes
• Experiencia de usuario/interfaz de usuario

El LSA también es responsable de la calidad técnica de la aplicación. La práctica recomendada de Pega Express^™ es automatizar las pruebas de unidades y escenarios para garantizar la calidad del desarrollo y establecer los procesos de DevOps con el fin de racionalizar la integración de los cambios en la aplicación. El LSA es responsable de garantizar que la estructura de la aplicación esté organizada de modo tal que admita las pruebas automatizadas. Para obtener más información sobre las pruebas, consulte el tema de Pega Academy Abordajes cruciales para pruebas.   

Antes de crear la aplicación (para obtener más información, consulte nuestro curso de Senior System Architect), el LSA trabaja con el Product Owner y los Business Architects para comprender el alcance de la aplicación dentro de la organización. En función de esta información, el LSA se asegura de que la aplicación esté diseñada para admitir tanto las metas de negocio inmediatas como las de largo plazo.

La información del negocio es esencial porque Pega Platform le permite a usted organizar la aplicación con las mismas dimensiones que el negocio. Puede reutilizar los procedimientos y las políticas comunes, a la vez que acomoda las diferencias entre productos, regiones, canales y segmentos de clientes.

Esta flexibilidad se logra mediante la organización de aplicaciones en capas, una sobre otra. Esta disposición resulta en una estructura de un Situational Layer Cake que se compone de cuatro niveles:

• Organización
• Framework
• División
• Implementación 

Para obtener otra perspectiva de la importancia de la estructura del Situational Layer Cake, consulte esta Charla destacada de socio en Pega Community.  

En la siguiente imagen, haga clic en los íconos + para obtener más información sobre cada una de las cuatro capas de la estructura del Situational Layer Cake.

Un minorista de indumentaria tiene dos marcas de tiendas. Una marca se concentra en el mercado exclusivo de indumentaria, mientras que la otra marca administra una cadena de tiendas con precios competitivos. Cada marca debe gestionar artículos devueltos. El minorista puede desarrollar una aplicación generalizada que gestione las devoluciones de prendas en la capa Framework. Cada marca puede crear luego una capa Implementación para personalizar el proceso de devolución. Cada aplicación personalizada contiene activos específicos de la marca, como el estilo y las políticas.

Las decisiones de diseño técnico que se toman en la fase de preparación pueden reflejar la estructura de una aplicación en las siguientes capas:

Desde la ubicación superior y hacia abajo de las capas:

• Las capas superiores son las capas Implementación (una para cada tienda) que se ubican lado a lado sobre la capa Framework. Cada capa Implementación es específica de cada tienda e incluye especialización de devoluciones y marca exclusiva.
• Debajo de las capas Implementación, se encuentra la capa Framework, que contiene componentes técnicos comunes para el proceso de devolución. La capa Framework se encuentra por encima de la capa Organización.
• A su vez, la capa Organización se encuentra sobre la capa Pega Platform y contiene los activos técnicos comunes para todas las áreas del negocio. Esta se encuentra en la capa inferior de la aplicación de modo que cualquier proceso o tienda que necesite reutilizarla pueda hacerlo.
• Por último, la capa Pega Platform se encuentra en la base, lo que permite que las capas superiores puedan usar toda funcionalidad residual.

Las aplicaciones requieren datos de algún tipo de fuente, ya sea dentro de la empresa o externa a la organización.

• Orígenes de datos dentro de la organización: se trata de los datos almacenados dentro de aplicaciones de Pega Platform y otros sistemas desfasados dentro de la organización.
• Datos externos a la organización: se trata de los datos almacenados en aplicaciones o sistemas de software de terceros.

Para comenzar el modelo de datos, debe determinar qué elementos de datos están almacenados dentro de los sistemas existentes. En total, se deben considerar los datos provenientes de tres fuentes: Pega, la empresa y datos externos.

Cuando se tienen en cuenta las decisiones de diseño en relación con los datos, hay tres aspectos que se deben considerar:

• Modelo de datos empresarial: los datos son aplicables en el nivel empresarial y están disponibles para todas las aplicaciones desarrolladas o configuradas dentro de la empresa.
• Modelo de datos de la aplicación: los datos que se mantienen dentro de la aplicación.
• Modelo de datos vigente: los datos que requieren una búsqueda o un origen de datos de referencia.

Una empresa, MyDebt, ofrece soluciones de gestión de deuda a las personas que transitan una dificultad financiera. MyDebt tiene una aplicación de Pega Platform llamada DebtSol que le proporciona al personal de primera línea de casos de deuda la capacidad de tomar llamadas de individuos y ofrecer soluciones para afrontar sus dificultades actuales.  La solución está diseñada para registrar detalles acerca del individuo y su situación financiera actual, por ejemplo, deudas, ingresos, gastos y activos, y luego usar reglas de negocio para ofrecer una solución que resuelva sus deudas.

El modelo de datos de la aplicación reutiliza un modelo de datos existente de clase empresarial para registrar los detalles individuales de la Persona e identificó un modelo de datos específico para la aplicación DebtSol.

En la siguiente imagen, haga clic en los íconos + para ver el modelo de datos de ejemplo.

La autenticación en Pega Platform garantiza que únicamente los usuarios y sistemas con identidades verificadas puedan acceder a los recursos, como páginas web, API y datos.

Entre los ejemplos de autenticación, se incluyen:

• Inicios de sesión de usuario
• Solicitudes de la plataforma a servicios externos
• Solicitudes de servicios externos a la plataforma

Tenga en cuenta y prefiera un mecanismo de autenticación y una configuración adecuados para los registros del operador que contemple la jerarquía organizacional, los grupos de trabajo y las colas de trabajo. Para restringir las acciones de usuario, puede usar funciones de Pega Platform para la autorización o el control del acceso. 

Revise los tres modelos de autorización básicos por adelantado con el equipo para decidir cuál es el modelo aplicable al proyecto.

• Control de acceso basado en roles (RBAC)
• Control de acceso basado en atributos (ABAC)
• Control de acceso basado en cliente (CBAC)

Seguridad

También es importante revisar y determinar cuáles son los elementos de la lista de verificación de seguridad que se aplican al contexto del proyecto durante la fase de preparación.

Preste especial atención a los siguientes factores: 

• Esquema de autenticación
• Grupos/roles de acceso
• Estructura de la organización
• Configuración de tiempo de espera
• Auditoría
• Seguridad de cargas de archivos   

Para cada dato confidencial o información de identificación personal, aplique las medidas de seguridad adecuadas para proteger el acceso y la configuración del usuario, como cifrado, ofuscación o acceso controlado.

Para obtener más información acerca de la seguridad de la aplicación, consulte el tema de Pega Academy Lista de verificación de seguridad.

Pega Platform es compatible con una variedad de estándares de integración y protocolos de comunicación. Esto permite que usted se centre en abordar los requerimientos del negocio de su aplicación en lugar de enfocarse en los problemas de conectividad. Para cada componente de integración, revise y valide que dispone de los detalles adecuados para la configuración y la entrega.  

Por ejemplo, asegúrese de tener visibilidad, comprensión y claridad en relación con los siguientes aspectos de cada componente de integración:

• Direcciones URL por entorno
• Protocolos
• Autenticación
• Repositorio en cloud o en las instalaciones, o de terceros (gestión de contenido)
• Versiones de SSL/TLS
• Certificados
• Puertos

La implementación de la aplicación se realiza durante el ciclo de vida del proyecto para migrar la aplicación por los diferentes entornos, desde el desarrollo hasta el armado y la producción. El departamento de TI del cliente y su equipo técnico deben acordar un enfoque para gestionar el trabajo dentro del entorno de desarrollo y de qué manera implementar mejor la aplicación. Incluya DevOps desde el principio del proyecto.

El LSA lidera los debates de DevOps durante la fase de preparación para asegurar la adherencia a las prácticas recomendadas de Pega Express, lo que garantiza calidad técnica y velocidad en la entrega.  En estos debates, el LSA establece la estructura de la aplicación y las prácticas recomendadas de DevOps para el equipo técnico de la aplicación de Pega.    

Al usar el enfoque de entrega de Pega Express, adoptar un enfoque de DevOps en el desarrollo de aplicaciones implica que los desarrolladores usen la práctica recomendada de trabajar en sucursales para configurar sus actualizaciones a la aplicación y definir procesos de implementación a fin de migrar la aplicación de un entorno a otro. Desde el principio se deberían configurar implementaciones completas. De esta manera, la aplicación en su totalidad se migra de un entorno a otro, en lugar de hacerlo en paquetes incrementales. 

Aplicar esta práctica recomendada asegura que el paquete de implementación contenga una colección acumulativa de todas las reglas que rigen la aplicación y los datos, a la vez que otorga flexibilidad, ya que solo se implementa lo que ha cambiado desde la última implementación.

Los procesos de DevOps se deberían configurar con todos los controles y balances, entre ellos:

• Lista de verificación de seguridad
• Cumplimiento del sistema de contención
• Ejecución de pruebas de unidad y escenario
• Garantizar la calidad de la aplicación a medida que se migra de un entorno a otro   

Defina una estrategia clara de creación de reportes desde el inicio para garantizar que la aplicación de Pega Platform esté diseñada para satisfacer tanto las necesidades operativas como de creación de reportes de gestión del negocio. A menudo, las organizaciones requieren que las aplicaciones de Pega Platform proporcionen datos a las soluciones existentes de depósito de datos empresariales.

Una práctica recomendada es extraer datos de Pega Platform mediante la herramienta de extracción de páginas, Business Intelligence Exchange (BIX). Identificar este requerimiento en el inicio influye en la configuración de los objetos de datos en la aplicación de Pega Platform y en la solución de interfaz que se utiliza para integrar con el depósito de datos. 

Estos son problemas de diseño clave que se deben decidir de antemano cuando se debe tratar con la extracción de datos:

• Frecuencia de extracción (como diaria/semanal)
• Diseño de extracción de transacciones (cada transacción o transacciones acumuladas al final del día)
• Historial de transacciones
• Todas las propiedades o propiedades específicas
• Formato de extracción (CSV, XML o DB)

La arquitectura de interfaz de usuario (UI) forma parte del diseño técnico de la aplicación. 

La UI cubre lo siguiente:

• Prácticas recomendadas para adoptar durante el proyecto
• Prácticas de trabajo para el equipo  

Al comienzo del proyecto, el desarrollador de soluciones de UI, en colaboración con el Product Owner, el Lead Business Architect, el Lead Systems Architect y el evaluador, lleva adelante varias sesiones para definir la arquitectura de UI.  Estas decisiones anticipadas garantizan que la UI sea sencilla de mantener, consistente en toda la aplicación y que adhiera a las prácticas recomendadas de UI.  

El desarrollador de soluciones de UI considera lo siguiente:

• Sistemas de diseño
• Reutilización de presentaciones (como experiencia de marca y diseño de estilo)
• Requerimientos no funcionales
• Arquitectura de autoservicio web
• Procesos de gobernanza

A partir de la versión 8.3 de Pega Platform, usted puede acelerar su UI con Cosmos de manera impecable.  Para obtener más información acerca de cómo Cosmos ayuda a crear una experiencia de usuario de primera línea, consulte el evento TechTalk en Pega Community, Accelerate your workflow with Cosmos UI (Acelere su flujo de trabajo con UI de Cosmos). 

En la siguiente imagen, haga clic en los íconos + para obtener más información sobre la UI.