Reingeniería de Procesos de Negocio

Se están ejerciendo unas increíbles presiones comerciales para hacer que los sistemas sean más flexibles, más orientados al cliente y más fáciles de utilizar. El proceso de datos constituye el núcleo y la base de toda empresa. Al mismo tiempo, la revolución de la reingeniería de procesos comerciales (BPR) aumenta las preocupaciones, mientras los programadores escriben parches y más parches con el fin de mantener en funcionamiento los procesos actuales.

Las empresas se encuentran en mitad de la espiral mortal del mantenimiento: más de 1.000 personas asignadas a un proceso monolítico de reclamaciones, facturación o cualquier otra aplicación comercial crítica, que se compila para formar un programa ejecutable. Y, además, no está bien documentado. Y, por otra parte, corren rumores sobre una posible demolición de los programas antiguos. Es cierto que el proceso cliente/servidor está comenzando a adquirir la máxima vigencia en las empresas, pero es impensable un cambio radical a verdaderas aplicaciones críticas nuevas y mejoradas. Afortunadamente, hay buenas noticias -y una buena cantidad de tecnología sólida- para establecer un compromiso constructivo: una tecnología que permita ganancias comerciales incrementales con un mínimo de riesgo, y métodos que hagan posible para las compañías aprovechar los sistemas básicos sin desecharlos completamente. Estas se conocen como estrategias de rodeo: si no puede desechar sus sistemas antiguos, aprovéchelos dando un rodeo, mediante las mejores partes del proceso cliente/servidor, para cumplir con fechas a corto plazo mientras crea cosas con vistas al futuro.

La técnica de "screen scraping", que en tiempos fue la más popular de las estrategias de rodeo, comienza precisamente ahora a rozar la superficie de lo que es posible conseguir, aunque es la que ofrece menos beneficios. Se está aplicando también otra variedad de métodos de arquitectura más agresivos, que son utilizados por las organizaciones de mayor tamaño.

Esencialmente, las estrategias de rodeo permiten compensar las carencias de los sistemas antiguos sustituyendo alguna parte de esos sistemas por nueva tecnología cliente/servidor incorporada en el front-end, por lo menos un interface GUI y posiblemente mucho más, dependiendo de qué decida uno instalar en primera línea, y en qué cantidad.

En todas las estrategias se comienza por dividir el sistema antiguo en tres capas o niveles -presentación, proceso y datos- y transformando el primer nivel, y posiblemente parte o la totalidad de los niveles segundo y tercero, en un servidor GUI, un servidor de funciones o un servidor de base de datos. (Este triunvirato de aplicación se conoce en ocasiones como una arquitectura de software cliente/servidor de tres capas o etapas, pero no debe confundirse con la clásica arquitectura de hardware de tres niveles, formada por estación de trabajo desktop, servidor de gama media y mainframe host)

Una vez que se haya estructurado el sistema, el desafío está en poner en comunicación la porción antigua y la nueva porción cliente/servidor. Los cinco métodos básicos de hacerlo se conocen como screen scrapping (o presentation mapping), mapping de procesos, mapping de datos, replicación de datos antiguos y servidor de base de datos antigua. Los dos últimos métodos no requieren mapping ni conversión, sino simplemente un nivel de mensajes para actualizaciones directas de datos back-end.

Mapping de Presentación

Conocido también como screen scrapping, el nivel de mapping de presentación sustituye al nivel de presentación antiguo, mejorando el aspecto de la aplicación basada en el host. Un PC sustituye al terminal no inteligente en la arquitectura estándar master/slave basada en el host. Una nueva aplicación basada en el cliente recoge datos en la corriente de datos utilizada para alimentar al terminal no inteligente, analiza los campos que llegan y los transfiere a un interface GUI en el PC.

La mayoría de los vendedores de herramientas de conectividad PC-a-mainframe, incluyendo Attachment y DCA, ofrecen actualmente extensiones de Mapping de Presentación a herramientas de desarrollo front-end populares, como Visual Basic de Microsoft.

El Mapping de Presentación ofrece ganancias mínimas pero inmediatas, con un mínimo de riesgo. Como este método limita al interface de usuario al flujo de pantallas en el sistema antiguo existente, los posibles intentos de reingeniería de los procesos actuales quedan severamente restringidos.

Sin embargo, en ocasiones, estas decisiones pueden resultar poco económicas a largo plazo. Una capa de pintura puede ser una solución temporal para muebles viejos, pero probablemente habrá que renovarlos o reconstruirlos más tarde o más temprano. Esto es lo que sucede con muchas compañías que optan por implementar el Mapping de Presentación.

Una de las principales causas de los fallos del Mapping de Presentación en la práctica, especialmente en aplicaciones de gran escala, está en la sincronización de los front-ends y los back-ends. Las compañías arreglan sólo por lo general las partes más utilizadas de sus aplicaciones existentes, permitiendo que los usuarios recurran a las pantallas no inteligentes originales en caso necesario. En los grandes centros de proceso de datos, los responsables del Mapping de Presentación no son muchas veces los que poseen la aplicación back-end, y mantener la consistencia entre las dos puede resultar difícil. Frecuentemente, los retrasos producen tales problemas para los usuarios que pierden confianza en el sistema y terminan utilizando su ruta de escape incorporada, para volver a los terminales no inteligentes.

Los problemas de consistencia pueden ser resueltos en parte mediante una aplicación tipo sistema experto y controlada por tablas, que facilite unas rápidas actualizaciones. El sistema analiza la pantalla de llegada y crea un repositorio de metadatos en el cliente, en el que se almacenan las tablas que transfieren o convierten las antiguas pantallas y campos a las nuevas. El posicionamiento de campos en la nueva aplicación front-end no está codificado fijo, sino que es controlado dinámicamente por estas tablas. La sincronización del front-end y el back-end requiere entonces simplemente que el programador actualice la transferencia o mapping.

Mapping de procesos

Desafortunadamente, añadir sólo un nuevo nivel de presentación resulta muy poco flexible y generalmente queda muy por debajo de soportar la necesaria reingeniería de procesos comerciales (BPR). Con frecuencia es necesario profundizar algo más en el sistema, ya que cuanto más cantidad del sistema antiguo se sustituya, mayor será la libertad que habrá para la reingeniería. Y, naturalmente, mayor será el riesgo en que se incurrirá. No obstante, la transición no es una cuestión de todo o nada, y puede tener lugar por etapas.

El mapping de procesos, conocido también como "transaccionalización", es el paso siguiente en el espectro de las estrategias de rodeo, y requiere la creación de nuevas capas o niveles de presentación y de proceso -generalmente para obtener una mayor eficiencia operacional- aunque limita al usuario al conjunto actual de funcionalidad back-end.

La arquitectura del antiguo sistema mainframe existente está destinada básicamente a responder a eventos de pantalla. El mapping de procesos permite combinar uno o varios eventos de pantalla discretos para crear transacciones o eventos comerciales en el front-end, siguiendo una secuencia deseada. Toda la lógica de presentación se escribe y se almacena en el cliente, y la nueva lógica de aplicación es creada en el front-end para interactuar por sí misma con el usuario hasta que se complete toda la información requerida para un proceso o transacción comercial completo. Entonces, se envía la transacción comercial a la porción mainframe de la capa o nivel de proceso.