Arquitectura de negocio Center-out

La arquitectura de software implica resaltar los componentes esenciales y de alto nivel que se necesitan para una aplicación. La arquitectura también describe la dependencia e interacción entre los componentes de la aplicación. Elegir la arquitectura correcta ayuda a lograr la capacidad de cambio y escalabilidad necesarias en una aplicación.

Como Lead System Architect (LSA), debe proporcionar soluciones de negocio para los problemas de negocio mediante la definición de la arquitectura centrada en el panorama general. En general, la arquitectura de software se compone de tres capas, como se muestra en la siguiente imagen:

En las aplicaciones de Pega, la arquitectura de negocio Center-out™ es una arquitectura de software ajustada para lograr los resultados del cliente y el negocio. Proporciona resultados significativos con rapidez y mantiene la arquitectura en el tiempo evitando errores con los enfoques descendentes y ascendentes.

El enfoque descendente diseña las aplicaciones específicas de los canales de interacción. Una de las desventajas más significativas del enfoque descendente es implementar la misma lógica de capas de presentación varias veces para ofrecer una experiencia constante en los canales.

El enfoque ascendente diseña la implementación centrada en el producto. El riesgo con el enfoque ascendente es que cada sistema tiene su propia vista de los datos que usan sus aplicaciones. Los sistemas heredados creados en silos atraen duplicados de los datos que se mantienen en otros sistemas. Los mismos datos pueden estar en varios sistemas. Además, diferentes partes de los datos sobre una única entidad de negocio (un cliente) pueden estar en diferentes sistemas, sin que haya una solución individual para proporcionar una vista única de la entidad completa.

El enfoque Center-out une el negocio con la TI para poder centrarse en el resultado de negocio e innovar rápidamente las soluciones. Los equipos pueden implementar soluciones de nivel empresarial en semanas o días de forma colaborativa desde una plataforma low-code compartida, con prácticas recomendadas del pensamiento de diseño incorporadas.

El enfoque Center-out se trata de:

• Centrarse en los objetivos de Microjourney™
• Identificar cuando se necesita una interacción con un canal para completar un paso
• Identificar qué datos son necesarios para completar un paso o qué datos se actualizan al completar un paso

Se necesitan tareas de configuración basadas en modelos de Pega para “activar un canal” y “conectarse a un origen de datos” a fin de completar la implementación. Esta opción es mejor que lo siguiente:

1. “Desarrollar una solución web”, método que rápidamente tiene problemas para considerar cómo la misma solución se puede ofrecer como una app móvil, un chatbot o cómo se puede usar como un componente de otra aplicación mediante API;
2. “Implementar un nuevo módulo SAP”, que se limita a las unidades de negocio que usan SAP y puede tener una vista limitada de los datos disponibles del negocio.

El diseño de las aplicaciones de Pega comienza con el enfoque Center-out. Los cinco pasos de esta arquitectura se organizan en torno a los clientes y los resultados del negocio.

1. Comenzar con un cerebro: gestionar la inteligencia de forma central: Los resultados de negocio deberían guiarse por la información del cliente en tiempo real; las reglas se aplican de forma constante y todas las acciones recomendadas están en el destino.
2. Hacer el trabajo: centrarse en los resultados y alinear su proceso: Usar la gestión de casos para gestionar, automatizar y mejorar el trabajo mediante un enfoque Microjourney que implementa una parte del recorrido del cliente en función de un resultado específico.
3. Conectarse a los canales: experiencia constante: Mantener la lógica de front-end y back-end coordinadas mediante la API Pega Digital Experience. Los cambios se presentan de forma dinámica sin tener que volver a codificar.
4. Conectarse con los datos y mantener una lógica ágil: Analizar los sistemas de back-end para extraer datos importantes sin sumar complejidad. La capa de virtualización se llama Pega Live Data. Pega Live Data permite a los usuarios definir de forma rápida y sencilla los datos requeridos para crear las aplicaciones que necesitan y, a continuación, acceder a esos datos en su aplicación en ejecución, todo ello sin tener que preocuparse de cómo y dónde se almacenan los datos y cómo y desde dónde acceden a ellos.
5. Estar listos para escalar, gestionar la variación: La arquitectura Situational Layer Cake™ de Pega ayuda a adaptar los Microjourneys a los diferentes tipos de cliente, líneas de negocio, ubicaciones geográficas, etc. Comience a pequeña escala y con agilidad. Escale para ser grande, más amplio y esté preparado para el futuro.

Front Stage Group (FSG) es una importante empresa proveedora de servicios relacionados con eventos, como reservas de eventos, reservas de hotelería y servicios de transporte. FSG proporciona servicios a clientes que provienen de diferentes regiones mediante diferentes canales de comunicación. Su sistema de base de datos es una combinación de bases de datos heredadas y modernas para conservar los datos. Las aplicaciones heredadas actuales de FSG implementadas usando otras tecnologías y estilos de arquitectura funcionan bien. Los canales de front-end de FSG incluyen una aplicación de centro de llamadas que la usa CSR, una aplicación web que la usa el usuario final y una aplicación de chatbot para responder las preguntas frecuentes del cliente. Cada canal obtiene la información directamente del origen según sea necesario, no hay una capa en común para todos los canales de front-end. Los sistemas de back-end incluyen una base de datos local, una base de datos en la nube, un sistema ERP y un sistema de mainframe. El acceso de datos y la lógica de persistencia se escriben según el proveedor.

El equipo del centro de excelencia (COE) recientemente creado ha previsto algunas posibles limitaciones de estas aplicaciones. Se explican a continuación:

Problema 1: El enfoque descendente de FSG funciona bien para la comunicación específica de un canal en el escenario actual. FSG puede presentar un nuevo canal para soportar la competencia del negocio, lo que implica escribir un código nuevo. Puede ser tedioso y complejo mantener un código específico del canal, ya que hay posibilidades de que la coherencia en la comunicación entre los canales disminuya o sea nula. La suma de un canal nuevo debe hacerse desde cero, ya que no hay oportunidades de reutilizar las capacidades implementadas en otros canales.

Problema 2: El enfoque ascendente de FSG usa una lógica de base de datos específica del proveedor para acceder a los datos e imprimirlos. No hay una lógica de virtualización de datos. La configuración actual de la base de datos y las aplicaciones dependientes funciona bien. Sin embargo, si el proveedor de base de datos cambia los protocolos de acceso a los datos, FSG debe volver a escribir el código para almacenar y acceder a los datos. Si se agrega algún sistema de base de datos nuevo, también se debe agregar más código.

Un equipo de COE de FSG creado hace poco ha propuesto la arquitectura de negocio Center-out de Pega.

La solución al problema 1 (en la arquitectura existente) usa Pega 8.x para crear aplicaciones. El motor, los procesos y las políticas de las reglas de negocio están disponibles para todos los canales e interfaces. Proporciona una experiencia omnicanal. Los Microjourneys implementados en la arquitectura de negocio Center-out se pueden configurar para entregarse en otros canales.

Por ejemplo, si hay que agregar a Alexa como un canal nuevo, el proceso implica solo agregar los componentes y proporcionarle a Alexa acceso a la aplicación; es rápido y simple.

Pega también ofrece la API Pega Digital Experience (DX). Los clientes pueden entregar experiencias de usuario mediante su tecnología de front-end de preferencia sin tener que duplicar la implementación de las necesidades de interfaz de usuario. Los componentes de Pega se pueden basar en su tecnología nativa y comprenden las acciones del los componentes de Pega disponibles.

La solución al problema 2 (en la arquitectura existente) es usar la capa de virtualización Pega Live Data. El modelo de datos que usa la aplicación de Pega no depende del modelo de datos que se usa en los sistemas de registro. En función de la condición, puede dirigirse al sistema de base de datos requerido para acceder a los datos. Los planes de guardado de datos ayudan a almacenar los datos nuevos o actualizados sin depender del momento y la manera en que llegan los datos.

Por ejemplo, una página de datos en Pega 8.x puede tener dos conectores, uno con protocolo de acceso REST y otro con protocolo de acceso SOAP, que se dirigen a dos sistemas de back-end diferentes (o sistemas SOR), una condición que se evalúa para usar el origen requerido.

El estudio de caso de FSG demuestra claramente los beneficios de la arquitectura de negocio Center-out. Para obtener más información sobre el enfoque Center-out™, consulte Business Architecture Center-out.