Spanish (pdf)
Article in xml format
Article references
Automatic translation
Send this article by e-mail
Cited by SciELO 
Cited by Google 
Similars in
SciELO 
Similars in Google 
Permalink
1. INTRODUCCIÓN
El éxito de la introducción de las Tecnologías de la Información (TI) en las organizaciones está determinado por la gestión que se desarrolla de las mismas a través de la habilitación de un conjunto de sus capacidades, utilizando un grupo de facilitadores que forman parte de las prácticas de gestión [1], [2], [3], [4].
Los administradores de TI se enfrentan al desafío de alinear (hacer converger, armonizar, integrar, enlazar, sincronizar, etc.) los objetivos y procesos de TI a los de las organizaciones, aplicar la mejora continua en los servicios que prestan, medir su eficacia y demostrar un retorno de la inversión que evidencie el impacto de las TI como habilitadores y conductores de los cambios en las organizaciones. Para lograr este alineamiento en entornos de determinada complejidad caracterizados por dispositivos heterogéneos y dispersos con cortos períodos de obsolescencia, múltiples servicios sometidos a variados requerimientos regulatorios y sus usuarios desde contextos diversos, la automatización de la gestión de infraestructuras ti se ha convertido en un imperativo [5], [6], [7], [8], [9].
Se ha ido superando un modelo de gestión puramente orientado al monitoreo y control del rendimiento de la infraestructura existente. En este, el área de las TI de las organizaciones se apoyaba para la ejecución de los procesos sin recibir retroalimentación con respecto al impacto de parte de un sector que considera la alineación a los objetivos del negocio. Sin embargo, varios estudios internacionales demuestran que el desalineamiento sigue siendo una problemática que urge solucionar en las organizaciones [6], [10]-[15].
Existen múltiples marcos de referencia, iniciativas y estándares de lo que resultan dificultades para su aplicación alineada a los diferentes escenarios de negocios, aspectos que obstaculizan su integración, insuficiencias para la formulación de requisitos de las organizaciones como políticas de TI, y diversidad e inexactitud en la evaluación del impacto. La existencia de varios modelos para la gestión integrada complejiza la integración de estos, así como la representación de políticas de TI a ser ejecutadas en los diferentes dominios de gestión de las infraestructuras TI.
El presente trabajo propone un modelo que, utilizando estandarización, integración y automatización, debe contribuir a reducir la complejidad y el desalineamiento en la gestión de infraestructuras de las tecnologías de la información. En el mismo, se detallan los componentes del modelo.
2. DESCRIPCIÓN DE MARCOS DE REFERENCIA PARA GESTIÓN DE INFRAESTRUCTURAS ti
Se han publicado varias metodologías, estándares y guías de buenas prácticas que permiten la articulación entre personas, procesos y tecnología, con el objetivo de cumplir con los objetivos estratégicos y de operación en una organización. Además, incorporan gran cantidad de conocimientos acumulados a lo largo de muchos años en la explotación de infraestructuras TI en función de las organizaciones. Tales conocimientos se pueden utilizar como instrumentos para abordar tanto el gobierno como la gestión de TI, entre ellos: COBIT (por las siglas en inglés de Control Objectives for Information and Related Technology), ITIL (por las siglas en inglés Information Technology Infrastructure Library), las normas iso 20000, iso 27000, iso 38500, CMMI (por las siglas en inglés de Capability Maturity Model Integration) y eTOM (por las siglas en inglés de enhanced Telecomunication Operations Map). Todas estas consensuadas y validadas a nivel internacional por más de 155 países [16], [17].
No obstante, seleccionar uno o varios marcos apropiados para la gestión y el gobierno de las TI no resulta sencillo, ya que algunos, como en el caso de COBIT, aunque abordan los dominios tanto de la gestión como del gobierno, hacen mayor hincapié en este último, incluido un modelo de madurez [18]. Otros modelos como ITIL se enfocan en la gestión y en la definición de los aspectos funcionales, atributos operacionales y de organización [19], [20].
Por su parte, ISO 38500 enuncia el gobierno de las TI, sus principios y actividades; otros marcos como la ISO 27000 se orientan en la gestión de la seguridad. Adicionalmente, la implementación de un marco de referencia requiere de una inversión previa en conocimientos e infraestructura [21], [22][23].
La gran heterogeneidad de modelos y estándares existentes permite a las organizaciones seleccionar aquellos que se ajusten mejor a sus necesidades. Sin embargo, muchos de los marcos de referencia existentes se complementan, de ahí que la tendencia actual es a su integración, para garantizar la utilización de los mismos de manera eficiente [24], [25]. Estas soluciones de integración no incorporan la evaluación del impacto de tales prácticas en las organizaciones.
En la medida en que las infraestructuras TI han crecido en tamaño, complejidad y heterogeneidad, también ha crecido la necesidad de gestionarlas de manera integrada con el fin de hacer que sus características se puedan representar de forma estructurada y estandarizada.
Existen varios modelos de gestión que se han estandarizado, cada uno con su propio protocolo de comunicaciones y definición de información de gestión, utilizados en diferentes ámbitos. En razón a lo anterior, está presente el dilema de la integración de los modelos de gestión con vistas a tener un control holístico de la red y sus servicios. Una vía para lograrlo es la integración de los modelos de información.
Esta integración, unida a la automatización de la ejecución de políticas en las TI, debe permitir su comportamiento autonómico. Múltiples propuestas han surgido para lograr la integración de modelos de información pertenecientes a modelos de gestión estandarizados, pero las mismas no garantizan que se puedan ejecutar las políticas de la organización en las infraestructuras.
La mayor parte de las organizaciones operan utilizando una ventana de tiempo en la cual pueden realizarse los cambios en su infraestructura sin afectar el negocio.
La Gestión de Redes Basadas en Políticas (PBNM) permite hacer cambios en esa ventana de tiempo, pues facilita la automatización de tareas complejas y repetitivas; no obstante, está enfocada a la ejecución de políticas a nivel técnico y no tiene asociadas soluciones que faciliten el diseño de políticas de TI a partir de requisitos de las organizaciones [26].
Entre los modelos de información y datos más destacados se encuentran los correspondientes a los estándares SNMP (por las siglas en inglés de Simple Network Management Protocol), ampliamente utilizado en el ámbito de Internet, y osi sm (por las siglas en inglés de Open Systems Interconnection-Systems Management), que es la base de muchos otros modelos de información y ha sido poco utilizado debido a su complejidad. Otros modelos de información de amplia aceptación son CIM (por las siglas en inglés de Commun Information Model), SID (por las siglas en inglés de Shared Information Data Model) y DEN-ng (por las siglas en inglés de Directory Enabled Network-next generation) [27]-[36]. Los modelos de información mencionados anteriormente han sido estandarizados por diferentes organismos encargados de esto [30], [37].
CIM se destaca por ser un modelo de gran integrabilidad, cosa que logra gracias a su gestor de objetos, CIMOM, que abarca no solamente modelos de gestión estandarizados, sino también algunos propietarios [36]. Por otra parte, DEN-ng cuenta con gran capacidad para representar políticas, ya que precisa menos recursos para la ejecución de estas.
La representación de políticas mediante la tríada evento-condición-acción (ECA) empleada por DEN-ng faculta la inclusión, de forma explícita, de eventos que determinan cuándo deben evaluarse las políticas. Además, DEN-ng posibilita la representación del contexto del objeto gestionado, de ahí que ambos modelos, CIM y DEN-ng, brinden amplias capacidades para representar políticas en entornos de gestión integrados [38].
Según el grupo de trabajo del IETF (por las siglas en inglés Internet Engineering Task Force), un modelo de gestión basado en políticas incluye un contenedor o repositorio de políticas, un punto de decisión de políticas o servidor de políticas (PDP, por las siglas en inglés de Policy Decision Point) y uno o varios puntos de ejecución de políticas (PEP, por las siglas en inglés Policy Enforcement Point). En los PEP se aplican o ejecutan las políticas que gobiernan los dispositivos físicos. El pdp revisa las políticas almacenadas en el contenedor de políticas y efectúa un proceso de toma de decisiones independientemente de las características de los dispositivos asociados a los PEP.
Son los PEP los encargados de traducir las políticas en operaciones o comandos específicos que puedan ser interpretados por la tecnología de los recursos por ellos gestionados. La Fig. 1 muestra una arquitectura general para un sistema PBNM, que sigue la filosofía cliente-servidor [39], [40].
El atributo más importante que ofrece la PBNM es cierta abstracción útil para manejar la brecha que existe entre las necesidades del negocio y las políticas de TI a este nivel y el funcionamiento de los elementos de red. Dichas políticas gobiernan el funcionamiento en tiempo real de la infraestructura y proporcionan un poderoso mecanismo para lograr cierto nivel de autonomía en la gestión alineada a las necesidades de la organización [37].
Para el funcionamiento alineado de PBNM, se requiere diseñar políticas a nivel de negocio y estratificarlas hasta las instancias que se ejecutarán en los PEP.
Por otra parte, al segmentar la gestión en dominios, PBNM posee dificultades para el tratamiento de conflictos entre las políticas que se aplican a las diferentes áreas de influencia. Además, cuando se emplea esta arquitectura, es muy importante ser cuidadosos en la selección de los modelos de información que se utilizarán, en aras de la predictibilidad, eficiencia y la operación sobre múltiples soluciones de gestión integrada, así como soluciones propietarias [38].
Adicionalmente, los métodos para la evaluación del impacto de los modelos de gestión o gobierno para las organizaciones son diversos. Algunos evalúan el impacto a nivel estratégico [4] y otros el alineamiento estructural [41]. También se han empleado modelos de madurez [42]-[44]. Además, existen modelos para evaluar el impacto de la implementación de los diferentes marcos de referencia [16], [45], [46]. Esta dispersión en la evaluación de impacto no permite tener medidas globales para evaluar la gestión y el gobierno de las TI en las organizaciones en el ámbito estratégico, estructural y social.
3. PROPUESTA DE SOLUCIÓN
Como resultado de la necesidad de vencer la barrera de la diversidad de estructura, procesos y términos para la integración, alineamiento, disminución de la complejidad y aplicación pertinente en las organizaciones de los marcos de referencia, considerando las necesidades asociadas al monitoreo y control de las infraestructuras TI para tener un control holístico de las mismas mediante la automatización eficaz de políticas TI que se diseñen como resultado de la integración de marcos de referencia, y para corroborar la reducción de la complejidad y el incremento del alineamiento a través de la evaluación de impacto, se desarrolló el Modelo para la Gestión de Infraestructuras TI (MGITI). Su esquema general se muestra en la Fig. 2.
El MGITI parte de la obtención de un marco integrado para la gestión de infraestructuras TI, el cual, unido a las políticas, estrategias y sistema organizativo establecidos por la organización, facilita el diseño de políticas de TI contextualizadas a las necesidades de las organizaciones. Estas políticas de TI se dividen en automatizables y no automatizables, en función de lo cual diseña y dimensiona la infraestructura necesaria para la automatización de la ejecución de políticas de TI. Las políticas de TI automatizables se ejecutan sobre las infraestructuras TI. Finalmente se evalúa el impacto del MGITI para la organización.
Durante la investigación realizada para el desarrollo del MGITI, se identificaron un conjunto de premisas consideradas necesarias para la aplicación exitosa de dicho modelo. Estas premisas se obtuvieron del análisis de los factores críticos establecidos por consenso en el uso de las infraestructuras TI en las organizaciones [47]; y los factores de fracaso en la implementación de marcos de referencia. Ellas son:
La alta gerencia de las organizaciones debe conducir el empleo innovador de las infraestructuras TI para soportar sus procesos, incrementar la eficiencia y generar nuevas formas de negocio.
El personal que opera las TI debe estar familiarizado con los objetivos de la organización y estar calificado tanto para operar la tecnología instalada como para apoyar los procesos que se desarrollan en la organización.
La infraestructura TI debe ser al menos la necesaria para ofrecer los niveles de servicio que necesita la organización.
La organización debe incentivar la adopción de marcos de referencia tanto para la realización de sus procesos TI como para el gobierno y la gestión de las infraestructuras TI.
Seguidamente, se hace referencia a cada uno de los componentes del MGITI.
3.1 Marco integrado de procesos
Para la obtención del marco integrado de procesos contextualizados a la organización, primera componente del MGITI, útil para la gestión de la infraestructura TI, se propone el procedimiento que se muestra en la Fig. 3.
Fuente: elaboración propia.
Fig. 3 Procedimiento para la obtención del marco integrado de procesos para la gestión de infraestructuras TI
Como se puede apreciar en la Fig. 3, la obtención del marco integrado de procesos parte de la definición de las capacidades TI.
Se plantea en este que estas capacidades se obtienen a partir del análisis y síntesis de los catalizadores y factores críticos de éxito propuestos por COBIT v5, de las capacidades y recursos propuestos por ITIL v3, y de tener en cuenta los principales problemas en la adopción de marcos de referencia para la gestión de TI [22]. Se propone que algunas de las capacidades TI a considerar por una organización sean:
Desarrollo tecnológico: tiene en cuenta el desarrollo del hardware y de las aplicaciones y de los servicios de TI en función de generar valor para la organización
Sistema organizativo: incluye principios y políticas, estructura, relaciones y mecanismos de comunicación, así como flujos de información.
Capacidad económica: considera los gastos de inversiones CAPEX (por las siglas en inglés de CAPITAL EXpenditures) y los gastos de operación OPEX (por las siglas en inglés de operating EXpense) para garantizar, entre otras cosas, la inversión y renovación tecnológica, el mantenimiento, escalamiento y operación de la infraestructura.
Adopción de buenas prácticas y estándares en sus procesos y procedimientos de trabajo: facilita la formulación de políticas y procesos, así como el ordenamiento de los recursos humanos, el diseño de los flujos de información y la operación de los servicios, infraestructuras y aplicaciones. Contribuye al ordenamiento de las tareas de gestión y a la mitigación de riesgos asociados al empleo de las infraestructuras TI.
Recursos humanos: con sus conocimientos contribuirán a potenciar la innovación y generar nuevos valores al negocio desde las TI. Estos podrán diseñar procesos más eficientes que reducirán la brecha temporal entre el momento que se realiza la inversión en TI y que dicha impacte positivamente en la organización.
Nivel de automatización de tareas de gestión de las TI: facilitan el monitoreo automatizado de parámetros de rendimiento de las infraestructuras TI, lo cual reduce el OPEX; el cumplimiento de los acuerdos de nivel de servicio (SLA por las siglas en inglés Service Level Agreement) pactados con otras áreas de la organización y la controlabilidad de la infraestructura TI.
Para la valoración de las capacidades a considerar por la organización, se recomienda que en las organizaciones se cree un comité de expertos que evalúe cada capacidad en función de tres criterios:
Impacto: se refiere al efecto que tiene la capacidad en la organización.
Factibilidad: considera si la organización cuenta con los conocimientos, recursos y autorizaciones para utilizar la capacidad evaluada.
Madurez: tiene en cuenta el nivel de desarrollo de la capacidad en la organización.
Como los criterios a partir de los cuales se van a evaluar las capacidades son de tipo cualitativo, debe emplearse una escala ordinal, y para ello se propone la escala de Likert, que codifica de forma ordenada los valores de uno a cinco, donde cinco corresponde al valor máximo [48].
Se recomienda que, en la medida que los expertos evalúan las capacidades, se conformen tres matrices: I (impacto), F (factibilidad) y M (madurez) (ver las matrices representadas en (1), (2) y (3)), en las cuales se almacenen los valores asignados a las capacidades seleccionadas por cada experto. En dichas matrices, las filas (e) se corresponden con las capacidades a evaluar, y las columnas (j), con los expertos incorporados en las mismas. Cada elemento Iej ∈ I, I=(iej) e (iej) corresponde con las evaluaciones asignadas por el experto a cada capacidad, evaluando el criterio impacto, (iej); 
(ver (1)). Cada elemento Fej ∈ F, F=(fej) y fej corresponde con las evaluaciones asignadas por el experto a cada capacidad, evaluando el criterio factibilidad (ver (2)); y cada elemento mej ∈ M, M=(mej) y mej corresponde con las evaluaciones asignadas por el experto a cada capacidad, evaluando el criterio madurez (véanse expresiones (1,2,3)).
Dado que todas las capacidades analizadas están interrelacionadas, no se debe interpretar el resultado de estas por separado. Considerando que la dependencia entre las capacidades que se analizan varía de una organización a otra, en cada organización debe calcularse el coeficiente de correlación de Spearman, y evaluar que se encuentre por encima de 0,6 con el fin de validar la hipótesis de dependencia [49]. En caso de cumplirse lo anterior, se propone utilizar un método de análisis multivariado para la selección de las capacidades críticas a partir de la matriz obtenida. Específicamente, se plantea emplear el método de análisis de componentes principales, el cual permite reducir el número de variables y eliminar la varianza no compartida y la hecha por error, esta última asociada a sesgos en la toma de datos que podrían aparecer por cansancio de los expertos o por heterogeneidad en sus intereses [50].
Teniendo en cuenta que la cantidad de especialistas a consultar en cada organización no será grande (mayor de 200), se propone el empleo del método de Factorización de Ejes Principales para identificar las capacidades más significativas dentro de estas [51]. Con lo anterior, se obtienen las capacidades significativas con relación al impacto, la factibilidad y la madurez.
Seguidamente, a partir de las capacidades más significativas en cada organización, se preseleccionan los marcos de referencia para la gestión de infraestructuras TI a emplear, considerando los procesos que cubren los ámbitos y tipos de uso [52]. Debe realizarse un análisis a partir de la definición de procesos o tareas en cada marco de referencia de las capacidades por cada uno de los marcos de referencia preseleccionados, eligiendo aquellos que abordan con mayor nivel de profundidad las capacidades que deben institucionalizarse a partir de la asimilación de buenas prácticas para cada organización. Entre estos están los que tendrán mayor impacto, los que son más factibles de cambiar y los que tienen menor nivel de madurez. Además, debe seleccionarse un marco base para la integración, que debe ser el que trate la mayor cantidad de procesos que faciliten en control de las capacidades más significativas.
Una vez seleccionados los marcos de referencia a integrar y el marco base, se aplica el método propuesto por Calvache [53] para armonizar los mismos. Este proceder permite determinar los puntos en común tanto en los procesos que abordan, como en los términos que utilizan, eliminando las ambigüedades. De esta forma, el proceso de armonización permite obtener los procesos y términos comunes con diferentes marcos de referencia, así como la manera en que se abordan cada uno de los conceptos que se trabajan en los diferentes marcos de referencia seleccionados. Se debe hacer y conservar una correspondencia entre los modelos iniciales y el armonizado, de manera que puedan asimilarse nuevos modelos o considerarse extensiones en los modelos empleados.
A continuación, se lleva a cabo un mapeo entre la información, procesos, actividades y tareas que abarca cada marco de referencia seleccionado a partir de la armonización, lo que permitirá determinar cuáles de estos aspectos se abordan con mayor nivel de detalle.
Finalmente, sobre un marco base seleccionado previo a la etapa de armonización se integran la información, procesos, actividades y tareas detallados como resultado del mapeo. Esto permite un mayor nivel de especificación de los elementos antes precisados, obteniéndose el marco integrado de procesos para la gestión de infraestructuras ti contextualizado a la organización. De la información, procesos, actividades y tareas que integran el marco integrado, se obtienen los requisitos para realizar el diseño de políticas de TI tal y como se detalla en el componente siguiente.
3.2 Componente de diseño de las políticas de ti de la organización
Para hacer el diseño de políticas de TI, se deben establecer los requisitos para las mismas a partir del marco integrado de procesos primeramente obtenido para la organización. Pudieran existir antecedentes de políticas de TI en la organización, en ese caso se debe realizar la verificación de la satisfacción de los requisitos definidos por las políticas existentes. En caso de no existir políticas de TI en la organización, es necesario realizar el diseño de estas.
Primeramente se deben definir las políticas de TI asociadas a los escenarios de despliegue de los servicios que ofrece la organización, considerando las buenas prácticas [54]-[56], para el funcionamiento adecuado de los mismos.
Para el adecuado diseño de políticas TI se propone la confección de una lista de chequeo que contenga, por ejemplo: la infraestructura TI crítica para la organización, el nivel de preparación de los recursos humanos que interactúan con las infraestructuras TI, los elementos de configuración de cada servicio, así como de la infraestructura subyacente que lo soporta, la lista de alertas que se consideren y las respuestas ante las mismas, las principales métricas de rendimiento asociadas al cumplimiento de los SLA, las tareas comunes de gestión: salvas, gestión de fallas, gestión de cambios, aprovisionamiento de servicios, creación y borrado de usuarios, así como los requisitos de calidad, asociados al negocio: sus estrategias y metas junto a las principales restricciones asociadas a los servicios, entre otros.
Para el diseño de políticas de TI, en este trabajo se plantea extrapolar los métodos de diseño basados en arquitecturas, específicamente, el método de diseño de arquitectura de software (ABD por las siglas en inglés de Architecture Based Design), aprovechando sus posibilidades para: trabajar de manera integrada la combinación de requerimientos de negocio, calidad y funcionales; garantizar completitud del sistema desde su diseño; facilitar la reutilización de conocimientos; permitir la representación de incumbencias transversales de determinados parámetros a través de la orientación a aspectos; y permitir mostrar patrones de interacción y responsabilidades.
Siguiendo con los pasos establecidos en el método ABD [57], [58], se propone realizar un proceso recursivo de descomposición de requisitos para el diseño de políticas. En cada paso de descomposición de los requisitos deben asignarse los niveles de responsabilidad, de autoridad y prever los recursos que sean necesarios. Para cada requisito de calidad o asociado a las necesidades de la organización, deben asociarse las políticas de TI que le darán cumplimiento. Cada uno de estos requisitos deben pasar por una revisión de despliegue, de concurrencia y de lógica de funcionamiento. En la revisión de despliegue, se evaluará el lugar en que se ejecutarán las políticas, lo que permitirá segmentar el ámbito de las políticas en diferentes dominios de aplicación, según las necesidades de la organización, que podrían ser de hardware, software, aplicaciones, servicios, datos o personas.
En la de concurrencia se evalúa si el cumplimiento de la política de TI depende de otras políticas, por ejemplo, si el cumplimiento de las políticas asociadas al funcionamiento de un servicio depende del cumplimiento de las políticas de TI asociadas a la infraestructura subyacente de este. La revisión de la lógica de funcionamiento permitirá establecer relaciones de precedencia o de sucesión entre las políticas de TI diseñadas.
Además, para la descomposición de requisitos, es necesario considerar estratos, proponiéndose, para este caso, los niveles de negocio, sistema e instancia/dispositivo.
Realizar en cada uno de estos niveles la descomposición de requisitos permitirá la obtención de políticas de manera estratificada. Primeramente, se obtendrán las políticas a nivel de negocio, a continuación, se determinarán las políticas de sistema que se necesitan para cumplir con las anterior mencionadas. Finalmente, se diseñarán las políticas que se deben configurar a nivel de dispositivo/instancia con el mismo objetivo.
Como resultado de la aplicación del método ABD deben quedar documentadas un conjunto de vistas de las políticas: vista lógica, que debe incluir los roles y responsabilidades, tanto las funcionales como las asociadas a la calidad; vista de concurrencia o proceso, donde se documentan los flujos asociados a la ejecución de políticas, incluyendo los mensajes que se transmiten y reciben, facilitando la identificación de las políticas que se ejecutan de manera concurrente; vista de despliegue, que incluye la infraestructura subyacente para el despliegue; y por último, la vista de implementación, en la que se detallan los casos de uso para la captura de los requisitos funcionales y los escenarios para los requisitos de calidad.
Adicionalmente, empleando el método ABD, es posible definir plantillas de políticas. Estas plantillas pueden reutilizarse para diferentes políticas y facilitan la solución de conflictos entre ellas. Se recomienda definir plantillas de políticas para: la atención a alarmas; la respuesta ante fallos; la configuración de servicios, elementos de software, de hardware o de red; la actualización, ya sea de sistemas operativos, de antivirus o de aplicaciones, y el monitoreo. En todas las plantillas de políticas deben incorporarse elementos de entrada/salida de datos que faciliten su empleo.
El empleo ABD permite agrupar las políticas de diferentes maneras: según la periodicidad, según los dominios a los que se aplican, asociadas a los atributos de calidad a los que responden, entre otras.
Los expertos a cargo de la aplicación del método ABD en las organizaciones podrán establecer el orden de acuerdo con los aspectos que decidan.
Una vez diseñadas las políticas estratificadas, se procede a identificar conflictos entre las mismas a través del método Policy continuum [59].
Finalmente, para la validación de las políticas diseñadas, se procede a la construcción del árbol de utilidad de estas, empleando el método ATAM, lo que permite verificar el cumplimiento de los atributos de calidad definidos. ATAM brinda una caracterización para varios atributos creada a partir del conocimiento existente en las comunidades de atributos de calidad, como rendimiento, capacidad de ser modificable, disponibilidad, usabilidad y seguridad [60], [61].
El árbol de utilidad contiene escenarios que constan de mecanismos de arriba abajo para verificar el cumplimiento de las políticas diseñadas mediante reglas operacionales. Para la elaboración de los escenarios, se utilizan o los requisitos a partir de los cuales se diseñan las políticas de TI, o directamente las políticas de TI.
En cada escenario, se evalúa la interacción entre las políticas de TI diseñadas para identificar de manera temprana riesgos y puntos sensibles. En los escenarios modelados para cada una de las políticas de TI se determinan: estímulo externo, decisión arquitectónica y respuesta (tríada de evento-condición-acción).
Seguidamente, se realiza la priorización de cada escenario con base en dos dimensiones: importancia y grado de dificultad para ser realizado [60].
En función de esta valoración, se determina automatizar o no las políticas.
Las políticas de TI no son automatizables cuando este proceso resulta muy complejo y tiene poca importancia. Estas políticas de TI no automatizables se deben implementar de manera manual, lo que no es objeto de esta investigación.
3.3 Componente dimensionamiento de infraestructuras para automatización de políticas de TI
Para garantizar la automatización de la ejecución de políticas de TI, es necesario confirmar que se cuenta con la infraestructura necesaria, algo planteado en una de las premisas del MGITI, y contar con recursos de hardware y de conectividad adicionales en la infraestructura subyacente, para garantizar los parámetros de calidad de servicio definidos.
Se considera que la infraestructura subyacente para alcanzar los niveles de calidad de servicio deseados (Iexp) depende de la infraestructura mínima necesaria para alcanzar los atributos de funcionamiento de la red (IFN) y de la infraestructura necesaria para conseguir el nivel de confianza que se planifica en la red (INC).
Para determinar la infraestructura necesaria para tener un nivel de confianza en la red, debe modelarse la infraestructura subyacente capaz de enfrentar deficiencias temporales o permanentes en el funcionamiento de los servicios, así como la reconfiguración de estos. Resulta una buena práctica [62], [63] segmentar la función estadística u(i,t) en períodos de tiempo T y comparar los resultados de la función estadística con predictores basados en datos históricos de funcionamiento seleccionando la función que más se adecúe a cada intervalo de tiempo. Es posible obtener tantas funciones u (i,t) como intervalos estadísticos se tomen. De esta manera, para cada intervalo [ɤ, ɤ+T] y cada máquina virtual soportando un servicio sobre un servidor físico, o para cada servicio soportado sobre una máquina física (i) se tiene para obtener INC las expresiones (4) y (5):
El cálculo de esta infraestructura subyacente está determinado por parámetros como, por ejemplo, la disponibilidad, seguridad y confiabilidad de los servicios establecidas en los acuerdos de nivel de servicio, cuya variación en el tiempo se modela a través de la función u (i,t) descompuesta en (5).
En esta función, ũ (i,t) representa la tendencia de funcionamiento de los servicios y modela el comportamiento de un sistema, cuyos parámetros de funcionamiento varían en el tiempo, dentro de umbrales establecidos en el régimen sin averías. Por su parte, ŭ (i,t), representa irregularidades con respecto a la tendencia de funcionamiento de los servicios y e(i,t) representa errores o incertidumbre en el funcionamiento de estos. Todo esto se emplea para determinar la infraestructura necesaria para un nivel de confianza de la red [62], [64].
Para el cálculo de la infraestructura necesaria para alcanzar un nivel de confianza en la red (INC) es necesario realizar un mapeo de parámetros de calidad de servicio a métricas de rendimiento de las redes. Para ello se emplea una matriz de diseño mdij que considera la infraestructura necesaria para garantizar determinados requisitos funcionales [62], [64]. Dicha matriz se construye a partir del análisis histórico de los parámetros de rendimiento de la infraestructura subyacente, lo que permite la obtención de grupo de parámetros de diseño PDi para cada servicio (i) que utiliza cada cliente (j) bajo las restricciones que definen los requisitos funcionales para cada cliente (RFj) [64]. A partir de los parámetros anteriores se determina la infraestructura necesaria para un nivel de confianza de la red INC (ver (6)), tal que 
.
De esta forma es posible obtener la infraestructura requerida para alcanzar los niveles de calidad de servicio deseados Iexp (ver (7)).
Una vez obtenida la infraestructura subyacente necesaria para la prestación de servicios con los niveles de calidad diseñados (Iexp), es necesario, para automatizar la ejecución de políticas, desplegar una infraestructura adicional que se ha denominado Infraestructura para la Automatización de Políticas (IAP).
Esta infraestructura adicional se determina considerando los elementos necesarios para la automatización de políticas en una arquitectura pbnm, de ahí que se requiera determinar la infraestructura necesaria en los Puntos de Decisión de Políticas (IPDP) y en los Puntos de Ejecución de Políticas (IPEP).
Para IPEP, se parte de evaluar las posibilidades de ejecución de políticas en estos, lo cual considera su capacidad para soportar los agentes y su nivel de autonomía. Adicionalmente, es preciso conocer la cantidad de PDP que se necesitan, pues algunos de estos pueden ser legados. Para el cálculo de IPDP, debe considerarse la demanda de procesamiento que estos tendrán. En el caso de trabajar de manera autonómica, la demanda de procesamiento dependerá del mecanismo que se implemente para la toma de decisiones.
Es importante tener en cuenta que la planificación y organización de políticas debe realizarse, no solamente para establecer prioridades entre estas, sino, además, para implementar los PDP en el lugar óptimo de la infraestructura gestionada. En este sentido surge una relación de compromiso, pues mientras más PDP se desplieguen en la red, más se dispersa la toma de decisiones y se hace más certera la ejecución de políticas a bajo nivel, pero la evaluación del impacto de las políticas ejecutadas será más compleja, al igual que la detección de conflictos entre estas. Una práctica bastante extendida [65], [66], [67] es la definición de PDP según sus funciones: seguridad, calidad de servicios, etc., creando subsistemas de aplicación de políticas, los cuales se pueden segmentar basados en criterios funcionales y no funcionales.
También, para determinar la infraestructura necesaria para automatizar la ejecución de políticas, debe considerarse la infraestructura que se requiere en el repositorio de políticas (IRP), el cual depende de la capacidad de almacenamiento del gestor y la estructura de la base de datos que se utilizará para el almacenamiento de políticas y del modelo de información que se utilice para la representación de políticas.
Finalmente, el despliegue de la arquitectura de gestión basada en políticas implica el consumo de ancho de banda para el envío de políticas y para la verificación del funcionamiento de los elementos gestionados (BWPBNM). A partir de lo anterior, se recoge en (8) cómo obtener la infraestructura necesaria para la automatización de políticas (IAP).
3.4 Componente ejecución de políticas automatizables en las infraestructuras ti
Para la ejecución de políticas automatizadas en las infraestructuras TI, estableciendo un enlace entre la configuración de los elementos de la red y las necesidades de la organización, y permitiendo la detección y corrección de conflictos entre las políticas definidas, se propone una modificación a la arquitectura PBNM definida por la IETF, la cual se muestra en la Fig. 4.
Dicha modificación consiste en incorporar un Punto de Decisión de Políticas Principal (PDPP), el cual tiene una jerarquía superior y puede detectar y resolver conflictos entre políticas, según lo explicado en el componente diseño de políticas, forzando a los PDP a regresar a los PEP a un estado anterior, en el caso de que se manifieste una condición prevista, por ejemplo, la ocurrencia de un conflicto entre las políticas que se ejecutan en las capas jerárquicas inferiores.
Además, el empleo de dos modelos de información, uno a alto nivel y otro a bajo nivel. Como modelo de información para la ejecución de políticas a alto nivel se propone DEN-ng en su versión 7 o superior, entre el PDPP y el PDP dada su capacidad para representar políticas empleando la triada evento-condición-acción que permite: identificar y resolver conflictos entre las políticas, trabajar con máquina de estado finito y abordar los contextos a partir de su expresividad semántica y conceder al sistema la posibilidad de determinar cuándo serán evaluadas las condiciones.
Este último elemento le otorga la misma capacidad de respuesta temprana, ya que no es necesario que las condiciones sean visibles para que se ejecuten las acciones.
Asimismo, hacer esto, garantiza mayor eficiencia en el funcionamiento de la arquitectura porque es posible definir eventos a partir de los cuales se evaluarán las condiciones, lo que implica no tener que invertir recursos computacionales y de ancho de banda adicionales para la evaluación periódica de las condiciones.
Para la ejecución de políticas a bajo nivel, se propone el empleo de CIM de la Fuerza de Tarea para la Gestión Distribuida (DMTF por las siglas en inglés de Distributed Management Task Force) como modelo de información entre los PDP y los PEP, el cual abarca gran cantidad de escenarios de gestión, y tipos de infraestructuras de redes y servicios. CIM permite la operación de la arquitectura tanto en soluciones de gestión integrada como propietaria, ya que es capaz de representar, con mayor integralidad, los diferentes ámbitos de gestión. Su gestor de objetos, CIMOM, se ha extendido hasta comprender los más importantes modelos de gestión estandarizados, así como modelos propietarios, y se han desarrollado extensiones para las nuevas tecnologías a gestionar, por ejemplo: las Redes Definidas por Software (SDN por las siglas en inglés de Software Defined Network), la Virtualización de las Funciones de Red (NFV por las siglas en inglés de Network Functions Virtualization) y la nube [38], [68]. Se puede afirmar que, en general, todos los elementos que forman parte de la infraestructura de redes y servicios a gestionar soportan implementaciones de CIM. Debido a que, la mayor parte de los sistemas que implementa PBNM trabajan a bajo nivel, ejecutando políticas sobre los elementos gestionados, es preciso establecer un enlace entre la configuración de estos elementos y las necesidades de la organización.
También se incorpora a la arquitectura propuesta por el IETF, una base de datos de configuración (CMDB por las siglas en inglés de Configuration Management Database) donde se registran los atributos de cada instancia de configuración (CI, por las siglas en inglés de Configuration Instance) durante su ciclo de vida, las relaciones que la misma posee con otras instancias y los registros vinculados a cada una, por ejemplo, registros de incidentes, problemas o cambios. La CMDB se emplea para la evaluación de condiciones y registro de las modificaciones que se ejecuten como resultado de la ejecución de políticas en los PEP.
Para ejecutar las acciones de gestión se utiliza el PDP, especializado en tomar las decisiones de cuáles políticas se deben ejecutar y del procesamiento de las mismas, alineando de esta forma las necesidades del negocio con el comportamiento coherente de la infraestructura TI. Para este fin, el PDP transforma las políticas o reglas en representaciones operacionales aptas para ser interpretadas por PEP que se encuentran en los elementos gestionados.
Para ello, el PDP debe contar con un motor de inferencia y se basa, para la toma de decisiones, en la información contenida en la CMDB y en el Repositorio de Políticas [68].
Según recomienda el IETF, en el PDP debe existir una aplicación de gestión basada en políticas preferiblemente con interfaz web para el monitoreo y control de los elementos que forman parte de la infraestructura que ejecuta las políticas.
Dicha aplicación debe permitir modelar las políticas que controlarán el sistema y verificar la no existencia de conflictos entre las políticas existentes, lo que se debe hacer en cada uno de los estratos. Las nuevas políticas de TI que no presentan conflictos con las precedentes se almacenan en el repositorio de políticas, el cual constituye una base de datos donde se registran todas las políticas a ejecutar.
En el PDPP ocurre el proceso de toma de decisiones de las políticas representadas con la tríada evento-condición-acción.
La condición puede contener un conjunto de cláusulas que darán como resultado una condición simple, a partir de la cual puede evaluarse si esta se satisface consultando la CMDB. En el caso de que esté previsto que se ejecuten varias acciones, se establecerá el nivel de prioridad en función de la estrategia de ejecución de las mismas, que se define en el PDPP.
3.5 Componente estrategia de evaluación de impacto
El impacto de las TI en las organizaciones para incrementar la rentabilidad empresarial, elevar la productividad, mejorar los procesos que conducen a la elevación del desempeño organizacional y de los servicios, ha sido ampliamente tratado.
En función de la evaluación del impacto del MGITI en las organizaciones, en este trabajo se propone un conjunto de medidas agrupadas en las alineaciones establecidas en el Modelo de Alineación Estratégica SAM (por las siglas en inglés de Strategic Aligment Model) propuesto por [69], que consideran la alineación estratégica y estructural, a las que se incorpora posteriormente la alineación social.
Dentro de la alineación estratégica, se proponen en este trabajo, como medidas; la cantidad de requisitos de la organización; el nivel de formalización de procesos TI en la organización, lo que se considera en el componente uno del modelo mediante la obtención del marco integrado de procesos para la gestión de TI contextualizado a las necesidades de cada organización; y la implementación de estándares que se encuentran tanto en el marco integrado como en el empleo de modelos de información y en la arquitectura pbnm modificada para la ejecución de políticas de TI automatizables en la infraestructura.
Para garantizar la alineación estructural, se propone el establecimiento de acuerdos de nivel de servicio entre el área de TI y otras áreas de procesos de la organización. Para realizar esto, se debe definir un conjunto de indicadores de calidad de servicio.
En la evaluación de la alineación social, se consideraron la calidad de comunicación, lenguaje común, entendimiento compartido y conocimiento de dominio compartido, y se agrega el nivel del compromiso de los usuarios de la TI [70]. Este aspecto se implementa a través de la asignación de responsabilidades para diseño de políticas en el proceso de estratificación de políticas; la formulación de políticas de TI a partir de requisitos de la organización y que contribuyen a la sistematización de conocimiento en políticas de TI automatizables y no automatizables.
La definición de políticas a nivel de negocio permite el entendimiento de estas por parte de la junta directiva de la organización. El establecimiento de SLA entre el área de TI y las diferentes áreas de procesos de la organización proporcionan un lenguaje común de comunicación entre estas.
Además, la formalización de políticas a nivel de negocio, de sistema y de instancia, permite la reutilización de las políticas de TI diseñadas en diferentes organizaciones compartiendo el repositorio de políticas; y el empleo CIM, como modelo de información entre los PDP y los PEP facilita que los administradores de TI solamente deban dominar los estándares del DMTF, independientemente del proveedor de tecnología, lo cual impacta en la reducción del costo total de la propiedad en las organizaciones.
4. ANÁLISIS Y DISCUSIÓN DE RESULTADOS
MGITI, se aplicó el mismo para el despliegue de la Plataforma Integral de Telecomunicaciones Unificadas, PLATEL 3.0.
Según establece el MGITI, para identificar las necesidades de cada una de las organizaciones en las que se realiza el despliegue, se indicó el empleo de marcos de referencia para el establecimiento de SLA en los clientes con el objetivo de alinear la implementación de la solución de comunicaciones unificadas que se comercializa a las necesidades de las organizaciones clientes, considerando sus capacidades.
De la integración de los diferentes marcos de referencia que incorporan metodologías para la aplicación de SLA en las organizaciones: COBIT 5, ITIL v3 y eTOM, se obtienen los procesos y métricas a considerar, estas se deben alinear a las necesidades de las organizaciones a partir de las cinco fases que integran el ciclo de vida de los SLA y las siete funciones: diseño, negociación, aprovisionamiento, ejecución, monitoreo, evaluación y reporte.
Las funciones de monitoreo y de reporte del cumplimiento de los SLA permiten la verificación de las MRRS y la evaluación de impacto con la emisión de informes que reporten el cumplimiento de dichos sla.
Como resultado del marco integrado para la gestión de los SLA para los servicios de comunicaciones unificadas que las empresas pueden extender para la gestión de sus infraestructuras TI de acuerdo con el desarrollo de sus capacidades, se obtienen las relaciones entre procesos, variables de control y requisitos que se muestra en la Tabla 1.
Tabla 1 Relación entre los procesos y los atributos de calidad para la implementación de PLATEL 3.0
Fuente: elaboración propia.
A partir de los requisitos obtenidos se diseñaron, empleando ABD, las políticas para la configuración de la plataforma en las diferentes organizaciones. Además, se obtuvieron un conjunto de políticas TI a través de la ampliación de los atributos en requisitos de calidad abstractos.
El dimensionamiento de la infraestructura para la automatización de la ejecución de políticas y para lograr un nivel de servicio permitió la obtención de configuraciones prediseñadas para el despliegue de la arquitectura en función de las necesidades de las organizaciones. Para identificar cuál es la configuración que requiere cada organización, durante la fase de negociación se elicitan requisitos funcionales como: cantidad de usuarios, cantidad de usuarios concurrentes, cantidad de servicios por usuarios y total de servicios, sistemas y aplicaciones de comunicaciones que abarca. Además, se determina si el despliegue de la arquitectura se realizará de forma centralizada o distribuida.
Para ejecutar las políticas que se diseñan, se incorporó a la arquitectura PLATEL 3.0 un subsistema de gestión. Este subsistema tiene la misión de llevar a cabo los dos modos de actuación de la gestión de red, o sea, monitorizar y controlar todos los elementos que conforman la plataforma de comunicaciones unificadas, esto de acuerdo con las políticas diseñadas. El mismo, presenta una arquitectura de PBNM empleando como base WEBM (PBNM - WEBM), proporcionando de esta forma una gestión integral de la red de comunicaciones unificadas. El empleo de cim como modelo de información para la comunicación entre el PDP y los PEP resuelve el problema de la heterogeneidad de los elementos gestionados y reduce la complejidad en la operación del sistema. Además, se normalizó el modelo para enviar a los clientes reportes del cumplimiento de los SLA con el fin de lograr un mayor entendimiento por parte de estos.
Para automatizar las políticas diseñadas, se desplegó la arquitectura PBNM - WEBM para el monitoreo y control de la infraestructura que soporta el servicio de voz sobre IP (VoIP). Para garantizar el funcionamiento de dicho servicio, se monitoriza el porciento de usabilidad de la RAM, la CPU y del disco duro; el tráfico en las tarjetas de red en el servidor, así como los principales parámetros de QoS para la VoIP [71]: la pérdida de paquetes, el jitter, la latencia, el estado de las extensiones, así como la cantidad de llamadas concurrentes y fallidas. Para facilitar el proceso de gestión se efectúa un control sobre cada uno de estos parámetros empleando políticas establecidas por el administrador de la red.
Esto tiene como objetivo lograr que los elementos y servicios que hospedan los servidores de telefonía IP tengan un comportamiento autónomo y se dimensionen en función de la demanda.
Además, se generan reportes en los cuales se muestra el comportamiento de los parámetros monitorizados durante un tiempo determinado (el intervalo es configurable).
Como se muestra en [72], para el despliegue del servicio de VoIP gestionado, se montó un servidor de base de datos PostgreSQL 9.4, con sistema operativo GNU/Linux, Nginx 1.4.6 y framework Django versión 1.7, se verificó que todos los terminales de VoIP eran gestionables y que los agentes tenían la infraestructura necesaria para su funcionamiento (todos eran PC Pentium 4 o superior con 512 Mb de memoria RAM). Para el punto de decisión de políticas, se determinó que era necesario un servidor con un Microprocesador de 2 núcleos, 4GB de memoria RAM, 250 Gb de memoria en el disco duro y una fuente de 800 W como mínimo para lograr el despliegue de la herramienta Zabbix, la cual tiene capacidad de ejecutar monitorización y control de elementos de hardware [73]; además funciona como PDP y como repositorio de políticas. Este servidor puede ser desplegado sobre máquinas virtuales o máquinas físicas, según se determine en la organización.
La comunicación entre los agentes y el punto de decisión de políticas se implementó a través del protocolo HTTP, verificándose que el ancho de banda disponible era suficiente. Además, los tiempos de sondeo se pudieron configurar para no atentar con el correcto funcionamiento del servicio en el momento de establecimiento de llamadas.
La automatización de la gestión tuvo un gran impacto por cuanto permitió garantizar los parámetros de calidad de servicio de la organización. Se crearon varias máquinas virtuales configuradas para funcionar como servidores de VoIP.
Se pudo monitorear en el servidor que, si dicho programa sobrepasaba los umbrales de rendimiento definidos, o sea, 60 % de uso de la memoria RAM, 65 % de uso del CPU, más del 70 % de uso de las capacidades de red o más de 80 % de uso de la capacidad de almacenamiento, comenzaría a ser ejecutada como pos condición un script que creaba una máquina virtual para apoyar las peticiones de clientes. En adición, el servidor Zabbix notifica a los administradores del sistema sobre la acción ejecutada. Este proceso resulta transparente para el usuario final y permite que la plataforma PLATEL 3.0 funcione alineada a las necesidades de las organizaciones, a la vez que reduce la complejidad en su gestión.
5. CONCLUSIONES
La gestión de infraestructuras TI con impacto en las organizaciones requiere del empleo de múltiples marcos de referencia de manera integrada, unido a inmediatez y pertinencia en la respuesta, lo cual se consigue a través del diseño y automatización de política de TI. Dichas políticas necesitan de la integración de modelos de gestión, la definición de dominios de gestión y la solución de conflictos entre políticas para ejecutarse en entornos tecnológicos heterogéneos. Todo lo anterior provoca alta complejidad y desalineamiento entre las necesidades de las organizaciones y las TI.
El presente trabajo soluciona el problema científico mencionado mediante el desarrollo de un modelo para la gestión de infraestructuras TI, que constituye el principal aporte de la investigación realizada, pues contribuye a reducir la complejidad y el desalineamiento de dichas infraestructuras. El modelo desarrollado considera los principales estándares y recomendaciones asociadas a la gestión de infraestructuras TI.
Otros aportes identificados dentro del modelo son: un marco integrado de procesos contextualizado a las necesidades de las organizaciones; el empleo de los métodos ABD y ATAM para la definición de políticas de TI y su estratificación, lo que facilita la alineación estratégica mediante el cumplimiento de requisitos en las organizaciones; modificaciones a la arquitectura de gestión basada en políticas, asociadas a estratificación de la toma de decisiones y a la selección de dos modelos de información que facilitan la integración de modelos de gestión estandarizados y propietarios, así como la solución de conflictos entre políticas; el establecimiento de medidas de evaluación de impacto en lo estratégico, lo estructural y lo social, lo que contribuye a evaluar la incidencia de cada componente del modelo; y el establecimiento de un procedimiento que orienta el empleo del MGITI y precisa los puntos de control sobre el funcionamiento del mismo, contribuyendo a su usabilidad.
