Cambiando el enfoque de Arquitectura; de Empresarial hacia Servicios

¡Hola que tal!

Decidí escribir este post derivado de que en los últimos meses he estado involucrada en varios proyectos que tienen un patrón en común. He notado que grandes compañías que desde hace algunos años han operado con sistemas basados en aplicaciones empresariales, están cambiando de enfoque arquitectónico, y en el proceso de explorar nuevas arquitecturas, una de las opciones lógicas es usar servicios, y no me refiero a únicamente implementar servicios web, sino que además requieren una capa de integración que resuelva diversos temas, es decir, están optando por implementar arquitecturas orientadas a servicios y automatización de procesos. A continuación analizaremos algunas de las principales razones que he podido identificar para incentivarlos a llegar a ésta determinación y cómo podríamos llevar a cabo dicho cambio, diseñando una arquitectura acorde a la situación.

Pensemos en el siguiente ejemplo que muestra una arquitectura de estilo empresarial con Java, en la cual se mezcla una serie de componentes Opensource, que le proveen la característica de Orientación a Aspectos, persistencia por medio de objetos, entre algunas otras, tal como se ilustra en el diagrama:

Estamos hablando de una aplicación web sencilla pero bien definida, cuya funcionalidad seguramente cubre los objetivos para los cuales fue diseñada inicialmente, definitivamente cumple con una estructura en capas, tiene la posibilidad de conectarse con diversas tecnologías fuera de la aplicación y usa en su mayoría herramientas Opensource, lo que la convierte en una opción económica.

A simple vista no representa mayores problemas que la complejidad misma del negocio, embebida en la capa de servicios, y quizás los temas que impliquen las prácticas que se han adoptado en la construcción de código. Entonces ¿Cuál es el verdadero problema? ¿De dónde surge la necesidad de cambiar el diseño de éstas aplicaciones que parecieran no ser problemáticas?

Podríamos pensar que es cuestión de actualización o de ir con las tendencias tecnológicas, por ejemplo, ahora que el tema de los Microservices y APIs está tomando un papel protagónico en el diseño de arquitecturas, es fácil visualizarnos en escenarios donde querríamos colocarlos.

Sin embargo, más allá de las tendencias y lo que decidamos usar para implementar una transformación tecnológica, la razón fundamental siempre será la misma, el negocio u operación de la organización demanda un crecimiento cada vez mayor y más rápido, mismo que debe ser soportado por la tecnología. Si las aplicaciones actuales no pueden avanzar al mismo ritmo que el crecimiento operativo, éstas tienden a ser obsoletas y limitantes.

Con éste precedente, podemos establecer que el primer factor de cambio es precisamente la falta de agilidad al cambio. Esta idea es refutable con el argumento de que no por ser una sola aplicación, el proceso de cambio tiene que ser demasiado lento, y si bien esto es cierto para aplicaciones bien controladas, también es un hecho real que la mayoría de los proyectos que inicialmente fueron pensados con un alcance, con el tiempo van creciendo desmedidamente, y como ejemplo, lo que comenzó como una aplicación construida por un equipo de 5 personas, se vuelve en monolito en el que intervienen más de 20, tratando de generar un solo archivo desplegable. Sobra decir que los errores humanos están a la orden del día y los controles de cambios y despliegues se convierten en una pesadilla.

El siguiente factor detectado en estas aplicaciones, es que a pesar de que están divididas en capas, muchas veces tienen las responsabilidades mezcladas, por ejemplo, cuando en la capa de presentación e interpretación se agregan validaciones de negocio que implican un flujo cada vez más complejo, con la justificación de que son validaciones de presentación, y que además en un inicio eran muy simples, con el tiempo se convierte en el patrón de implementación. Otro factor relevante es el uso de control de accesos por rol a los componentes en cada pantalla, mismos que agregan complejidad y segregan en cada una, lógica de validaciones de roles. Estas prácticas provocan el aumento de carga de la capa que solo debería tener objetos ligeros de presentación.

Otro factor determinante es la falta de flexibilidad a los cambios en los servicios de negocio. Pensando en una aplicación donde la reutilización de los objetos es reducida, y por otro lado, el acoplamiento con las tecnologías es alto, el impacto de un cambio en algún elemento genera un efecto dominó, sin mencionar la duplicidad de reglas de negocio, o dicho de otra forma, la falta de centralización de éstas, que implican que un cambio pequeño se convierta en días enteros de prueba y error.

En el caso del ejemplo mencionado al inicio, se usó hibernate para la persistencia en base de datos. Se adoptaron prácticas tales como usar de manera excesiva objetos QueryByExample, mismos que generan en tiempo de ejecución los objetos de mapeo para ejecutar los accesos a BD, además de que los mezclaron con objetos Spring JDBC. Todas estas condiciones particulares hicieron que la capa de acceso a datos sea demasiado lenta y que consuma muchos recursos, lo que originó la necesidad de agregar una gran cantidad de infraestructura que soportara dicho procesamiento. Definitivamente esta solución es muy costosa, además de ser un círculo vicioso, porque entre más accesos a base de datos se requieran, más recursos demandará. Entonces, partiendo de este escenario, la idea de tener una capa de acceso a datos completamente homogénea, sin frameworks pesados y con posibilidades reducidas de mal uso de los objetos, es un must que las arquitecturas deben contemplar.

Esta es solo una lista representativa de las posibles áreas de oportunidad que presentan las arquitecturas en cuestión, y dado que la intención es mostrar cómo quedaría representado un diseño arquitectónico más flexible, que contrarreste los problemas del presente, en el siguiente diagrama conceptual se ilustra un ejemplo de lo que éste pudiera contener.

En este diseño se contempla el uso de herramientas del stack de Oracle de capa media en ambientes OnPremise, desde el front end, back end y hasta el control de identidad y accesos de los usuarios.

En cada capa se segmentan las responsabilidades y funciones de los elementos, permitiendo:

• Crear una interfaz gráfica tan robusta como un Portal o tan ligera como un sitio web, capaz de incluir tecnologías como Node.js, y exponerla de diferentes maneras, para que pueda ser interpretada por diversos canales, usando ADF y las herramientas de Webcenter.
• Realizar la automatización de procesos de negocio por medio del Business Process Manager (BPM).
• Mantener un punto de centralización de acceso a todas las aplicaciones de la organización, que a su vez permite rutear y mediar mensajes, realizar transformaciones de datos y usar una serie de componentes tecnológicos que robustecen las integraciones, internas a la organización y con los socios de negocio, por medio del Oracle Service Bus (OSB).
• Generar composiciones de servicios usando diferentes tipos de adaptadores, con el fin de orquestar las invocaciones a las diversas aplicaciones y fuentes de datos, de manera estandarizada y visual, por medio de BPEL y Mediator.
• Agrupar y ordenar las reglas de negocio, hacerlas editables por personas no técnicas y exponerlas como servicios de validación para ser usados en cualquier punto de los procesos, usando Oracle Business Rules (OBR).
• Proveer visibilidad a los usuarios de negocio sobre el comportamiento de la operación en tiempo real, por medio de tableros con distintos tipos de gráficos, usando Business Activity Monitoring (BAM).
• Controlar la identidad y los accesos que poseen los usuarios y propagarlos hacia el resto de los elementos de la arquitectura, usando Oracle Identity Manger (OIM) y Oracle Access Manager (OAM).

De esta forma, no solo trabajamos apegados a estándares de la industria, sino que además se fomenta la separación de responsabilidades, incrementamos la agilidad debido a que cada elemento es independiente de los demás y ponemos en práctica una serie de principios básicos que, bien aplicados, aportarán cambios significativos al negocio.

Espero que esta explicación sea lo suficientemente clara para poder mostrar porqué las arquitecturas segmentadas son preferibles sobre las autocontenidas.



¡Hasta pronto!