Dirección estratégica de la infraestructura y las operaciones

La gestión de servicios de TI explica cómo se organizan las actividades en un centro de servicios TI de una empresa u organización, según un modelo "orientado a servicios". Esto significa partir de unos servicios finalistas de TI, que se alimentan de otros servicios internos o externos y que soportan los procesos de negocio de la empresa.

La gestión de la disponibilidad explora con más detalle este proceso (ITIL), de acuerdo con un enfoque de análisis coste-beneficio entre los niveles de disponibilidad de los diferentes servicios de TI y el impacto en los negocios que soportan ante las inversiones en infraestructuras, en cambio tecnológico y en mejora de los procesos de TI.

Las decisiones de arquitectura (quizás las de cariz más estratégico y permanente) analizan las diferentes arquitecturas de un centro de servicios TI. Desde las arquitecturas de proceso en la empresa hasta las arquitecturas de las infraestructuras de servidores, pasando por las arquitecturas de las aplicaciones y otro software intermediario. El diseño arquitectónico está conectado con la disponibilidad de los servicios, y con la eficiencia de su construcción y mantenimiento, mediante el desacoplamiento entre aplicaciones de negocio e infraestructuras tecnológicas.

La gestión de la capacidad se refiere de nuevo a los procesos ITIL que tratan sobre la disponibilidad de capacidad en el sentido amplio de la palabra; es decir, las necesidades a corto plazo, del día a día, de disponer de la suficiente capacidad de proceso y la tecnología con suficiente nivel de actualización. A medio plazo y a largo plazo se plantean necesidades de transformación más importantes y radicales de cambios en la plataforma tecnológica. Estas transformaciones precisan de un plan tecnológico que tiene que dibujar la hoja de ruta de migración de las infraestructuras, del software y de las aplicaciones, de gran impacto en el conjunto global de servicios TI a los negocios.

Las decisiones de estandarización tecnológica, derivadas en gran parte de lo que se denomina la comoditización de las infraestructuras, que se ha producido por la propia evolución del mercado, la exigencia de los clientes y el abaratamiento de costes de almacenamiento y mantenimiento de todo tipo de infraestructuras, a través de instalaciones virtuales y remotas (todo el fenómeno de la nube).

Las decisiones de provisión y gestión de la infraestructura tecnológica. Las tendencias de evolución tecnológica, estandarización y comoditización de la infraestructura tecnológica están acelerando el proceso de externalización de la provisión y/o gestión de estos servicios.

Servicios finalistas. Servicios que visualiza el cliente/negocio, que le aportan valor con un determinado coste y unos acuerdos de nivel de servicio. En principio, el cliente/negocio no tiene por qué saber cómo se realizan ni qué coste interno tienen para el proveedor, ni de qué otros servicios depende. En ocasiones, los servicios finalistas se denominan también servicios comerciales, sobre todo cuando los servicios TI de la empresa proporcionan también servicios TI a clientes externos; es decir, ofrecen adicionalmente sus servicios en el mercado.

Servicios internos o técnicos. Servicios necesarios para proveer los servicios finalistas. Estos servicios se pueden ofrecer también a otros servicios internos.

Requerimientos del negocio.

Nombre y descripción del servicio.

Niveles de servicio

• Objetivos

• Horarios de servicio

• Costes

• Precios

Activos

• Aplicaciones

• Infraestructuras

• Datos

• Entorno

Servicios de apoyo: procesos de apoyo de los objetivos:

• Acuerdos de nivel de servicio operativos.

• Contratos

• Servicios de apoyo

• Procesos IT

Recursos

• Equipos de apoyo

• Proveedores

Servicio de sistemas de información. Las transacciones y las actividades y los procesos necesarios para los usuarios de los negocios que se ejecutan en las infraestructuras técnicas de TI. Están formados por un conjunto de aplicaciones, servidores, sistemas operativos y bases de datos.

Servicio de puestos de trabajo. Servicios que se dan a los dispositivos, fijos y móviles, que interaccionan directamente con los usuarios de negocio (PC fijo, PC portátil, PDA, tableta, teléfono inteligente, teléfono fijo, teléfono móvil, etc.). Este servicio incluye, también, el mantenimiento y/o sustitución del terminal (hardware), el mantenimiento del software residente en el terminal y la provisión de la identidad y derechos de acceso.

Servicio de telecomunicaciones. Servicios que permiten que los puestos de trabajo se comuniquen con las infraestructuras técnicas de TI.

El responsable de servicio finalista (funcional o comercial) tiene un cariz estratégico, orientado al negocio y de definición funcional. Sus funciones son las siguientes:

• Establecer las condiciones del servicio, ANS, disponibilidad, fiabilidad, seguridad.

• Establecer el coste/precio del servicio.

• Responsabilizarse del output del servicio; es decir, del resultado para el usuario.

• Conocer la funcionalidad del negocio al que da el servicio.

• Conocer la arquitectura de aplicaciones que dan servicio al sistema de información.

• Proponer la evolución futura y las mejoras del servicio.

El responsable técnico o tecnológico de un servicio finalista tiene que hacer que se produzca dicho servicio. Es quien conoce cómo es por dentro y cómo se produce el servicio, lo cual no tiene un interés especial para el negocio. Gestiona el día a día de las operaciones necesarias para dar el servicio finalista. Sus funciones son las siguientes:

• Controlar la cascada de servicios internos/técnicos necesarios para hacer funcionar el servicio finalista o comercial.

• Conocer la arquitectura de los diferentes servicios "proveedores" y saber de qué manera contribuyen a la consecución del servicio finalista.

• Asegurar el logro del nivel de calidad acordado en todos los servicios que controla.

Servicios de proceso de datos. Se trata de los servidores de proceso, servidores de bases de datos, servicios de impresión, servicios de electrónica de comunicaciones, servicios de almacén de datos (robot de copias de seguridad). En centros grandes, pueden coexistir varias tecnologías que requieren servicios especializados diferenciados ⁽³⁾ . Para cada uno de estos servicios habrá que definir niveles de servicio, horarios de disponibilidad, mecanismos de alta disponibilidad para hacer frente a posibles averías. También hay que disponer de servicios de apoyo técnico que permitan la reparación rápida de caídas.

Servicios de instalaciones físicas (infraestructuras CPD). Se trata de disponer de un espacio físico condicionado, de la alimentación eléctrica necesaria, de los sistemas de refrigeración adecuados, de los sistemas de continuidad eléctrica pertinentes y de sistemas de seguridad física suficientes. Por lo tanto, como servicio, hay que disponer de acuerdos de nivel de servicio con los servicios de hardware (temperatura, humedad, disponibilidad de acometida eléctrica, consumos energéticos, etc.). Y, evidentemente, hay que haber establecido mecanismos de backup ante contingencias, como por ejemplo, los cortes de suministro eléctrico.

Gestión de la demanda de servicios tecnológicos: Establecer la estrategia de servicios de infraestructura tanto de los que precisan directamente los usuarios como de los que precisan los sistemas de información para lograr los niveles de servicio acordados con los gestores de los servicios finalistas de sistemas de información (aplicaciones).

Elaboración de un catálogo de servicios. Este catálogo tiene que incluir tanto servicios finalistas (como por ejemplo, el arranque de un proceso por lotes batch, o la recuperación de un proceso), como de tipo interno; es decir, los que proporcionan servicios de proceso y almacén a las aplicaciones o a los puestos de trabajo.

Diseño y elaboración de un plan tecnológico. Este plan tiene que avanzarse a las necesidades a medio plazo y a largo plazo de la evolución de los sistemas de información, debidas tanto a las necesidades del negocio como a la evolución tecnológica de los proveedores.

Gestión del catálogo de servicios de infraestructura. Como ya hemos comentado, se trata de asegurar que se realice un catálogo de servicios que contenga información precisa y actualizada de todos los servicios operacionales, y se registre debidamente. La gestión de este catálogo provee de información fundamental para el resto de los procesos de gestión de servicios, como por ejemplo, detalles de las características de los servicios, el estado actual o las interdependencias.

Gestión del nivel de servicio (SLM ⁽⁴⁾ ). Se trata de establecer y negociar acuerdos de nivel de servicio con los clientes (en el supuesto que nos ocupa, servicios finalistas de sistemas de información), y también diseñar servicios de acuerdo con los objetivos propuestos. La gestión del nivel de servicio también es responsable de asegurar que los acuerdos de nivel operacional (OLA ⁽⁵⁾ ) y los contratos de apoyo (UC ⁽⁶⁾ ) sean los adecuados, y de de supervisar los niveles de servicio e informar.

Gestión de la capacidad. Se trata de asegurar que la capacidad de servicios de la infraestructura permita lograr los objetivos de capacidad acordados de manera económicamente efectiva y puntual. La gestión de la capacidad tiene en cuenta todos los recursos necesarios para los servicios de infraestructuras TI y prevé las necesidades a corto, medio y largo plazo, tanto desde el punto de vista de la capacidad de los sistemas como del de los recursos humanos del servicio.

Gestión del riesgo. Se trata de identificar, evaluar y controlar riesgos; esto incluye el análisis del valor de los activos de infraestructura, la identificación de amenazas a estos activos y la evaluación de su vulnerabilidad ante estas amenazas.

Gestión de la disponibilidad. Se trata de definir, analizar, planificar, medir y mejorar la disponibilidad del servicio en todos los aspectos; es decir, asegurar que la infraestructura, los procesos, las herramientas y las funciones de TI sean adecuados para lograr los objetivos de disponibilidad propuestos.

Gestión de la continuidad del servicio de TI. Se trata de controlar los riesgos que podrían impactar seriamente en los servicios de TI y poner en peligro la continuidad del negocio; es decir, controlar que el proveedor de servicios de TI asegure un nivel mínimo del servicio propuesto, de manera que se reduzca el riesgo de acontecimientos desastrosos, a la vez que se planifica la recuperación de servicios de TI.

Gestión de la seguridad de TI. Se trata de asegurar la confidencialidad, la integridad y la disponibilidad de las informaciones, datos y servicios de TI de una organización. Normalmente, la gestión de la seguridad de TI forma parte de la política global de seguridad de una organización y tiene, por lo tanto, un alcance más amplio que la diseñada por el proveedor de servicios de TI.

Gestión del cumplimiento de normativas y estándares de trabajo. Se trata de asegurar que los procesos, sistemas y servicios de TI cumplan las políticas corporativas y los requerimientos legales, como por ejemplo, metodologías, arquitecturas, plan tecnológico o políticas de seguridad.

Gestión de la arquitectura de TI. Se trata de diseñar los servicios de infraestructura de acuerdo con el plan tecnológico, teniendo en cuenta la estrategia global de los servicios finalistas. Como veremos más adelante, en centros grandes hay que mantener una arquitectura de servidores muy compleja, dado que en situaciones de multiproveedor los cambios de versión siguen evoluciones diferentes y, por lo tanto, es difícil mantener la compatibilidad y coherencia global si se quiere que exista interoperabilidad entre las diferentes plataformas (cosa que, a veces, es imposible). Por lo tanto, es fundamental definir lo que se denomina arquitectura de infraestructuras. El arquitecto de infraestructuras tiene que prever la evolución de la tecnología y tiene que disponer de un plan tecnológico que proporcionará la hoja de ruta de la transformación ordenada de todos los elementos a medio y a largo plazo.

Gestión de proveedores. Se trata de asegurar que todos los contratos de suministradores apoyen las necesidades de la empresa y que todos los suministradores cumplan los compromisos contractuales. Si se tiene en cuenta que el nivel de externalización en estos tipos de servicios es muy alto, la dependencia de los servicios de los proveedores externos es crítica y requiere de una política rigurosa tanto en los procesos de selección del proveedor, como en los de mantenimiento y seguimiento del contrato.

Gestión de cambios. Hay que planear muy cuidadosamente los cambios en los componentes infraestructurales de las aplicaciones, y en los cambios importantes de las propias infraestructuras con el objetivo de provocar el mínimo de interrupciones y caídas de servicios afectados por estos cambios. Hay que tener en cuenta que hay cambios en las aplicaciones que afectan a las infraestructuras y viceversa. Los proyectos de infraestructura se tienen que dirigir como cualquier otro proyecto y, por lo tanto, se tienen que incluir en el portafolio de proyectos, ser coordinados por la oficina de proyectos y evaluados según coste, tiempo y calidad.

Gestión de versiones. Hace falta un control y una programación de los diferentes elementos que se ponen en producción para evitar incoherencias en el conjunto y permitir dar marcha atrás en caso de implantación fallida.

Validación y pruebas. Todos los cambios en los servicios de infraestructuras se tienen que testear previamente para garantizar que ofrecen los servicios deseados por las aplicaciones que soportan. Del mismo modo, cuando haya que hacer un cambio de infraestructuras, hará falta testear las aplicaciones en el nuevo entorno antes de su instalación definitiva. A menudo es causa de fallo en la puesta en marcha confiar en que los cambios en la infraestructura son "transparentes" en las aplicaciones, tal como dice el fabricante propietario del producto tecnológico, y no hacer el test en las condiciones comentadas. Testear todas las aplicaciones que se pueden ver afectadas por un cambio en una infraestructura tecnológica es uno de los costes ocultos más importantes de las organizaciones TI, pero como el negocio no obtiene ninguna mejora o valor por este cambio, no se pone demasiado interés en defenderlo.

Parametrización y personalización. Adaptación de las plataformas y productos tecnológicos a las necesidades de los servicios, de acuerdo con las funcionalidades especificadas. Este proceso requiere personal altamente especializado y con fuertes conocimientos de productos concretos. A menudo los fabricantes pasan una formación específica para sus productos y la certifican.

Activos de servicio y gestión de la configuración. El mantenimiento de la base de datos de gestión de la configuración (CMDB ⁽⁷⁾ ) es uno de los procesos básicos en infraestructuras y aplicaciones. En la CMDB es donde se conserva la información requerida para la prestación de los diferentes servicios.

Gestión de acontecimientos. Hace falta monitorizar el funcionamiento de todos los elementos activos de la infraestructura tecnológica. La gestión de acontecimientos se ve facilitada por la incorporación de elementos de monitorización en los diferentes sistemas. De todas maneras, en organizaciones TI grandes y complejas hacen falta productos de monitorización global que permitan concentrar en una sola mirada todos los controles, de este modo se dispone de una visión global y se rentabilizan los costes de operación.

Gestión de incidencias. La gestión del ciclo de vida de las incidencias pretende devolver el servicio de TI a los usuarios cuanto antes mejor. Un componente fundamental de este proceso lo constituyen los protocolos de actuación ante incidencias detectadas ⁽⁸⁾ En concreto, tiene que estar predefinido, en cada caso, el escalado de resolución de la incidencia sin ambigüedades (hay que definir adecuadamente los niveles de especialización necesarios para cada tipo de incidencia). Normalmente, el servicio SAU resuelve los primeros niveles de las incidencias de usuario (nivel 1 y nivel 2), escalando a otros servicios si no lo puede hacer (nivel 3: servicios de apoyo técnico). En ocasiones se define un nivel 4 de servicios superexpertos para incidencias de gran complejidad y criticidad, normalmente del proveedor externo del producto o servicio.

Peticiones de servicio. Normalmente son peticiones menores cuya resolución no pide la creación de un servicio nuevo o proyecto, sino que se pueden resolver mediante actividades concretas que se pueden llevar a cabo desde el SAU (por ejemplo, restaurar una contraseña) o servicios ad hoc (por ejemplo, el servicio de provisión de identidades y derechos de acceso). Cada vez más se tiende a automatizar la respuesta a este tipo de peticiones haciendo que sea el propio usuario quien resuelva su incidente con sus propios medios (caso de la contraseña, por ejemplo) mediante formación, ayudas en la intranet o herramientas de usuario final. De este modo se reducen los costes del SAU.

Gestión del acceso. Consiste en otorgar determinados derechos a los usuarios, el más importante de los cuales es el de proporcionarle la identidad que le permitirá estar dado de alta en la organización y disponer de un paquete de servicios básicos, como por ejemplo, el correo electrónico, paquetes de ofimática estándar, servicio de ficheros en la red o servicio de productos de seguridad (por ejemplo, el antivirus). A partir de la identidad se establecen los derechos de acceso a las aplicaciones y las bases de datos, según las políticas de seguridad de acceso establecidas por los diferentes negocios y a nivel corporativo. Todas estas informaciones acostumbran a residir en algún tipo de directorio o repositorio central que es consultado por todos los servicios técnicos de aplicaciones e infraestructurales. Una mala gestión de estos derechos comporta descontrol en los costes de licencias y en la factura global que la organización TI tiene que abonar a los diferentes proveedores, además de riesgos por la seguridad.

Gestión de problemas. Consiste en controlar el ciclo de vida de todos los problemas con el objetivo de prevenir incidentes y minimizar el impacto de aquellos que no se pueden prevenir. La gestión proactiva de problemas analiza los registros de incidentes y utiliza datos de otros procesos de gestión del servicio de TI para identificar tendencias o problemas significativos. Es fácil confundir una incidencia con un problema. Normalmente, una incidencia repetida esconde la existencia de un problema: una incidencia acostumbra a ser el síntoma de un problema (que es la causa). Pero tampoco hace falta sobreactuar y gestionar cada incidente como si fuera un problema. Es importante distinguir la gestión de incidentes de la gestión de problemas que tendrán soluciones, procesos y responsabilidades muy diferentes.

Gestión de la operación de las infraestructuras. Este proceso acostumbra a recibir el nombre de explotación y consiste en monitorizar y controlar los servicios y las infraestructuras de TI. La gestión de operaciones de TI se ocupa del día a día de la operación de componentes y las aplicaciones de infraestructuras, lo cual incluye la programación de trabajos en un calendario, actividades de apoyo y restauración y el mantenimiento rutinario.

Costes tangibles

• Pérdida de productividad de los usuarios de los negocios.

• Pérdida de productividad de los técnicos de TI.

• Pérdida de ingresos.

• Coste extra por tiempos extras dedicados.

• Pérdidas de bienes en la producción.

• Multas y sanciones estipuladas en los contratos.

Costes tangibles

• Pérdida de clientes.

• Pérdida de notoriedad.

• Incremento de la insatisfacción.

• Daño a la reputación del negocio.

• Pérdida de confianza en los servicios TI.

• Impacto sobre la moral de los trabajadores.

Procesos centrales en el diseño del servicio. Gestión de incidencias, gestión de problemas, gestión de configuraciones, etc. Todos ellos tienen un impacto central en la minimización del impacto de la no-disponibilidad.

Procesos de alta disponibilidad. Diseños de las infraestructuras técnicas que, mediante sistemas redundantes, permiten recuperar el servicio en poco tiempo. Desde sistemas muy simples, que en minutos se pueden recuperar mediante procesos manuales, hasta sistemas automáticos en clúster, que permiten mantener el servicio con caídas inapreciables para el usuario.

Registro de incidencias. El registro de incidencias (y de la gestión de incidencias) permite informar a todos los actores de las características precisas de la incidencia y aportarles los datos imprescindibles para su resolución.

Escalado en la gestión de incidencias. Hay que diseñar el proceso de comunicación y resolución de incidencias de manera que se minimicen los tiempos que transcurren entre cada fase del proceso: tiempo que tarda en producirse la alerta, tiempo que tarda en llegar el equipo de reparación (apoyo técnico) o el tiempo que se consume en la reparación y la recuperación del servicio.

Relación con los proveedores. En la gestión de proveedores de servicios de apoyo técnico hay que llegar a acuerdos de nivel de servicio estrictos, que pueden determinar, por ejemplo, la disponibilidad de piezas de repuesto o el acceso al fabricante del producto.

CMDB. Tener una CMDB actualizada permanentemente asegura eficacia y eficiencia en la detección, la identificación, el diagnóstico y las ayudas a la resolución de incidencias.

Sistema de comunicación con el usuario. Es imprescindible que los usuarios estén constantemente informados de la situación de la resolución y que dispongan de estimaciones sobre el tiempo de reanudación del servicio, de manera que puedan tomar decisiones sobre la activación de planes B cuando consideren que el tiempo de no disponibilidad puede ser excesivo. Aún es más importante, como criterio de diseño, que los usuarios conozcan y acuerden los niveles de no disponibilidad calculados y estén informados con anterioridad de cuándo existen circunstancias (por ejemplo, cambios de versiones) que permiten prever una situación de no disponibilidad.

Mantener un conjunto de planes de continuidad y planes de recuperación del servicio que apoyan a los planes de continuidad del negocio (PCN).

Practicar ejercicios periódicos que aseguren que los planes de continuidad se mantienen de acuerdo con los cambios en los negocios y en sus requerimientos.

Proporcionar asesoramiento a los departamentos de la empresa sobre temas relacionados con riesgos y continuidad.

Hacer ejercicios periódicos de análisis de riesgos conjuntamente con los procesos de gestión de la disponibilidad y gestión de la seguridad, que aseguren que los servicios TI trabajan con los niveles acordados de aceptación de riesgos.

Asegurar la construcción de los sistemas de seguridad y recuperación, y su puesta en producción.

Evaluar los impactos de los cambios en los planes de continuidad y recuperación.

Asegurar la existencia de medidas proactivas de mejora de los servicios siempre que sea justificable en costes.

Acordar los contratos con los proveedores los servicios continuidad y recuperación.

Desacoplamiento. Se implementa un desacoplamiento del código de los servidores respecto del código del cliente, con independencia de plataformas y tecnologías, de manera que los códigos de cada uno tienen ciclos de vida independientes y pueden estar soportados por tecnologías diferentes que tienen su particular evolución en el tiempo.

Modularidad. Facilita la creación de aplicaciones modulares heterogéneas, basadas en los servicios, que interoperan entre ellas y comparten información.

Reutilización. Uno de los principales argumentos de la arquitectura SOA. Se reutilizan fragmentos de código ya desarrollados en forma de servicios en diferentes aplicaciones.

Interoperabilidad. No importa sobre qué lenguaje o plataforma trabaja el servicio.

Escalabilidad. Por medio de un acoplamiento flexible y las características de la capa de integración, el servicio se puede escalar horizontalmente o verticalmente según las necesidades. Las peticiones asíncronas permiten la posibilidad de soportar un gran número de usuarios sin sobrecargar la red.

Flexibilidad. Gracias al desacoplamiento es muy fácil adaptar las aplicaciones a nuevas necesidades.

Eficiencia. Gracias a la reducción de costes y tiempos de desarrollo que comporta la reutilización de los servicios, se puede incrementar la velocidad de construcción de nuevas aplicaciones. También hay que tener en cuenta la reducción de costes de mantenimiento debido a la menor complejidad del código del cliente, la claridad que proporciona la separación de funciones de cada parte del código y la ventaja de no tener que rehacer código cuando cambia la tecnología en alguna parte de los servicios.

Obsolescencia. El periodo de construcción de las diferentes piezas puede ser superior al periodo de tiempo en el que estos componentes son útiles; es decir, puede pasar que cuando todo el conjunto de componentes esté listo, varios componentes ya tengan funcionalidades obsoletas o que no interesen.

Costes de administración del catálogo de componentes. Hace falta una definición funcional de cada componente muy estricta con un conocimiento perfecto de los outputs de cada componente respecto del conjunto de inputs posible.

Estrategia de construcción de componentes. Hay que decidir el nivel de granularidad: piezas grandes con muchas capacidades y funciones, o piezas pequeñas con definiciones muy claras y simples.

El diseño de arquitecturas no es sólo una cuestión técnica, al conocimiento técnico (que tiene que ser exhaustivo) hay que añadir el siguiente:

• La visión de empresa, que muestra el modelo actual y futuro de la organización en la forma de una serie de flujos y servicios de relación entre clientes internos y externos.

• La visión de los procesos, que muestra quién hará qué, donde, cuando y con qué herramientas.

• La visión de la información, que describe las necesidades de datos, información y conocimiento de la empresa.

• La visión de las aplicaciones, que muestra qué aplicaciones apoyarán al trabajo (la misión y los procesos) de la organización.

El objetivo principal tiene que ser la flexibilidad y capacidad de adaptación. Las consideraciones de elegancia técnica, coste, riesgo, amigabilitat, rendimiento, etc., a pesar de que importantes, tienen que ser secundarias. La arquitectura tiene que ser capaz de asegurar la continuidad de la misión y los procesos básicos de negocio de la empresa y, a la vez, de adaptarse a los cambios y prioridades del negocio para asegurar y aumentar las ventajas competitivas.

Cada arquitectura de empresa es única, no se puede copiar, no se puede aportar desde el conocimiento externo (a pesar de que los consultores y los expertos puedan ayudar a elaborarla), no se puede sustituir con la incorporación de un sistema de información de empresa (ERP), a pesar de que en determinadas empresas pequeñas y medianas esto pueda ayudar.

Una arquitectura de empresa nunca se acaba. Cómo que el esfuerzo de diseño e implantación es grande, la tentación es hacerlo sólo un golpe y que dure por siempre jamás. Aun así, es más práctico, bajo algunos principios y criterios generales básicos y que sólo se deciden una vez, abordar el diseño y re-diseño de arquitecturas de una manera progresiva, iterativa y permanente. Consecuentemente, es muy bueno tener un proceso estructurado de diseño y construcción (una estrategia) y que algunos órganos de la empresa tengan esta tarea (este servicio) asignado. Una buena recomendación se tener un consejo (board) permanente y un "arquitecto en ningún" (chief architecture).

La arquitectura requiere un alto grado de conocimiento y este conocimiento es amplio y variado. Hacen falta habilidades de estructuración del conocimiento y un conocimiento y diálogo bastante abierto sobre cómo trabaja la empresa: qué sueño sus procesos, qué datos (operacionales y estratégicas) necesitan los trabajadores y directivos, qué aplicaciones y servicios técnicos, como está hecha la integración, en qué documentos y productos está todo esto soportado y cómo funcionan.

La estandarización es crucial. El diseño de servicios estandarizados y la vigilancia permanente de este nivel de estandarización es el único que permite a largo plazo la conectividad e interoperabilidad entre los procesos y las aplicaciones, tanto internamente como externamente, y la portabilidad entre diferentes entornos o ante cambios organizativos. Es también la condición para mantener la libertad e independencia de los proveedores externos de servicios.

Carencia de alineamiento con el plan global de sistemas de información, sobre todo en cuanto a evolución de los sistemas de información relacionados con el soporte a los procesos de negocio.

Carencia de una política de estándares y criterios de adquisición de tecnología: se produce una fragmentación en diferentes tecnologías que conviven.

Diseños arquitectónicos deficientes. Arquitectura de integración frágil con excesivas interdependencias.

Tecnologías obsoletas, o deficientemente mantenidas por el fabricante. Riesgo creciente de situación de caída del sistema con grave ruptura del servicio TI al negocio con elevados costes de restauración del sistema.

Empeoramiento de los niveles de disponibilidad del servicio. Crecimiento del número de caídas del sistema. Creciente dificultad de diagnóstico y resolución. Tiempo de recuperación progresivamente más alto. Tiempo de respuesta de las transacciones inadecuado. Carencia de capacidad de almacenamiento de datos.

Sistemas de protección de la continuidad de los servicios inexistentes.

Tecnologías demasiado caras, en el sentido de que han aparecido tecnologías con funcionalidades equivalentes o superiores con costes sensiblemente más bajos.

Sistemas de protección de datos deficientes, que no cumplen la legislación vigente.

Creciente desacoplamiento entre aplicaciones y sistemas operativos y entre los sistemas operativos y el hardware. Al menos en teoría, la realidad es que los sistemas operativos acaban por estar vinculados al hardware del mismo constructor, que hace lo que puede para mantener aspectos diferenciales (son su ventaja competitiva).

Tecnologías de virtualización. De una manera u otra, se consigue que las máquinas físicas, que por sí mismas ya están formadas por racks de procesadores todos iguales, alojen maquinas lógicas funcionando de manera totalmente independiente. De este modo, pueden coexistir centros de procesamiento (virtuales) de diferentes clientes y aplicaciones, por lo que se consigue rentabilizar el máximo de utilización del hardware, puesto que según la demanda del cliente en cada momento ocupan más o menos consumo de procesadores de una manera dinámica.

Los centros grandes con gran número de clientes se benefician del diferente ritmo de consumo según el horario, así como de los esquemas de consumo diferenciados en zonas geográficas distintas, debido a la diferencia horaria. También se benefician del "efecto estadístico" teórico según el cual las puntas de trabajo se distribuyen de manera distinta dependiendo del cliente. Gracias a la estructura de procesadores por racks, pueden apagarse de manera dinámica según el pattern de la demanda (horas valle) y obtener ahorros de consumo energético cada vez más importantes.

Disponibilidad de especialistas en los sistemas de hardware y los sistemas operativos. Los sistemas de virtualización son altamente críticos y complejos de gestionar, y precisan de personal con conocimientos especializados. El mantenimiento de las versiones de los sistemas operativos y de su compatibilidad con el hardware precisa también de especialistas. La compatibilidad entre aplicaciones y los sistemas operativos, y de estos con las diferentes versiones del hardware, es uno de los mayores problemas de cualquier centro de servicios TI (por lo tanto, el desacoplamiento del que hablábamos al principio es más teórico que real).

Las nuevas tecnologías de construcción permiten tener las máquinas dispuestas de modo que circulen flujos de aire frío y caliente que actúan con el máximo de eficiencia, con importantes ahorros de consumo eléctrico por refrigeración. Algunos centros se sitúan en zonas de clima frío para reducir el consumo por refrigeración.

Valorar la viabilidad del proceso de externalización. Cuanto más deficiente sea la gestión actual (un conocimiento bajo o fragmentado del conjunto de piezas que lo componen, una situación de complejidad de varios sistemas coexistiendo de manera precaria), más difícil será la externalización y puede, incluso, llegar a ser una garantía de fracaso en la transición y puesta en marcha del proceso. En estos casos, el cálculo del coste real de la gestión de un sistema complejo es difícil de evaluar (y se tiende a minusvalorar) y puede representar un coste insoportable para el proveedor una vez ha tomado su control.

Seleccionar el proveedor adecuado y establecer el contrato. Las IaaS representan una gran dificultad. Evidentemente, el proveedor puede incorporar a sus funciones la transformación de los sistemas para actualizarlos y simplificarlos, pero esta operación puede tener un coste muy elevado y, lo que es peor, difícil de evaluar y que hay que añadir al contrato global. El proveedor puede tener un papel pasivo de gestión de la operación o un papel proactivo de socio tecnológico en la optimización y renovación de las infraestructuras externalizadas.

Gestionar la transición es un elemento clave de este proceso. Si la infraestructura se encuentra inicialmente en locales del proveedor y está gestionada por él en todos sus aspectos de operación, soporte técnico, etc., el cambio a una situación de externalización es, en sí mismo, un proyecto de alto riesgo y debe ser abordado con la metodología de proyectos habitual por un equipo de proyecto mixto entre técnicos del proveedor y del cliente. Este equipo puede recibir el soporte de la oficina de proyectos de un tercero neutral y experto en este tipo de procesos. La planificación es esencial y los negocios clientes del servicio tienen que participar tanto en la planificación como en el seguimiento.

Hay que tener en cuenta que este es un proceso que puede durar bastante de tiempo, entre seis meses y un año, y es necesario, por lo tanto, desarrollarlo por fases que aseguren el mantenimiento de la calidad del servicio. El mantenimiento del servicio con un mínimo de interrupciones (con duraciones y horarios pactados) tiene que ser un requisito esencial durante el periodo de transición.

Incluir en el contrato la devolución del servicio al cliente para que pueda cambiar de proveedor o retomar de manera interna el servicio, con lo que esto supone de documentación exhaustiva y verdadera, y la complejidad y los costes de un proceso que es tanto o más complicado que la transferencia del servicio al externo por primera vez. Se puede decir lo mismo de los cambios de proveedor.