Arquitectura TI: Tips de ciclos de vida de un diseño y gestión de servicios de integración

Muchos piensan que desarrollar servicios es solo armar una estructura que genere una respuesta a partir de una petición…y en términos prácticos esto es cierto, sin embargo, vale la pena preguntarse: ¿eso es todo?, la realidad es que no

post-arquitectura-ti

Antes de realizar el diseño de cualquier servicio es necesario tener la respuesta a las siguientes preguntas: ¿Cuál es el objetivo?, ¿A qué unidades de negocio impacta?, ¿Con quién se espera que interactúe?, ¿Qué se espera que responda?, ¿Cuál es el nivel de uso que tendrá? Esto resulta vital para definir la estructura y la tecnología apropiada.

La respuesta a todas esas preguntas pareciera ser sencilla, pero en ocasiones algunos técnicos tienden a no prestarle atención, pasan por alto el objetivo y las necesidades reales y terminan construyendo modelos que son técnicamente correctos, pero funcionalmente no aplicables.   

La arquitectura de servicios no debe ser considerada una receta de cocina, cada organización tiene una historia y una razón de ser diferente, por lo cual, no siempre un modelo o patrón es aplicable para todo el mundo, existen muchas formas de resolver una necesidad, lo importante es que lo que se diseñe y construya cumpla con el principio de la simplicidad, reutilización y robustez. Intentaremos darte una pista de lo que debes considerar para iniciar un proceso de diseño de servicios:

  1. Identifica las tareas principales del área de negocio que requiere automatizar y/o intercambiar información. En palabras sencillas consiste en listar las funciones o la razón de ser de la unidad de negocio. Por ejemplo: Asignar precios, ejecutar pago a proveedores, comprobar nivel crediticio, verificar riesgos.
  2. De la lista identificada priorizar aquello que para el negocio es más urgente resolver, idealmente los usuarios quieren resolver todo a la vez, pero a menos de que tengas un equipo grande de personas no podrás trabajar en todo al mismo tiempo.
  3. Identifica los elementos de información que participan en las tareas definidas en el paso anterior. Esto se refiere a los grupos de datos/documentos que ingresan, los que se generan durante la actividad y los que típicamente se entregan a otras áreas de negocio como resultado de las tareas ejecutadas.
  4. Modela un lenguaje único para referirse a cada elemento de información. En oportunidades encontrarás sistemas e inclusive unidades de negocio dentro de una organización que manejan la misma información, pero con nombres y alcances diferentes. ¡La clave es la estandarización!.

El propósito de esta etapa es definir una estructura común de información clasificada en dominios. Se considera un dominio una colección de entidades asociadas a un área de gestión específica que de cierta forma están relacionadas. Cada entidad debe estar definida en términos de atributos, características y comportamientos.

El modelo de información es un modelo vivo, es decir, que está en evolución constantemente, por lo cual, con cada funcionalidad que analices probablemente requerirá la inclusión de nuevas entidades, hasta que la organización llegue al estado ideal de madurez.

  1. Comienza a diseñar: puedes iniciar con servicios CRUD independientes para cada tarea de negocio identificada, dejando las reglas como un componente aparte que puedan ser invocados desde el servicio. Arma las entradas y salidas en base al lenguaje único, internamente define las transformaciones que correspondan. Para las transformaciones será necesario la traducción del modelo de entidades de negocio a uno o varios modelos técnicos de datos, según la naturaleza de las tecnologías subyacentes con las que cuenta la organización.
  2. Define la estrategia de ejecución a saber síncrona o asíncrona.

Una vez tengas los servicios de bajo nivel de granularidad puedes iniciar con servicios orquestados que combinan servicios de bajo nivel, siempre y cuando el negocio requiere respuestas amplias que combinen información de entidades de negocio diferentes.

  1. Define la tecnología y los elementos que participarán (Seguridad, disponibilidad, concurrencia, auditoría). En ocasiones las limitantes y/o bondades de una tecnología resultan determinantes para cerrar el ciclo de diseño.
  2. Estandariza los mensajes o códigos de respuesta que utilizarán los servicios.
  3. Documenta cada servicio con el mayor nivel de detalle posible: Entradas y validaciones, salidas, transformaciones, reglas que participan. Considera el camino feliz y todas las acciones alternas en caso de error o falla. En algunos casos dependiendo de la tecnología o el nivel de granularidad que tengan los servicios, la gestión de Rollback se puede delegar a nivel de los Stores Procedures creados en la base de datos.

Para documentar existen muchas herramientas, nuestra recomendación es que uses alguna que te permita elaborar diagramas de secuencia bajo notación UML.

  1. Controla las versiones de tus servicios, esto es importante porque te ayudará a manejar de forma eficiente los cambios o mejoras futuros.

¡Esperamos que estos tips te sean de ayuda para iniciar este interesante camino en el desarrollo de servicios! ¡Recuerda que el éxito depende de la constancia!

Si quieres recibir más información

Si estás interesado en saber más sobre Soaint y sus servicios déjanos tu correo electrónico y nos pondremos en contacto contigo a la mayor brevedad posible.

Comparte este artículo en tus redes

Share on facebook
Share on google
Share on twitter
Share on linkedin

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *