Hoy en día los servicios de TI son considerados como críticos para la supervivencia de muchos negocios, por lo que las áreas internas y los proveedores de TI requieren  dar  servicios altamente disponibles y estables, haciendo lo que sea necesario para que no se vean interrumpidos.

Estrategias para lograrlo hay muchas, por ejemplo los clásicos DRPs (planes de recuperación de desastre, por sus siglas en inglés), BCPs (planes de continuidad de negocio, por sus siglas en inglés), la implantación de arquitectura redundante, programas de concientización o la adopción de estándares y mejores prácticas de la industria, etc. Sin embargo, antes de definir una estrategia, es necesario que primero se tenga la información de los servicios de TI y de la infraestructura que los soporta, es decir, tener una visión exacta, completa y actualizada del entorno de TI, de las aplicaciones y los usuarios que dependen de éste.

Esto parece obvio para cualquier tipo de empresa pero, sobre todo en una organización de servicios, con la complejidad y la naturaleza dinámica del entorno económico y de la industria de TI, es difícil tener una visibilidad global de los activos, y es aún más difícil determinar las interrelaciones entre éstos.

¿Y dónde reside dicha información? Puede estar en un sinfín de lugares: en carpetas o pilas de papeles con el pretexto de que se requirió una firma para su validez, en el correo electrónico de cada uno de los operadores de un help desk, en los sistemas internos hechos en casa o por proveedores, en las páginas web de consulta para el público o desde otras aplicaciones que se “cuelgan” literalmente de las aplicaciones existentes para crear otras funcionalidades. De esta forma, la información viaja, se almacena, se explota, se actualiza y se accede a ella.

Tampoco es raro que la configuración de la red y elementos de comunicación por los cuales viaja dicha información solo la conozca el área de Telecomunicaciones de la organización.

Así pues, en la búsqueda de servicios de TI altamente eficientes y confiables lo primero que un área de TI debe hacer es conocer y entender la necesidad y requerimientos del negocio, para establecer la estrategia que apoye al logro de los objetivos del mismo y después tener a la mano toda la información relevante de los servicios de TI requeridos para ello. Esto implica que debe tener resueltas muchas interrogantes, entre ellas las siguientes:

  • ¿Realmente se está explotando adecuadamente la infraestructura tecnológica?, ¿está sobrada o está limitada?, ¿cuáles son los puntos de falla críticos?
  • ¿Qué equipos no tienen contrato de soporte asociado?, ¿qué contratos están vigentes y por vencer?
  • ¿Qué acuerdos de niveles de servicio internos y externos de aplicaciones e infraestructura están desarrollados de acuerdo a las necesidades del negocio?, ¿hay que cambiar los términos de los contratos?, ¿cuánto estamos dispuestos a pagar?
  • ¿Qué equipos están involucrados por cada aplicación?, ¿qué disponibilidad ofrecemos o se puede alcanzar?
  • ¿Qué impacto tendrán las aplicaciones con el cambio de cierta infraestructura?
  • ¿Cuál es el nivel de disponibilidad actual de los servicios?

Si no cuenta con respuestas, significa que no tiene suficiente información para analizar y entonces será difícil identificar áreas de oportunidad y establecer la estrategia adecuada.

Hacer un ejercicio de mapeo de aplicaciones vs infraestructura es una vista que provee la liga entre los elementos de configuración lógica y física. Esta vista se vuelve más sofisticada si nos lleva a determinar una relación más efectiva entre la administración de servicios y la evaluación de impactos para el negocio.

A continuación doy un ejemplo exponiendo lo que se hizo al respecto en cierta empresa de servicios y la estrategia que utilizaron para el mapeo. Enuncio sólo 3 casos de situaciones internas para mostrar que no contaban con la información completa y que no era nada fácil asegurar que los servicios permanecieran arriba y fueran estables, debido a la gran cantidad de variables en  juego:

  1.  Un usuario reporta a la mesa de ayuda que no funciona una aplicación. Las aplicaciones están catalogadas como críticas y de misión crítica, para que de ahí tomen acción los operadores, levanten el ticket correspondiente y realicen las escalaciones necesarias. El área asignada para resolver el problema es la que le da soporte a la aplicación y observa que hay elementos y funcionalidades desconocidos porque hubo cambios de los cuales no fue informada.
  2. Debido a que se decidió hacer cambios a una aplicación de misión crítica, es necesario programar una ventana de mantenimiento en la cual se dará de baja la aplicación por un periodo determinado. Se realiza el control de cambios y se planean las actividades de “rollback”, todo con un proceso informal. Sin embargo, cuando se inicia la ventana, se dan cuenta que hay otras aplicaciones que tenían dependencia de ésta y que no funcionan adecuadamente.
  3. El negocio determina que se realizará una venta especial de servicios, para lo cual se solicita que las aplicaciones funcionen al recibir miles de solicitudes. Sin embargo, hay cambios pendientes en la infraestructura, como el cambio de un switch central y no se cuenta con el tamaño suficiente en las bases de datos para las nuevas transacciones.

Así pues, para tener toda la película, se propusieron hacer el esfuerzo de llevar a cabo un análisis de la información necesaria de ciertas aplicaciones consideradas como de misión crítica vs la infraestructura que las soporta.

El objetivo del proyecto fue llevar a cabo la documentación de 4 niveles iniciando con el enfoque de procesos, seguido del mapeo de aplicaciones y el mapeo de infraestructura vs las aplicaciones críticas, que le permitiera a la organización tener claridad para realizar un análisis e identificar áreas de oportunidad para la toma de decisiones que apoyen al negocio. Los 4 niveles del mapeo se explican más adelante.

Primeramente, convocaron al grupo de personas de las áreas de desarrollo, telecomunicaciones y los responsables de soportar las aplicaciones, para conjuntar toda la información en 4 niveles. Así mismo, debían identificar los siguientes elementos:

  • Identificación de contratos de soporte.
  • Niveles de servicio comprometidos y existentes.
  • Identificación de procesos y procedimientos de atención a incidentes y problemas.
  • Relación de incidentes en la infraestructura.
  • Identificación de mecanismos de software y hardware para aumento de disponibilidad.
  • Identificación de premisas de diseño y dimensionamiento.
  • Procesos de administración de la capacidad.

Se apoyaron de una herramienta de modelado basada en UML 2.1 sobre plataforma Windows con una interfaz intuitiva y multiusuario (ver recuadro), con la cual se identifican las relaciones a nivel aplicación y a nivel telecomunicaciones, y a través de los 4 niveles de profundidad se fue desglosando la información:

  • El nivel 0 consistió en identificar todas las aplicaciones existentes y sus relaciones a nivel de aplicación, es decir, las relaciones vía bases de datos, web, tuxedo, FTP, etc.
  • El nivel 1 radicó en realizar el modelado con diagramas de flujo de los módulos más importantes identificando las relaciones con todas las otras aplicaciones y puntos críticos de falla.
  • El nivel 2 incluyó la documentación modelando la conectividad entre las aplicaciones relacionadas, incluyendo la interfaz o medio a través de la cual se da la comunicación.
  • El nivel 3 se dividió en 2 partes que ilustraban la instalación física del ambiente en producción con los diagramas de red y los diagramas de despliegue:
    • Los diagramas de red mostraban una aplicación fuente y una aplicación destino, identificando los servidores en donde residen y todos los elementos de infraestructura por la cual fluye la información entre ambas. También mostraba la conectividad entre los dispositivos de la infraestructura (servidores, switches, ruteadores, etc.)  y el detalle de protocolos y puertos.
    • Los diagramas de despliegue expresaban por un lado,  el modelado de los componentes de middleware como son servidores de aplicación y sistemas de manejo de bases de datos, y por otro, la forma en que están distribuidos los componentes de las aplicaciones a lo largo de la infraestructura y el middleware.  

Una vez que se hizo el primer esfuerzo en conjuntar toda la información, se reunieron los responsables de todas las áreas involucradas, que en algunos casos se encontraban en oficinas de diversos estados de la república, para revisarla y analizarla.

La dinámica que se siguió en las sesiones fue la demostración de los diagramas desarrollados a 4 niveles, aplicación por aplicación, para que los asistentes a las reuniones tuvieran una visión general del proyecto, conocieran y revisaran la información que se incluyó tanto de las aplicaciones como de la infraestructura que la soportan, y por último, identificaran áreas de oportunidad.

Estratégicamente, el grupo directivo de TI obtuvo respuestas para establecer un mejor control interno de las aplicaciones (planear los cambios de aplicaciones e infraestructura y las ventanas de tiempo, revisar políticas de acceso, respaldos, información en línea, relaciones existentes, etc.) y conocer la situación de la infraestructura contra las aplicaciones que soporta (repercusiones en cambios de algún componente, capacidades necesarias, contratos y proveedores), así como identificar áreas de oportunidad para establecer líneas tácticas.

Tácticamente se concluyeron varias líneas de acción:

  1. Determinar los niveles de servicio requeridos por el negocio, y así establecer niveles de servicio tanto de las aplicaciones como de la infraestructura, en los casos en que no hay, y revisar los existentes. De las aplicaciones analizadas consideradas como de misión crítica y críticas, no todas tenían definido un nivel de servicio general de disponibilidad y, solo algunas actividades de los módulos más importantes tenían tiempos de respuesta y un nivel de disponibilidad comprometidos.
  2. Dado que se demostró la existencia de unos cuantos procedimientos de soporte, hay que hacer un esfuerzo importante de documentación.
  3. Ya que no hay análisis de los incidentes presentados con mayor frecuencia en las aplicaciones y en la infraestructura de red y comunicaciones, se va a generar un reporte de los incidentes; lo cual va a representar un elemento adicional que aportará mayor profundidad en los análisis.
  4. Se observa también la ausencia de un proceso de administración de la capacidad, por lo que se desarrollará y pondrá en marcha, y deberá incluir las premisas de diseño y dimensionamiento de las aplicaciones e infraestructura y los mecanismos que pueden ser implementados para aumentar la disponibilidad.
  5. Compartir la información generada en este esfuerzo con todas las áreas para que las apoye en sus funciones y por otro lado, se fomente una  mayor comunicación entre ellas.
  6. El gran reto será mantener la información actualizada, por lo que se adaptará el proceso de administración de cambios para mantenerla viva.

Para terminar este artículo, concluyo con las acciones inmediatas que el área de TI está tomando y sus próximos objetivos:

  • Está tomando la información para realizar un análisis de riesgos lo que les dará mayor claridad para establecer estrategias y apoyar al negocio.
  • Incrementar su competitividad, mejorar su eficiencia y elevar la productividad. Operativamente, busca alcanzar la excelencia en la administración de la plataforma tecnológica, es decir, aprovechar mejor la infraestructura, ofrecer altos niveles de disponibilidad y cumplir con lo que requiere el negocio.
  • Se comenzaron a definir políticas para el uso de la información, lo que aceleró proyectos de implantación utilizando plataformas de arquitectura de aplicaciones, que a su vez ayudarán a realizar consultas más eficientes a las bases de datos, entre aplicaciones, y con menor riesgo para su integridad.
  • Por último, toda la información del ejercicio de mapeo se utilizará para poblar inicialmente una herramienta de Discovery (ver recuadro) y se está trabajando en el rediseño de conexiones de red.

[email protected]

_________________________________________________________________________________________________

Herramientas de modelado basados en UML

Las herramientas de modelado de sistemas informáticos, son herramientas que se emplean para la creación de modelos de sistemas que ya existen o que se desean desarrollar. Los modelos se generan dependiendo del tipo de sistema, de los datos, de los requerimientos, etc.

Cada herramienta resulta en uno o más diagramas (o esquemas) que representan el sistema completo o parte de él.  Cada diagrama «ayuda» al otro, permitiendo una mejor comprensión de la parte del sistema que modela.

Algunos tipos de diagramas son los de clase, de objeto, compuestos, de paquete, de componente, de despliegue, de flujo de datos, de entidad relación, de transición de estados, de diccionario de datos, de especificación de procesos, etc.

Las herramientas de modelado deben cumplir con determinadas características:

  • Permitir una visión descendente del sistema y la facultad de particionarlo.
  • Poseer componentes gráficos con algo de apoyo textual. 
  • El modelo resultado debe ser transparente, es decir, fácil de comprender. 
  • Poseer una mínima redundancia (el aumento de redundancia, disminuye la transparencia del modelo y aumenta las tareas de mantenimiento).

El UML (Lenguaje Unificado de Modelado, por sus siglas en inglés) provee beneficios significativos para ayudar a construir modelos de sistemas de software rigurosos y donde es posible mantener la trazabilidad de manera consistente.

El UML estándar está compuesto por tres partes: bloques de construcción (tales como clases, objetos, mensajes), relaciones entre los bloques (tales como asociación, generalización) y diagramas (por ejemplo, diagrama de actividad).

_________________________________________________________________________________________________ 

Herramientas de Discovery

Son herramientas que incluyen el descubrimiento inicial de activos en el entorno de TI, la gestión y la actualización de configuraciones de activos, la topología de las relaciones y dependencias, y la asociación de los usuarios finales con las aplicaciones de las que dependen. La topología debe incluir las relaciones físicas, las relaciones lógicas entre activos y procesos de negocio, y las relaciones lógicas entre los activos y procesos de negocio con las personas que los utilizan.

En otras palabras, llevar a cabo la captura, conciliación y actualización continua de las cuatro dimensiones de los datos del entorno TI:

  1. Activos — ¿Cuáles son las existencias totales de activos implantados?
  2. Configuraciones — ¿Cuáles son sus componentes y configuración? 
  3. Relaciones — ¿Cuáles son sus interdependencias? 
  4. Usuarios — ¿Quién utiliza los recursos?