Kenn Marcucci 1151891

Diego Pedrozo 1151898

Sebastián Bermón 1151900
SCADA REPLACEMENT
DOCUMENTACIÓN DE DECISIONES

ADR-001: Utilizar arquitectura Publish-Subscribe

Contexto

El cliente necesita reemplazar su sistema SCADA legacy por uno nuevo basado en
tecnologías modernas como streaming de datos, microservicios, escalabilidad automática,
big data, etc.

El nuevo sistema debe:

● Permitir el reemplazo modular de componentes.

● Facilitar la reutilización y el intercambio de módulos con otros TSOs.
● Recibir y analizar datos en tiempo real de dispositivos en el campo.
● Detectar alertas y generar acciones sobre los equipos.

Decisión

Se utilizará una arquitectura Publish-Subscribe, donde:

● Los productores son los dispositivos que envían datos en tiempo real.
● El bus de eventos recibe y distribuye los datos entrantes.
● Los consumidores son los servicios que procesan y analizan los datos.

Justificación

Las ventajas de usar Publish-Subscribe:

● Desacopla productores y consumidores, permitiendo escalar/reemplazar cada uno

por separado.
● Facilita compartir datos entre múltiples consumidores.
● Permite procesamiento asíncrono y en paralelo de los datos.
● Es adecuado para escenarios de tiempo real y streaming de datos.

Esto cumple con los requerimientos de modularidad, reutilización e intercambio de

componentes.

Consecuencias

● Se necesita implementar un bus de eventos confiable y escalable.

● Los consumidores deben implementar buffering y throttling cuando sea necesario.
● La lógica de negocio se distribuirá en múltiples servicios desacoplados.
● Los datos deberán ser idempotentes o tener mecanismos de reintento.
Kenn Marcucci 1151891
Diego Pedrozo 1151898
Sebastián Bermón 1151900
SCADA REPLACEMENT
DOCUMENTACIÓN DE DECISIONES

DEUDA TÉCNICA
● Se necesita implementar un bus de eventos confiable y escalable.

La necesidad de un bus de eventos confiable y escalable puede ser un desafío en

términos de implementación. Se requerirá un esfuerzo significativo para desarrollar,
desplegar y mantener una infraestructura que satisfaga estas necesidades, lo que
podría generar deuda técnica si no se aborda adecuadamente.

● Los consumidores deben implementar buffering y throttling cuando sea

necesario.

La implementación de buffering y throttling en los consumidores puede agregar

complejidad al desarrollo y requerir un monitoreo constante para ajustar los límites
según sea necesario. Esta complejidad adicional podría llevar a una deuda técnica si
no se maneja de manera eficiente.

● La lógica de negocio se distribuirá en múltiples servicios desacoplados.

Al distribuir la lógica de negocio en múltiples servicios desacoplados, se introduce la

complejidad de la comunicación entre estos servicios. La gestión de transacciones
distribuidas y la coherencia de datos pueden convertirse en desafíos que generen
deuda técnica si no se abordan de manera efectiva.

● Los datos deberán ser idempotentes o tener mecanismos de reintento.

La necesidad de que los datos sean idempotentes o de implementar mecanismos de

reintento agrega complejidad al diseño y desarrollo del sistema. Ignorar estas
consideraciones podría resultar en deuda técnica, especialmente si los datos no son
manejados de manera robusta.

● Escalabilidad y Reemplazo de Componentes

Aunque la arquitectura Publish-Subscribe permite escalar y reemplazar productores

y consumidores por separado, la implementación efectiva de esta escalabilidad y
modularidad puede requerir una cuidadosa planificación y diseño. Una
implementación deficiente podría resultar en deuda técnica si futuras modificaciones
o mejoras se vuelven difíciles de implementar.

● Capacitación del Personal

Kenn Marcucci 1151891
Diego Pedrozo 1151898
Sebastián Bermón 1151900
SCADA REPLACEMENT
DOCUMENTACIÓN DE DECISIONES
La adopción de una nueva arquitectura puede requerir que el personal se familiarice
con los conceptos y tecnologías asociadas. La falta de capacitación adecuada puede
generar deuda técnica si los equipos no están completamente preparados para
trabajar con la nueva arquitectura.