En muchas organizaciones, una vez que se ha realizado el trabajo para integrar un nuevo sistema en el mainframe, por ejemplo, se vuelve mucho más fácil interactuar con ese sistema a través del mainframe en lugar de repetir la integración cada vez. Para muchos sistemas heredados con una arquitectura monolítica esto tenía sentido, integrar el mismo sistema en el mismo monolito varias veces habría sido un desperdicio y probablemente confuso. Con el tiempo, otros sistemas comienzan a llegar al sistema heredado para obtener estos datos, con el sistema integrado de origen a menudo “olvidado”.
Por lo common, esto lleva a que un sistema heredado se convierta en el único punto de integración para múltiples sistemas y, por lo tanto, también se convierta en una fuente de datos ascendente clave para cualquier proceso comercial que necesite esos datos. Repita este enfoque varias veces y agregue el acoplamiento estrecho a las representaciones de datos heredados que vemos a menudo, por ejemplo, como en Agregador crítico invasivoentonces esto puede crear un desafío significativo para el desplazamiento heredado.
Al rastrear las fuentes de datos y los puntos de integración “más allá” del patrimonio heredado, a menudo podemos “volver a la fuente” para nuestros esfuerzos de desplazamiento heredados. Esto puede permitirnos reducir las dependencias del legado desde el principio, además de brindar la oportunidad de mejorar la calidad y la puntualidad de los datos, ya que podemos poner en juego técnicas de integración más modernas.
También vale la pena señalar que es cada vez más importante comprender las verdaderas fuentes de datos por motivos comerciales y legales, como el RGPD. Para muchas organizaciones con un extenso patrimonio heredado, solo cuando surge una falla o un problema, la verdadera fuente de datos se vuelve más clara.
Cómo funciona
Como parte de cualquier esfuerzo de desplazamiento heredado, necesitamos rastrear las fuentes y sumideros de origen para los flujos de datos clave. Dependiendo de cómo elijamos dividir el problema common, es posible que no necesitemos hacer esto para todos los sistemas y datos a la vez; aunque para tener una thought de la escala common del trabajo a realizar, es muy útil comprender los flujos principales.
Nuestro objetivo es producir algún tipo de mapa de flujo de datos. El formato actual utilizado es menos importante, más bien la clave es que este descubrimiento no solo se detiene en los sistemas heredados, sino que profundiza más para ver los puntos de integración subyacentes. Vemos muchos diagramas de arquitectura mientras trabajamos con nuestros clientes y es sorprendente la frecuencia con la que parecen ignorar lo que hay detrás del legado.
Hay varias técnicas para rastrear datos a través de sistemas. En términos generales, podemos verlos como trazar el camino río arriba o río abajo. Si bien a menudo hay datos que fluyen hacia y desde los sistemas de origen subyacentes, encontramos que las organizaciones tienden a pensar solo en términos de fuentes de datos. ¿Quizás cuando se ve a través de los lentes de los sistemas heredados, esta es la parte más seen de cualquier integración? No es raro encontrar que el flujo de datos desde el legado hacia los sistemas de origen es la parte menos comprendida y menos documentada de cualquier integración.
Para upstream, a menudo comenzamos con los procesos comerciales y luego intentamos rastrear el flujo de datos hacia el legado y luego de regreso. Esto puede ser un desafío, especialmente en sistemas más antiguos, con muchas combinaciones diferentes de tecnologías de integración. Una técnica útil es usar es tarjetas CRC con el objetivo de crear un diagrama de flujo de datos junto con diagramas de secuencia para los pasos clave del proceso comercial. Cualquiera que sea la técnica que utilicemos, es very important involucrar a las personas adecuadas, idealmente aquellos que originalmente trabajaron en los sistemas heredados, pero más comúnmente aquellos que ahora los respaldan. Si estas personas no están disponibles y se ha perdido el conocimiento de cómo funcionan las cosas, entonces podría ser más adecuado comenzar en la fuente y trabajar aguas abajo.
El seguimiento de la integración aguas abajo también puede ser extremadamente útil y, según nuestra experiencia, a menudo se descuida, en parte porque si
Paridad de funciones está en juego, el enfoque tiende a estar solo en los procesos comerciales existentes. Al rastrear aguas abajo, comenzamos con un punto de integración subyacente y luego tratamos de rastrear hasta las capacidades comerciales clave y los procesos que admite. No muy diferente de un geólogo que introduce tinte en una posible fuente de un río y luego ve en qué corrientes y afluentes aparece el tinte corriente abajo. Este enfoque es especialmente útil cuando el conocimiento sobre la integración heredada y los sistemas correspondientes es escaso y es especialmente útil cuando estamos creando un nuevo componente o proceso comercial. Al rastrear aguas abajo, es posible que descubramos dónde entran en juego estos datos sin saber primero la ruta exacta que toman, aquí es possible que desee compararlos con los datos de la fuente unique para verificar si las cosas se han alterado en el camino.
Una vez que comprendemos el flujo de datos, podemos ver si es posible interceptar o crear una copia de los datos en la fuente, que luego puede fluir a nuestra nueva solución. Por lo tanto, en lugar de integrar el legado, creamos una nueva integración para permitir que nuestros nuevos componentes vuelvan a la fuente. Necesitamos asegurarnos de tener en cuenta los flujos ascendentes y descendentes, pero estos no tienen que implementarse juntos como vemos en el ejemplo a continuación.
Si no es posible una nueva integración, podemos usar Intercepción de eventos
o related para crear una copia del flujo de datos y enrutarlo a nuestro nuevo componente, queremos hacerlo lo más arriba posible para reducir cualquier dependencia de los comportamientos heredados existentes.
Cuándo usarlo
Revert to Supply es más útil cuando estamos extrayendo una capacidad o proceso comercial específico que se basa en datos que en última instancia se obtienen de un punto de integración “escondido detrás” de un sistema heredado. Funciona mejor donde los datos pasan a través del legado sin cambios, donde hay poco procesamiento o enriquecimiento antes del consumo. Si bien esto puede parecer poco possible en la práctica, encontramos muchos casos en los que el legado solo actúa como un centro de integración. Los principales cambios que vemos que le suceden a los datos en estas situaciones son la pérdida de datos y una reducción en la puntualidad de los datos. Pérdida de datos, ya que los campos y elementos generalmente se filtran simplemente porque no había forma de representarlos en el sistema heredado, o porque period demasiado costoso y arriesgado realizar los cambios necesarios. Reducción en la puntualidad ya que muchos sistemas heredados utilizan trabajos por lotes para la importación de datos y, como se explica en Agregador crítico el “período seguro de actualización de datos” a menudo está predefinido y es casi imposible de cambiar.
Podemos combinar Revert to Supply con Parallel Operating y Reconciliation para validar que no se produzca ningún cambio adicional en los datos heredados. Este es un enfoque sólido para usar en common, pero es especialmente útil cuando los datos fluyen a través de diferentes rutas hacia diferentes puntos finales, pero en última instancia deben producir los mismos resultados.
También puede haber un poderoso caso de negocios para usar Revertir a la fuente, ya que a menudo se dispone de datos más ricos y oportunos. Es común que los sistemas de origen se hayan actualizado o cambiado varias veces y estos cambios permanezcan efectivamente ocultos detrás del legado. Hemos visto varios ejemplos en los que las mejoras en los datos eran en realidad la principal justificación de estas actualizaciones, pero los beneficios nunca se materializaron por completo, ya que las actualizaciones más frecuentes y completas no podían estar disponibles a través de la ruta heredada.
También podemos usar este patrón donde hay un flujo de datos bidireccional con un punto de integración subyacente, aunque aquí se necesita más cuidado. Cualquier actualización que finalmente se dirija al sistema de origen primero debe fluir a través de los sistemas heredados, aquí pueden desencadenar o actualizar otros procesos. Afortunadamente, es muy posible dividir los flujos aguas arriba y aguas abajo. Entonces, por ejemplo, los cambios que regresan a un sistema de origen podrían continuar fluyendo a través del legado, mientras que las actualizaciones podemos tomarlas directamente de la fuente.
Es importante tener en cuenta los requisitos y restricciones interfuncionales que puedan existir en el sistema de origen, no queremos sobrecargar ese sistema o descubrir que no es confiable o no está lo suficientemente disponible para proporcionar directamente los datos requeridos.
Ejemplo de tienda minorista
Para un cliente minorista, pudimos usar Revert to Supply para extraer un nuevo componente y mejorar las capacidades comerciales existentes. El cliente disponía de un amplio parque de tiendas y de una internet de reciente creación para realizar compras on-line. Inicialmente, el nuevo sitio internet obtuvo toda su información de existencias del sistema heredado, a su vez, estos datos procedían de un sistema de seguimiento de inventario del almacén y de las propias tiendas.
Estas integraciones se lograron a través de trabajos por lotes durante la noche. Para el almacén, esto funcionó bien, ya que las existencias solo salían del almacén una vez al día, por lo que la empresa podía estar segura de que la actualización del lote recibida cada mañana seguiría siendo válida durante aproximadamente 18 horas. Para las tiendas esto creaba un problema ya que el inventory obviamente podía salir de las tiendas en cualquier momento durante la jornada laboral.
Dada esta restricción, el sitio internet solo puso a disposición para la venta el inventory que estaba en el almacén. Los análisis del sitio combinados con los datos de existencias de la tienda recibidos al día siguiente dejaron en claro que, como resultado, se estaban perdiendo ventas: las existencias requeridas habían estado disponibles en una tienda todo el día, pero la naturaleza por lotes de la integración heredada hizo que esto fuera imposible de aprovechar. de.
En este caso se creó un nuevo componente de inventario, inicialmente para uso exclusivo del sitio internet, pero con el objetivo de convertirse en el nuevo sistema de registro para toda la organización. Este componente se integró directamente con los sistemas de caja registradora en la tienda que eran perfectamente capaces de proporcionar actualizaciones casi en tiempo actual a medida que se realizaban las ventas. De hecho, la empresa había invertido en una purple altamente confiable que vinculaba sus tiendas para admitir pagos electrónicos, una purple que tenía mucha capacidad disponible. Los niveles de existencias del almacén se extrajeron inicialmente de los sistemas heredados con el objetivo a más largo plazo de revertirlos también a la fuente en una etapa posterior.
El resultado closing fue un sitio internet que podía ofrecer con seguridad existencias en la tienda tanto para reservas en la tienda como para la venta en línea, junto con un nuevo componente de inventario que ofrecía datos más completos y oportunos sobre los movimientos de existencias. Al volver a la fuente del nuevo componente de inventario, la organización también se dio cuenta de que podía obtener acceso a datos de ventas mucho más oportunos, que en ese momento solo se actualizaban a través de un proceso por lotes. Los datos de referencia, como las líneas de productos y los precios, continuaron fluyendo hacia los sistemas de la tienda a través del mainframe, perfectamente aceptable dado que esto cambiaba con poca frecuencia.
