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!

Comentarios

  1. Hola Sandra, muy interesante tu artículo. La ruptura de paradigmas de este tipo nos ayuda a enfrentar mejor un mundo de cambios tecnológicos tan agresivos en el que actualmente vivimos. Estoy llevando un trabajo de investigación al respecto, pero no tengo claro el enfoque que le daré ya que el tema es bastante amplio ¿Podrías darme algunas pautas al respecto?

    ResponderBorrar
    Respuestas
    1. Hola Oscar, una disculpa de antemano por esta respuesta tan tarde.

      Aún te interesa el tema? Ya terminaste de desarrollarlo?

      Saludos!

      Borrar
  2. Hola Sandy. Interesante, muy interesante. Cambiar la visión y entender lo que se puede hacer con las nuevas tecnologías es un gran reto. ¿Alguna referencia que me puedas recomendar?

    ResponderBorrar
    Respuestas
    1. Hola Güicho, así es, estos temas son muy interesantes y muy retadores, ya que requieren ampliar nuestras áreas de conocimientos.

      Por el momento no se me ocurre alguna referencia, si algo se viene a mi mente te lo hago saber.

      Saludos!

      Borrar
  3. Hola Sandra, inicialmente gracias por compartir conocimiento. Ya había tenido la experiencia de ver dicho stack y si bien es cierto "le da orden a la casa" por lo menos en la identificación y separación de los roles (y considero que faltaría incluir el UDDI de Oracle (ORM) y quizá también la OIM para la gobierno de "assets" de TI y no queriendo ser muy purista) en lo que quiero enfatizar y discrepar es que no estoy de acuerdo en que los componentes de spring/Hibernate sean un framework pesado (con una mínima argumention técnica casi que nula) y ya por eso lo desacredites, etc para una solución empresarial alienada al rumbo cambiante de los negocios. Hay que recordar por ejemplo que el framework ORM que usa por ejemplo OSB 11g y BPEL 11g es nada más y nada menos que ECLIPSELINK/TOPLINK y si bien buscamos un benchmark de los ORM usados, este no está bien posicionado frente a otros, como Hibernate.

    ResponderBorrar
    Respuestas
    1. Hola Leonel, te agradezco mucho tus comentarios, me parece muy valiosa tu aportación.

      De entrada pido una disculpa si mi post refleja algo que no es, probablemente no plasmé mi idea correctamente y puede ser malinterpretada, sin embargo mi intención no es desacreditar a Hibernate, Spring o cualquier otra herramienta, en realidad yo he trabajado con ellos durante mucho tiempo y he sido fan desde mis inicios de programación, así como también de otras herramientas y frameworks, y sin duda opto por recomendarlos cuando las circunstancias lo ameritan.

      Lo que yo quise transmitir es que he visto varios clientes con problemas similares que deciden cambiar radicalmente, en resumen, desafortunadamente las malas prácticas de programación que se van acumulando con los años y que eventualmente se convierten en una gran bola de nieve (cosa que puede pasar en cualquier tecnología), es una de las principales razones que ha motivado a este cambio de arquitectura empresarial hacia una separada en aplicaciones de industria, lo cual tiene ciertas ventajas, y por supuesto implicaciones, y que definitivamente no significa que todo va a funcionar de maravilla.

      El ejemplo que puse hace referencia a un caso muy particular, por lo que traté de mencionar las razones de dicho cliente y la resolución de su nueva a arquitectura a manera de contestar esa pregunta. En realidad no digo que Hibernate sea pesado y por eso el cliente decidió cambiar, sino que el mal uso de Hibernate y Spring, la baja calidad de la programación, más un diseño inicial con un alcance limitado, con el tiempo les ha costado mucho más dinero, trabajo, pérdidas y entregas productivas de semanas que deberían ser de horas. Y el tema es que por más recursos de infraestructura que se le pongan, sus aplicaciones ya no soportan la operación, y mucho menos pueden ir a la par de la demanda del negocio, lo que les ha dado la perspectiva de que no tienen nada de flexibilidad al cambio.

      Factores como estos, la presión del mercado de implementar cada vez más con herramientas de cloud, entre otros, son los que veo que afectan esas decisiones, y ciertamente me guste o no, es una realidad con la que nos toca lidiar.

      Espero haber clarificado un poco mejor mi punto de vista.

      Saludos!

      Borrar

Publicar un comentario

Entradas más populares de este blog

Conceptos básicos de Servicios Web SOAP, WSDL y XSD

OWSM and WS-Security: Username Token Authentication for SOAP and REST Services in OSB 12c.

Conversión de servicios SOAP a REST/JSON usando OSB 11g