Alternativas de Diseño e Implementación de un Servicio Hiperconectado
Analizaremos este aspecto del diseño e implementación desde dos puntos de vista:
- Lógico o de Arquitectura de los Procesos
- Físico o de Arquitectura de hosting
La Arquitectura de Procesos y la Arquitectura Física (o de hosting) son dos cosas totalmente distintas.
La primera hace referencia al diseño de los procesos, que podrá ser en uno o dos niveles con las consideraciones de modelado y diseño de interoperabilidad necesarios en cada caso. La segunda hace referencia al lugar físico dónde alojar los procesos (infraestructura física o virtualizada) y por ende las instancias (instalaciones) de los BPMS que den soporte a los procesos.
Arquitectura de los Procesos (diseño lógico):
Desde el punto de vista del resultado final, es decir del Servicio Hiperconectado en producción implementado sobre plataformas BPMS, se pueden identificar 2 posibles arquitecturas:
- Arquitectura de procesos Centralizada
- Arquitectura de procesos Distribuida
Arquitectura de Procesos Centralizada
La Arquitectura de Procesos Centralizada es aquella en la cual el Servicio Hiperconectado se implementa en base a 2 niveles de procesos:
Nivel 1: Proceso padre que implementa el “hilo principal” del Servicio Hiperconectado (centralizando)
Nivel 2: subprocesos hijos que implementan los subtrámites en cada organismo
El nivel 1 (proceso padre del Servicio Hiperconectado) se implementa sobre un BPMS en una instancia nueva, independiente y centralizada de cualquier instancia de BPMS o sistema legado preexistente en los organismos intervinientes.
Esta nueva instancia se debe integrar (interoperar) con las instancias preexistentes en los organismos.
En este caso llamaremos proceso padre (o trámite padre) al “hilo principal o conductor” del Servicio Hiperconectado implementado sobre esa nueva instancia de BPMS, y llamaremos procesos hijos (o trámites hijos) a los trámites preexistentes en los organismos.
El tipo y nivel de integración del proceso padre del Servicio Hiperconectado con los procesos hijos de los trámites en cada organismo dependerá de cada caso, pudiendo ir desde una simple integración con intercambio de información, hasta una completa absorción del proceso hijo por parte del proceso padre.
Lo que sí es evidente es que, en esta integración, los procesos hijos siempre tendrán que ser modificados para integrarse en el Servicio Hiperconectado.
La modificación dependerá del grado de desarrollo actual en que se encuentre el proceso hijo al momento de implementar el Servicio Hiperconectado. Por ejemplo, si el proceso hijo está implementado sólidamente (con un buen diseño y sin problemas ni oportunidades de mejora identificadas) sobre un BPMS, entonces la integración con el proceso padre será a través de intercambio de datos sin mayores modificaciones en el propio flujo del proceso hijo. Si el flujo del proceso hijo presentara problemas y/o oportunidades de mejoras ya identificadas, el mismo podrá ser ajustado e incluso absorbido (implementado totalmente por) el proceso padre. Aquellos procesos hijos que se encuentren actualmente implementados en sistemas legados o a través de flujos informales mediante herramientas ofimáticas y correos, son los principales candidatos a ser totalmente implementados (absorbidos) en el proceso padre del Servicio Hiperconectado.
Continuando con el ejemplo de la imagen para la definición del Servicio Hiperconectado, su implementación con arquitectura centralizada se ilustra a continuación:
El nivel 1 lo conforma el nuevo hilo principal del Servicio Hiperconectado integrando los trámites 2 y 3 que son absorbidos e implementados directamente en el nivel 1 debido a que se encontraban en un grado de desarrollo bajo (uno en sistemas legados y el otro en forma manual y ofimática). Mientras que el trámite 1 es aprovechado y reutilizado mediante integración con el hilo principal del Servicio Hiperconectado, conformando el nivel 2 en el BPMS que ya estuviera allí.
Arquitectura de Procesos Distribuida
En la arquitectura distribuida el Servicio Hiperconectado es implementado en base a un solo nivel de procesos. Es como la arquitectura centralizada, pero sin el nivel 1, solo con los procesos del nivel 2.
Por lo tanto, el hilo principal del Servicio Hiperconectado debe ser implementado en base a la integración horizontal de los procesos (trámites) hijos sin un proceso padre que integre y orqueste.
En cada organismo se mantiene y ajusta cada implementación BPMS preexistente o se implementan nuevas si el trámite no estuviera previamente soportado en un BPMS.
Continuando con el ejemplo de la imagen para la definición del Servicio Hiperconectado, su implementación con arquitectura distribuida se ilustra a continuación:
Arquitectura de hosting (diseño físico)
Refiere a la implementación física de la solución y, si bien está relacionada con la arquitectura de procesos es independiente de ésta.
Para la arquitectura de hosting analizaremos las siguientes dos opciones:
1. Hosting en infraestructura propia del organismo
2. Hosting en infraestructura de terceros fuera del organismo. El tercero podrá ser un proveedor oficial de este tipo de servicio como ser el Data Center de ANTEL, o podrá ser un proveedor específico para trámites en línea como Agesic, o podrá ser otro organismo del Servicio Hiperconectado (por ejemplo, con mejor infraestructura).
Un organismo que forma parte de un Servicio Hiperconectado podrá tener cualquiera de las dos opciones de hosting o, incluso, una combinación de ambas.
La selección del tipo de arquitectura física por parte de cada organismo del Servicio Hiperconectado dependerá de consideraciones que el mismo deberá hacer desde los puntos de vista:
1. De conveniencia económica
a. Infraestructura existente, nueva etc.
b. Recursos humanos calificados para su administración y mantenimiento.
2. De normativa interna. Considerando aspectos de seguridad de la información, accesos, legales, etc.
Para la Arquitectura de Proceses Distribuida (descentralizada) las posibles implementaciones físicas (hosting) no difieren de lo que ya se hace hoy en día con los trámites en línea. Es decir, cada organismo tiene su propia infraestructura, con su propia instancia de BPMS ejecutando sobre la misma y una única y propia configuración de seguridad y accesos para las personas y para sus propios actores internos de los procesos.
Por lo tanto, la forma de implementar y gobernar los trámites no cambia mayormente. El principal cambio estará en el diseño de los procesos de cada trámite y en los ajustes de interoperabilidad (ciertamente complejos), dobles flechas rojas en ilustración, necesarios para que cada trámite deje de funcionar como un proceso independiente y pase a funcionar como un subproceso tipo “eslabón” de un proceso más grande integrado con los demás organismos.
En la Arquitectura de Procesos Centralizada aparece un nuevo elemento que es el nivel 1 del proceso padre y por ello es necesario definir dónde se alojará ese proceso principal.
Para ello existen dos posibilidades:
1. Que el proceso padre, y por ende la nueva instancia independiente del BPMS, se aloje fuera de los organismos intervinientes en el Servicio Hiperconectado, es decir en un tercer organismo que oficie de “host” del Servicio Hiperconectado.
2. Que el proceso padre, y por ende la nueva instancia independiente del BPMS, se aloje en uno (cualquiera) de los organismos intervinientes en el Servicio Hiperconectado.
Desde el punto de vista estrictamente de diseño, es recomendable la opción 1, pero ello implica que un tercero, como ser Agesic u otro, tome esa responsabilidad.
Conjuntamente con lo anterior hay que tener en cuenta los aspectos de administración y acceso al nivel 1. Esto es, por ejemplo, que si se aloja en un tercero (por ejemplo Agesic) hay que dar permisos de acceso a todos los organismos a un ambiente externo a dichos organismos.