Anda di halaman 1dari 177
Talleres y trabajos académicos. Álvaro Gomariz López 1

Talleres y trabajos académicos.

Álvaro Gomariz López

Trabajo académico Gobierno de ti, Cobit e ITIL

Trabajo académico Gobierno de ti, Cobit e ITIL Gobierno de TI, Cobit e ITIL Álvaro Gomariz

Gobierno de TI, Cobit e ITIL

Álvaro Gomariz Lopez

Contenido

Introducción

5

Gobierno de TI

7

7

8

Enfoque del Gobierno de TI

9

11

COBIT

12

Historia de versiones de COBIT

14

COBIT 4.1

14

16

COBIT y sus objetivos de control

17

Procesos

19

20

Nuevo modelo de madurez

21

Estructura de procesos

21

Análisis ......................................................................................................................

22

Conclusiones

24

ITIL v 3.0

25

Introducción

25

BSM e ITIL v3

25

Integración

26

Gestión del ciclo de vida del servicio

26

Cambios clave en los procesos

28

Servicios como activos

30

Utilidad y

30

Mayor énfasis en la proactividad

...........................................................................................

32

Eliminación de silos

................................................................................................................

32

Qué esperar con ITIL v3

33

Transición de ITIL v2

a ITIL v3

33

Beneficios para el

35

Conclusión ...................................................................................................................................

35

Introducción

La práctica común de las empresas en el mundo es no considerar importante a las áreas de tecnologías de la información (TI), provocando que éstas tengan poco personal, presupuesto reducido y la identifiquen como el área de soporte para el equipo del usuario final únicamente.

Sin embargo, con el paso del tiempo, añadiendo las nuevas tendencias en tecnología surgidas en países desarrollados, han incrementado de manera muy importante el papel y la influencia de las TI, provocando que éstas, formen parte fundamental en la operación y desarrollo de las organizaciones.

Este cambio en la percepción de las TI se debe al surgimiento de marcos de referencia, que en la actualidad se consideran herramientas clave para poder llevar a cabo este renacimiento de la figura de las TI.

Todos estos marcos de referencia son independientes al rubro o tamaño de la organización. Estos tienen como objetivo proporcionar metodologías para tener los recursos de TI de manera estructurada y organizada, apoyando a la organización para alcanzar sus objetivos estratégicos.

En la actualidad la mayor parte de la inversión en infraestructura y nuevas aplicaciones de TI buscan apoyar funciones específicas de la organización. Algunas organizaciones incluyen en sus procesos internos a socios o clientes, mejor conocidos como stakeholders. Este tipo de tendencias provoca que los CEO’s (directores ejecutivos) y CIO’s (directores de TI) se vean comprometidos con la necesidad de reducir lo más

posible la brecha que existe en las relaciones entre TI y el negocio.

Debido a esto la administración efectiva de la información y de las tecnologías relacionadas, se han vuelto un factor crítico para la supervivencia y éxito de las organizaciones.

Esta criticidad emerge de:

La creciente dependencia de información y de los sistemas que la proporcionan

que se ha generado en las organizaciones. El incremento de la vulnerabilidad y riesgos, como los son las “ciber- amenazas”

y la guerra de la información. El importante aumento en el costo de las inversiones actuales y futuras en TI.

El inmenso potencial que tienen las TI para provocar un cambio radical en las organizaciones y en las prácticas de negocio, esto con el fin de obtener nuevas oportunidades y reducción de costos.

Tomando en cuenta todos estos factores, podemos decir que es necesario un cambio en el rol en las áreas de TI para lograr obtener el máximo rendimiento a una inversión en tecnología además de utilizarla como un arma competitiva en el mercado. De esta

manera conseguimos que la actitud de TI frente al negocio sufra una metamorfosis y deje de ser meramente reactiva tornándose proactiva, logrando anticiparse a las necesidades de la organización. (NETWORK-SEC, 2010)

Gobierno de TI

A fin de poder definir al Gobierno de TI, debemos iniciar por definir al Gobierno Corporativo, el cual se puede describir como, el conjunto de responsabilidades y prácticas ejecutadas por la junta directiva y la administración con el fin de proveer dirección estratégica. (ISACA, 2010)

Pero, ¿de qué manera se provee una correcta dirección estratégica para la organización?

Garantizando que los objetivos sean alcanzados

Estableciendo que los riesgos son administrados apropiadamente y;

Verificando que los recursos de la empresa son usados de manera responsable

Como se puede observar, se toman en cuenta tres aspectos importantes que influyen en el desempeño, como son los objetivos, los cuales constituyen el fin principal de la organización. Por otro lado la administración de riesgos, que son todos aquellos factores que la organización debe de tomar en cuenta como posibles amenazas, las cuales debe de mitigar con análisis y planes de continuidad; y por último los recursos, el elemento clave para la operación de la organización, sea financiero, humano o de infraestructura.

Con la descripción dada, es claro que con lo que pretende el Gobierno corporativo, podemos explicar que el Gobierno de TI es una parte integral del Gobierno corporativo y consta del liderazgo, estructuras organizacionales y procesos que garanticen que las TI de la empresa sustenten y extiendan las estrategias y objetivos organizacionales. Por ello, el Gobierno de TI es una responsabilidad compartida de la junta directa y la administración ejecutiva de la organización. (ISACA, 2010)

La norma ISO/IEC 38500 Corporate Governance of Information Technology, lo define como "El sistema mediante el cual se dirige y controla el uso actual y futuro de las

tecnologías de la información” (Villuendas, 2011)

¿Por qué Gobierno de TI?

En las organizaciones, con el paso del tiempo, la dirección se está dando cuenta del impacto significativo que la información puede tener en el éxito de una empresa, lo que deriva en que la dirección espere un alto entendimiento de la manera en que las TI

son operadas y de la posibilidad que sea aprovechada con éxito para tener una ventaja competitiva.

El marco de Gobierno de TI deberá ayudar a la alta dirección a saber si con la información administrada es posible garantizar el logro de objetivos, ser flexible, tener un buen manejo de riesgos y reconocer apropiadamente sus oportunidades actuando acorde a ellas. (IT Governance Institute, 2007) .

A su vez, definirá la alineación de las estrategias de TI con la estrategia de la organización, asegurará la disminución del apetito de riesgo, proporcionará estructuras organizacionales que faciliten la implementación de estrategias y metas, así como que fluyan de forma gradual en la empresa.

También creará relaciones constructivas y comunicación efectiva entre el negocio y TI, además de con los socios externos; y por último medirá el desempeño de TI. Con lo antes mencionado, podemos decir de manera general que el Gobierno de TI es una disciplina acerca de la toma de decisiones de TI en las que participa intensamente, o debería participar, la alta dirección de las organizaciones. La Gestión de TI, sin embargo, se refiere a las decisiones que se adoptan básicamente por parte de los profesionales de TI, aunque participe la alta dirección u otros gestores. (Villuendas,

2011)

Implementación del Gobierno de TI

La implementación de un marco de Gobierno de TI se lleva acabo tomando en cuenta las diferentes condiciones y circunstancias existentes en una organización, estas principalmente determinadas por factores como los son:

Lograr una interacción del gobierno de TI con la ética y cultura de la organización, siendo este el elemento subjetivo, es vital el entender el ambiente laborar y hábitos en la organización, parte trascendental es la comunicación que se tenga hacia el personal.

Apegarse a leyes y regulaciones vigentes (sean internas o externas), para el cumplimiento del marco de gobierno, debido a que es indispensable no dejar de lado todos aquellos reglamentos internos establecidos en la organización, ni tampoco las leyes regulatorias de la región, país o estado donde se radique.

Considerar la misión, visión y valores de la organización, para tener un correcto paralelismo del Gobierno de TI hacia los objetivos actuales y a futuro de la organización, considerando también los valores de la misma.

En la estructura organizacional, el Gobierno de TI se apoyara para su operación en el organigrama del negocio para poder asignar también actividades, comprendiendo los roles y responsabilidades.

Estrategias y tácticas de la organización, esto para tener la directriz de la manera en la cual la organización realiza su toma de decisiones y ejecución de actividades, el gobierno de TI tendrá que reforzarlas para el logro de los objetivos de la organización. (NETWORK-SEC, 2010)

Enfoque del Gobierno de TI

El enfoque que se le ha dado al Gobierno de TI, es principalmente para que sea una solución operativa, que trate con los retos presentados por TI, mejore el desempeño y posibilite la ventaja competitiva como apoyar en prevenir problemas.

Además, hacer del Gobierno de TI una responsabilidad compartida entre el negocio (cliente) y el proveedor de servicios de TI, con el pleno compromiso y la guía de la alta dirección.

Otro punto es el alinear el Gobierno de TI con un amplio Gobierno Corporativo, incluyendo a la junta y administración ejecutiva, a fin de proporcionar liderazgo y estructuras organizacionales necesarias recalcando la buena administración y control de los procesos. (BDO Consulting, 2008) En la figura 1, podemos observar las áreas de enfoque del Gobierno de TI.

 Estrategias y tácticas de la organización, esto para tener la directriz de la manera en

Alineación Estratégica: Se enfoca en garantizar la alineación estratégica entre los planes de negocio y de TI y en alinear las operaciones de TI con las operaciones de la empresa. (IT Governance Institute, 2007)

Como ya se estableció, la estrategia de TI debe responder a las estrategias de la organización de donde se concluye que las aplicaciones deben atender las necesidades funcionales y de información de los procesos, los cuales a su vez, soportan el cumplimiento de los objetivos estratégicos. De esta manera el ciclo se completa:

La Estrategia TI nace de la Estrategia Empresarial y la soporta

Las aplicaciones nacen de la estrategia TI y soportan los procesos

Los procesos soportan la Estrategia Empresarial

Entrega de Valor: Se refiere a ejecutar las propuestas de valor a todo lo largo del ciclo de entrega, asegurando siempre que TI genere los beneficios prometidos en la estrategia, haciendo énfasis en optimizar los costos y en brindar el valor intrínseco de TI. (IT Governance Institute, 2007)

La función de TI se debe gestionar para cumplir con los requerimientos de soporte a las decisiones y a los procesos de la organización (estratégicos, misionales y de soporte).

Administración de Recursos: Se trata de la inversión óptima así como la administración adecuada de los recursos críticos de TI: Aplicaciones, información, infraestructura y personas. Los temas claves se refieren a la optimización de conocimiento e infraestructura. (IT Governance Institute, 2007)

La responsabilidad de TI va más allá de administrar los recursos que tiene bajo su manejo. Estos recursos deben ser usados para entregar de manera óptima los productos de información para lo cual fueron adquiridos.

Administración de Riesgos. Requiere conciencia de los riesgos por parte de los altos ejecutivos de la empresa, un claro entendimiento del apetito de riesgo, que tiene la empresa, comprender los requerimientos de cumplimiento, transparencia de los riesgos significativos para las empresas y la inclusión de las responsabilidades de administración de riesgos dentro de la organización. (IT Governance Institute, 2007)

El Gobierno de TI debe velar porque ningún evento impida la entrega de los productos y la continuidad del servicio de TI. Para esto se debe hacer una adecuada administración de los riesgos de la función TI y de los procesos soportados por TI, por parte del funcionario de la organización a quien se haya asignado esta responsabilidad.

Medición del desempeño: Rastrea y monitorear la estrategia de implementación, la terminación del proyecto, el uso de los recursos, el desempeño de los procesos y la entrega del servicio, con el uso de herramientas como Balance Score Card que traducen la estrategia en acción para lograr las metas medibles más allá del registro convencional. (IT Governance Institute, 2007)

El cumplimiento de la estrategia TI se logra mediante la administración de los recursos TI a través de la adecuada gestión de los procesos de Planeación y Organización (PO), Adquisición e Implantación (AI), Entrega y Soporte (DS) y Monitoreo y Evaluación (ME).

Estos procesos deben ser medidos para establecer el aporte que hacen o dejan de hacer en el logro de la estrategia de TI, mediante indicadores que evidencien los resultados de la gestión de dichos procesos.

Mapa de implementación de Gobierno de TI para la organización

En la figura 2, se muestra el mapa recomendado para la implementación del Gobierno de TI, este define los diferentes pasos y actividades de cada uno de ellos para lograr el Gobierno de TI. Las etapas para desarrollar una solución de Gobierno de TI son:

Identificar las necesidades de la organización es un punto primordial, involucra actividades como fomentar la conciencia y obtener compromiso de todos los niveles de la organización, analizar las metas del negocio y de TI, realizar la selección de procesos y controles, analizar riesgos y definir alcances.

Prever la solución de problemas, donde se evalúan la capacidad y madurez de los procesos de TI seleccionados, posteriormente para cada uno se definen niveles de objetivo y madurez apropiados y alcanzables.

Planear la solución, consiste en identificar las iniciativas de mejoras prioritarias y factibles, traduciéndolas en proyectos justificables, alineados con el valor de negocio original y los factores de riesgo. Una vez evaluados esos proyectos deben incluirse en una estrategia de mejora y un programa práctico para llevar a cabo la solución.

Al implantar la solución, mientras el plan de mejora se lleva a cabo, gobernado por proyectos establecidos y metodologías de administración del cambio, la obtención exitosa de los resultados de negocio deseados de asegura mediante:

la retroalimentación y lecciones aprendidas post-implementación. El monitoreo de las mejoras sobre el desempeño de la corporación y Balance Scorecard de TI.

El último punto del mapa es el lograr la sustentabilidad. Se construye integrando el Gobierno de TI con el Gobierno Corporativo de la organización, y

la responsabilidad de TI a través de la empresa, con estructuras organizacionales apropiadas, determinar claramente políticas y controles, cambio cultural impulsado desde la alta dirección, mejora continua en procesos, y con monitores e informes óptimos.

la responsabilidad de TI a través de la empresa, con estructuras organizacionales apropiadas, determinar claramente políticas

COBIT

COBIT son las siglas para definir Control Objectives for Information and related Technology (Objetivos de Control para la información y tecnología relacionada), el cual es un marco de referencia creado por ISACA (Information Systems Audit and Control Association (Asociación de Control y Auditoria de Sistemas de Información) para la gestión de la TI y el Gobierno de TI. Es un conjunto de herramientas de soporte que permite a la gerencia de las organizaciones el cerrar la brecha entre los requerimientos de control, problemas técnicos y los riesgos del negocio. (IT Governance Institute,

2007)

Este marco provee buenas prácticas y presenta actividades para el Gobierno de TI en una estructura manejable y lógica. Las buenas prácticas de COBIT reúnen el consenso de expertos, quienes ayudarán a optimizar la inversión en TI y proporcionarán un mecanismo de medición que permitirá juzgar cuando las actividades van por el camino equivocado.

La misión de COBIT es el investigar, desarrollar, publicar y promover un conjunto de objetivos de control generalmente aceptados, autorizados, actualizados por ISACA para ser utilizadas en el día a día por la gerencia del negocio, los profesionales de IT y

de la seguridad. En la figura 3 vemos que define también procesos, metas y métricas para el control. (IT Governance Institute, 2007).

de la seguridad. En la figura 3 vemos que define también procesos, metas y métricas para

El principio básico del marco de referencia de COBIT está representado en el esquema de la figura 4. Los recursos de TI son manejados procesos para alcanzar las metas de TI que responden a los requerimientos del negocio.

de la seguridad. En la figura 3 vemos que define también procesos, metas y métricas para

Historia de versiones de COBIT

A la fecha, COBIT tiene cuatro versiones mayores publicadas:

En 1996, la primera edición de COBIT fue publicada. Esta incluía la colección y análisis de fuentes internacionales reconocidas y fue realizada por equipos en Europa, Estados Unidos y Australia.

En 1998, fue publicada la segunda edición; su cambio principal fue la adición de las guías de gestión. Para el año 2000, la tercera edición fue publicada y en el 2003, la versión en línea ya se encontraba disponible en el sitio de ISACA.

Fue posterior al 2003 que el marco de referencia de COBIT fue revisado y mejorado para soportar el incremento del control gerencial, introducir el manejo del desempeño y mayor desarrollo del Gobierno de TI.

En diciembre de 2005, la cuarta edición fue publicada y en Mayo de 2007, se liberó la versión 4.1 que es la que actualmente se maneja.

La versión número 5 de COBIT está planeada para ser liberada en el año 2012, esta edición consolidará e integrará los marcos de referencia de COBIT 4.1, Val IT 2.0 y Risk IT. Este nuevo marco de referencia viene integrado principalmente del Modelo de Negocios para la Seguridad de la Información (BMIS, Business Model for Information Security) y el Marco de Referencia para el Aseguramiento de la Tecnología de la Información (ITAF, Information Technology Assurance Framework).

COBIT 4.1

El Marco de Referencia de COBIT 4.1, está conformado por 34 Objetivos de Control de alto nivel, todos diseñados para cada uno de los Procesos de TI, los cuales están agrupados en cuatro grandes secciones mejor conocidos como dominios, estos se equiparán a las áreas tradicionales de TI de planear, construir, ejecutar y monitorear.

Planificación y Organización, proporciona la dirección para la entrega de soluciones y la entrega de servicios.

Adquisición e Implementación, proporciona las soluciones y las desarrolla para convertirlas en servicios.

Entrega de servicios, recibe soluciones y las hace utilizables para los usuarios finales.

Soporte y Monitorización, monitorea todos los procesos para el asegurar que se sigue con la dirección establecida.

• Soporte y Monitorización, monitorea todos los procesos para el asegurar que se sigue con la

Ésta estructura, ejemplificada en la figura 5, cubre todos los aspectos de la información y de la tecnología que la soporta. (IT Governance Institute, 2007) y define los dominios como sigue:

Dominio Planear y Organizar (PO) - Este dominio cubre las estrategias y las tácticas, y tiene que ver con identificar la manera en que TI puede contribuir mejor con los objetivos del negocio. Es importante mencionar que la realización de la visión estratégica requiere ser planeada, comunicada y administrada desde diferentes perspectivas; y finalmente, la implementación de una estructura organizacional y tecnológica apropiada. (IT Governance Institute, 2007)

La gerencia espera cubrir la alineación de la estrategia de TI con el negocio, optimizar el uso de recursos, el entendimiento de los objetivos de TI por parte de la organización, la administración de riesgos y calidad en los sistemas de TI para las necesidades del negocio.

Dominio Adquirir e Implementar (AI) - Con el fin de cumplir una estrategia de TI, las soluciones de TI necesitan ser identificadas, desarrolladas o adquiridas, como también implementadas e integradas en los proceso del negocio. Además, el cambio y el mantenimiento de los sistemas existentes serán cubiertos para garantizar que las soluciones sigan satisfaciendo los objetivos del negocio. (IT Governance Institute,

2007)

La gerencia con este dominio pretende cubrir, que los nuevos proyectos generen soluciones que satisfagan las necesidades del negocio, que sean entregados en tiempo y dentro del presupuesto, que los nuevos sistemas una vez implementados trabajen adecuadamente y que los cambios no afecten las operaciones actuales del negocio.

Dominio Entregar y Dar Soporte (DS) - Involucra la entrega en sí de los servicios requeridos, incluyendo la prestación del servicio, la administración de la seguridad y de la continuidad, el soporte a los usuarios del servicio, la administración de los datos y de las instalaciones operativas. (IT Governance Institute, 2007) El objetivo es lograr que los servicios de TI se entreguen de acuerdo con las prioridades del negocio, la optimización de costos, asegurar que la fuerza de trabajo utilice los sistemas de modo productivo y seguro, implantar de forma correcta la confidencialidad, la integridad y la disponibilidad.

Dominio Monitorear y Evaluar (ME) - La totalidad de los proceso de TI deben de ser evaluados regularmente en el tiempo, para conocer su calidad y cumplimiento de los requerimientos de control. Este dominio incluye la administración del desempeño, el monitoreo del control interno, el cumplimiento regulatorio y la aplicación del gobierno. (IT Governance Institute, 2007)

Con esto se obtendrá de manera oportuna la detección de problemas por medio de la medición del desempeño, se garantiza que los controles internos sean efectivos y eficientes, la vinculación del desempeño de TI con las metas del negocio así como la medición y reporte de riesgos, además del control, cumplimiento y desempeño.

Otro concepto clave de COBIT, es la determinación y la mejora sistemática de la madurez del proceso, el cual tiene 6 niveles (0 al 5) para medir el nivel de madurez de los procesos de TI:

  • 0 Inexistente No existe información alguna, ni conocimiento sobre el gobierno de TI

  • 1 Inicial / ad hoc En el proceso existen tareas indefinidas, pero hay confianza en la iniciativa

  • 2 Repetible pero intuitivo El proceso cuenta con personal de calidad y tareas definidas

  • 3 Definido Proceso definido e institucionalizado, cuenta con política, estándares y procedimientos establecidos

  • 4 Gestionable y medible El proceso tiene estructuras de control completas y análisis del desempeño.

Procesos de COBIT

En la tabla 1 se enlistan los nombres y claves de los 34 procesos que conforman COBIT y su clasificación dentro de cada uno de los cuatro dominios

COBIT y sus objetivos de control Para cada uno de los 34 procesos definidos en los
COBIT y sus objetivos de control Para cada uno de los 34 procesos definidos en los

COBIT y sus objetivos de control

Para cada uno de los 34 procesos definidos en los cuatro dominios de COBIT, se ha

generado un objetivo de control. Podemos definir “control” como las políticas,

procedimientos, prácticas y estructuras organizacionales que han sido diseñadas para asegurar razonablemente que los objetivos del negocio se alcanzarán y los eventos no deseados, serán prevenidos o detectados y corregidos. (IT Governance Institute, 2007) Estos objetivos de control de TI proporcionan un conjunto completo de requerimientos de alto nivel a considerar por la gerencia para un control efectivo de cada proceso de TI.

Estos controles son sentencias de acciones de gerencia que deben de aumentar el valor o reducir el riesgo en el negocio, generalmente consisten en políticas, procedimientos, prácticas y estructuras organizacionales, las cuales proporcionan un aseguramiento razonable de que los objetivos del negocio se verán alcanzados.

Pero ¿qué tipo de decisiones necesita tomar la gerencia en relación a estos objetivos de control?

Primero, seleccionar aquellos que sean aplicables al negocio, decidir cuales se implementaran y elegir como implementarlos (con qué frecuencia, extensión, automatización). Además de aceptar el riesgo de no implementar aquellos que podrían requerirse en la organización.

COBIT 5

El enfoque de COBIT 5, mostrado en la figura 6, será el gobierno y la administración de la información corporativa. Adicional se muestra un gran interés en incorporar estándares y mejores prácticas de la industria en el gobierno de TI.

Procesos La orientación de COBIT 5 es en procesos y existen 36 procesos que están separados

Procesos

La orientación de COBIT 5 es en procesos y existen 36 procesos que están separados como áreas de Gobierno y Administración. (ISACA, 2011)

Área: Gobierno Corporativo de TI

Evaluar, Dirigir y Monitorear (EDM) 5 procesos

Área: Administración de TI Corporativa

Alinear, Planear, Organizar ( PO) 12 procesos

Construcción, Adquisición e implementación (BAI) 8 procesos

Entrega, Servicio y Soporte (DSS) 8 procesos

Monitoreo, Evaluación e Informes (MEI) 3 procesos

Los nuevos procesos son los de EDM

EDM1 - Establecer y mantener el marco de referencia del Gobierno EDM2 - Asegurar la Optimización del Valor EDM3 - Asegurar la optimización del riesgo EDM4 - Asegurar la optimización de los recursos EDM5 - Asegurar la transparencia hacia los stakeholders

Los procesos de disponibilidad y capacidad fueron mezclados:

BAI4 - Administrar la disponibilidad y capacidad

La mesa de servicio ha sido removida como parte del nombre de un proceso, ahora el proceso que la incluye es:

DSS4 - Administrar las solicitudes de servicio e incidentes

Los volúmenes de COBIT 5 son tres

Volumen 1: El Marco de Referencia ~ 60pp principios y modelos del gobierno

corporativo de TI Volumen 2: Guía de referencia de Procesos ~ 200pp Guia detallada de

referencia de los procesos Volumen 3: Implementando y mejorar continuamente el Gobierno corporativo de TI (Cobit 5 Update - it's almost ready, 2011)

Cambios en COBIT 5

COBIT 4.1 hacía referencia a ITIL; CMM, ISO 17799, PMBOK, PRINCE2. Uno de los objetivos de COBIT 5 sigue siendo mejorar la compatibilidad con otras guías de buenas prácticas y estándares.

Nuevo modelo de madurez

Hasta ahora COBIT proponía un modelo propio para medir la “madurez” de los

procesos de la organización. La nueva versión de COBIT tomará precisamente el modelo de madurez definido por ISO en la norma ISO/IEC 15504 más conocida como SPICE (Software Process Improvement Capability Determination, Determinación de la Capacidad de Mejora del Proceso de Software) (ISACA, 2011). Los niveles definidos en el modelo SPICE son los siguientes:

Nivel 0: Incompleto

Nivel 1: Realizado

Nivel 2: Gestionado

Nivel 3: Establecido

Nivel 4: Predecible

Nivel 5: Optimizado

Como se observa en la figura 7, siguen existiendo seis niveles, de acuerdo a la adopción del modelo de ISO 15504 se les llama ahora niveles de capacidad. Estos son relacionados con nueve atributos de los procesos. Este cambio asegura el cumplimiento con el estándar mientras que da un mejor enfoque en cuan bien los procesos están siendo ejecutados y si están logrando su propósito.

Nuevo modelo de madurez Hasta ahora COBIT proponía un modelo propio para medir la “madurez” de

Estructura de procesos

La estructura de procesos es similar a la anterior. Tras los cambios, se dispone de un total de 36 procesos (34 en la versión 4.1). Al dar un primer vistazo comprobamos que muchos de los procesos ya están adoptados en la organización: Gestión de

proveedores, gestión de cambios, gestión de la configuración, gestión de incidencias, gestión de problemas. COBIT 5 propone tres procesos para la monitorización y evaluación.

Seguramente en muchas organizaciones estos tres procesos estén agrupados e implementados como un único proceso.

Análisis

Una de las muchas características anticipadas de COBIT 5 es el incremento en la atención de la integración del negocio y TI. Esta orientación mejorará la comunicación, clarificará los roles y responsabilidades y reducirá los incidentes relacionados con la información y la tecnología que pudieran dañar a la organización.

COBIT 5 integra todas las mejores prácticas dispersas en los distintos marcos de referencia de ISACA COBIT, VAL IT, Risk IT, BMIS (Modelo de negocios para la seguridad de la información) e ITAF (Marco de referencia para el aseguramiento de TI) en una sola base de conocimiento que permita tener un acercamiento consistente del valor, riesgo y seguridad en la organización. La arquitectura de COBIT 5 junta a los stakeholders, sus preocupaciones, intereses y necesidades así como la base de conocimiento de ISACA.

COBIT 5 tiene cinco principios:

  • 1. Como integrador: Un marco de referencia de gobierno y gestión para la información

y tecnología relacionada que inicia por evaluar las necesidades de tecnología de los

stakeholders.

  • 2. Motivado por el valor a los stakeholders.

  • 3. Enfocado en el negocio y su contexto

  • 4. Basado en habilitadores, definidos en el marco de referencia como aquellos recursos

que permiten el éxito de TI.

  • 5. Estructurado en el gobierno y gestión En esencia, COBIT 5 cubre de manera

completa la organización y provee una base de integración de otros marcos de referencia, estándares y mejores prácticas que algunas organizaciones pueden ya estar usando. En la tabla 2 vemos las principales diferencias entre versiones:

23

Conclusiones

Las organizaciones en la actualidad han comenzado a preocuparse por la necesidad de hacer que sus áreas de TI sobresalgan y puedan contribuir a lograr los objetivos centrales de la organización.

El Gobierno de TI fue diseñado para todas aquellas organizaciones que deseen aprovechar las TI como apoyo para el logro de dichos objetivos.

COBIT es el marco de referencia que ayuda a sustentar el Gobierno de TI, estableciendo un conjunto de actividades y controles para lograr que los procesos de TI se integren a las estrategias de la organización para el logro de objetivos del negocio.

Sobre el lanzamiento de COBIT 5, con la información que disponemos hasta el momento sólo podemos hacernos una idea general de lo que será esta versión. No obstante, los cambios destacados en el borrador al que se tiene acceso no introducen grandes cambios respecto a COBIT 4.1. Esto nos lleva a pensar que la nueva versión no será muy distinta de la actual y que por lo tanto resultará sencillo adaptar los modelos basados en COBIT 4.1 a COBIT 5.

ITIL v 3.0 Introducción

Las organizaciones que se han ocupado de aplicar las mejores prácticas del modelo ITIL® (IT Infrastructure Library) a sus sistemas se plantean numerosas preguntas en torno a la nueva versión, conocida como Prácticas de Gestión de Servicios ITIL o ITIL versión 3 (v3). ¿Cumplirá las expectativas de los directivos de TI, siempre enfrentados al reto de abordar proyectos innovadores que contribuyan al crecimiento de sus compañías?

BSM e ITIL v3

BSM se basa en el uso de la tecnología y de los procesos que ayudan a garantizar que todo aquello que haga la TI se considerará en el contexto del valor que genera para el negocio. Las prácticas de ITIL contribuyen a facilitar la gestión de la TI desde esta perspectiva de negocio. Muchas organizaciones de TI han adoptado ITIL porque sus disciplinas les permiten realizar mejor su trabajo, incrementar la calidad del servicio y reducir costes. El modelo ITIL v3 parte de los principios de la versión 2 y genera una evolución en el pensamiento de la industria de TI, que le proporciona un nuevo nivel de madurez en la gestión de servicios. BSM ayuda a la TI a dar el siguiente salto en la búsqueda de una gestión de servicios más madura e ITIL v3 incorpora la estrategia BSM como una mejor práctica.

Las principales publicaciones sobre las prácticas de gestión de servicios de ITIL v3 se centran en demostrar el valor que representa para el negocio, entre ellas el libro Service Strategy(Estrategia del Servicio), que trata sobre el posicionamiento de la gestión de servicios de TI y BSM. Este posicionamiento es importante porque muchas organizaciones se esfuerzan por integrar las aplicaciones de negocio (internamente y en los sistemas de sus partners) para automatizar los procesos end-to-end y prestar servicios de negocio. El reto al que se enfrentan estas organizaciones es encontrar la forma de establecer objetivos operativos a partir de los servicios de negocio y gestionar esos servicios en consonancia con los objetivos.

Un ejemplo de este tipo de objetivo es reducir los errores derivados de los procedimientos manuales mediante la automatización y procesar las transacciones con más rapidez.

Uno de los propósitos de BSM es ayudar a las organizaciones a resolver este problema.

Una característica clave de BSM es su capacidad de asignar dinámicamente los activos de TI a los servicios de negocio que facilitan. BSM cambia la visión de la infraestructura de TI convirtiendo el mapa de la topología en un modelo que identifica los vínculos

entre activos y servicios, y permite a la TI establecer nexos entre los eventos de la infraestructura y sus repercusiones para el negocio.

Por ejemplo, puede que necesite comprender cómo va a afectar un cambio de un servidor en los servicios de TI y de negocio relacionados. Los servicios se componen de procesos en los que se apoya el funcionamiento del negocio.

Establecer correspondencias entre un activo y un servicio se considera fundamental para garantizar la continuidad del negocio. En el pasado, puede que se necesitase saber que un cambio en el Servidor A podía afectar al funcionamiento de SAP.

Con BSM, su nivel de comprensión va más allá. Puede saber que el módulo de SAP para pedidos online puede resultar afectado y, como consecuencia, perjudicar las ventas por Internet, lo cual le permite ver el impacto que este problema podría tener en su facturación, algo fundamental para el negocio.

Integración entre TI-Negocio

ITIL v2 se centra fundamentalmente en alinear la TI con el negocio. Esto implica posicionar la tecnología para ponerla en sintonía con los objetivos globales del negocio y proporciona un lenguaje común que facilita la comunicación entre el área de TI y los responsables del negocio. ITIL v3 representa un avance sustancial, ya que se centra en integrar la TI en el negocio.

Diluye la distinción entre TI y negocio, e incluso sustituye el lenguaje de la TI por el lenguaje de los negocios.

BSM brinda una base sólida para lograr este tipo de integración.

Las soluciones BSM proporcionan una visión global de la infraestructura de TI que muestra las relaciones entre los recursos de la infraestructura, los servicios y los procesos de negocio que sustentan. Por ejemplo, las soluciones BSM pueden establecer asociaciones entre los servicios de e-business de Oracle y SAP y los componentes de la infraestructura de TI donde se ejecutan tales servicios.

Esta visión integrada muestra la relación entre la tecnología y los servicios y procesos de negocio, lo que permite a la TI tomar decisiones en función de su impacto en el negocio.

Gestión del ciclo de vida del servicio

ITIL v2 se centra en prácticas que aplican un enfoque modular a los procesos. Cada proceso tiene su propio módulo. El problema de este modelo es que no deja a las personas pensar en las actividades desde la perspectiva del tiempo de vida de un servicio. Por el contrario, ITIL v3 ayuda a las organizaciones a adoptar un punto de vista más estratégico que abarca todo el ciclo de vida del servicio. Este tipo de enfoque reporta algunas ventajas:

Favorece la integración de la estrategia de negocio con la estrategia de

servicios de TI Facilita la implantación y gestión de servicios adaptados a unas necesidades de egocio dinámicas, volátiles, altamente cambiantes y de alto riesgo

Identifica las oportunidades de mejora y cambio a lo largo de todo el ciclo de vida del servicio

Corrige las carencias y deficiencias de las anteriores versiones de ITIL ITIL v3 define cinco fases en el ciclo de vida del servicio:

Estrategia, diseño, transición, operación y mejora continua del servicio. El modelo contiene los procesos necesarios para gestionar los servicios en el marco de esta estructura del ciclo de vida. El objetivo de cada fase es generar valor para el negocio. En la Tabla 1 se recogen las características de cada fase del modelo.

• Favorece la integración de la estrategia de negocio con la estrategia de • servicios de

Los libros Service Strategy (Estrategia del Servicio) y Service Design (Diseño del Servicio) de ITIL v3 promueven un modelo flexible de provisión de servicio utilizando un enfoque de valor de la red. Al desarrollar esta red, es importante examinar con cuidado las capacidades de los proveedores internos y externos.

Para conseguirlo, ITIL v3 dedica gran parte de sus directrices a explicar los tipos de proveedores, lo que incluye la forma de analizar los distintos mercados y las fortalezas de cada proveedor, así como la manera más efectiva de crear una red de valor y seleccionar las opciones de suministro que mejor se adapten a los objetivos de negocio de una empresa.

ITIL v3 introduce también el concepto de modelos adaptables dentro del ciclo de vida completo de la práctica. Éste es un componente clave del principio denominado

“Transición del Servicio” (Service Transition), en el que se indica la forma de ayudar a

los proveedores de servicios a elegir un modelo ad hoc para cada tipo de transición de servicio que implique el paso de la fase de diseño al entorno de producción. Los modelos adaptables brindan la posibilidad de responder rápidamente a los constantes cambios de las necesidades del negocio.

En ITIL v3, la fase de mejora continua del servicio ha evolucionado para ejercer influencia en todo el ciclo de vida del servicio, ya que identifica las necesidades de mejora en cada fase de la práctica de gestión del servicio. La mejora ha dejado de verse como la última parte del proceso de prestación del servicio, para considerarse como un proceso permanente que abarca todas las etapas del ciclo de vida del servicio.

Al igual que ITIL v3, BSM adopta un enfoque de gestión del servicio basado en la estructura de su ciclo de vida e implanta las mejores prácticas para aplicar este tipo de gestión en numerosas áreas. Por ejemplo, las soluciones BSM pueden proporcionar una gestión completa de los cambios que controle el proceso de principio a fin, lo cual abarca desde la petición de cambio hasta la planificación, aprobación, implantación, verificación y, finalmente, la notificación de la correcta aplicación del cambio.

Cambios clave en los procesos

Todos los procesos ITIL de la versión anterior siguen siendo la base sobre la que se asientan las prácticas de ITIL v3. Cada proceso se ha mejorado para actuar en el contexto de un ciclo de vida y se han eliminado las carencias existentes.

También se han introducido cambios en la formulación del ciclo de vida para mejorar la versatilidad de las prácticas de ITIL.

Por último, se han modificado algunos procesos. He aquí algunos ejemplos:

En el proceso de Gestión de Incidencias se ha eliminado la petición del servicio para establecerlo como un proceso aparte denominado “Request Fulfillment” (gestión de peticiones). Se ha utilizado este enfoque para poder seguir usándolo con las tecnologías actuales, pero centrando la gestión de incidencias exclusivamente en manejar la interrupción del servicio

La Gestión de Eventos se ha actualizado para mejorar las actividades de gestión de incidencias. El proceso de gestión de eventos proporciona elementos formales para manejar de forma proactiva problemas potenciales del servicio antes de que se conviertan en problemas reales y para reconocer con más rapidez aquellos problemas que son incidencias

Los procesos de Gestión del Cambio se han corregido a fin de limitar la tendencia a modificar los modelos para adaptarlos a los tipos de cambios. Por tanto, se han simplificado y actualizado para permitir el cambio y, al mismo tiempo, mantener los elementos de mitigación del riesgo

La Gestión de las Versiones y la Implantación ha sufrido considerables cambios para ampliar su alcance e incluir todas las áreas implicadas en la puesta en producción, lo que incluye la infraestructura, las aplicaciones, los servicios y las iniciativas de proyectos La documentación de ITIL ha variado de la v2 a v3 para reflejar el nuevo enfoque de gestión del servicio en el contexto de su ciclo de

vida. En la Tabla 2 se compara la organización de la documentación en ambas versiones.

vida. En la Tabla 2 se compara la organización de la documentación en ambas versiones. Cada

Cada uno de los libros básicos de ITIL v3 incorpora lo mejor de las versiones ITIL v1 y v2, así como prácticas probadas de gestión del servicio de TI utilizadas en la actualidad. Las prácticas centrales de las fases de gestión del ciclo de vida del servicio, definidas en estos cinco libros, se complementan con otras publicaciones más detalladas. Tales publicaciones, centradas en temas específicos, cubren aspectos relativos a prácticas, sectores y grupos de interés concretos. Son documentos relacionados con las operaciones y el cumplimiento de la normativa en distintos sectores de la industria.

Los nuevos libros suplementarios suministrarán directrices que conciernen a los puntos de vista de distintos grupos de interés a fin de ayudar a las organizaciones a dar mayor impulso a sus proyectos de gestión de servicios. Aunque los mecanismos de gestión de servicios puedan diferir, las expectativas de resultados siguen siendo las mismas: generar valor para el negocio.

Servicios como activos ITIL v3 introduce el concepto de servicios como activos. Considera que un servicio

Servicios como activos

ITIL v3 introduce el concepto de servicios como activos. Considera que un servicio es un activo para su consumidor. Los activos de servicios se componen de dos entidades:

Utilidad y garantía.

La utilidad es el servicio en sí, suministrado por una combinación de personas, procesos y tecnología. Como ejemplos podríamos citar un servicio de introducción de pedidos online de un establecimiento comercial y otro de suscripción online al plan de seguro de salud de una compañía.

La garantía es la seguridad de que la utilidad se ejecutará dentro de los niveles esperados. Por ejemplo, la citada herramienta de introducción de pedidos online podría garantizar factores tales como informar sobre la existencia de stock y el plazo de entrega.

Un servicio puede ser consumido por clientes internos y externos. Por ejemplo, puede que el servicio de introducción de pedidos sólo lo consuman clientes externos, mientras que el servicio de suscripción al plan de seguro médico de una compañía puede estar dirigido exclusivamente a clientes internos, como son los empleados.

Frente al modelo ITIL v3, ITIL v2 maneja fundamentalmente activos tangibles tales como los componentes de la infraestructura tecnológica. Por ejemplo, la información de garantía de un activo se define en la información contractual asociada a ese activo y la utilidad se ve generalmente como la razón para gestionar el activo. ITIL v3 reagrupa la información sobre activos definida en ITIL v2 bajo las categorías de utilidad y garantía.

En ITIL v3, utilidad y garantía interaccionan para crear el valor del activo. Como consecuencia, los activos tienen un impacto directo sobre el valor del negocio (porque

ellos mismos generan algo de valor). Ese “algo” puede ser beneficios, innovación, satisfacción del cliente o cualquier otro aspecto que determine el éxito del negocio.

Las soluciones BSM introducen esta ventaja clave de ITIL v3 proporcionando una visión detallada del impacto que tienen los servicios para el negocio. Esta visión permite a la TI ponderar el valor de los activos de servicios y fundar sus decisiones de negocio (por ejemplo, la priorización de determinadas acciones) en función de la importancia que tiene para la compañía el servicio implicado.

Cuantificación del ROI y el retorno del valor ITIL v3 define el retorno en términos que van más allá del aspecto monetario. Incluye indicadores tan importantes como el aumento de la satisfacción de los clientes o los empleados. ITIL v3 ayuda a las empresas a cuantificar, medir y optimizar el retorno en función de dos parámetros: el retorno de la inversión (ROI) y el retorno del valor.

El libro “Estrategia del Servicio” de ITIL v3 proporciona directrices para definir estos

dos parámetros dentro de un determinado contexto de negocio. Esto ayuda a la TI a comprender qué aspectos cubren el ROI y el retorno del valor. También le ayuda a determinar qué genera valor y la importancia que tiene el que los responsables del área de TI y de negocio se pongan de acuerdo sobre la definición de valor.

De acuerdo con las especificaciones de ITIL v3, el retorno del valor de un proyecto propuesto o en marcha puede evaluarse a partir de ocho dimensiones fundamentales:

valores competitivos, financieros, funcionales, de proceso, de relación, estratégicos, técnicos y/o de uso. Los responsables de la TI pueden desarrollar una imagen completa del valor utilizando estas métricas de la forma adecuada para comunicar el retorno de valor del proyecto que dirigen.

El libro “Diseño del Servicio” de ITIL v3 proporciona directrices para determinar los

mecanismos de medición del ROI y del retorno del valor, suministrando información detallada sobre:

Qué se debe medir

Cómo se debe medir

Qué métricas deben utilizarse

Cómo utilizar la medición para demostrar los logros

BMS también incorpora los principios de ITIL v3 en este área. En concreto, permite a los departamentos de TI establecer correspondencias entre los componentes de la infraestructurade TI y los servicios y procesos de negocio que ejecutan.

Como resultado, la TI puede centrar sus esfuerzos en aquellos servicios y procesos que contribuyen a incrementar el ROI o el retorno del valor y establecer sus prioridades de

la forma más adecuada. Lo que es más, puede ajustar mejor sus operaciones y demostrar su contribución a la generación de valor para el negocio.

Con BSM, el ROI puede ser sustancial tan sólo por lo que representa en ahorro de

costes de TI. Según Forrester, “Si dan todos los pasos necesarios para llegar a un

modelo de gestión de servicios BSM, las compañías pueden ahorrar hasta un tercio de su presupuesto para operaciones de TI.

Dado que el 76 por ciento del presupuesto de TI se dedica a explotación, las empresas que implanten BSM podrán obtener un ahorro potencial del 25 por ciento de su gasto global en TI.

Mayor énfasis en la proactividad

ITIL v3 ayuda a la TI a determinar qué factores deberían desencadenar una acción. Los departamentos de TI no deberían esperar a que un proceso completo haya finalizado o haya transcurrido un determinado periodo de tiempo para determinar si se han conseguido los objetivos deseados o si es posible mejorar el proceso. Por el contrario, deberían comprender qué indicadores de un proceso son síntomas de problemas potenciales y deben provocar una acción.

Cada libro de ITIL v3 presenta eventos o condiciones que indican problemas potenciales o posibles áreas de mejora y generan acciones. Este enfoque favorece una estrategia dirigida a la gestión proactiva más que reactiva de los servicios.

Al igual que ITIL v3, BSM fomenta la aplicación de acciones proactivas en una serie de áreas. Por ejemplo, las soluciones BSM pueden monitorizar la infraestructura de TI, determinar el impacto de los eventos sobre el negocio y generar automáticamente notas de incidencias para aquellos eventos que presenten un nivel de impacto elevado.

Esto permite al personal de TI actuar de forma proactiva en la gestión de incidencias antes de que provoquen el corte de servicios vitales para el negocio.

Eliminación de silos

Otro aspecto importante de ITIL v3 es su creciente esfuerzo por evitar la separación de los procesos de TI en silos o compartimentos independientes. Aunque ITIL v2 habla de integración de procesos, define los procesos de cada función de TI (gestión de incidencias, gestión de problemas, gestión de cambios, gestión de la configuración, gestión de versiones y servicio de atención al usuario) en capítulos distintos. Esta separación de procesos por función no favorece su integración. A menudo los procesos en sí están bien implantados, pero su integración a lo largo del servicio asociado es débil o inexistente.

Por el contrario, ITIL v3 reclasifica los procesos extrayéndolos de su área funcional para enmarcarlos en las fases de su ciclo de vida, lo que fomenta su integración en funciones por servicio.

Es más, ITIL v3 reconoce que la integración efectiva de los procesos exige que las personas pertenecientes a diferentes disciplinas de TI adopten un punto de vista más global.

Los miembros del departamento de TI no sólo deben ser expertos en sus respectivas áreas, sino entender la interacción de sus áreas con las demás. Por ejemplo, el responsable de la gestión de cambios, no sólo debe conocer en profundidad los mecanismos de las operaciones del cambio, sino comprender las implicaciones que éstos tienen en la estrategia y el diseño.

Como en el caso de ITIL v3, uno de los puntales de BSM es la integración de procesos y proporciona soluciones para lograr esa integración a través de todas las funciones de TI.

Por ejemplo, algunas soluciones integran la gestión de cambios con los procesos del servicio de atención al usuario. La aplicación de gestión de cambios notifica automáticamente a la aplicación del centro de atención al usuario la existencia de cambios que provocarán la interrupción de un servicio, lo que permitirá a dicha aplicación avisar a los usuarios afectados de forma anticipada. Asimismo, la aplicación de gestión de cambios mantiene al service desk informado sobre el estado del cambio y le notifica automáticamente su finalización, con lo que se cierra el ciclo.

Qué esperar con ITIL v3

Las compañías que han implantado ITIL v2 están obteniendo considerables beneficios, entre ellos, mayor calidad en la prestación de servicios, menos costes y mejor adaptación a la normativa. Tales compañías están bien posicionadas para seguir aprovechando los éxitos cosechados con ITIL v2 mientras tratan de alcanzar un nuevo grado de madurez en la gestión del servicio mediante la adopción de ITIL v3.

Transición de ITIL v2 a ITIL v3

Una vez aclarados los conceptos fundamentales de ITIL v3 y el modo en que han evolucionado desde la versión 2, ¿qué recomendaciones hace la OGC (Office of Government Commerce) con respecto a la forma de hacer la transición?

La transición de ITIL v2 a v3 es evolutiva más que revolucionaria. ITIL v3 implica un cambio de actitud mental. Garantiza que se tomará en consideración el ciclo de vida de un servicio antes de su implantación, eliminando así la actual mentalidad basada en silos y favoreciendo una mejor integración de la TI con los procesos, operaciones y factores que impulsan el avance del negocio.

El interfaz entre ITIL v2 y ITIL v3 es transparente, lo que significa que las organizaciones de TI que ya han adoptado ITIL v2 no necesitan reinventar la rueda para implantar

ITIL v3. Esto implica que cualquier logro obtenido con la implantación de ITIL v2 se mantiene en ITIL v3.

Su estrategia de transición a los principios de ITIL v3 dependerán considerablemente del nivel de madurez y la inversión realizada en las prácticas de ITIL implantadas en la actualidad. El equipo de desarrollo de ITIL v3 recomienda adoptar el mismo enfoque que adoptaría con cualquier otra iniciativa de mejora de servicios, un enfoque incremental.

Todo el mundo en su organización de TI debería familiarizarse con las prácticas de ITIL v3 y luego valorar cómo las mejoras de esta versión pueden alinearse con las mejoras del servicio existentes. Dado que ITIL v3 mejora algunas prácticas anteriores de ITIL, un punto de partida adecuado es revisar esas mejoras y considerar lo que se puede obtener de ellas a lo largo del tiempo.

Si su organización aún no ha empezado a implantar ITIL, puede preguntarse si es aconsejable empezar con ITIL v2 y luego pasar a la versión 3. Tenga presente que siempre tiene valor mejorar la gestión del servicio en cualquier momento.

En cualquier caso, primero debería revisar las nuevas directrices de ITIL v3. Para el verano del 2007, está prevista la publicación del nuevo esquema de cualificación y formación para ITIL.

Aproveche los recursos de formación para empezar a conocer el alcance y los conceptos básicos de las prácticas de gestión del servicio propuestas por ITIL. Si se encuentra en la fase de examinar las actuales prácticas de ITIL, puede continuar por este camino y tratar de escoger los elementos apropiados de ITIL v3 cuando planifique su estrategia de implantación. ITIL v3 abarca los elementos de las prácticas de la versión anterior. Por tanto, si nunca ha implantado el modelo ITIL, puede dar el salto a ITIL v3 directamente. O bien, si ya ha puesto en marcha su implantación de ITIL, puede incorporar ITIL v3 en sus planes de mejora.

Si ya ha invertido en formación, no debe preocuparse. Las certificaciones siguen siendo válidas y puede optar por realizar nuevos cursos para complementar su formación en la materia y adaptarla al esquema de ITIL v3.

Un ejemplo

ITIL v3 propugna la innovación en el negocio. Al automatizar los vínculos entre la estrategia de negocio y la cartera de servicios (que contiene servicios en producción y posibles servicios futuros), puede facilitar la identificación de oportunidades para innovar. Con esta fórmula, puede mejorar considerablemente la velocidad a la que detecta y posibilita las oportunidades de innovación.

Por ejemplo, un miembro del departamento de TI que utilice una solución BSM para ver todos los procesos de negocio puede detectar la existencia de un proceso disgregado en un silo que podría integrarse mejor utilizando un nuevo servicio de la

cartera de servicios. Entonces, es posible que ese empleado se dé cuenta de que la integración de ese proceso tiene el potencial de revolucionar el negocio porque reduciría el tiempo de generación de valor y los costes, y mejoraría la eficiencia y efectividad del negocio. El empleado, en colaboración con el área de negocio, puede integrar el proceso dentro de los nuevos componentes de servicio requeridos para soportar el negocio. Por tanto, puede desarrollar e implantar el proceso integrado en el nuevo servicio utilizando el modelo del ciclo de vida de los servicios de ITIL v3 junto con la solución BSM. Con esta combinación, la organización de TI puede generar beneficios para el negocio con el menor riesgo posible.

Beneficios para el negocio

Una de las principales ventajas de ITIL v3 es que permite a las organizaciones aprovechar por completo su inversión en TI. Esto brinda la posibilidad de extraer todo el potencial de la TI y la experiencia de los profesionales para hacer el negocio más innovador y valioso.

La TI se beneficia de esta poderosa combinación porque sus profesionales desempeñan un papel más enriquecedor y satisfactorio. A esto se suma que su visibilidad y la percepción de su valor para la compañía crecen, ya que los directivos empiezan a ver la TI como un factor de creación de valor para el negocio.

Los responsables del negocio también se benefician de una relación mucho más estrecha con la TI y una mejor comprensión de la capacidad de este departamento para aprovechar la tecnología en proyectos de innovación. A través de la colaboración con la TI, los responsables del negocio pueden implantar nuevos procesos que incrementen su competitividad y, gracias a la innovación tecnológica, pueden abrir nuevas áreas de negocio previamente inalcanzables.

Conclusión

BSM integra todos los principios de ITIL v2 e incluso incorpora algunos de los nuevos elementos de ITIL v3. La combinación de BSM e ITIL v3 ayuda a la TI a alcanzar nuevos niveles de madurez en la gestión del servicio de TI a través de la integración de la TI con el negocio y la transición a la gestión del ciclo de vida del servicio.

Dado que ITIL v3 es una evolución de ITIL v2, las organizaciones que ya han iniciado su implantación pueden pasar fácilmente a la versión 3 sin perder ninguno de los beneficios conseguidos a raíz de los esfuerzos realizados. Asimismo, pueden percibir los beneficios adicionales que aporta ITIL v3 gracias a la integración de TI con el negocio y su nuevo posicionamiento como partner de negocio. De esta forma, las organizaciones pueden explotar todo el potencial de sus recursos de TI para mejorar su ventaja competitiva.

Referencias

BDO Consulting. (2008). Gobierno de Tecnología de Información (TI). Panamá: BDO Consulting.

Cobit 5 Update - it's almost ready. (19 de Abril de 2011). Recuperado el 2 de Noviembre de 2011, de ITSM portal: http://www.itsmportal.com/columns/cobit-5- update- %E2%80%93-it%E2%80%99s-almost-ready Institute, I. G. (2007). Cobit Quickstart 2nd edition. USA: ITGI.

ISACA. (2011). Cobit 5 The Framework (Exposure draft). IL,USA: CRISC.

ISACA. (2009). Transforming Enterprise IT. USA: ISACA.

IT Governance Institute. (2008). Alineando Cobit 4.1, ITIL v3, ISO/IEC 27002 en beneficio de la empresa. USA: ITGI.

IT Governance Institute. (2007). Cobit 4.1. USA: ITGI.

IT Governance Institute. (2005). Keys to IT Governance. USA: ITGI.

MIRBAHA, M. (2008). IT Governance in financial, comparing two sectors using Cobit 4.1. Estocolmo: KTH. NETWORK-SEC. (2010). Implantación de Gobierno de TI. Valencia: NETWORK-SEC. TOOMEY, M. (2009). Impulsando el liderazgo de TI através del buen gobierno corporativo con las TI. Australia: Atos consulting.

Villuendas, A. (19 de 09 de 2011). Definción de Gobierno de TI. Recuperado el 02 de 10 de 2011, de www.tgti.org: http://www.tgti.es/?q=node/57

“Formación Oficial ITIL, ITIL FUNDAMENTOS” Tecnofor

Web oficial de la OGC (Office of Government Commerce) británica (www.best- management-practice.com)

Trabajo académico Web 2.0 y Ajax

Trabajo académico Web 2.0 y Ajax Web 2.0 y Ajax 38

Web 2.0 y Ajax

Álvaro Gomariz López 64260

Contenido

WEB 2.0

41

Proponiendo una definición ........................................................................................................

41

La Web: de recurso a entorno hipermediático

43

La “folksonomía” y la Web

44

Los RSS y las tecnologías

44

Inteligencia colectiva ...............................................................................................................

45

  • a. La producción y el “modelo bazar”

46

  • b. Recursos en común y el equilibrio de Nash

46

  • c. El control del grupo

47

Conclusiones

49

51

52

54

55

Problemas e

55

Referencias ..................................................................................................................................

57

WEB 2.0

El término Web 2.0 hace referencia a la evolución que ha experimentado el servicio web. En constante progresión, ha pasado de unas primeras páginas estáticas en HTML (Web 1.0), a un segundo nivel más elaborado (Web 1.5), caracterizado por la creación

“al vuelo” de documentos dinámicos. Pero los cambios que se intuyen ahora son más

profundos y complejos. Este nuevo estadio de la Web es el que se conoce como Web

2.0.

La nomenclatura “2.0” no es casual y sugiere un cambio significativo en relación al modelo de páginas web disponibles hasta ahora. Esta denominación sigue el símil de los programas informáticos: las versiones de un mismo producto se identifican con dos o más números, separados por puntos. Las variaciones realizadas en el programa se indican incrementando la numeración con la lógica de que cuanto más a la derecha está el número que varía, de menor importancia resulta la mejora o la corrección realizada. Pero si es el primer dígito el que cambia, se está indicando que se han producido modificaciones sustanciales.

La manera de denominar el servicio web también sugiere que nos encontramos ante un producto que estará sometido a una constante revisión. Resulta significativo que los creadores de un servicio 2.0, durante su lanzamiento (que suele alargarse, cuando menos, unos cuantos meses), nunca muestran en sus páginas el socorrido mensaje de "en construcción", sino que identifican su situación como “en fase Beta", tal como se hace con los programas informáticos. Lo cual apunta a que una Web 2.0 no se construye, sino que se prueba. Y se modifica continuamente para dotarla de nuevas prestaciones.

Este nuevo modelo nos ha dejado palabras y siglas para definir productos o situaciones comunicativas de reciente aparición, algunas de ellas todavía sin equivalente en nuestro idioma (blogs o bitácoras, vblogs o videoblogs,folkMind, folksonomía, mashup, agregador, permalink, RSS, feed, Redes sociales, tag clouds, trackBack, wiki, AJAX…). No es propósito de este artículo explorar las posibilidades de cada una de estas aplicaciones. Pretendemos acercarnos a la Web 2.0 como concepto general para definirlo, con el fin de aislar los rasgos característicos, identificar los actores que intervienen y ayudar a comprender el cambio de paradigma que plantea. El objetivo es descubrir qué es la Web 2.0.

Proponiendo una definición

Aunque parezca increíble, encontrar una respuesta concreta o una definición estricta en la bibliografía actual (incluida la electrónica) es difícil. Más aún si tenemos en cuenta que es un término que desde su aparición, a mediados de 2004, se ha extendido rápidamente entre la comunidad de Internet (a inicios de julio de 2007, Google indexa aproximadamente 332 millones de entradas bajo esa expresión). Los padres del término otorgan al concepto valores y matices abstractos, y plantean la Web 2.0 como un koan ( 1) sólo asequible a los iniciados que, tras invertir largas

horas de reflexión y experiencia, se verán recompensados con la iluminación y el conocimiento. Así, por ejemplo, Davis (2005) afirma que la Web 2.0 «no es una tecnología, sino una actitud» y O’Reilly (2005b) expresa que el concepto «no tiene límites definidos, sino [que es] más bien un núcleo gravitatorio».

La dificultad de estos autores para definir el concepto de forma clara radica en su pretensión de abordar todas las variables que rodean al fenómeno de forma

simultánea, mezclando entorno, tecnología, aplicaciones, usos

Dado que para poder

... acercarnos al objeto con propiedad necesitamos disponer de una definición que no lleve a confusión, podemos considerar como Web 2.0 todas aquellas utilidades y servicios de Internet que se sustentan en una base de datos, la cual puede ser modificada por los usuarios del servicio, ya sea en su contenido (añadiendo, cambiando o borrando información o asociando metadatos a la información existente), bien en la forma de presentarlos o en contenido y forma simultáneamente.

Dicho de otra forma, una aplicación on line podrá considerarse como Web 2.0 cuando permita procesos de interactividad de contenidos contributiva ( 2)(cuando el usuario pueda añadir y compartir información con otros usuarios, como en Flickr / www.flickr.com), procesos de interacción de contenidos combinatoria (cuando posibilite la interrelación de contenidos de diferentes bases de datos como en los denominados purés o Mashups o, por poner un ejemplo concreto, en What’s Up? / www.jeroenwijering.com/whatsupo procesos de interacción de interficie como en Netvibes (www.netvibes.com) o iGoogle (www.google.com/ig), ya sean de preferencias estéticas o de funciones (cuando el usuario puede ubicar los contenidos en diferentes lugares de la pantalla o decidir qué contenidos aparecen) o generativa (cuando el sistema, a partir del análisis del modo de operar del usuario con la interficie, decida por el usuario cómo o qué datos presentar).

Cabe señalar que esta definición, de forma intencionada, no excluye aquellas aplicaciones on line que estén soportadas en entornos diferentes al servicio web. Se dará, pues, la paradoja de que algunas aplicaciones denominadas Web 2.0 no sean

propiamente “web”, esto es, accesibles a través de un navegador, y se requiera de

programas o dispositivos específicos para recibir sus contenidos o servicios (como ocurre en las redes peer to peer ( 3)).

El hecho de permitir al interactor la manipulación directa de la fuente de datos que sustenta un servicio on line no tiene, al menos técnicamente, nada de novedoso: los foros (un elemento de comunicación electrónica muy conocido entre los internautas) podrían considerarse como un ejemplo (tal vez, el primero) de la Web 2.0. Igualmente, las aplicaciones de telebanca, al permitir acciones como el traspaso de efectivo de una cuenta a otra, en realidad, están dejando que el usuario modifique los contenidos de la base de datos bancaria. Pero es que la Web 2.0 no es nueva: herramientas tan representativas de la corriente Web 2.0 como los weblogs se remontan a 1993 (Riley, 2005). Y el wiki, por ejemplo, data de 1995 ( 4).

Así, la novedad de las aplicaciones Web 2.0 viene determinada por los nuevos usos y situaciones comunicativas que se derivan de la asociación de nuevos datos a los datos

existentes en una base de datos (metadatos) y a la explotación de esos metadatos y de que, además, la asociación pueda realizarse de forma sencilla, ubicua y mancomunada.

Los metadatos, esto es, los datos que hablan de otros datos, sirven paraidentificar, describir, localizar, recuperar, organizar y preservar la información a la que están vinculados. A partir de estas múltiples funciones se están desarrollando aplicaciones web de muy diversa índole. Sin ánimo de ser exhaustivo, encontramos servicios que cumplen con la definición de 2.0 propuesta anteriormente, asociados a categorías tan dispares como buscadores, herramientas de publicación, portales personales, sistemas de distribución del conocimiento, espacios virtuales para almacenar y compartir contenidos, listados de marcadores sociales o utilidades distribuidas de acceso on line (ver tabla ( 1)).

La Web: de recurso a entorno hipermediático

Resulta curioso observar cómo la aparición de las aplicaciones Web 2.0 supone un

avance “hacia atrás”. Dicho de otra forma, se evoluciona hacia los sistemas

hipertextuales primigenios, como el teórico Memex de Vannebar Bush, el NLS de Douglas Engelbart o el Xanadu de Ted Nelson, los cuales estaban dotados de ciertas características que la Web 1.0 o 1.5 no pudo ofrecer jamás. Nelson, en su web (http://xanadu.com/xuTheModel), menciona defectos del WWW tales como el establecimiento de enlaces en un solo sentido, la existencia de enlaces que apuntan a recursos inexistentes, la imposibilidad de agregar notas o comentarios, la imposibilidad de comparar diferentes versiones de un documento o la inexistencia de un control sobre los derechos de autor y su gestión, entre otros. Estas carencias, en mayor o menor medida, están siendo superadas por la Web 2.0.

En esta misma línea, y teniendo en cuenta que Liestøl considera como recurso de documentos hipermedia aquel que permite al interactor «leer, copiar y navegar por una gran base de datos con enlaces hipertextuales, pero la información permanece fija; no pueden añadirse nuevos documentos y la relación estructural del material viene dada» y que el mismo autor se refiere a entorno de hipermedios como aquel donde el interactor «que lee no interacciona desde el exterior sino desde dentro, añadiendo documentos y enlaces, lo que modifica la estructura y los contenidos del sistema» (1997: 135), podemos afirmar que con las aplicaciones Web 2.0, el espacio web ha conseguido la categoría de auténtico entorno hipermedia. Y es que las aplicaciones y servicios Web 2.0 están dotando al interactor de la capacidad para ver, seguir y crear enlaces unidireccionales y bidireccionales, de la posibilidad de comparar diferentes versiones, de trabajar de forma simultánea sobre un mismo documento o de la posibilidad de publicar contenidos de forma ubicua y desde el propio entorno de acceso a los documentos.

La “folksonomía” y la Web semántica

Hemos mencionado anteriormente que los metadatos son el rasgo característico de la Web 2.0. Y más concretamente, la posibilidad de crearlos y de explotarlos. Pero su valor no radica en la posibilidad técnica de su existencia y de su manipulación sino en las manifestaciones y fenómenos comunicativos a los que está dando lugar.

Así, nos encontramos ante aplicaciones cuya importancia reside en la clasificación de la información. Las grandes bases de datos multimedia, por ejemplo, deben hacer uso de los metadatos para gestionar los enormes volúmenes de información con los que trabajan y resolver las peticiones que reciben con cierta rapidez. Tal como comenta Fernández Quijada (2006), «la manera fundamental de abordar esta hiperinflación es la indexación y el tratamiento automatizado de los datos de esta indexación».

En algunas aplicaciones 2.0 los usuarios se convierten en indexadores de la información. Y lo hacen relacionándola con palabras clave o marcas (tags) que ellos mismos eligen libremente. Esta libertad del usuario para etiquetar la información se ha

bautizado con el nombre de “folksonomía” y se opone, en cierta forma, a la taxonomía

tradicional, donde las categorías de clasificación están previamente establecidas. Espacios virtuales en los que almacenar y compartir contenidos como Flickr (www.flickr.com) para imágenes fotográficas, Goear (www.goear.com) para sonidos y canciones o YouTube(www.youtube.com) para contenidos videográficosutilizan la “folksonomía” como forma de clasificar y, posteriormente, localizar los contenidos. Lo mismo ocurre con los “marcadores sociales” –como del.icio.us (http://del.icio.us) o simpy (www.simpy.com), servidores donde los usuarios almacenan las direcciones

de sus enlaces favoritos, los marcan con tags y, si quieren, los hacen públicos. Como

adelantábamos, la trascendencia de la “folksonomía” se basa en los resultados

obtenidos y no en la mera posibilidad técnica. Si observamos más allá de la anécdota o

de la aplicación en concreto, veremos que, en realidad, nos encontramos con gran número de personas trabajando, de forma continua, voluntaria y gratuita, en la

clasificación de material, o lo que es lo mismo, dando significado a contenidos de todo

tipo (sitios web, imágenes fotográficas, material audiovisual

...

).

Estos usuarios, que

crean y mantienen una base de datos de forma manual voluntaria (Bricklin, 2001 ( 5))

están contribuyendo, sin saberlo, a fraguar la idea de la Web semántica (www.semanticweb.org) planteada por Berners-Lee (2001).

Los RSS y las tecnologías push

Las tecnologías de la información denominadas pull (del inglés, “tirar”) son aquellas en las que el usuario inicia la demanda de información y el sistema sirve los contenidos solicitados. La navegación tradicional funciona de este modo. Con la integración de metadatos a la información es muy fácil invertir el proceso y construir aplicaciones push (del inglés, “empujar”), esto es, herramientas de comunicación en las que el sistema toma la iniciativa y es capaz de enviar contenidos a los usuarios y que dichos contenidos sean acordes a sus intereses. Con las tecnologías push no es el usuario quien va a buscar la información, sino que es la información la que acude al

encuentro del receptor. El ejemplo más claro de tecnologías push de la Web 2.0 lo encontramos en la explotación de los documentos RSS asociados a losweblogs.

Un RSS (Rich Site Summary o Really Simple Syndication) ( 6) es un documento que contiene metadatos relacionados con un sitio web en concreto. Los archivos RSS (llamados también feeds RSS o canales RSS) se estructuran en ítems, con el título, el resumen y el enlace de la información que describen y, eventualmente, pueden

contener otros datos (fecha de publicación del documento, nombre del autor…).

Los weblogs son, como los wikis, otra de las herramientas de publicación rápida del universo 2.0. Los contenidos de los blogs y de sus parientes cercanos, los audioblogs y los videoblogs ( 7), son accesibles mediante tecnologías pull, visitándolos con el programa adecuado. Pero existe otra forma de obtener la información que contienen. Cuando un blogger (persona que mantiene un weblog) escribe una nueva entrada en su bitácora, de forma automática, genera o modifica un documento RSS asociado a ella. Así, los seguidores de un determinado blog, mediante programas denominados “lectores de feeds de RSS”, pueden mantenerse informados sobre las actualizaciones y novedades publicadas en sus blogs favoritos, sin necesidad de visitarlos uno a uno, estableciéndose una comunicación de tipo push. Hasta hace poco, los lectores de feeds de RSS eran herramientas que debían ser instaladas en el ordenador del usuario para funcionar (iTunes /www.apple.com/itunes). La Web 2.0 ha creado lectores de feeds on line como bloglines (www.bloglines.com) o Google Reader (www.google.com/reader). Actualmente ciertos programas navegadores como Firefox (www.mozilla.com/firefox) o Microsoft Internet Explorer 7 (www.microsoft.com/windows/IE/ie7/default.mspx)ya los incorporan como opciones de sus menús. De este modo, se está produciendo un acercamiento de las tecnologías push hacia los usuarios.

Inteligencia colectiva

Una de las grandezas que se atribuyen a Internet es que cualquier usuario, individual o colectivo, puede convertirse en emisor, creando y publicando su propio sitio web. Con las herramientas de publicación 2.0 es extremadamente fácil colocar contenidos en la Red. Pero la Web 2.0 no sólo ofrece herramientas para trabajar en entornos contributivos sino que, además, otorga a la comunidad la posibilidad de ejercer su

“inteligencia colectiva” (entendida como la capacidad del grupo para resolver

problemas que cada individuo del colectivo, de forma personal, no sería capaz de resolver ni, incluso, de entender). La inteligencia colectiva provocará, por ejemplo, que cierta referencia aparezca mejor o peor situada en Google o será capaz de construir un producto tan monumental como la Wikipedia(www.wikipedia.org).

Las actividades de la “inteligencia colectiva” en Internet pueden dividirse en tres

grandes grupos: la producción de contenidos, la optimización de recursos y el control ejercido sobre contenidos e individuos.

a. La producción y el “modelo bazar”

La inteligencia colectiva, entendida meramente como el trabajo individual de millones de usuarios, produce nada más (y nada menos) que el fruto de la suma de sus partes. Así, nos encontramos ante aplicaciones como los marcadores sociales (del.icio.us) o los almacenes virtuales (flickr) que actúan a modo de repositorios, cuyo valor se corresponde de forma directa y unívoca con la cantidad de referencias disponibles ( 8).

Además, como se verá, la producción de la inteligencia colectiva se ejerce sin la figura de una autoridad supervisora central que coordine el trabajo. Esta forma de trabajo

fue bautizada por Raymond (2000) como el “modelo bazar” (opuesto al “modelo

catedral”, jerarquizado y supervisado por un poder central). El modelo Bazar (o la cooperación sin mando) es el sistema empleado en el diseño de programas de código

abierto. El modelo se caracteriza por una constante publicación de resultados, una máxima distribución de responsabilidades y tareas y «ser abierto hasta la promiscuidad para estimular al máximo la cooperación» (Vidal: 2000).

b. Recursos en común y el equilibrio de Nash

Al observar cómo la inteligencia compartida ejerce funciones para optimizar recursos, nos encontramos ante entornos como el de las redes P2P como las de eDonkey2000, accesible mediante un programa cliente como emule (www.emuleproject.net), o BitTorrent, accesible mediante un programa cliente como uTorrent (www.utorrent.com). Estas redes también pueden medir su eficacia de manera directamente proporcional al número de ficheros que comparten. Pero en ellas, además de información, el colectivo aporta al entorno infraestructura propia, necesaria para que el sistema funcione. Así, cada usuario conectado reserva espacio en el disco duro de su ordenador como almacén de los contenidos compartidos y destina algo del ancho de banda de su propia conexión para poder distribuirlos en la red P2P.

Además de los sistemas P2P, han surgido proyectos de sistemas distribuidos ( 9) en los que el usuario participa exclusivamente cediendo recursos, sin obtener ningún beneficio directo a corto plazo. Uno de los más duraderos ha sido el pionero proyecto Search for ExtraTerrestrial Intelligence (SETI /http://setiathome.ssl.berkeley.edu), orientado a analizar las señales recibidas del espacio exterior con el fin de encontrar patrones de los que se pueda inferir la existencia de vida extraterrestre inteligente. Otro proyecto destacado de procesamiento distribuido ha sido Compute Against Cancer (www.computeagainstcancer.org), orientado a la lucha contra el cáncer.

En estos proyectos es fácil entender una colaboración desinteresada, completamente altruista, debido a la noble finalidad de los objetivos y a que los recursos se ofrecen mientras el propietario no los necesita. En cambio, no es tan fácil comprender por qué funcionan entornos como el P2P, donde la estrategia de beneficios máximos consiste en acceder a recursos y materiales ajenos sin compartir recursos y materiales propios. La respuesta no es sencilla. Pero si se contempla la relación usuario / sistema P2P desde la teoría de los juegos, encontraremos argumentos que nos ayudarán a contestar esa pregunta. Desde ese punto de vista, se puede entender que el uso de un

sistema P2P cumple con las características de un «juego de aditividad no nula, con repetición» (10), entorno ampliamente estudiado por esta especialidad de las matemáticas.

Para minimizar el abuso por parte de un usuario-jugador, algunos sistemas premian a los participantes que comparten más material. De esta manera la tendencia de los usuarios es la de optar por la estrategia de colaborar compartiendo recursos, sin tener

la tentación de dejar de hacerlo (para no ser penalizados por el sistema). O lo que es lo mismo, pero dicho en términos de la teoría de los juegos, el sistema tiende a un punto de equilibrio de Nash(11), cosa que lo hace estable, sólido, permanente. Además, las redes P2P se basan en la cooperación egoísta, estrategia que se ha demostrado como

la más eficaz en todo tipo de escenarios (económicos, biológicos, culturales

...

).

c. El control del grupo

Adelantábamos anteriormente que en el trabajo de la inteligencia colectiva no existe una autoridad central que organice el proyecto, lo cual no es del todo cierto. Es la propia inteligencia colectiva la que, además de producir contenidos y de compartir recursos, se convierte en entidad ubicua, reguladora de la producción, supliendo la existencia de una figura ubicada, jerárquicamente superior, que controle el trabajo del resto. Será, pues, la propia comunidad de usuarios, que hasta ahora no había podido actuar como un ente homogéneo en el entorno web (porque no era entorno, sino simple recurso), quien califique, valore, recomiende o prime ciertos contenidos por encima de otros. Y esa valoración no va a depender de un solo individuo sino del grupo como tal.

El control de la inteligencia colectiva se ejerce de dos maneras: a) en forma plebiscitaria, en la que la opción escogida por mayoría es la que se toma como decisión; y b) en forma de edición permanente, donde cada individuo, en cualquier momento, añade, corrige o elimina los contenidos aportados por otros individuos.

La comunidad puede ejercer un control plebiscitario en el momento que es capaz de otorgar valor, como colectivo, tanto a los usuarios individuales como a los contenidos. Dicho de otra forma, el comportamiento del conjunto de los usuarios influirá de manera determinante en los datos de la aplicación, asignando metadatos

“calificadores” a personas o a informaciones. Esto ocurre, como ya hemos

mencionado, en buscadores como Google, donde la prioridad de aparición de un enlace depende del número de veces que los usuarios lo incluyen en sus propias páginas (pageRank) o, en otros buscadores, de la cantidad de visitas que los interactores hacen a una determinada página web.

Otro ejemplo de control plebiscitario lo encontramos en el ejercicio de la

“folksonomía”, donde las decisiones del individuo formarán parte del todo. La

“folksonomía” se convertirá en una fuerza de regulación de contenidos, ya que

contribuye «a generar una categorización emergente, donde cada elemento quedaría clasificado bajo la etiqueta ganadora» (Fumero, 2005).

Estos sistemas, que podríamos denominar “de votación”, basados en el

reconocimiento, el prestigio, la confianza o la relevancia que otorga el colectivo a contenidos o a otros iguales, suelen ser el fundamento para que ciertas aplicaciones Web 2.0 se sustenten: el servicio de subastas virtuales eBay, por ejemplo, se cimienta en la opinión manifestada por los usuarios al completar una transacción. Aunque cada usuario valora de forma individual cómo se ha desarrollado la operación en la que ha participado personalmente (calificando el tiempo de entrega, el embalaje del

producto, el estado del artículo adquirido, la realización del pago en el tiempo y por el importe convenidos…), es el porcentaje final, determinado por la cantidad de transacciones valoradas positivamente, el que configura el índice de confianza

asignado a un determinado usuario siendo, finalmente, esa “inteligencia colectiva” la que otorga o niega la honestidad a cada comprador o proveedor y establece su “índice de confiabilidad”.

El otro tipo de control que hemos mencionado, el control de edición permanente, es el que se desarrolla en aplicaciones Wiki, como Citizendium(http://en.citizendium.org) o la más conocida Wikipedia (12). En Wikipedia(que es, de momento, el entorno que otorga mayor grado de libertad a los usuarios), el control se fundamenta, paradójicamente, en la inexistencia de privilegios o categorías de control: todos los usuarios tienen la misma jerarquía frente al sistema (13). Cualquier visitante de la Wikipedia puede introducir nuevos contenidos, corregir errores o eliminar entradas. Así, cuando Eco (2006), con cierto tono apocalíptico, se pregunta «¿Quién controla en

la Wikipedia no sólo los textos sino también sus correcciones? ¿O actúa una suerte de compensación estadística, por la cual una noticia falsa antes o después se localiza?» ya sabe la respuesta: la fuerza de la Wikipediaradica en esa “suerte de compensación estadística” que Eco intuye como una debilidad y que se ha demostrado como una

excelente forma de control de revisión por pares. Tal como proclama la denominada Ley de Linus (14), bajo la que se han elaborado los programas de código abierto, «dados suficientes ojos, todos los errores serán evidentes». Así, cualquier internauta (erudito o incompetente, honrado o malintencionado, experto o novel) puede añadir o modificar una entrada, sin registros ni identificaciones previas. El control sobre la información introducida se ejerce a posteriori por todos los usuarios que accederán a esos contenidos ya que, si detectan alguna anomalía, podrán modificarlos nuevamente, sin censura.

Tal como afirma Morville (2005), en el caso de la Wikipedia «la autoridad deriva de la arquitectura de la información, del diseño visual, del control y de la marca ‘Wikipedia’ y de la fe extensa en la honradez intelectual y en el poder de la inteligencia colectiva».

Aunque a primera vista puede parecer que el sistema tenderá a desestabilizarse, la experiencia demuestra que no es así: la Wikipedia en lengua inglesa, nacida en 2001, contaba, a inicios de febrero de 2006, con más de 950.000 entradas. ¡Algunas de ellas corregidas por personas de tanto prestigio como el propio Eco!

Conclusiones

La Web 2.0 ha permitido el desarrollo y la puesta en práctica de ideas y conceptos teóricos que Internet no soportaba hasta el momento: podemos hablar del servicio web como de un entorno hipermedia, nos acercamos a la Web semántica y las tecnologías push son una realidad accesible.

Además, la inteligencia colectiva se ha erigido como la auténtica protagonista de los entornos de comunicación telemáticos. Y lo ha hecho en tres ámbitos diferentes y con tres funciones: como creadora de contenidos, como socializadora de recursos y como entidad controladora de la producción.

Pero el hecho fundamental que merece la máxima atención es que nos encontramos ante nuevas formas de producción y de edición de contenidos. Y eso nos obliga a desarrollar nuevas formas de acceder a ellos y aprender a consumirlos. O, al menos, a gestionarlos con la cautela que se deriva de las nuevas formas de autoría, caracterizadas por la libertad, el anonimato, la ubicuidad, el trabajo en equipo y la constante revisión de la producción.

El inconveniente que se deriva de ese continuo estado de creación y modificación es el mismo que afecta a otros medios de comunicación electrónicos on line: si atendemos a la clasificación que hace Rolero de los documentos según su conservabilidad (2001,

web) observaremos que la información en Internet no es “inalterable” (como ocurre con el libro impreso), sino que se considera “permanente” (no desaparece hasta que

alguien, voluntariamente, la borra o la modifica). A pesar de esto, la Web se está

utilizando como fuente de citas en todo tipo de artículos y publicaciones científicas, tanto impresas como electrónicas, teniendo la precaución de mencionar la fecha de consulta del documento al que se hace referencia, puesto que el administrador del sitio web podría modificar los contenidos o, incluso, eliminarlos.

La Wikipedia, a pesar de estar sometida a un mayor número de modificaciones y de ser ingente el número de administradores potenciales, también puede utilizarse como herramienta de referencia. Incluso con mayor eficacia que una página web, ya que, aunque a primera vista pudiera parecer lo contrario, el grado de inalterabilidad de sus contenidos es inferior. La libertad, la cantidad y el anonimato de los sujetos capaces de modificarla son algunos de los factores que llevan a una baja permanencia de sus contenidos. Pero la Wikipedia ofrece herramientas para recuperar versiones anteriores y comprobar, por ejemplo, que cierta cita, en una fecha determinada, era exactamente la que aparece en un documento. El entorno web 1.0 no proporciona estos

mecanismos de revisión y aun así lo hemos “integrado” al conjunto de posibles fuentes de referencia, sin achacarle defectos “apocalípticos”.

En el caso de la Wikipedia, conociendo cómo se construye, el interactor que accede a sus artículos puede asumir el riesgo que comporta que los autores y editores de “La enciclopedia libre” sean múltiples, anónimos y distribuidos y, a cambio, beneficiarse de

las virtudes de la inteligencia colectiva. ¿O es que no debemos ser prudentes antes de aceptar como verídicos otros contenidos que se publican en Internet? Igual que

debemos cuestionarnos los contenidos que aparecen en televisión y no podemos asumir que todo lo que aparece en forma de libro impreso es la Verdad, así hay que enfrentarse a la Red: siendo críticos. Críticos con los medios. Con todos los medios. Y no sólo con las nuevas formas de producción o de distribución de contenidos on line.

AJAX

AJAX parece ser la palabra de moda en el “mundo” del desarrollo de aplicaciones Web, AJAX no es una tecnología, sino la unión de varias tecnologías que juntas pueden lograr cosas realmente impresionantes.

Hace un tiempo AJAX parece ser la palabra de moda en el “mundo” del desarrollo de

aplicaciones Web; de hecho muchos lo escuchan nombrar pero pocos saben que es realmente y, menos aún, saben en donde buscar información clara sobre que es esta

nueva “maravilla” de la tecnología que Jesse James Garret publicó en un artículo en

Inglés excelente que vale la pena traducir por completo.

¿Por qué es tan interesante AJAX? Porque en realidad AJAX no es una tecnología, sino la unión de varias tecnologías que juntas pueden lograr cosas realmente impresionantes como GoogleMaps, Gmail el Outlook Web Access ( ref ) o algunas otras aplicaciones muy conocidas: AJAX, en resúmen, es el acrónimo para Asynchronous JavaScript + XML y el concepto es: Cargar y renderizar una página, luego mantenerse en esa página mientras scripts y rutinas van al servidor buscando, en background, los datos que son usados para actualizar la página solo re-renderizando la página y mostrando u ocultando porciones de la misma.

Si algo del actual diseño de interacción puede ser llamado glamoroso, es crear Aplicaciones Web. Después de todo, ¿cuándo fue la última vez que escuchaste a alguien hablar de diseño de interacción de un producto que no esté en la Web? (Okay, dejando de lado el iPod). Todos los nuevos proyectos cool e innovadores están online.

Dejando de lado esto, los diseñadores de interacción Web no pueden evitar sentirse envidiosos de nuestros colegas que crean software de escritorio. Las aplicaciones de escritorio tienen una riqueza y respuesta que parecía fuera del alcance en Internet. La misma simplicidad que ha permitido la rápida proliferación de la Web también crea una brecha entre las experiencias que podemos proveer y las experiencias que los usuarios pueden lograr de las aplicaciones de escritorio.

Esa brecha se está cerrando.

Google Suggest y Google Maps son dos ejemplos de un nuevo acercamiento a las

aplicaciones Web, que nosotros en Adaptative Path hemos denominado AJAX. El nombre es una abreviación o acrónimo para Asynchronous JavaScript + XML, y ello representa un cambio fundamental en que es posible en la Web.

Definiendo Ajax

Ajax no es una tecnología. Es realmente muchas tecnologías, cada una floreciendo por su propio mérito, uniéndose en poderosas nuevas formas. AJAX incorpora:

· presentación basada en estándares usando XHTML y CSS;

· exhibición e interacción dinámicas usando el Document Object Model ;

· Intercambio y manipulación de datos usando XML and XSLT ;

· Recuperación de datos asincrónica usando XMLHttpRequest ;

· y JavaScript poniendo todo junto.

El modelo clásico de aplicaciones Web funciona de esta forma: La mayoría de las acciones del usuario en la interfaz disparan un requerimiento HTTP al servidor web. El servidor efectúa un proceso (recopila información, procesa números, hablando con varios sistemas propietarios), y le devuelve una pagina HTLM al cliente. Este es un modelo adaptado del uso original de la Web como un medio hipertextual, pero como fans de “The Elements of User Experience” sabemos, lo que hace a la Web buena para el hipertexto, no la hace necesariamente buena para las aplicaciones de software.

Este acercamiento tiene mucho sentido a nivel técnico, pero no lo tiene para una gran experiencia

Este acercamiento tiene mucho sentido a nivel técnico, pero no lo tiene para una gran experiencia de usuario. Mientras el servidor esta haciendo lo suyo, que esta haciendo el usuario? Exacto, esperando. Y, en cada paso de la tarea, el usuario espera por mas.

Obviamente, si estuviéramos diseñando la Web desde cero para aplicaciones, no querríamos hacer esperar a los usuarios. Una vez que la interfaz esta cargada, porque la interacción del usuario debería detenerse cada vez que la aplicación necesita algo del servidor? De hecho, porque debería el usuario ver la aplicación yendo al servidor?

Como es diferente AJAX

Una aplicación AJAX elimina la naturaleza “arrancar-frenar- arrancar-frenar” de la interacción en la Web introduciendo un intermediario -un motor AJAX- entre el usuario y el servidor. Parecería que sumar una capa a la aplicación la haría menos reactiva, pero la verdad es lo contrario. En vez de cargar un pagina Web, al inicio de la sesión, el navegador carga al motor AJAX (escrito en JavaScript y usualmente “sacado” en un frame oculto).

Este motor es el responsable por renderizar la interfaz que el usuario ve y por comunicarse con el servidor en nombre del usuario. El motor AJAX permite que la interacción del usuario con la aplicación suceda asincrónicamente (independientemente de la comunicación con el servidor).

Así el usuario nunca estará mirando una ventana en blanco del navegador y un icono de reloj de arena esperando a que el servidor haga algo

Como es diferente AJAX Una aplicación AJAX elimina la naturaleza “arrancar -frenar- arrancar- frenar” de la

Cada acción de un usuario que normalmente generaría un requerimiento HTTP toma la forma de un llamado JavaScript al motor AJAX en vez de ese requerimiento. Cualquier respuesta a una acción del usuario que no requiera una viaje de vuelta al servidor (como una simple validación de datos, edición de datos en memoria, incluso algo de navegación) es manejado por su cuenta. Si el motor necesita algo del servidor para responder (sea enviando datos para procesar, cargar código adicional, o recuperando nuevos datos) hace esos pedidos asincrónicamente, usualmente usando XML, sin frenar la interacción del usuario con la aplicación.

Quien está usando Ajax

Google está haciendo una significativa inversión en el acercamiento Ajax. Todos los grandes productos que Google ha introducido en el ultimo año (Orkut, Gmail, la última versión de Google Groups, Google Suggest, y Google Maps ) son aplicaciones Ajax.

Otros están siguiendo la tendencia: muchas de las funciones que la gente ama en Flickr dependen de Ajax, y el motor de búsqueda de Amazon A9.com aplica tecnologías similares.

Estos proyectos demuestran que Ajax no es solo técnicamente importante, sino también prácticos para aplicaciones en el mundo real. Esta no es otra tecnología que solo trabaja en un laboratorio. Y las aplicaciones Ajax pueden ser de cualquier tamaño, de lo más simple, funciones simples como Google Suggest a las muy complejas y sofisticadas como Google Maps.

Problemas e inconvenientes.

Las páginas creadas dinámicamente mediante peticiones sucesivas AJAX, no son registradas de forma automática en el historial del navegador, así que haciendo clic en el botón de "volver" del navegador, el usuario no será devuelto a un estado anterior de la página, en cambio puede volver a la última página que visitó. Soluciones incluyen el uso de IFrames invisible para desencadenar cambios en el historial del navegador y el cambio de la porción de anclaje de la dirección (después de un #).

Los motores de búsqueda no analizan JavaScript. La información en la página dinámica no se almacena en los registros del buscador.

Hay problemas usando Ajax entre nombres de dominios, a esto se le conoce como Same Origin Policy o Política del Mismo Origen, el cual es una medida de seguridad, el cual puede ser solucionada con Cross-Origin Resource Sharing (CORS).

Dependiendo de como se desarrolle el sitio web, puedes mejorar o empeorar la carga en el servidor. Ajax puede ayudar al servidor a evitar la fase de renderizacion de html, dejándole ese trabajo al cliente, pero también puede sobrecargar al servidor si se hace varias llamadas a Ajax.

Es posible que páginas con Ajax no puedan funcionar en teléfonos móviles, PDA u otros aparatos. Ajax no es compatible con todos los software para ciegos u otras discapacidades.

Referencias

.

DAVIS, I.: «Talis, Web 2.0 and All That», 4 de julio de 2005;

ECO, U.: «Los riesgos de la Wikipedia», La Nación, Buenos Aires, 29 de enero de 2006;

GILES, J.: «Internet encyclopaedias go head to head», Special Report, Nature, 14 de diciembre de 2005; en:www.nature.com/news/2005/051212/full/438900a.html

NELSON, T.: «The Xanadu® Model», Xanadu; en:http://xanadu.com/xuTheModel

MORVILLE, P.: «Authority», Semantic Studios, 11 de octubre de 2005; en:

O’REILLY, T.: «Not 2.0?», 5 de agosto de 2005a;

«What Is Web 2.0. Design Patterns and Business Models for the Next Generation of Software», 30 de septiembre de 2005b;

Trabajo académico Cloud Computing

Trabajo académico Cloud Computing Cloud Computing 59

Cloud Computing

Álvaro Gomariz López 64260

ÍNDICE

¿Qué es el Cloud Computing?

 

63

Concepto de Cloud Computing

64

Características del cloud

65

Clasificación de soluciones de

cloud

68

Por familias cloud (modelos de servicio)

68

Infrastructure as a Service (IaaS)

 

68

Software as a

Service (SaaS)

69

Plataform as a Service (PaaS)

69

Bussines Process as a Service (BPaaS)

70

Por principales formas de implementación (formas de integración y explotación)

70

Cloud

Público (Externo)

70

Cloud

Privado (Interno)

71

Cloud

de

71

Cloud

Híbrido

72

Por agentes intervinientes en el negocio

 

72

Ventajas y retos del cloud

 

74

Ventajas 74

 

Retos del cloud computing.

76

Disponibilidad de

 

77

Falta de estandarización e integración

 

78

Seguridad y privacidad de los

 

79

Seguridad 79 Herramientas y estándares.

83

Privacidad de los datos.

90

Módelos de

96

Fase 1: Análisis y evolución de la situación

 

97

Fase 2: Valoración de

 

101

61

Fase

3:

Recomendaciones

106

Fase 4: Definición de la hoja de ruta

109

110

Referencias y

 

118

62

¿Qué es el Cloud Computing?

En este primer capítulo vamos a ver diferentes aspectos del Cloud Computing, su origen así como su definición.

En los últimos años debido a la internacionalización de las grandes empresas junto con la evolución del uso de las tecnologías y procesamiento de datos han provocado que las necesidades a nivel de procesamiento de las empresas y organizaciones hayan aumentando a un ritmo exponencial en lo que a la capacidad de los ordenadores personales se refiere. Por esto y con el fin de poder llevar a cabo las actividades de los sistemas más exigentes, se ha producido una evolución de los sistemas de procesamiento de datos, siendo principalmente la de la ejecución en varios equipos de dichos procesos.

Este primer paso fue posible en gran parte por los sistemas operativos de tipo Unix y su posibilidad de configuración de clusters, o lo que es lo mismo, agrupaciones de ordenadores con compontes hardware que se comportan como un único ordenador.

Tras varias décadas de investigación y desarrollo en esta tecnología, la aparición de Linux como sistema operativo abierto permitió la implementación de clusters basados en arquitectura PC, consiguiendo instalaciones de calculo de alto rendimiento a bajos precios y haciendo de esta la solución en la década de 1990.

Esta solución fue acogida en instituciones de investigación en la primera década de 2000, pero debido a su complejidad, su dificultad ante el uso de diferentes grids y los problemas de portabilidad entre estas provocaron que no se popularizase fuera del ámbito académico y de investigación.

A su vez, en este periodo de tiempo, también se popularizaron tecnologías que permitían implementar máquinas virtuales, permitiendo desacoplar el hardware del software replicando el entorno de usuario sin la necesidad de instalar y configurar el software para cada aplicación, lo cual presentaba la ventaja en la distribución y el mantenimiento de complejos sistemas software así como la integración bajo un mismo entorno de sistemas diferentes.

Con este método se permitía una distribución sencilla de la carga de trabajo eliminando los problemas de la arquitectura grid y dando pie a lo que ahora llamamos Cloud Computing. Modelo emergente como nueva solución al procesamiento de datos y alojamiento de los mismos a su vez apropiado para su uso comercial para los grandes procesamientos de datos de los proveedores de servicios de Internet.

Concepto de Cloud Computing Refiriéndonos a la definición dada por el NIST ( National Institute of

Concepto de Cloud Computing

Refiriéndonos a la definición dada por el NIST (National Institute of Standards and Technology), definimos el cloud computing como un modelo tecnológico que permite el acceso ubicuo, adaptado y bajo demanda en una red a un conjunto compartido de recursos de computación configurables compartidos (por ejemplo: redes, servidores, equipos de almacenamiento, apliaciones y servicios), que pueden ser rápidamente aprovisionados y liberados y con un esfuerzo de gestión reducido o interacción mínima con el proveedor del servicio.

Como definición complementaria podemos encontrar la prorporcionada por el RAD Lab de la Universidad de Berkeley la cual explica que el cloud computing se refiere tanto a las aplicaciones entregadas como servicio a través de Internet, como el hardware y el software de los centros de procesamiento de datos que proporcionan dichos servicios. Estos han sido conocidos durante mucho tiempo como Software as a Service (SaaS), mientras que el hardware y el software del centro de datos es a lo que se llama nube.

Con todo esto podemos entender que el computing representa una novedad en lo que al procesamiento de la información y gestión de las áreas TIC para empresas y organismos públicos.

Características del cloud computing.

Entre las características asociadas al cloud computing se encuentran las siguientes:

Pago por uso. Una característica principal del cloud es el sistema de facturación en función del

Pago por uso.

Una característica principal del cloud es el sistema de facturación en función del consumo, lo que es lo mismo, el pago a realizar varía en función del uso que se realiza del servicio cloud contratado por el cliente.

Abstracción

Es la propiedad de aislamiento de los recursos informáticos contratados al proveedor de servicios cloud de los equipos informáticos del cliente. Esto es posible gracias a la virtualización, con lo que la organización cliente no necesitará un personal de mantenimiento de infraestructuras, actualizaciones, pruebas y otras tareas relacionadas quedando estas a cargo del servicio contratado.

66

Agilidad en la escalabilidad.

Propiedad basada en el aumento o disminución las funcionalidades ofertadas al cliente, atendiendo a sus necesidades puntuales sin modificaciones de contrato o penalizaciones en el mismo. De igual modo, el coste del servicio se modificará acorde a las necesidades puntuales de uso de la solución. Esta característica relacionada con el pago por uso evita los riesgos inherentes de un posible dimensionamiento erróneo inicial en el consumo o en la necesidad de recursos.

Multiusuario.

Capacidad que permite el cloud que posibilita a varios usuarios compartir los medios y recursos informáticos, permitiendo la optimización de su uso.

Autoservicio bajo demanda.

Característica que permite al usuario acceder de una manera flexible a las capacidades de computación en la nube de manera automática a medida que las vaya requiriendo, sin necesidad de una interacción humana con su proveedor y proveedores de servicios cloud.

Acceso sin restricciones.

Característica consistente en la posibilidad ofrecidad a los usuarios de acceder a los servicios contratados de cloud computing en cualquier lugar, momento y con cualquier dispositivo que disponga de conexión a red de servicio IP. El acceso a los servicios de cloud computing se realiza a través de la red, lo que facilita que distintos dispositivos, tales como teléfonos móviles, PDA’s, u ordenadores portátiles, puedan acceder a un mismo servicio ofrecido en la red mediante mecanismos de acceso comunes.

Clasificación de soluciones de cloud computing.

Las soluciones de cloud computing existentes en el mercado actual permiten clasificaciones según el aspecto a valorar para dicha clasificación.

En función de la documentación analizada así como de las referencias de los informes, principalmente, del NIST (-NIST Cloud Computing Standards Roadmap) y Deloitte (-Cloud Compunting: Forecasting change. Market Overview and Perspective) se definen tres características fundamentales que marcan la clasificación de las soluciones cloud: familias, formas de implementación y agentes intertervinientes.

Clasificación de soluciones de cloud computing . Las soluciones de cloud computing existentes en el mercado

Por familias cloud (modelos de servicio)

Infrastructure as a Service (IaaS)

Familia de cloud computing consistente en poner a disposición del cliente el uso de la infraestructura (capacidad de computación, espacio de disco y bases de datos entre otros) como un servicio.

Los clientes que optan por este tipo de familia de cloud en vez de adquirir o dotarse directamente de recursos como pueden ser los servidores, el espacio del centro de datos o los equipos de red optan por la externalización en busca de un ahorro en la inversión en sistemas TI.

Con esta externalización, las facturas asociadas a este tipo de servicios se calculan en función de la cantidad de recursos consumidos por el cliente, sistema basado en el modelo de pago por uso.

Software as a Service (SaaS)

Familia de cloud computing basada en la entrega de aplicaciones como servicio, siendo un modelo de despliegue de software mediante el cual el proveedor ofrece licencias de su aplicación a los clientes para su uso como un servicio bajo demanda.

Los proveedores de los servicios SaaS pueden tener instalada la aplicación en sus servidores web propios (permitiendo a los clientes acceder, por ejemplo, mediante un navegador web), o descargar el software en los sistemas del contratante del servicio. En esta última situación, se provocaría la desactivación de la aplicación una vez finalizado el servicio o el contrato de licencia de uso.

La solución de cloud computing de SaaS puede orientarse a otros tipos de clientes según su condición:

Usuarios particulares:

 

o

Servicios de ofimática en cloud.

Redes sociales.

 

o

Red 2.0

Usuarios profesionales:

 

o

C.R.M.

o

E.R.P

Plataform as a Service (PaaS)

Familia de cloud consistente en la entrega, como servicio, del conjunto de plataformas informáticas destinadas al desarrollo, testeo, despliegue, hosting y mantenimiento de los sistemas operativos y aplicaciones propias del cliente.

Las principales características asociadas al PaaS como solución de cloud son:

Facilita el despliegue de las aplicaciones del cliente sin el coste la complejidad derivados de la compra y gestión del hardware y de las capas de software asociadas.

Ofrece a través de redes de servicio IP todos los requisitos necesarios para crear y entregar servicios.

Bussines Process as a Service (BPaaS)

Familia de cloud computing consistente en la provisión como servicio de procesos de negocio end-to-end altamente estandarizados a través de su entrega dinámica, la modalidad de pago por uso y los modelos de consumo de autoservicio bajo demanda.

Su propiedad principal es que los recursos empleados mediante esta solución para ejecutar los procesos de negocio, son compartidos entre los diferentes clientes del proveedor. En muchos casos, este hecho proporciona un aporte de valor al negocio, sin embargo, la solución BPaaS se encuentra en fase incipiente, siendo todavía todavía un modelo de negocio en el que los proveedores tan solo operan en la actualidad en puntos concretos.

Por principales formas de implementación (formas de integración y explotación)

Cloud Público (Externo)

Forma de implementación caracterizada por la oferta de servicios de computación virtualizados (bases de datos, sistemas operativos, plataformas de desarrollo, aplicaciones, etc.) por parte de los proveedores para múltiples clientes, accediendo éstos a dichos servicios a través de Internet o redes privadas virtuales (VPNs).

Como características inherentes a esta forma de implementación podemos citar las que siguen:

Reducido plazo de tiempo para la disponibilidad del servicio

No se requiere llevar a cabo inversión monetaria para su implementación

Permite la externalización a un proveedor de servicios de cloud de todas las funciones básicas de la empresa

Posibilita el aprovechamiento de la infraestructura de los proveedores de servicios, permitiendo adicionalmente una alta escalabilidad y flexibilidad en la modificación del dimensionamiento del servicio.

Favorece la utilización de conjuntos de software estandar.

Lleva asociadas unas cuotas iniciales de pago más bajas que el resto de implementaciónes. Adicionalmente los costes del cloud público son variables, cumpliendo el principio de pago por uso.

La información corporativa se encuentra alojada en la nube pública junto a la del resto de clientes del proveedor, lo que implica, además de no poder tener localizada fisicamente dicha información, imponer al proveedor una serie de requisitos de alta exigencia en temas de seguridad y protección de datos.

Cloud Privado (Interno)

Forma de implementación caracterizada por el suministro por parte del proveedor de entornos virtualizados que pueden ser implementados, usados y controlados por la misma empresa controlante del servicio. Esto infica no solo que la solución cloud puede ser administrada por la organización contratante, por el proveedor o por un tercero, sino que puede existir en las instalaciones propias del cliente o fuera de las mismas.

Las características propias de esta forma de implementación son:

Reducido plazo de tiempo para la puesta en servicio y una alta flexibilidad en la asignación de recursos

Al contrario que el cloud público, requiere de inversión económica para la implementación de la solución contratada.

Lleva asociados sistemas y bases de datos locales.

Ofrece la posibilidad de aprovechar el personal existente y las inversiones en sistemas de información realizadas con anterioridad.

Implica más espeficidad en las soluciones adquiridas, ya que está diseñada para ajustarse a las necesidades propias de la empresa contratante.

Permite disponer de un control total de la infraestructura, de los sistemas y de la información corporativa tratada por estos.

Facilita el control y la supervisión de los requisitos de seguridad y protección de la información almacenada.

Cloud de Comunidad.

Se trata de clouds usados por diferentes entidades cuyas funciones y servicios sean comunes, permitiendo con ello la colaboración entre grupos de interés.

Ejemplos de este tipo de implementación son los clouds de comunidades de servicios de la salud, para facilitar el acceso a aplicaciones e información crítica de carácter sanitario, y los clouds de comunidades gubernamentales, para facilitar el acceso a recursos de interoperabilidad entre organismos públicos y Administraciones públicas.

Al analizar un cloud de comunidad, se debe considerar que, en principio, sus fortalezas y debilidades se sitúan entre las del privado y las del público. En general, el conjunto de recursos disponibles con un cloud de comunidad es mayor que en el privado, con las ventajas evidentes que ello conlleva en términos de elasticidad. Sin embargo, la cantidad de recursos es menor que los existentes en una solución de cloud público, limitando la elasticidad respecto a dicho cloud público. Por otra parte, el número de usuarios de este tipo de nube es menor que los de la nube pública, lo que la dota de mayores prestaciones en cuestiones de seguridad y privacidad.

Cloud Híbrido

Forma de implementación cuya infraestructura cloud (en la nube) se caracteriza por aunar dos o más formas de clouds (privado, comunitario o público), los cuáles continúan siendo entidadesúnicas interconectadas mediante tecnología estandarizada o propietaria, tecnología que permite la portabilidad de datos y aplicaciones (ej. el rebalanceo de cargas entre nubes). Una entidad que emplee esta forma de implementación se podría beneficiar de las ventajas asociadas a cada tipo de cloud, disponiendo con ello de una serie de características adicionales, tal y como se muestra a continuación:

• Ofrece una mayor flexibilidad en la prestación de servicios de TI, al mismo

tiempo que se mantiene un mayor control sobre los servicios de negocio y de datos.

• Con una solución de cloud híbrido, al igual que en los casos detallados

anteriormente, se consigue una rápida puesta en servicio.

• Implica mayor complejidad en la integración de la solución cloud, como

consecuencia de ser una solución que se compone de dos formas distintas de implementación de servicios en la nube.

• Permite integrar las mejores características de las dos formas

de

implementación cloud, en cuanto al control de los datos y a la gestión de las funciones

básicas de la entidad.

Posibilita la selección

por parte

del

proveedor,

de infraestructura escalable

y

flexible, permitiendo una alta agilidad en el redimensionamiento de la solución.

Permite el control interno de los servicios cloud desde la propia entidad.

Por agentes intervinientes en el negocio

Como principales agentes intervinientes en el

negocio

se

pueden

definir:

el

proveedor, el intermediario, el habilitador, el auditor y el suscriptor, los cuales se detallan a continuación.

Proveedor

El proveedor presta servicios a través de la nube a suscriptores o intermediarios, es decir, el servicio ofertado por la empresa proveedora al cliente, ya sea de forma directa o a través de un intermediario.

Intermediario

El intermediario presta servicios de intermediación entre los usuarios finales y los proveedores en un mercado dinámico de oferta y demanda como es el cloud computing. Como ejemplo se pueden mencionar los servicios frontales o las intermediaciones extremo-extremo.

Habilitador

Se trata de un agente proveedor típicamente enfocado al mercado de proveedores de cloud. Son empresas que proveen de software y hardware a proveedores de servicios cloud, para que éstos desarrollen y ofrezcan al usuario servicios en la nube.

Auditor

El auditor es el agente encargado de llevar a cabo las evaluaciones independientes de los servicios en la nube, de las operaciones asociadas a los sistemas de información, del rendimiento y de la seguridad en el uso de la solución cloud.

Suscriptor

La figura denominada suscriptor se corresponde con el usuario contratante de los servicios cloud, por lo que se puede identificar a esta figura como el cliente de los proveedores, los intermediarios y los auditores.

Ventajas y retos del cloud computing.

Ventajas

Las soluciones y servicios de cloud computing ofertados por los proveedores e intermediarios ofrecen una serie de ventajas a las empresas privadas (económico-financieras, foco en el negocio, rapidez y flexibilidad, tecnológicas, seguridad, disponibilidad y movilidad etc.), a la economía, a las organizaciones públicas y de investigación y a los ciudadanos (mayor y mejor oferta de servicios, gobierno abierto, educación), respecto de las funcionalidades ofrecidas por los sistemas tradicionales de TI.

De acuerdo a encuestas11 realizadas por la Agencia Europea de Seguridad de las Redes y de la Información (ENISA) a entidades localizadas en la Unión Europa, América y Asia entre las cuales se encuentran pymes españolas, las principales ventajas que se aprecian e influyen a la hora de adoptar este tipo de soluciones en pequeñas y medianas empresas son el ahorro de costes de capital (68,1%) y la facilidad de aumentar los recursos disponibles (63,9%).

Ventajas y retos del cloud computing. Ventajas Las soluciones y servicios de cloud computing ofertados por

74

En base a la documentación analizada, y tomando como referencias principales los documentos de la Fundación Ideas (―Cloud Computing: Retos y Oportunidades‖), de Deloitte

(―Cloud

Computing: Forecasting change. Market Overview and

Perspective‖), del Observatorio Regional para la Sociedad de la Información en Castilla y León (―Cloud Computing: La Tecnología como Servicio‖), y otros documentos, se detallan a

continuación las distintas ventajas ofrecidas por la tecnología cloud respecto de los sistemas tradicionales de TI para los diferentes colectivos que componen la sociedad y la economía

española.

Para muchos de estos colectivos y sectores, el cloud puede suponer un canal muy efectivo de acceso a las nuevas tecnologías para el desarrollo de sus actividades que con modelos tradicionales estarían vetados por el coste de la inversión. Gracias al acceso a las tecnologías se favorece la productividad de las empresas, se mejoran los servicios públicos y la calidad de vida y se evoluciona hacia modelos avanzados de Sociedad de la Información y el conocimiento.

Retos del cloud computing.

Existen elementos aceleradores del desarrollo y adopción de los servicios de cloud computing y elementos inhibidores. De acuerdo a la encuesta realizada por ENISA a entidades localizadas en la Unión Europa, América y Asia, los principales retos que identifican las distintas empresas y organizaciones públicas están relacionados con la seguridad, siendo la confidencialidad de los datos corporativos, el principal reto identificado por los encuestados, seguido de la privacidad e integridad de los servicios y/o datos de la entidad. Por detrás de estos aspectos de seguridad se sitúa como principal consideración la disponibilidad de los servicios y datos.

Retos del cloud computing. Existen elementos aceleradores del desarrollo y adopción de los servicios de cloud

76

Disponibilidad de servicio. Según el artículo de la Universidad de Berkeley existe aún la duda entre

Disponibilidad de servicio.

Según el artículo de la Universidad de Berkeley existe aún la duda entre las empresas y organismos del sector público y privado sobre la garantía de cumplimiento de los niveles de servicio acordados con el proveedor, en los procesos de mayor criticidad para la compañía.

Será responsabilidad del sector el superar estas dudas y desarrollar, mediante la generalización de acuerdos de nivel de servicio y cláusulas de penalización, el clima de confianza en el servicio necesario para garantizar que la migración a entornos cloud no penalizará la disponibilidad y el nivel de servicio acordado con los clientes.

Un requisito mínimo para la extensión de los servicios de cloud computing en la provisión de aplicaciones multimedia o con gran necesidad de transmisión de datos, es la universalización de la banda ancha, en la que juegan un papel fundamental los proveedores de servicios de telecomunicaciones. En el siguiente gráfico se aprecia la evolución de las distintas tecnologías de banda ancha fija y móvil (ancho de banda de bajada en este caso). Como señala el informe

―Oportunidades y desafíos de la banda ancha‖ de Gaptel31, las previsiones futuras de acceso

de banda ancha pasan por las tecnologías de fibra óptica para el segmento de acceso fijo y 3.5G, 4G y WiMAX en el segmento móvil.

El despliegue de estas tecnologías y la disponibilidad de servicios que como el cloud, aprovechen los mayores anchos de banda, pueden suponer una importante ventaja para la competitividad de aquellos países que hayan hecho una clara apuesta por favorecer y acelerar estos despliegues.

Falta de estandarización e integración tecnológica. En el contexto del cloud todavía se encuentran algunas limitaciones

Falta de estandarización e integración tecnológica.

En el contexto del cloud todavía se encuentran algunas limitaciones en relación a la estandarización de las plataformas de los proveedores que dificultan en gran medida los procesos de migración de datos y aplicaciones y la integración con otros subsistemas de negocio que se requieran mantener en modo tradicional en una compañía. Adicionalmente, un cliente cloud puede tener distribuidas sus aplicaciones en diversos proveedores y requiere para su negocio que todas ellas se integren y sincronicen en la implementación de procesos. La industria cloud y las Administraciones Públicas tienen igualmente un importante reto en el desarrollo de estándares y de un marco de interoperabilidad efectivo (aspectos recogidos de forma expresa en la Agenda Digital para Europa). Los estándares sobre los que es necesario avanzar se citan a continuación:

1. Estándares del cloud para la interoperabilidad: como se ha venido comentando a lo largo del documento, existe una amplia gama de capacidades y funcionalidades disponibles en las soluciones ofertadas por los proveedores que

78

actualmente se pueden encontrar en el mercado. Sin embargo, la tecnología cloud computing se encuentra aún en sus primeras etapas de desarrollo, no estando aún consolidada dentro de los departamentos TI del mundo empresarial. Por ello, la estandarización de procesos asociados al uso de soluciones cloud se encuentra también en periodo de desarrollo, quedando aún mucho camino por recorrer en procesos asociados a la interoperabilidad.

2. A pesar de encontrarse en periodo de desarrollo, muchos estándares de TI existentes en la actualidad contribuyen a la interoperabilidad entre los servicios en la nube y las aplicaciones dispuestas en ella para su uso, así como contribuyen en la interoperabilidad entre distintos servicios en la nube. Entre estos estándares, dentro de los específicos para la tecnología cloud podemos encontrar los que se muestran en la siguiente tabla:

Seguridad y privacidad de los datos.

Seguridad

El Cloud Computing presenta en muchos casos los mismos problemas de seguridad que tenemos en los sistemas convencionales. Además aparecen nuevos riesgos específicos derivados de las nuevas arquitecturas que se usan para trabajar en la nube.

La seguridad es un punto clave ya que los datos ylas aplicaciones de los clientes resi dirán en proveedores externos que controlarán la nube. La nube es un sistema complejo pero podemos bstraerlo como un conjunto de primitivas simples que son replicadas miles de veces en unidades funcionales comunes, por tanto debemos afrontar la seguridad realizando esa descomposición y teniendo en cuenta los aspectos básicos de la nube donde aparecen los riesgos para la seguridad.

La aparición de tecnologías como la virtualización (un sistema operativo provee una capa de abstracción que permite ejecutar otros SOs en maquinas virtuales independientes), las arquitecturas orientadas a servicio así como el despliegue real de la banda ancha son aspectos a evaluar para proteger la seguridad de la nube junto con la aparición de tendencias como las aplicaciones Web 2.0

La mayoría de las aplicaciones en la nube van a disponer de un interfaz Web por el cual accederemos a los distintos servicios de las nube, por tanto en este aspecto vamos a tener los mismo riesgos de seguridad que un hospedaje tradicional: SQL Injection, cross site scripting,… igual de problemáticos que en sistemas convencionales no externalizados. En cuanto a la seguridad física al igual que existen unas políticas establecidas para los centros de datos estas se incorporarán a la nube en el proveedor de la misma.

Centrándonos en los problemas específicos de seguridad en la nube tendríamos que tener en cuenta los siguientes aspectos:

Virtualización: siendo una de los áreas claves que permiten a la nube

ofrecer su funcionalidad, la misma será todo lo segura que pueda serlo la virtualización. La clave será el monitor de VM (hipervisor) ya que han aparecido vulnerabilidades en varios (Microsoft Virtual PC, VMware, Xen…). El aislamiento de cada VM es fundamental así como que el hipervisor fuera root- secure lo que implica que ningún nivel de privilegio [8] de las VM puede actuar de interfaz con el sistema computador. Una solución que ayuda al control e los distintos sistemas hospedados en la capa de antivirus que debería estar siempre entre el monitor las distintas VMs.

 Localización de Datos: la confidencialidad de los datos será un aspecto fundamental para la seguridad,

Localización de Datos: la confidencialidad de los datos será un aspecto fundamental para la seguridad, ya que al trabajar en la nube es muy posible que no sepamos físicamente donde están localizados los mismos (incluso pueden estar replicados para ofrecer redundancia y con ellos mayor disponibilidad del servicio). Por tanto los mismos (acceso, seguridad perimetral,…) se tratarán en función de las leyes vigentes en el país donde se alojen.

Procesos confiables: dentro del host que finalmente lleva a cabo el procesamiento (normalmente Clusters) se estarán ejecutando procesos de distintos ámbitos. Es una amenaza de seguridad que alguno de estos procesos(o el usuario que lo ejecute) sea malicioso. Es por esto que deberíamos establecer un control de usuarios confiables a través de la distribución de certificados digitales para asegurar la autenticación de los usuarios. Una vez dentro de la nube el uso de SSL/TLS permitirá garantizar la confidencialidad de la comunicación entre las entidades internas.

 Privacidad: la nube debería ofrecernos y soportar el desarrollo de PET( Privacy Enhancing Technologies )

Privacidad: la nube debería ofrecernos y soportar el desarrollo de PET(Privacy Enhancing Technologies) de manera que cualquier información fuera identificable o identificada para el cumplimiento de distintas áreas jurisdiccionales(por ejemplo al pasar información relevante de un país con una ley a otros país donde no existe la misma ley, o bien con información fiscal de un país europeo a un paraíso fiscal) Integridad de datos: dentro de la nube los datos deben mantener su integridad a salvo de posibles transacciones no autorizadas. No existe un estándar concreto para evitar que un atacante dentro de la nube pudiera violar esta integridad, por lo que el usuario debería confiar en el proveedor a través de SLA´s (niveles de garantía contractual) que asegurasen esta característica. Comercialmente se han propuesto varias soluciones a través de huellas HASH que se registran cada vez que se incorpora un archivo a la nube, creando una cadena de custodia que proporcionaría la integridad como un servicio adicional dentro de infraestructura.

Autenticación: son necesarios mecanismos de cifrado para el acceso a los recursos(HMAC- SHA1 en Amazon S3) de la nube así como a las instancias de los sistemas operativos virtualizados. Al igual que un sistema convencional (pero haciendo énfasis en este punto) porque no tenemos control alguno de la configuración ni demás aspectos que se encuentran en la nube. A nuestros ojos podría ser como un hosting compartido tradicional pero detrás existirá una maraña de clusters que proporcionarán las bondades que hemos comentado del Cloud Computing.

Confidencialidad de datos: podríamos pensar que la mejor forma de garantizar este aspecto sería que el proveedor de la infraestructura de la nube cifrara todos los datos que alojara [8] aunque no sería una solución recomendable. Entraríamos en un escenario típico de qué algoritmo usar, quién mantiene las claves,… y con los problemas de disponibilidad que puede provocar cualquier error en el cifrado en el proveedor. Al igual que no tenemos control en muchos aspectos de la nube, el proveedor debería permitir configurar estos mecanismos para asegurarnos que los datos se almacenan seguros sin que sean revelados a terceros. Si fueran cifrados el proveedor debería certificar de alguna manera su esquema interno y ser uditable.

Certificación de proveedores: al igual que existen mecanismos(certificados digitales) para autenticar

a

un

servidor

en

Internet,

el

proveedor podría asegurar el entorno dentro de la nube a través de un certificado análogo expedido por una entidad reconocida externa, que nos asegurara que todas sus políticas de seguridad en la nube son acordes a lo establecido. Uno de los objetivos de la CSA es conseguir este tipo de certificaciones de manera estándar para garantizar el desempeño [3] De

esta manera y con un acuerdo de cumplimiento de servicio (SLA) podríamos tener muy acotados los aspectos de seguridad y disponibilidad.

Aunque no podemos pensar que sea sencillo ya que sistemas Cloud importantes como es la red social Facebook con más de 100 Millones de usuarios y con más de 15.000 servidores dentro de la nube, han sufrido robos de datos de usuarios debido fallos de actualización en sus sistemas internos.

Herramientas y estándares.

Los estándares de seguridad en la nube definen procesos, procedimiento y prácticas para su correcta implantación. En muchos casos incluyen las políticas típicas de sistemas tradicionales pero también añaden aspectos específicos para el entorno de la nube.

El esquema tradicional de capas será aplicable no siendo relevante el tener un único sistema

centralizado de protección,

sino

la

conjunción

de

muchos sistemas que consigan dotar al interior de la

nube de seguridad completa.

SAML

Es

un

lenguaje

basado en XML considerado un

 

estándar

de

comunicación

para

la

autenticación,

autorización así

como

para

el

intercambio

de atributos entre similares en la nube.

SAML estandariza las peticiones y respuestas que

contienen información del usuario para la autenticación así como información de atributos en XML. Este formato puede ser utilizado para pedir información de seguridad a una autoridad SAML, la cual tiene la capacidad de hacer relay (transferir y manejar) con la información de seguridad. Podríamos considerar a esta aplicación o plataforma dentro de la nube, como un validador de partes que tienen que comunicarse e intercambiar atributos. SAML usará http como protocolo de comunicación a través de SOAP.

Open Authenticacion (OAuth)

Es un protocolo abierto que provee de un API muy sencillo de autorización, estandariza diversos métodos para control de accesos en aplicaciones en la Web. Permite publicar e interactuar con datos de acceso protegidos(importación contactos Gmail). Por si mismo no proporciona confidencialidad y dependerá de otros protocolos como SSL para garantizarla.

OpenID

Es un protocolo abierto y descentralizado estándar para autenticar al usuario. Nos permite acceder a muchos servicios utilizando la misma identidad digital a través de un sistema Single-Sign- On(SSO) habilitador del control de acceso. Sustituye el típico acceso de login y password permitiendo a los usuarios loguearse sólo una vez para acceder a distintos servicios de la nube. Este protocolo no se apoya en una autoridad central que autentique la identidad de los usuarios. Permite la autenticación a través de distintos métodos como las smartcards, sistemas biométricos o la típica clave. Tendríamos por una parte el proveedor de identidad y por otra el proveedor del servicio donde accederíamos a distintos recursos. Actualmente tanto Google como Facebook permiten utilizar este protocolo para el control de accesos en sus respectivas nubes.

SSL/TSL

La capa segura a nivel de transporte TLS permite la comunicación cliente- servidor en la red de forma confidencial con la garantía de identificar a las partes (autenticación extremo a extremo), esto se conoce como autenticación mutua asegurada. El primer paso es la negociación del algoritmo que soportan ambas partes (negociación de cifrado), para posteriormente realizar el intercambio de claves así como determinar el algoritmo de autenticación que van a usar (suelen ser de clave pública). Por último tiene lugar la encriptación de cifrado simétrico y el cifrado del mensaje que intercambian las partes. La integridad de estos mensajes se consigue a través de funciones hash.

Trusted Cloud Computing Platform (TCCP)

En el Instituto Aleman Max Planck están llevando a cabo una investigación para asegurar la confidencialidad e integridad de los datos a través de la nube proponiendo un modelo denominado TCCP que proporciona la infraestructura como servicio(IaaS) de manera segura. A continuación vamos a mostrar los principales aspectos de esta plataforma propuesta.

Amazon EC2 provee una infraestructura donde los

clientes

pueden

ejecutar

su

VM

y

realizar

tus

necesidades computacionales en la red. En esta propuesta de diseño utilizan un sistema similar pero abierto y de uso libre para el diseño de la TCCP denominado Eucalyptus[13]. Este provee al usuario de una arquitectura similar a la de Amazon EC2(de hecho en sus últimas versiones proporciona compatibilidad con EC2).

El sistema maneja uno o varios clusters, cuyos

nodos ejecutan un monitor de VM(normalmente XEN) para alojar las VMs de los clientes en coordinación con el Cloud Manager(CM). Desde el punto de vista del usuario Eucalyptus proporciona una interfaz Web para lanzar, manejar y finalizar las virtualizaciones. Las imágenes de las VM(VMIs) se cargan desde el CM y una vez iniciadas el usuario puede acceder a ellas siendo el CM el encargado de gestionar los serviciosde gestión de usuarios sobre las VM.

Comentábamos anteriormente que uno de los riesgos más importantes de la virtualización es que el

monitor de las VM fuera root-secur,e de manera que no pudiera haber ninguna VM que actuara directamente con el sistema computacional. Estas tareas recaen en el administrador del sistema que tiene suficientes privilegios para poder permitir y efectuar ataques de este tipo, ya que puede conectarse en remoto disponiendo de acceso root a todas las VM. Por tanto necesitamos una solución que permita restringir la ejecución privada de cada VM, así como evitar los accesos privilegiados malintencionados del administrador. La propuesta de este grupo de investigación resuelve estos problemas con TCCP.

Por tanto debe ser capaz de:

Limitar la ejecución de las VMs dentro del perímetro IaaS (nodos confiables).

Garantizar en todo momento que un

administrador del sistema con privilegios de root, no puede conectarse en remoto y acceder a la memoria de las VM´s.

Por tanto vamos a pasar a un escenario parecido al anterior pero con componentes que permitan dotar de estas funcionalidades de seguridad.

Tenemos una serie de nodos confiables y el

Coordinador Confiable (TC) que es soportado por una entidad externa de confianza (ETE), el coordinador de la nube (CM) ofrece el conjunto de servicios accesible por los usuarios.

Necesitamos dos componentes principales: el

monitor de VM confiable (Trusted Virtual Machine Monitor) y el coordinador confiable (Trusted Coordinator). Cada nodo correrá un TVMM que alojará las VM´s de los usuarios y que previene que los usuarios privilegiados (administradores del sistema) puedan modificarlas o inspeccionarlas. Todos los nodos tienen incorporado un chip TPM(Trusted Platform Module)[14](que permite la certificación al incorporar una clave privada y ciertas operaciones criptográficas a nivel Hardware, este módulo va firmado con la clave pública del fabricante para garantizar su funcionamiento). El TC maneja la lista de nodos confiables (TN) que pueden ejecutar las VM

invitadas. Para que un nodo sea confiable debe estar dentro del perímetro y ejecutar el TVMM, para ello el TC lleva un registro de los nodos localizados en el perímetro de seguridad del IaaS atestiguando que están ejecutando el monitor confiable (TVMM).

Para asegurar las VMs cada monitor confiable

debe cooperar con el coordinador confiable (TC) para limitar la ejecución de las VM al nodo confiable, así como proteger la maquina virtual de la inspección o modificación de usuarios privilegiados. Se asume que la entidad externa de confianza ETE que alberga el TC esta securizada y actualizada respecto a los datos internos del perímetro del IaaS, por tanto el administrador del perímetro no tiene privilegios en el ETE de manera que solucionamos el problema de intromisión con privilegios. Esta entidad externa debería ser independiente y podría dar servicio a varias nubes IaaS, siendo como un trusted third-party en el caso de la criptografía tradicional.

Vamos a ver el funcionamiento detallado de

este esquema,

a

la

hora de lanzar

una

de

las

VM

alojadas en un nodo del perímetro:

Antes de lanzar la VM el usuario desconoce el nodo físico donde va a ser ejecutada, ni siquiera conoce los componentes del servicio, pero tiene el TC en el que puede confiar. En primer lugar el usuario genera una clave de sesión KVM y envía un mensaje al Cloud Manager que contiene α(petición inicial de la VMI) y (un hash de α), todo ello cifrado con la clave de sesión(para proteger la confidencialidad e integridad del estado inicial) además de enviar la clave de sesión cifrada con la clave pública del TC, por tanto esta entidad será la única que pueda autorizar a alguien al acceso a α, es decir sólo autorizará a nodos confiables.

Una

vez recibida la petición de lanzar la VM, el CM

designa un nodo para ejecutarla en el cluster, como el

nodo

tiene que acceder

a

α para

lanzar la

VM, se

manda un mensaje 2 al TC el cual descifra la clave de

sesión KVM

desde el lado de los nodos. Este mensaje

es cifrado con

la clave pública

de

la

TC para

que

pueda verificar que el nodo

es

confiable, si la clave

pública

no

se encuentra

 

en

el registro

de nodos

confiables

del

TC

la

petición

es denegada.

El

TC

descifra

la clave

de sesión y la manda al nodo en el

mensaje 3 que será

el único que pueda leerla,

por

tanto este nodo N está en disposición ahora de

descifrar alfa y realizar el boot

de la VM.

Al final el

nodo

envía

el mensaje 4 al usuario

que contiene la

identidad

del

nodo

que

correrá

su

VM

también

cifrado

con

la

clave

de

sesión

KVM que

ambos

conocen ya.

Por tanto con esta propuesta tenemos un entorno

confidencial de ejecución para cada VM del IaaS, además permite a los usuarios asegurarse de que el servicio cumple las reglas de seguridad antes de lanzar sus VMs. Actualmente esta investigación avanza hacia la creación de un prototipo funcional basado en el diseño presentado.

Non Repudation Protocol

Aunque algunas

ideas

sobre

los

protocolos

tradicionales de NR son útiles para garantizar este

aspecto

en

el

almacenamiento en la nube

son

óptimas

por

lo que

vamos a

no presentar un área de

investigación

sobre

este

tipo

de

protocolos orientados al Cloud Computing.

La seguridad de los datos en la nube es

uno de los

retos fundamentales para afrontar el modelo de negocio establecido de pago por uso. Esta propuesta presenta un nuevo protocolo de no repudio diseñado específicamente para la nube, servicios como Microsoft Azure Service Platform[15] o Amazon SimpleDB que proporcionan almacenamiento en la nube, puede presentar vulnerabilidades frente a la integridad y al no repudio que podrían ser solventadas con un diseño similar al que proponen desde la Universidad de Binghamton(Nueva York) y Auburn(Alabama).

Existen tres aspectos fundamentales cuando

almacenamos datos en la nube: por un lado la confidencialidad de los mismos (por ejemplo nóminas o historiales médicos) frente al proveedor, por otro su integridad (sobre todo cuando son recuperados de la nube) y por último el no repudio (frente a posibles descargas erróneaspara poder probar la inocencia del proveedor de servicio). Por tanto hay que tener especial cuidado en los dos procesos básicos al subir y recuperar la información.

La integridad de la transmisión puede ser soportada

por SSL,

sin embargo desde el punto de vista de los

usuarios también necesitaremos proteger esos datos en el almacenamiento en la nube.

Vamos a situarnos en un escenario típico en las que

dos partes comparten información a través de la nube. Tenemos a dos trabajadores de la misma empresa: Alice es la Controller que almacena los informes financieros de la empresa en la nube (que la empresa Eve les provee), por otro lado está Bob que es el CTO de la empresa, que descarga esta información de la nube. En este proceso tenemos cuatro aspectos de seguridad fundamentales:

  • 1. Confidencialidad:

aunque

supongamos

que

Eve

no

va

a

indagar

en

los

datos

de

la

empresa es una tercera parte no confiable, Alice y Bob no quieren que esta vea lo datos

que almacenan.

  • 2. Integridad: como Administradores de la nube

Eve puede modificar los datos que almacena Alice. ¿Cómo puede esta seguro Bob de que lo ha descargado de Eve es lo que subió Alice? ¿Cómo se puede garantizar?

  • 3. si Bob encuentra algún fallo o que

Repudio:

 

los datos han sido intervenidos ¿cómo ubicar

la

responsabilidad

en

el

fallo?

¿Qué evidencias pueden aducir Alice o Eve?

  • 4. (Blackmail)

Chantaje

:

el

problema

del

repudio puede abrir vías de chantaje en el

escenario

al

convertirse

 

un

usuario

en malicioso. Por ejemplo Alice almacena

información en la nube y posteriormente la descarga, entonces reporta que los datos han

sido

manipulados

por

un

fallo

en

el

proveedor. Alice pide una compensación por

la

pérdida

de

los

datos.

Eve

necesita

evidencias para demostrar que no fue así.

Como vemos la confidencialidad puede lograrse con

esquemas de cifrado pero la integridad y el repudio,

depende

de

proveer de un sistema

de registro

y

autenticación de las sesiones de subida y descarga de

datos.

La propuesta presentada solventa tanto la integridad en las subida- bajada de datos así como el repudio entre usuarios y proveedores de servicio, a

través

de

un

nuevo

protocolo

de

No

Repudio adaptado a la nuevo.

Los roles que muestran la figura anterior forman parte del nuevo protocolo de NR: el

clientes(Alice/Bob), tercera parte de confianza(TTP) a la cual se acudirá en última instancia. Suponemos que ningún actor va a actuar en contra de sus propios intereses (no maliciosos).

En cada transmisión de datos el emisor debe añadir como extra una evidencia para propugnar el no-

repudio,

por

tanto

del

lado

de

Alice

la

denominaremos NRO (de origen) y por el lado de Bob NRR (de recepción), para asegurar la confidencialidad, el emisor firma sus datos con la clave pública del receptor. Para evitar ataques de repetición se añade un número aleatorio y un número de secuencia (el cual se incrementa de uno en uno), además se incluye una etiqueta con el ID(en texto plano) del siguiente mensaje(emisor, receptor o TTP). La evidencia consistirá en el resultado del hash de estos IDs y la huella de los datos.

Encrypt{Sign(HashofData), Sign(Plaintext)}

Para lograr el no-repudio se requiere que el emisor

firme el hash con su clave privada, después de que una transacción se complete Alice obtendrá su NRR de Bob y este recibirá su NRO de Alice, pudiendo ambos comprobar la consistencia entre la huella del ID(texto plano) y el texto plano inicial.

Por tanto este protocolo aprovecha las ventajas de la comprobación de integridad de los datos firmados en la evidencia, siendo posible no sólo facilitar la detección del manipulado de los mismos sino también la no negación del emisor de un actividad gracias a su firma digital, mientras que cifrando con la clave pública del receptor, la evidencia garantiza la consistencia de la huella con el texto plano enviado con las IDs.

Privacidad de los datos.

Los datos residen en sistemas tecnológicos que se encuentran fuera del alcance del firewall de la empresa. Por este motivo, existe una gran reticencia al uso de la tecnología cloud en las empresas privadas y organizaciones públicas, en los sistemas de la entidad que contienen información crítica para la misma.

La seguridad y privacidad de la información que se traslada a la nube es uno de los aspectos más importantes para las compañías. Es evidente que los servicios de cloud computing prestados por el proveedor, implican un determinado nivel de confianza por parte de los contratantes del servicio en dichos proveedores, ya que se delega en un operador externo todas las acciones y la responsabilidad de la información de los datos corporativos y su control y gobierno. Además, dependiendo de la naturaleza de los procesos y datos externalizados, la casuística es aún más compleja al condicionarse la contratación y operación por el marco de la Ley Orgánica de Protección de Datos.

La LOPD y su reglamento de desarrollo33 establecen una serie de medidas de seguridad, técnicas y organizativas, a la hora de tratar datos de carácter personal. Se regulan aspectos de aplicación como la transferencia internacional de datos, subcontratación, atención de derechos ARCO (derecho de acceso, rectificación, cancelación u oposición sobre los datos de carácter personal), etc. Resulta especialmente interesante para el sector las disposiciones relativas al cumplimiento de la Ley en la transferencia internacional de datos.

Además de la LOPD, existe otras dos normas de gran importancia en el entorno del cloud computing: LSSI (Ley 34/2002 de 11 de julio de Servicios de la Sociedad de Información y de Comercio Electrónico) y SOX (Ley Sarbanes Oxley de 2002). La primera, de origen español, tiene por objetivo la regulación del régimen jurídico de los servicios de la Sociedad de la Información y de la contratación por vía electrónica, en lo referente a: obligaciones de los prestadores de servicios en la transmisión de contenidos por las redes de telecomunicaciones, comunicaciones comerciales por vía electrónica, información previa y posterior a la celebración de contratos electrónicos, condiciones relativas a su validez y eficacia, y régimen sancionador aplicable a los prestadores de servicios de la Sociedad de la Información.

Por su parte, la Ley SOX, nace en Estados Unidos con el objetivo de generar un marco de transparencia para las actividades y reportes financieros de las compañías que cotizan en bolsa, lo que le aporta más confianza y mayor certidumbre a los accionistas y al propio Estado. Esta norma, incluye la generación de controles del riesgo que afectan directamente a los Sistemas de Información, y que deben de mantenerse en un escenario de cloud computing.

Así, todo contexto contractual entre el suscriptor y el proveedor debe contextualizarse en un marco de confianza fundamentado en el cumplimiento de estándares y políticas de seguridad por parte de ambas partes.

El proveedor de servicios cloud debe garantizar el cumplimiento de los procesos y técnicas exigidas y

El proveedor de servicios cloud debe garantizar el cumplimiento de los procesos y técnicas exigidas y certificadas por dichos estándares, mientras que el suscriptor debe aplicar una política adecuada de control y gestión del riesgo tecnológico.

Dentro de esta política de control y gestión del riesgo tecnológico, y previamente a la adopción de modelos de computación en la nube en una organización, es necesario realizar un estudio de la implementación, donde se tengan en cuenta aspectos de seguridad y continuidad de negocio. El cumplimiento normativo será uno de los factores clave a la hora de llevar a cabo dicho estudio de implementación.

Como paso inicial, es necesario identificar la normativa aplicable. Para ello, es imprescindible analizar factores como los siguientes:

Información que se desea llevar a la nube.

92

Sector de la compañía.

Familia de servicio que se desea contratar (SaaS, PaaS, IaaS, BPaaS).

Criticidad del proceso de negocio que soportará la nube.

En función de los requisitos establecidos por las diferentes normativas que sean de aplicación, se elaborarán los requisitos normativos, con los que se validará si un determinado proveedor puede considerarse como una alternativa válida para ofrecer el servicio deseado.

El cliente, como responsable de los datos, tiene la obligación de exigir que el proveedor de servicios establezca todas las medidas de seguridad, técnicas y organizativas, que requiere la LOPD y su reglamento.

Se mantiene así la responsabilidad del cliente sobre la seguridad de los datos. En este sentido, la externalización, lejos de evitar problemas por delegar la seguridad de los datos en un tercero, introduce un riesgo de cumplimiento para el responsable de los datos, quedando a expensas del buen hacer del proveedor.

Adicionalmente a los requisitos normativos y al riesgo de cumplimiento, la propia organización deberá analizar qué requisitos de seguridad considera necesario aplicar.

Los requisitos de seguridad deben estar acordes con:

La política de seguridad de la compañía.

El nivel de seguridad requerido en función del tipo de información.

Los requerimientos de la compañía en cuanto a la disponibilidad del servicio.

El proceso de negocio al que vaya a dar soporte el servicio.

Disponibilidad del sistema y tiempos de recuperación.

Gestión y comunicación de incidentes de seguridad.

Borrado seguro.

Exportación de los datos almacenados.

Una vez analizado el nivel de cumplimiento de los requisitos normativos y de seguridad por parte del proveedor, la compañía debe ser consciente de que el carácter externalizado y las particularidades del modelo de computación en la nube supondrán en todo caso una serie de riesgos de seguridad.

Los riesgos de seguridad deberán ser analizados por negocio y asumidos por el máximo responsable del proceso de negocio al que se vaya a dar soporte. Por ello, se deben requerir explícitamente por contrato las medidas de seguridad a implementar.

Algunas de estas medidas son:

Documento de seguridad.

Copias de respaldo y procedimientos de restauración de datos.

Control de acceso.

Identificación y autenticación.

Gestión de incidencias.

Gestión de soportes de almacenamiento.

Comunicación cifrada de la información.

Registro de accesos a datos de nivel alto.

A continuación, se muestran algunos ejemplos de riesgos de seguridad que podrían ser de aplicación ante una eventual contratación de servicio de cloud computing:

Fuga de información provocada por ataques a la plataforma.

Incapacidad de migración de los datos ante la finalización del servicio.

Borrado no seguro de la información.

Incidencias/incidentes no comunicadas.

Pérdida de disponibilidad de la información y/o del servicio.

Pérdida de información por fallo del proveedor.

Dependencia del proveedor.

Existe una gran preocupación entre las entidades contratantes acerca de si los proveedores ofrecen la suficiente agilidad y privacidad, en un posible cambio de proveedor del servicio de la solución cloud. Uno de los principales factores en este sentido es la creación y adopción de estándares que faciliten el traspaso de información y procesos de un proveedor a otro, como se ha desarrollado de forma previa en el apartado estandarización e integración tecnológica.

Amortización tecnológica.

Las empresas y organizaciones públicas han invertido muchos recursos durante las últimas décadas en implementar procesos de modernización tecnológica e inversión en infraestructuras y personal para el área de TI. La utilización del cloud puede generar ciertas dudas para los directores de áreas de sistemas que todavía cuentan con activos tecnológicos no amortizados y que han logrado configurar un equipo de trabajo estable y cualificado para

su administración. Aunque es indudable que cloud puede generar un punto de ruptura en las estrategias de sistemas ya establecidas, su adopción debe ser considerada como algo progresivo, planificado y sostenible, estableciendo procesos de migración paulatinos y controlables que permitan garantizar la adecuada amortización y sustitución de los activos actuales y reorientar al personal de TI hacia líneas de trabajo de valor para el departamento.

Restricciónes geográficas.

Los servicios de cloud pueden ser proporcionados a través de geografías diferentes. Por ello, las entidades públicas y privadas deben ser conscientes de situaciones excepcionales relativas a la ubicación física, tales como leyes y regulaciones locales, que puedan afectar en temas de privacidad, seguridad y protección de datos de carácter personal y confidencial.

Por ejemplo, las leyes europeas referentes a la privacidad requieren de información personal de ciudadanos de la Unión Europea, información almacenada por la propia Unión Europea en sus sistemas. Para cumplir con este requisito, las organizaciones que vayan a adoptar un modelo de nube pública deben optar por aquel en el que puedan determinar explícitamente, y dentro de las directrices generales impuestas por la Unión Europea, la ubicación física de sus recursos.

Por el contrario, en algunos países como Estados Unidos, las leyes no consideran datos privados la dirección personal o el número telefónico, por ejemplo. Es por este motivo por el que los analistas prevén una adopción de la nube más lenta y menos profunda en los países europeos. También prevén que el porcentaje en el mercado y en las cifras de negocio será pequeño en comparación con la importancia de Europa como potencia industrializada.

Módelos de selección.

Una vez revisados el concepto, las características y los tipos existentes de cloud computing; así como tras haber identificado las ventajas y retos del uso de las soluciones cloud para los distintos públicos objetivo; se procede ahora a exponer el modelo de selección de procesos a trasladar a la nube. El modelo de selección en sí está relacionado con una serie de factores relevantes que deberán ser tenidos en cuenta durante las distintas fases de dicho modelo. En función de los resultados arrojados del análisis de los parámetros de cada fase para las especificidades propias de la empresa se logrará obtener una serie de recomendaciones y una hoja de ruta que marquen cómo implementar las soluciones cloud que aporten valor a la entidad.

Las distintas fases del modelo de selección se exponen en el gráfico siguiente:

Módelos de selección. Una vez revisados el concepto, las características y los tipos existentes de cloud

96

Fase 1: Análisis y evolución de la situación actual.

El primer paso para la selección de los procesos a trasladar a la nube es analizar los sistemas y aplicaciones, cuya gestión se desea externalizar mediante la contratación de una solución de cloud computing.

Para identificar si existen servicios basados en la tecnología cloud en el mercado, que se ajusten a los procesos específicos desarrollados en la propia empresa se puede utilizar el árbol de decisión40 siguiente constituido por diez preguntas fundamentales:

Fase 1: Análisis y evolución de la situación actual. El primer paso para la selección de

1- ¿Modelo de negocio vertical?

Esta pregunta permite comprobar si existen o no interdependencias entre los distintos procesos del negocio, plataformas, aplicaciones y capas de la infraestructura existentes en la propia organización.

En caso afirmativo el modelo de negocio es vertical. El objetivo de la próxima decisión consistirá en determinar qué pila de capas de solución41 deben ser subcontratadas, y para cuáles de ellas se debe considerar la implementación de soluciones cloud. (Ir a la pregunta 2).

En caso negativo el modelo de negocio es horizontal. En la próxima decisión a tomar será necesario determinar qué cantidad de cada capa afectada deberá ser externalizada o interconectada con otras capas internas, y para cuales de esos casos habrá que tener en cuenta las soluciones cloud ofertadas en el mercado. (Ir a la pregunta 3).

2- ¿Existen procesos de diferenciación?

Con esta pregunta se puede identificar si los procesos de negocio de la empresa aportan diferenciación dentro de su propio sector de actividad. Se determina si los aspectos clave de

97

los procesos de negocio y el rendimiento de éste son críticos para la competitividad y la rentabilidad de la empresa.

En caso afirmativo existen procesos de diferenciación que suponen una ventaja competitiva. El objetivo de la próxima decisión se centrará en impedir a la competencia la adopción de los procesos clave que proporcionan la ventaja competitiva a la empresa teniendo en cuenta el grado de interdependencia entre la aplicación y los posibles cambios en el proceso del negocio. (Ir a la pregunta 7).

En caso negativo no existen procesos de diferenciación por lo que se habrán de mantener las inversiones al mínimo requerido, mientras se plantea la reestructuración de los procesos de negocio en busca de un mayor beneficio para la empresa. (Ir a la pregunta 3).

3- ¿Existen obstáculos a la externalización?

Este punto resulta de utilidad para identificar si existen barreras o riesgos específicos asociados a la localización geográfica o a cuestiones de índole legal que pudieran impedir que alguna o todas las capas del proceso de habilitación sean externalizadas.

En caso afirmativo la implementación de un cloud público no podrá resultar una solución viable hasta que se gestionen y superen los obstáculos. Se deberá analizar si la opción de una solución cloud de familia PaaS alojada dentro de una nube privada, se ajusta a las funcionalidades específicas de los procesos de la empresa susceptibles de ser externalizados; resultando en dicho caso ser una buena alternativa a la tecnología tradicional de la empresa. (Ir a la pregunta 6). En caso negativo no existen barreras que puedan impedir la implementación de una completa externalización. No obstante se evitará implementar un cloud público o cualquier otra forma de integración y de explotación de cloud hasta que no sean afrontados y superados los impedimentos, barreras o condicionantes existentes. (Ir a la pregunta 4).

4- ¿Existen obstáculos a la adopción de soluciones cloud?

Con esta pregunta se identifica si el servicio prestado por la empresa presenta algún tipo de barrera u obstáculos para la adopción del cloud, principalmente derivadas de la migración del mismo a un entorno en la nube, que puedan ser perjudiciales para los principales ejes de actuación del proceso de negocio o para la consecución de los objetivos de retornos de inversión (ROI).

En caso afirmativo existen uno o varios obstáculos a la adopción del cloud. En esta situación cualquier solución de tipo cloud resultará inadecuada hasta que los obstáculos o impedimentos referidos sean gestionados correctamente y superados. En el próximo paso, la empresa, se replanteará de nuevo si el cloud beneficia a los principales ejes de actuación del negocio evitando en todo caso la implementación de cualquier forma de integración y explotación del cloud y/o familia sin haber gestionado y superado todos y cada uno de los obstáculos planteados para su adopción. (Ir a la pregunta 5).

En caso negativo, se consigue confirmar que no existe ningún impedimento desde la propia organización a la adopción de soluciones cloud. (Ir a la pregunta 5).

5- ¿Es el cloud computing compatible con el principal impulsor del negocio?

Con esta pregunta se analiza si las fortalezas de la tecnología cloud están en línea siendo compatibles con los requerimientos del principal impulsor de negocio de la entidad. En caso afirmativo los principales puntos fuertes del cloud se alinean plenamente con los objetivos del negocio. La tecnología cloud es una buena alternativa para la empresa, debiéndose realizar una valoración del mercado para identificar aquella opción que mejor se ajuste a los requerimientos propios.

En caso negativo los principales puntos fuertes del cloud no coinciden con los objetivos del negocio de la entidad. La tecnología cloud no es la opción más idónea para la empresa, debiéndose plantear la entidad otras alternativas como pueden ser la subcontratación o la externalización, con el uso de tecnologías tradicionales.

6- ¿Va a ser la solución una plataforma (Paas)?

El objetivo consiste en transformar la pila de capas de solución (citadas en pregunta 1) y las capas del proceso de negocio en un estándar, que dote de interoperabilidad a todos los servicios TI de la empresa.

En caso afirmativo la plataforma TI estará configurada por las siguientes capas de solución:

middleware, hardware y sistema operativo. También podría incluirse la infraestructura del centro de datos. El siguiente paso consiste en analizar el escenario más adecuado a fin de implementar una solución cloud de tipo PaaS idónea. (Ir a la pregunta 4).

En caso negativo la plataforma TI estará configurada por las siguientes capas de solución:

soluciones horizontales de hardware y software , las cuales pueden incluir la opción de pools de almacenamiento o ―granjas‖ de servidores e infraestructura bajo demanda. En este caso la tecnología cloud no representa la mejor opción para la entidad en particular debiéndose analizar alternativas como pueden ser la virtualización, la adquisición de equipos para funciones específicas, o la subcontratación y externalización de tareas.

7- ¿Está la aplicación aislada de los cambios en los procesos de negocio?

En este punto se analiza si se puede personalizar la arquitectura de procesos de negocio sin que impacte en la configuración subyacente de la aplicación estándarque la soporta y a su gestión compartida de TI. Si el proceso de negocio está aislado, el servicio de nivel TI puede ser en cierta manera independiente del proceso de negocio.

En caso afirmativo la aplicación está aislada de los cambios. El proceso de negocio está abstraído de la aplicación operativa hasta tal punto que cualquier persona con conocimientos del proceso de negocio que no cuente con el suficiente conocimiento de la aplicación puede alterar el mismo sin causar un impacto significativo en la gestión o eficiencia de la aplicación referida. El próximo paso consistirá en plantearse si la tecnología TI es un factor clave de diferenciación para el proceso del negocio. (Ir a la pregunta 8).

En caso negativo el proceso de negocio no está abstraído de la aplicación a nivel operativo por lo que cualquier cambio en el proceso del negocio implicará cambios en la aplicación para poder adaptar esta a los nuevos requerimientos del negocio. Se evitará la adopción de soluciones cloud.

8- ¿Está la diferenciación basada en la tecnología TI?

Con esta cuestión se determina la importancia de los recursos de TI dentro de los distintos procesos de negocio.

En caso afirmativo la tecnología TI es parte integral de la diferenciación. El siguiente paso consiste en mejorar el desarrollo e implementación de la tecnología TI existente sin revelar el contenido o estructura que permita a los competidores su replicación. (Ir a la pregunta 9).

En caso negativo, la externalización de cualquier proceso que tenga afección al negocio no resulta recomendable. (Ir a la pregunta 3).

9- ¿Están el hardware, el sistema operativo y la aplicación, hechos a medida para la organización?

Si las capas de solución compuesta por el hardware y el sistema operativo y las capas de la aplicación están realizadas a medida para la empresa el cloud no constituye una solución adecuada para la empresa.

En caso afirmativo la siguiente decisión a adoptar por parte de la entidad consistiría en considerar otra opción.

En caso negativo, caso de que el nivel de hardware y software y/o el de la aplicación, sean estándar, habrá que identificar la capa estándar de la tecnología IT de que se trate, buscando aquella solución cloud comercial que más se aproxime al mismo. (Ir a pregunta 10).

10- ¿Están el hardware y el sistema operativo hechos a medida para la organización?

Se persigue identificar que capa de la tecnología IT está estandarizada y que pueda ser considerada como una potencial candidata para su empleo en una solución cloud.

En caso afirmativo, es decir, cuando el hardware o el sistema operativo están hechos a medida (no estándar), la siguiente decisión pasa por considerar que tanto el cloud como la mayor parte de las alternativas y modelos de externalización no son adecuados para la implementación dentro de la entidad. Para tal fin habrá que reevaluar los requerimientos necesarios para la implementación de hardware y/sistema operativo hecho a la medida de las necesidades de la empresa.

En caso negativo, tanto el hardware como el sistema operativo (salvo la aplicación) presentan una configuración típica. El próximo paso consiste en descartar el uso de soluciones cloud para la capa de aplicación. (Ir a la pregunta 3).

La fase de identificación de procesos susceptibles de ser migrados a la nube corresponde a una tarea interna de la propia entidad por lo que para realizarla desde la empresa se fijarán los procesos que se desean externalizar, analizando su operativa para determinar los sistemas y aplicaciones que los soportan, y elaborando la documentación pertinente.

Está documentación deberá ser revisada y contrastada por los responsables técnicos del sistema o aplicación en cuestión, de cara a disponer de todos los requisitos técnicos necesarios para poder realizar las migraciones.

Con estos datos se dispondrá de la información y documentación asociada necesaria, para poder establecer todos los requisitos técnicos y funcionales a los que se deberán ajustar los proveedores en las ofertas presentadas.

Fase 2: Valoración de mercado.

Fijados los requisitos técnicos y funcionales de la futura migración, será necesario identificar la forma de implementación que más se ajuste a dichos requerimientos. Para ello, se habrán de evaluar una serie de factores externos a la empresa y característicos del mercado, que podrían afectar a la elección de la forma de implementación idónea para la empresa, así como a la elección del proveedor de servicios en la nube.

Entre estos factores externos a tener en cuenta dentro de esta fase de valoración de mercado se encontrarían el ámbito de la solución cloud y la previsión de crecimiento del mercado por tipo de solución cloud.

Tipología de la solución cloud

En primer lugar, con el objetivo de maximizar el conocimiento en la entidad sobre la tecnología cloud computing, y sobre los productos y servicios en la nube disponibles para una posible implementación en la empresa; la entidad en cuestión podría obtener una visión global de las distintas soluciones cloud existentes en el mercado, clasificándolas tanto por familia como por forma de implementación.

Para obtener esta visión global, la organización podría hacer uso por ejemplo, de un gráfico como el mostrado a continuación, donde se reflejan las posibles soluciones cloud existentes en el mercado y su nivel de compartición de recursos, en función del componente de la empresa donde se vaya a implementar: infraestructura, capas intermedias, aplicaciones e información o procesos de la organización.

Se entiende que el valor para el negocio aumenta a medida que a la infraestructura se le añade conocimiento de las aplicaciones, procesos e información propia de la organización.

Dentro de esta clasificación global de cloud computing , se habrá de localizar el ámbito de

Dentro de esta clasificación global de cloud computing, se habrá de localizar el ámbito de soluciones comerciales cuyas características más se ajustan a los requerimientos del proceso a migrar a la tecnología cloud.

Para ello, habrán de detallarse las características asociadas a cada uno de los tipos de soluciones cloud, candidatos a contener la solución final adoptada; analizando detenidamente las distintas ventajas y aspectos a mejorar asociadas a los mismos.

Procesos cubiertos por las soluciones

Otro punto importante será la comprobación de las funciones y procesos que se cubren con las actuales soluciones de cloud público, privado o híbrido existentes en el mercado. A continuación se enumeran las cargas de trabajo, sistemas, servicios, entornos y soluciones que están listos para ser trasladados a la nube y los que podrían no estarlo, en función de la solución escogida.

Aspectos de la operativa diaria listos para ser trasladados a la nube:

o

Cargas de trabajo de aplicación virtual sencilla.

o

Sistemas de prueba y pre-producción.

o

Servicios maduros como el correo electrónico, CRM y ERP.

102

o

Entornos de desarrollo de software.

o

Procesamiento por lotes con requisitos de seguridad limitada.

o

Cargas de trabajo aisladas, donde no es un problema la latencia entre componentes.

o

Almacenamiento como servicio (Storage as a Service).

o

Soluciones de copia de seguridad (Backup Service) y de restablecimiento de la operatividad tras posibles fallos de los sistemas (Restore as a Service).

Aspectos de la operativa diaria que podrían no estar listos para ser trasladados a la nube:

o

Cargas de trabajo que dependen de datos sensibles (información de empleados, de clientes, de otras empresas).

o

Cargas integradas por múltiples servicios interdependientes (como por ejemplo el procesamiento de transacciones en línea de alto rendimiento).

o

Cargas con requerimientos de una alta capacidad de auditoría y disponibilidad de datos.

o

Software de terceros que no permitan una estrategia de licenciamiento en cloud o virtualizada.

o

Cargas que requieren medida de utilización y cargo detallado (como pueden ser por ejemplo las de planificación y facturación departamental).

o

Cargas que requieran alto grado de personalización.

Previsión de crecimiento del mercado de cloud computing

Una vez detalladas las características relativas a cada posible tipo de solución cloud a implementar, el siguiente paso será el de evaluar su situación actual y la previsión de desarrollo futuro para cada uno de los tipos de soluciones cloud candidatos a ser implementados.

Este factor puede resultar de gran utilidad para las entidades que se planteen la adopción de la tecnología cloud computing, ya que la contratación de soluciones cuya previsión de crecimiento sea alta, posibilitará un mayor margen de evolución a corto plazo de la capacidad y las funcionalidades asociadas a dicho producto o servicio en la nube.

A continuación se muestran ejemplos de gráficas de evolución económica esperada, para las distintas soluciones de cloud privado, público e híbrido.

104
104

104

Otros parámetros Finalmente, dentro de la fase de valoración del mercado resultará necesario caracterizar el mercado

Otros parámetros

Finalmente, dentro de la fase de valoración del mercado resultará necesario caracterizar el mercado por nivel calidad de la solución, infraestructuras asociadas a cada solución, satisfacción con el proveedor, etc.

105

Fase 3: Recomendaciones

La siguiente fase del modelo de selección corresponde a recomendaciones. En esta etapa se agrupará la información y documentación propia recopilada durante la primera fase del modelo con la valoración del mercado llevada a cabo durante la segunda fase del proyecto.

De esta manera se relacionarán los requisitos propios de los procesos a migrar a la nube con las funcionalidades existentes en el mercado, evaluando las distintas soluciones según los parámetros definidos previamente, y elaborando las recomendaciones que servirán como base para la definición de la hoja de ruta de la migración a la tecnología cloud computing.

Entre los parámetros de utilidad para la empresa contratante, podemos citar los detallados a continuación:

Alineación de solución y procesos

Este parámetro relaciona las funcionalidades y servicios ofertados por las distintas soluciones cloud en el mercado, con los requerimientos propios o necesidades de la empresa u organización pública contratante valorando la compatibilidad y el alineamiento entre ambos.

Seguridad y privacidad

Este factor, de gran importancia para los suscriptores, relaciona los aspectos que desde la empresa se quieren tener en cuenta en el tratamiento de los datos corporativos de carácter privado, con los requisitos de seguridad y privacidad dados por la solución cloud evaluada.

Para los sistemas y aplicaciones “core” de la empresa, cuyas funcionalidades estén orientadas a cubrir las necesidades de negocio, la opción a elegir por motivos de seguridad y privacidad de los datos suele ser la de una nube privada, o en su defecto la de una nube híbrida.

Sin embargo para los sistemas y aplicaciones cuya funcionalidad esté destinada a la gestión de procesos menos críticos de la empresa, la opción preferente es la elección de una nube pública, ya que la ampliación de recursos en las mismas resulta más sencilla.

Ventajas frente a retos

Este indicador particulariza las ventajas y retos asociados a cada tipo de solución cloud computing ofertada por los proveedores, en el tipo de procesos y funcionalidades que desde la entidad se quieran trasladar a la nube; consiguiendo con ello obtener una balanza de ventajas y desventajas específicas para la empresa en cuestión, de gran utilidad para la elección de aquella solución cloud que aporte un mayor beneficio a la organización.

Retorno económico y productivo También se tendrá en cuenta un factor adicional, el retorno económico y

Retorno económico y productivo

También se tendrá en cuenta un factor adicional, el retorno económico y productivo que será de gran importancia para estimar el impacto que tendrá la migración en términos de eficiencia y rentabilidad. Para calcularlo, es necesario identificar una serie de puntos de control de coste claves en la empresa en cuestión, donde, gracias a la migración a un modelo basado en cloud computing, se pueda producir una reducción de dichos costes.

Una vez identificados estos puntos clave, se fijarán una serie de indicadores para cada uno de ellos, se recopilarán los datos necesarios y se calculará el coste actual de dichos puntos, confrontándolo con los costes y beneficios esperados tras la adopción de la solución de cloud computing.

Entre los posibles indicadores a definir, relevantes para la empresa a la hora de evaluar los costes asociados a los puntos clave identificados se podrían encontrar el Retorno de la Inversión (ROI), los Gastos de Capital (CAPEX) y los Gastos Operacionales (OPEX), entre otros.

La representación de uno de dichos parámetros se introduce como ejemplo en la siguiente gráfica, en la que se compara la evolución del retorno de la inversión esperada (ROI) entre una

107

solución cloud y una solución on-premise (tradicional), para el caso particular de una entidad y solución cloud cualquiera.

solución cloud y una solución on-premise (tradicional), para el caso particular de una entidad y solución

Además del ROI, también será necesaria en todo proceso de selección, la confrontación, dentro del factor económico y productivo de los tipos de gastos. Se deberán analizar los gastos de capital (CAPEX, se refieren al costo de desarrollar o proporcionar partes no consumibles para un producto o sistema como por ejemplo la infraestructura de un centro de procesamiento de datos) y los gastos operacionales (OPEX, los costes continuos para mantener un producto, negocio o sistema, como por ejemplo el pago de licencias), entre la solución cloud y la solución on-premise (tradicional). Respecto a los gastos de capital y operacionales asociados al cloud computing, y al retorno de

la inversión mostrado en la gráfica anterior, se pueden sacar las siguientes conclusiones:

Con una solución cloud, la reducción de los gastos de capital (CAPEX) se trasfiere a los gastos operacionales (OPEX), ya que las inversiones de hardware y software no son necesarias.

La solución cloud asegura un rápido y mayor retorno esperado (Payback47 y ROI), ya que la inversión inicial es inferior y el despliegue es más rápido que en la solución on- premise.

Tiempo de adopción de la solución cloud

Otro aspecto importante a tener en cuenta será el tiempo necesario para la adopción de las diferentes soluciones en el tiempo. Dicho parámetro se muestra en el siguiente gráfico:

108

La adopción del cloud computing en las empresas y organizaciones públicas es un proceso evolutivo en

La adopción del cloud computing en las empresas y organizaciones públicas es un proceso evolutivo en el tiempo, yendo desde el conocimiento de las nociones básicas acerca de este tipo de soluciones, pasando por la implementación de las soluciones más sencillas, como resulta ser la PaaS; una progresiva implementación de servicios más completos, con las soluciones IaaS y SaaS; hasta la institucionalización del cloud computing en la empresa y su posterior internacionalización, objetivo a conseguir por las empresas para un mayor crecimiento y expansión dentro de su sector de actividad.

Fase 4: Definición de la hoja de ruta

Tras haber relacionado la situación actual y expectativas futuras de la empresa respecto a la tecnología cloud, con las distintas funcionalidades asociadas a cada solución existente en el mercado, se emitieron durante la fase anterior una serie de recomendaciones a seguir, para llevar a cabo la elección de la opción que mejor se ajuste a la operativa específica de la empresa. Con estas recomendaciones, se procede en esta fase a elaborar una hoja de ruta o plan de acción. En primer lugar, se enumeran todas las acciones a acometer para llevar a cabo la completa implementación de la solución cloud.

Posteriormente se agrupan estas acciones en una serie de proyectos a realizar, se interrelacionan entre sí, y se detalla cada uno de ellos. En este detalle se describirá el objetivo de cada uno de los proyectos, su prioridad, sus dependencias respecto a otras acciones a acometer, la necesidad de recursos que va a implicar su realización, los procesos y sistemas de la empresa que se van a ver afectados por el proyecto, las principales actividades a acometer durante el proyecto, y la métrica establecida para su control y seguimiento.

Una vez detallados los distintos proyectos, se trazará una hoja de ruta donde se marquen los plazos temporales de cada uno de dichos proyectos, los posibles desarrollos de proyectos de forma simultánea, así como los hitos o puntos de control de cumplimiento de la planificación estimada.

Como ejemplo ilustrativo, se muestra en el gráfico inferior el caso particular de una hoja de ruta para la implementación de una solución cloud en una empresa:

Descripción de los tipos de soluciones cloud en el mercado El mercado de proveedores de soluciones

Descripción de los tipos de soluciones cloud en el mercado

El mercado de proveedores de soluciones de cloud computing se puede estructurar por tipo de familia cloud, tal y como se vio en apartados anteriores. Por ello, se exponen a continuación los diferentes tipos de soluciones presentes actualmente en el mercado, para cada familia cloud:

PaaS

Los tipos de soluciones incluidos dentro del servicio PaaS, junto con una descripción de cada uno de ellos, se indican a continuación en base a datos de Forrester y Gartner.

110

111
112

SaaS

En cuanto a las soluciones ofertadas por los proveedores de soluciones cloud de Software as a Service, la clasificación y descripción de los mismos por tipo de solución SaaS quedaría como se muestra en la tabla inferior, obtenida a partir de los datos de Gartner.

SaaS En cuanto a las soluciones ofertadas por los proveedores de soluciones cloud de Software as
114
114
115

IaaS

Clasificando ahora las soluciones IaaS ofertadas por los proveedores, según los distintos tipos de soluciones cloud de infraestructura como servicio, obtenemos la siguiente tabla:

IaaS Clasificando ahora las soluciones IaaS ofertadas por los proveedores, según los distintos tipos de soluciones

Referencias y bibliografía.

NIST(National Institute of Standards and Technology). http://www.nist.gov NIST Cloud Computing Standards Roadmap, NIST. (