Apalancando en IT para un mejor desempeno del negocio

Inicio

Contenido

blog

Comentarios y Contacto

Acerca de IT Leverage

portugues

.

|

.

english

 

Los recursos tecnológicos que soportan los procesos de negocio de una organización deben ofrecer una infraestructura adecuada para el desarrollo y la evolución del software y deben proveer la seguridad de que su continuidad operativa permanecerá en el tiempo. La necesidad de integración de servicios implementados sobre plataformas disímiles, y la percepción de ciertos riesgos en la obtención de soporte suficiente y en la certeza de continuidad de las operaciones soportadas por sistemas o plataformas legadas, llevan a la consideración de evolucionar, mantener o migrar dichos sistemas.

El tiempo de vida de los sistemas de software es bastante variable, muchos sistemas han sido creados desde hace más de 15 años y son aún sistemas de misión crítica. Esto es, la continuidad operativa de las empresas que los operan depende de los servicios provistos por el sistema y una falla en este puede traer consecuencias negativas sobre la operación diaria del negocio. Las decisiones que se toman sobre este tipo de sistemas son de orden estratégico debido a su importancia. Sistemas con estas características son los comúnmente denominados sistemas legados.

Diversos factores internos y externos, económicos, de mercado, legales, administrativos o políticas de organización, exigen cambios continuos en el negocio. Estos cambios generan o causan modificaciones en los requerimientos de software que recaen sobre los sistemas tecnológicos, haciendo necesaria la introducción de cambios para alinearse a los nuevos requerimientos del negocio.

Un número elevado de cambios en un sistema tiende a desestabilizar su estructura y hacer que los cambios subsiguientes sean más difíciles de incorporar. Entre mayor sea el numero de cambios en el sistema (cambios no enfocados a mejorar la estructura del sistema), menor se hace la calidad del sistema.

El mantenimiento de los sistemas legados es usualmente complejo y presenta una curva de aprendizaje bastante empinada debido principalmente a:

• Las diversas partes del sistema se encuentran desarrolladas en lenguajes de programación desactualizados. Contar con recursos que dominen estos lenguajes no es sencillo por lo que el costo de mantenimiento del sistema es elevado.
• La documentación de los sistemas es escasa e insuficiente.

• El número de años de mantenimiento continuo sobre el sistema hace que la estructura del software se incremente sustancialmente y sea propensa a la existencia de código muerto (que nunca se ejecuta) dentro de algunos programas.

• Existen limitaciones propias de las plataformas y sistemas legados, como limitantes en tamaño de los nombres de archivo, limitantes en el tamaño disponible para carga de programas en memoria, limitantes en la longitud de las variables, etc.

• Existencia de duplicidad de datos, datos desactualizados y datos incompletos.

• La base de soporte disponible para un sistema legado es limitada, y en ocasiones requerida tanto para aspectos técnicos, como funcionales y de proceso. La mayor parte del conocimiento del sistema se encuentra concentrado en pocas personas, y la disponibilidad de estos recursos puede no ser inmediata o no responder con la agilidad que se requiere.

Cuando se trata de modernizar un sistema de misión critica, se enfrenta un dilema propio a la evolución de un sistema legado: Continuar utilizando el sistema e introduciendo cambios en él, implica que los costos de mantenimiento se vean gradualmente incrementados y la complejidad del sistema continúe en ascenso; Decidir reemplazar el sistema por uno nuevo puede ser muy costoso y el soporte de los procesos de negocio puede resultar no ser tan eficiente como el ofrecido por el sistema legado.

La evolución del sistema legado hacia otro sistema más moderno involucra varios riesgos que provienen de razones como:

• Ausencia de una especificación completa del sistema. Por lo cual no existe una forma directa de especificar un sistema que sea funcionalmente equivalente al sistema actual.

• Los procesos de negocio soportados por el sistema se han desarrollado en base a las características propias del sistema, y si éste es reemplazado, los procesos también se verían modificados.

• La mayor parte de las reglas de negocio se encuentran inmersas en el código de las aplicaciones dentro del sistema y no se encuentran documentadas en otra parte.

• El desarrollo de nuevos sistemas de software implica en si mismo riesgos que son difíciles de controlar y pueden llevar a demoras en la entrega del nuevo sistema.

Existen cuatro estrategias para evolucionar un sistema legado:

• Eliminar completamente el sistema. Esta opción debe considerarse cuando el sistema no está haciendo ninguna contribución en los procesos de negocio, caso que sucede cuando los procesos de negocio han cambiado y se hacen independientes de los procesos soportados por el sistema.

• Tolerar y continuar con el mantenimiento del sistema. Esta estrategia es aplicable cuando el sistema es aún requerido, permanece estable, y no existen muchos requerimientos de cambio sobre el sistema.

• Transformar o integrar el sistema para mejorarlo. Esta opción debería escogerse cuando la calidad del sistema se ha visto degradada por los cambios adicionados al sistema y aún existen nuevos requerimientos funcionales para el sistema.

• Migrar o reemplazar el sistema por otro sistema. La migración es un proceso que transforma el sistema existente en uno nuevo. Cuando debido a diversos factores (cuestiones técnicas, contractuales, estratégicas, etc) la operatividad o el soporte a futuro del sistema sea incierto, se debe considerar esta alternativa.

La decisión de eliminar un sistema puede ser fácilmente tomada cuando éste ofrece poco valor al negocio y representa un riesgo elevado. Igualmente la decisión de mantenerlo se toma fácilmente cuando el riesgo que el sistema representa para el negocio es mínimo. Los sistemas que proporcionan alto valor al negocio y representan poco riesgo son los sistemas que cualquier negocio debería procurar tener. Los sistemas que ofrecen alto valor y a su vez representan un riesgo alto son los sistemas donde más factores deben considerarse antes de tomar una decisión respecto a su futuro.

El impacto sobre el sistema es proporcional al numero de cambios que lo afecten, así, tolerar y mantener el sistema tiene menos impacto que su transformación o reemplazo. Obviamente, entre mayor sea el impacto sobre el sistema actual, mayor será el riesgo que se corra durante su proceso de evolución.

El mantenimiento involucra actualizaciones en la aplicación sin hacer cambios drásticos en el código y sin modificar su arquitectura interna. La estrategia tiene tres variantes: mantenimiento adaptativo, mantenimiento correctivo y mantenimiento perfectivo.

El mantenimiento adaptativo se encarga de hacer cambios menores en la funcionalidad del sistema para asegurarse que permanece alineado con los nuevos requerimientos del negocio. Las actividades de mantenimiento pueden dirigirse también hacia la eliminación de errores en el código (mantenimiento correctivo) o la optimización del código existente para cumplir mejor con los requerimientos funcionales y de calidad de servicio (mantenimiento perfectivo).

La migración es una alternativa con alto impacto en el sistema y es considerada una solución de largo plazo. La migración busca reutilizar, tanto como le sea posible, los procesos existentes en el sistema legado, incluyendo el diseño y la especificación, de tal forma que se conserve la funcionalidad del sistema original a pesar de residir ahora en una plataforma tecnológica diferente.

La migración requiere generalmente el re-desarrollo de partes del sistema partiendo de la definición actualizada de algunos procesos de negocio. Esta metodología se denomina ‘top-down’ o de arriba hacia abajo. La metodología inversa, que parte desde el código legado para identificar los procesos de negocio, se denomina ‘bottom-up’ o ingeniería en reversa.

La migración puede llevarse a cabo de manera incremental, donde ciertos procesos de negocio presentes en el sistema original, son implementados sobre el nuevo sistema y posteriormente se hace una transferencia gradual de control desde el sistema original hacia el nuevo sistema; o con una aproximación conocida como Big-Bang, donde el sistema original es desconectado para dar paso al nuevo sistema. En los procesos de migración es importante evitar, de ser posible, la interrupción de las operaciones soportadas por el sistema.

No siempre es posible categorizar un problema de evolución en base a una de estas alternativas. Estas pueden combinarse o ser aplicadas en distintas partes del sistema para cumplir con el objetivo de modernización. Aun cuando estas acciones se definen a nivel del sistema en general, su aplicación se hace típicamente a nivel de componente funcional.

Una valoración sobre el sistema, considerando los aspectos necesarios para garantizar su continuidad y disponibilidad durante el tiempo (aspectos que incluyen factores como la disponibilidad de soporte en hardware y software), y la determinación de continuar con la operación de los procesos soportados en el sistema, permite tomar una decisión sobre la estrategia adecuada para evolucionar el sistema.

Durante el proceso de migración se debe procurar evitar que nuevos componentes de alto riesgo sean introducidos en el portafolio de soluciones de la empresa.

La evolución del sistema puede ser aproximada de dos maneras: mediante la integración del sistema con nuevas aplicaciones y componentes, técnica conocida como modernización de caja negra, donde un conocimiento general del sistema permite iniciar labores de integración; o mediante la transformación con un esquema de ‘caja blanca’, donde se requiere un conocimiento detallado del sistema, sus procesos, operaciones e interacciones para poder definir correctamente los requerimientos de negocio que serían soportados en el sistema objetivo. Un entendimiento insuficiente del sistema podría llevar a una especificación de requerimientos incorrecta, lo que llevaría a un proceso de migración no satisfactorio.

Transición hacia el nuevo sistema

El último paso en un proyecto de migración consiste en la transición hacia el nuevo sistema.

Existen tres estrategias principales de transición:

1. La estrategia Big-Bang. Consiste en apagar el sistema y reemplazarlo por el nuevo sistema  (todo o nada).
2. La estrategia de interoperabilidad por fases (gradual o incremental). Donde la transición se llevaría a cabo en pasos pequeños e incrementales, cada paso reemplazando unos pocos componentes del sistema legado con componentes correspondientes en el sistema objetivo.
3. Estrategia de operación en paralelo. Donde los sistemas legado y el sistema objetivo funcionarían simultáneamente y ambos ejecutarían todas las operaciones. Durante este periodo el sistema objetivo sería continuamente probado, y una vez certificada su conformidad, se retiraría el sistema legado.

La estrategia Big-Bang es algo irrealista por los riesgos que implica. La transición hacia el nuevo sistema en un solo paso cede el control total de operaciones y del flujo de información a un sistema que no ha demostrado sus méritos. Por otro lado, la interoperabilidad por fases es potencialmente compleja. Para ser exitosa requiere que los servicios soportados en el sistema legado sean descompuestos y separados en módulos funcionales que puedan ser migrados independientemente. La naturaleza monolítica y no estructurada de muchos de los sistemas legados hace que esta tarea no sea sencilla.

Una estrategia de transición para un sistema legado probablemente involucraría una combinación de estas tres aproximaciones aplicadas a partes distintas del sistema.

Para la estrategia combinada se seguirían los siguientes pasos para migrar componentes del sistema legado al nuevo sistema (aproximación incremental):

1. Análisis de la porción del sistema legado involucrada en la migración
2. Descomposición del componente o módulo funcional
3. Diseño de la interfaz objetivo (puntos de contacto o interacción con otros componentes o módulos)
4. Diseño de la aplicación objetivo
5. Diseño de la base de datos (o tablas) objetivo
6. Instalación del ambiente destino (aplicaciones middleware necesarias, activación de servicios, etc)
7. Migración de los datos desde el sistema legado
8. Migración de las aplicaciones del sistema legado
9. Migración de las interfaces del sistema legado
10. Transición al nuevo sistema

Usando esta estrategia, las aplicaciones del sistema legado serían gradualmente reconstruidas en el sistema objetivo usando tecnología moderna. El sistema objetivo sería inicialmente pequeño pero crecería según el proceso de migración sea llevado a cabo. Eventualmente el sistema soportaría toda la funcionalidad requerida del sistema, permitiendo el retiro del sistema legado (phase-out).

Dadas las expectativas que se generan durante los proyectos de migración, debido a la incorporación de tecnologías más modernas y flexibles, usualmente se espera contar con la adición de nuevas funcionalidades para justificar el tiempo, el riesgo y el costo invertido en el proyecto. No es recomendable la introducción de nuevas funcionalidades al sistema objetivo durante el proceso de migración. Dada la naturaleza de misión crítica de los sistemas legados, las salidas del sistema objetivo deberían ser completamente consistentes con aquellas producidas por el sistema original. Cuando la funcionalidad es equivalente, los planes de testing, que serían ejecutadas continuamente durante el proceso de migración, podrían enfocarse en comparar las salidas del sistema original con aquellas del nuevo sistema para determinar su validez.