Una cuestión de enfoque

por

Abandonar las prácticas que durante años han conducido a una arquitectura de sistemas acoplada, costosa e ineficiente, es una cuestión de enfoque.

Habitualmente las organizaciones orientan sus decisiones relativas al desarrollo de sus sistemas de información desde una perspectiva funcional. Cada área funcional tiene su sistema de información, o grupo de sistemas de información, que tratan de dar respuesta a los requisitos funcionales propios de esa área funcional.

Aunque las necesidades funcionales de cada área de la organización son importantes, sin una visión global que coordine estos requisitos es muy probable que surjan redundancias.

Además, los requisitos de integración suelen orientarse a compartir información, no procesos, y se les resta importancia durante el ciclo de vida de los proyectos: se resuelven buscando el mínimo impacto en los plazos sin una visión de futuro ni del impacto para la organización, se resuelven en las fases avanzadas de construcción y pruebas, y a menudo se tratan como requerimientos técnicos, sin considerar el valor funcional y de negocio que tienen estos requisitos de integración.

 

La gestion de sus requisitos de integracion determina la calidad de su mapa de sistemas

 

Sin embargo, la mera existencia de requisitos de integración supone el claro síntoma de que existen flujos de procesos transversales, que afectan a varias áreas funcionales, y tienen por tanto un alcance a nivel del negocio.

 

Por tanto, se impone cambiar algunas costumbres. Para empezar, aunque nos mantengamos a nivel de integración de datos habría que tener en cuenta:

  1. Para un sistema de información, los requisitos de integración son requisitos funcionales y por tanto deben ser recopilados, documentados, analizados, y considerados para enfocar el diseño, junto con el resto de requisitos funcionales.
  2. Los casos de uso deben incluir los requisitos de integración, y sus casos de error deben probarse como el resto de casos de uso.
  3. A la hora de diseñar los sistemas de información y la forma en que resolverán esos requisitos de integración, deben tenerse en cuenta cuestiones como:
    • la política de la organización (si existe, claro está… volveremos a este asunto cuando tratemos la gobernanza)
    • el impacto de futuros cambios en los sistemas afectados, que debe ser mínimo o cero (buscar el mínimo acoplamiento)
    • el uso de estándares para la definición de la estructura y del contenido de los datos a intercambiar
  4. La definición de la solución debe quedar perfectamente y detalladamente documentada, en documento aparte, como especificación de solución de integración de determinada funcionalidad, evitando asociarla a ningún sistema de información en concreto ni mucho menos a ninguna tecnología.

 

Pero el cambio de enfoque más importante que se debe acometer, y que idealmente debe partir de los responsables TIC y expertos funcionales de la organización, es orientar la arquitectura del mapa de sistemas de la organización a los procesos de negocio.

Este es también el cambio más complejo, porque pone el acento en la cadena de valor de la organización para identificar los flujos de proceso que la implementan a través de las distintas áreas funcionales implicadas, y desde el análisis de estos flujos de proceso se obtienen los requisitos de interoperabilidad, que no de integración. Damos un paso más allá y pasamos de integrar datos, a compartir procesos de negocio. De esta forma no solo obtenemos los beneficios de reducción del time to market, agilidad y flexibilidad en la cadena de valor sino que además, incrementamos la reusabilidad y reducimos los costes de los proyectos IT.

Casi nada.

 

Así que vamos a quedarnos con dos conclusiones:

  • Los requisitos de integración deben tomarse más en serio, tan en serio como cualquier otro requisito funcional de un sistema de información
  • El enfoque de la organización debe cambiar a los procesos de negocio, para desde ahí obtener los requisitos de integración, con un alcance más amplio para lograr la implementación de dichos procesos mediante servicios de negocio reutilizables y basados en estándares.

 

La estrategia SOA requiere un cambio de enfoque con una serie de factores clave

 

BPM y EDA tienen mucho que decir en este cambio de enfoque. El primero, para modelar y analizar los procesos de negocio. El segundo, para introducir la disponibilidad en tiempo real de los servicios de negocio y la información que envían.

 

Te puede interesar

0 comentarios

Trackbacks/Pingbacks

  1. Lógica de negocio vs lógica funcional: ¿Conoces la diferencia? - […] entre lógica de negocio y lógica funcional tiene relación directa con lo que decíamos aquí sobre la orientación a…

Enviar un comentario

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

Sigueme en las redes

Share This