¿Ayudan las APIs abiertas a la evolución de la tecnología e infraestructura?

Yo creo que si...

El pasado 21 de Noviembre, puede tener el placer de ser invitado y poder asistir como ponente en el importante evento API FORUM, dentro del conjunto de eventos y jornadas que organiza IKN a lo largo del año.

En esta ocasión tan particular, el desafió para mi fue bastante relevante, debido as su vez a la calidad y al numero de ponentes como podéis ver en la agenda del mismo:

Desde el primer momento que me hicieron la propuesta, mi idea inicial fue tratar de explicar y de argumentar de un modo lo mas sencillo y lo mas practico posible, el hecho por el cual las APIs, y en particular, las APIs abiertas, mas allá de lo que puede resultar  evidente, representan y/o pueden representar una importante ventaja en lo que se refiere a la renovación y a la evolución de las infraestructuras y las tecnologías de la infraestructura, tanto a nivel de Software, como a nivel de Hardware,

La sesión pivota sobre dos ideas troncales o principales, mas allá de lo que permiten las APIs abiertas (funcionalidades, aspectos técnicos, cumplimiento normativo, etc...) y de sus capacidades, independientemente de los distintos productos y servicios  que hay en el mercado y en la industria del sector TIC para ello. 

La primera radica en la importante consideración acerca de la diferencia de accesos y de usos que hay en la actualidad, en el borde exterior y en el borde interior, de la IT de las organizaciones y de su compatibilidad con las arquitecturas Web y arquitecturas SOA mas tradicionales.

La segunda reside en el hecho de aprovechar esas nuevas capacidades, tanto para publicar Web Services (servicios de negocio) de nuestras aplicaciones existentes, de forma controlada y de forma segura, al mismo tiempo que, del mismo modo, como para consumir servicios de aplicaciones (SaaS) y servicios de plataforma (PaaS) por parte de nuestras aplicaciones existentes, evolucionando nuestra instalación hacia la nube híbrida y potenciando una trasformación de las aplicaciones hacia modelos Cloud-Native mas basados en microservicios.

De nuevo, muchas gracias al API FORUM y a IKN, por darme la oportunidad de poder contarlo,

Para los que no pudisteis asistir, dejo aquí la presentación que utilice para apoyarme en ella durante la sesión que pude impartir:

Cómo aumentar el ciclo de vida de las infraestructuras con APIS abiertas from Victor M. Fernández

Espero que os sea de interés a todos y sobre todo, que os resulte útil ;-)

El porque de la trasformacion de la Organizacion IT !!!

Mucho se habla en el mercado y en la industria de las TIC acerca de como el Cloud Computing va a cambiar o esta ya cambiando las reglas del juego habituales que todos conocíamos. Lo cierto es que tanto fabricantes de tecnología (los de siempre ó los nuevos players) como integradores todos arriman el "ascua a su sardina",  lo cual no deja de ser predecible aunque no por ello bastante interesado y por ello, conocido.

Poniendo como referencia cualquiera de los 3 modelos de entrega de Servicios IT basados en Cloud Computing: IaaS (Infraestructura como Servicio), PaaS (Plataforma como Servicio) y SaaS (Software como servicio), bajo cualquier de las 3 tipologías mas conocidas, ya sea nube privada, nube publica (quizás la mas conocida) y nube híbrida (quizás la de mayor potencial); me gustaría compartir mi punto de vista acerca de los cambios que o se están produciendo o se van a producir en las Organizaciones IT promovidas indirectamente por el Cloud Computing o de forma directa por la denominada Tercera Plataforma (Cloud Computing, Big Data, Movilidad y Social Media) en lo mas extenso del termino conocido como Movilidad (BYOD, IoT, Wearables, Insideables, APIs, Pagos con Moviles (NFC), Diseño Adaptativo & Responsivo, etc...).

Creo que estos cambios tienen diferentes aspectos a gestionar y gobernar en el propio seno de la Organizacion IT:

1- Cambios en las tecnologías de la infraestructura (tanto en su implantación como en su mantenimiento)

• Convergencia en las redes
• Redes de datos LAN y redes de almacenamiento SAN
• Convergencia en las infraestructuras 
• Diferentes enfoques por fabricantes: vBlock, FlexPod, etc...
• Hyperconvergencia (gestión conjunta del computo y del almacenamiento)
• Enfoques similares por fabricantes y mundo open source: Kaviza, Proxmox, Nutanix, Trinity, vEVO:Rail, etc...
• Almacenamiento definido por software 
• Enfoques similares por fabricantes: vSAN, ViPR, etc...
• Redes definidas por software (gestión conjunta de las redes de datos LAN con el computo y el almacenamiento)
• Aparición de nuevos protocolos como vXLAN, NVGRE y nuevos enfoques de fabricantes: vNSX, etc...
• Inclusión de routers lógicos, balanceadores lógicos y firewalls de red lógicos junto a los ya existentes switches de red lógicos

Y en definitiva todo aquello que permita y posibilite el SDDC (Centro de Datos definido por software), es decir, poniendo foco en el software en base a la abstracción total del hardware, lo que posibilita grandes oportunidades para la automatización y la orquestación. Puede que aquí sea donde se presentan mas retos y desafíos, ya sea a través del manejo híbrido de las existentes maquinas virtuales (VMs) como al manejo de los nuevos contenedores (basados en Docker) y en todo su nuevo ecosistema (Kubernettes, Mesos, Marathon, etc...).

2- Cambios en las aplicaciones (tanto en su desarrollo como en su mantenimiento):

• Que se ejecuten en hardware x86_64
• Que estén desacopladas
• Tanto de la infraestructura (Sistema operativo, etc...)
• Como de las tecnologías de la infraestructura (Web Servers, Application Servers, Integration Servers, Datacache Servers, Database Servers, ECM, WCM, Directory Servers, etc...)
• Que "crezcan" y escalen horizontalmente
• Nodos de aplicaciones stateless en lugar de stateful
• Compartición de info mediante servicios de almacenamiento
• Fichero
• Bloque
• Objeto
• Que usen llamadas asíncronas  
• Web Services, es decir, servicios web
• REST mejor que SOAP
• Evitar el uso de llamadas RMI
• Evitar el uso de DBLinks
• Potenciar el uso de APIs 
• API Managers
• Funcionalidad básica (API tipo proxy) o avanzada
• QoS ("Grifo" del ancho de banda a consumir por cada API)
• Seguridad logica (Certificados, Tokens, etc...)
• Monetización del uso (de cada API publicada)
• Potenciar el uso de tópicos y colas para la mensajería
• Queue Servers
• ESBs, etc...

• Uso de micro-servicios en lugar de monolitos
• Aproximación gradual y progresiva
• Incorporación del uso de contenedores o sin ellos

Y en definitiva todo aquello que permita y posibilite el SDDC (Centro de Datos definido por software) dentro del mundo de las aplicaciones y su integración,

 3.- Cambios de Procesos (y sus procedimientos... ya sean predictivos o adaptativos):

Parece que ya no es ni va a ser suficiente con el ya mas que conocido cambio alternativo de las metodologías de gestión de proyectos de desarrollo de aplicaciones, de aproximaciones predictivas a aproximaciones ágiles (ojo, hago foco en la agilidad, NO en el agilismo), sino que se precisan y se van a precisar nuevos métodos, procesos y roles para gestionar todo lo ya comentado anteriormente y todo lo que viene además (realidad aumentada & virtual, drones, ro-botica, inteligencia artificial, hologramas, impresión 3D, etc...),

Es por esto que están tomando un fuerte impulso nuevas formas de hacer las cosas a como hemos  venido haciendo de forma tradicional, ya sea de forma predictiva o adaptativa, y se empiezan a escuchar ideas nuevas como las que proponen IT4IT,  DevOps,  LeanIT, etc... con nuevos mensajes que en ocasiones suponen un importante cambio cultural y de actitudes en las personas que forman parte de la propia organización IT:

La respuesta será NUNCA, ya que se trata de un flujo de extremo a extremo compuesto por la integración y entrega continua en el IT Delivery, al mismo tiempo, que la monitorización (avanzada) y el feedback continuo en la IT Operation.

Espero que os aporte a todos.

¿Por que se confunde habitualmente PRODUCTO con SERVICIO?

Aprovecho este articulo para comentar algo que creo, al menos en mi caso, podemos oír día si y día también como algo habitual y es la constante similitud entre PRODUCTO y SERVICIO, cosa que creo que no es, máxime por los resultados que esto implica y que suelen pasar desapercibidos siendo como son muy importantes.

De forma bastante tradicional las buenas practicas y metodologías de Gestión de Proyectos, ya sean predictivas (PMBOK, PRINCE e ISO 21500) o adaptativas (Agile: Scrum, XP, FDD, etc...), tienden a potenciar, creo que por error, la orientación únicamente hacia los aspectos funcionales del resultado de un proyecto TIC, es decir del PRODUCTO. Este hecho se ha visto incrementado (por no decir agravado) por la llegada e incremento de uso de las denominadas metodologías ágiles, las cuales amplifican este hecho poniendo todo el foco en las funcionalidades del PRODUCTO final, obviando todo lo demás. Esto es lo que algunos denominan Agilismo, para mi, hacer las cosas deprisa, corriendo, mal... y siempre lo mismo. Este punto de vista tan parcial, quizá pueda ser eficaz y eficiente en aquellos que se dedican a fabricar software de forma aislada ya sea con un entregable final en un medio físico como CD, DVD, etc... o directamente en un descargable desde Internet.

Sin embargo, en las Organizaciones IT, el resultado de un proyecto TIC, NO es un PRODUCTO, por tanto SI es un SERVICIO. Aquí entran aspectos de mayor extensión y complejidad como es la Gestión y Gobierno de Servicios (COBIT, ITIL, ISO 20000, ISO 38500, etc...) y la Arquitectura Empresarial (TOGAF). La diferencia estriba en el hecho que un SERVICIO no contempla únicamente los aspectos funcionales del resultado de un proyecto TIC, sino que potencia y pone foco al mismo tiempo y al nivel en las garantías (en el caso de la Gestión de Servicios) y/o en las calidades sistémicas (en el caso de la Arquitectura Empresarial).

Garantías: Disponibilidad y Rendimiento, Capacidad y Continuidad, y Seguridad

Calidades Sistémicas: Manifiestas: Rendimiento, Fiabilidad y Disponibilidad; Operacionales: Manejabilidad, Calidad, Trazabilidad y Seguridad; Evolutivas: Escalabilidad, Flexibilidad, Portabilidad, Reutilidad, Extensibilidad y Mantenibilidad

El hecho de equilibrar y potenciar al mismo tiempo y al mismo nivel tanto los aspectos funcionales como las garantías y/o calidades sistémicas del resultado de un proyecto TIC, es decir la orientación a SERVICIO, no esta reñido en ningún caso y en ningún momento con la Agilidad (quizás si con el Agilismo... es decir, con hacer las cosas deprisa, corriendo, mal y siempre lo mismo), como ya se habló en este anterior articulo, en base a potentes herramientas de trasformación como pueden ser LEAN IT y DEVOPS, esta ultima como complemento y mejora del mas tradicional SYSOPS.

En este sentido, aunque quizás muy joven y con poca madurez todavía, esta surgiendo con fuerza un nuevo framework de gestión y de gobierno IT denominado IT4IT, el cual, de una forma sencilla y practica pretende aunar la orientación a SERVICIO con la Agilidad y con aspectos claves de Arquitectura Empresarial de forma conjunta:

Sin duda interesante, seguro que genera debate ;-)

PMO y SMO. Diferencias, Similitudes y Colaboracion !!!

Aprovecho este articulo para transmitir que el pasado 3 de Junio tuve la oportunidad de poder participar como ponente en el IX Congreso Academico Internacional del itSMF,

En esta ocasion en concreto, la tematica del congreso mas alla de Gestion de Servicios TIC y del Gobierno IT, giró en torno a varios pilares claves, como se puede apreciar en la agenda:

- Tendencias (Cloud Computing, Movilidad y Big Data)
- Gestion TI
- Gobierno IT
- Compliance IT
- Legal IT

Personalmente ha sido un placer poder disfrutar tanto de su preparacion como de la realizacion del evento igualmente de forma compartida con todos los profesionales del sectos como con la organizacion del itSMF,

Como en anteriores ocasiones, dejo aqui la presentacion:

PMO y SMO, diferencias, similitudes y colaboracion from Victor M. Fernandez

¿Es posible agilizar la Gestion de Servicios TIC?

La respuesta es que SI, claro que SI

Sin embargo, hay que matizar, que agilizar en el sentido de agilidad y no en el sentido de agilismo

En este sentido es mucho mas practico y pragmatico, no caer en los aspectos puramente teoricos de las metodologias agiles SCRUM ni en las buenas practicas de ITIL, sino apoyarse de forma activa en herramientas reales y palpables de mejora continua, como es el caso de los principios de productividad de Lean IT y la orientacion a servicio junto con la gestion conjunta de proyectos y servicios, como es el caso de DevOps

Como ya se indicó anteriormente en este articulo, la Gestion de Servicios TIC, habitualmente en Organizaciones IT con bajo nivel de madurez en la Gestion y Gobierno IT, se suele confundir y se confunde de forma constante con la gestion tecnica del mantenimiento de una u otra determinada tecnologia, ya sean tecnologias de la infraestructuras (incluidas las redes, las comunicaciones, la seguridad y el puesto de trabajo) y/o tecnologias de las aplicaciones (sean de la naturaleza que sean, desarrolladas a medida o personalizadas en base a productos de mercado)



No obstante, la Gestion de Servicios TIC, tiene un alcance mucho mas amplio y con un mayor recorrido ya que va desde la Estrategia, Diseño, Transicion (aqui se mapea con la gestion de proyectos), Operacion hasta la Mejora Continua. Esto sienta las bases para la gestion por procesos y la mejora continua, pero la experiencia nos demuestra que es completamente insuficiente e incapaz en la practica, es decir, que la Gestion de Servicios TIC debe y tiene que verse enriquecida y alimentada si o si con Lean IT y con DevOps

Lean IT en modo resumido nos va a permitir varias mejoras, lo primero de todo poder conocer la voz del cliente (VoC), para asi focalizar todas las actividades en aquello que aporta valor al mismo, lo segundo conocer la realidad visual de los procesos que se ejecutan (VSM), lo tercero depurar el "desperdicio" (waste), es decir lo que no aporta valor, de la ejecucion de los procesos y lo cuarto organizar de forma visual las tareas para una mayor y mejor coordinacion. El mayor reto aqui, no es llevarlo a la practica (que tambien) sino conseguir que la mejora continua se mantenga constante y con el mismo enfasis a lo largo del tiempo



DevOps igualmente en modo resumido, a parte de orientar a toda la Organizacion IT al servicio de forma trasversal, mitigando el pensamiento vertical tan implantado en la practica, va a permitir un ciclo real de mejora continua desde el desarrollo, hasta las operaciones (explotacion), pasando por las Infraestructuras. El principal desafio aqui es que desarrollo entienda y colabore con infraestructuras y operaciones, al mismo tiempo que infraestrucutras y operaciones entiendan y colaboren con desarrollo; creando un circulo de entendimiento permanente en base a la entrega continua-correcta y al feedback continuo-transparente. El mayor desafio aqui, no es llevarlo a la practica (que tambien) sino conseguir que la mejora continua se mantenga constante y con el mismo enfasis a lo largo del tiempo

Otra variable, menos conocida, pero igualmente efectiva en la practica, es el uso de la Arquitectura Empresarial como facilitador comun y nexo de union en la gestion conjunta de proyectos y servicios, tal y como ya se comentó en este anterior articulo

Queda aparte el Gobierno IT de los Servicios TIC, ya que este articulo se centra unicamente en los aspectos de gestion de los mismos

Arquitectura Empresarial: Aspectos clave en la Gestión de Servicios TIC !!!

Habitualmente en las TICs (Tecnologias de la Informacion y Comunicacion), la Arquitectura se ciñe al diseño de los requisitos funcionales y los requisitos no funcionales (es decir tecnológicos), como nexo de union de ambos, tanto en los proyectos (Gestion de Proyectos) como en los Servicios (Gestion  de Servicios).
Sin embargo, en las Organizaciones IT, la importancia y relevancia de la Arquitectura se incrementa ya que el resultado de los proyectos consiste en la puesta en produccion de nuevos servicios, en los cuales es VITAL el cumplimiento de las calidades sistemicas [Manifiestas: Rendimiento, Fiabilidad y Disponibilidad; Operacionales: Manejabilidad, Calidad, Trazabilidad y Seguridad; Evolutivas: Escalabilidad, Flexibilidad, Portabilidad, Reutilidad, Extensibilidad y Mantenibilidad] desde su estrategia y diseño, como posteriormente en su mantenimiento.

No obstante, con la llegada de la Arquitectura Empresarial todo esto se eleva hasta el nivel estrategico [igual que la Oficina de Gestion de Proyectos (PMO) con el porfolio de proyectos y la oficina de Gestion de Servicios (SMO) con el catalogo de servicios] incorporando el diseño de los procesos de negocio.

Actualmente el marco metodologico mas extendido esta basabo en TOGAF, el cual pivota sobre 4 dominios o pilares fundamentales:

Arquitectura del negocio: define la estructura funcional, en términos de sus objetivos estratégicos, capacidades y procesos de negocio

Arquitectura de las aplicaciones: define la integración de las aplicaciones, garantizando su correcta alineación con los procesos de negocio

Arquitectura de los datos: define la integración y consolidación de datos, permitiendo la generación de informes, indicadores y tableros de control

Arquitectura de tecnología: hace referencia a todos los componentes y elementos tecnológicos que soportan los sistemas de información y los medios de comunicación. Estas tecnologías deben garantizar la continuidad del negocio

Mas alla de esto, propone un modelo operativo destino, el cual se puede quedar representado sobre la siguiente imagen:

Como critica constructiva, en el mismo, no aparece en ningun caso ni como funcion ni como proceso, ninguna responsabilidad sobre la estrategia y diseño de los Servicios, es mas, me atreveria a decir que denota su consideracion puramente operacional tanto de la Gestión de Servicios como de la Gestión de TI en general, lo cual es un error tan grave como común el cual ya se indicó en varios articulos anteriores (I y II). Asimismo no considera la Oficina de Gestion de Servicios (SMO) como responsable estrategico del Catalogo de Servicios (el cual es pieza angular de la oferta de la Organizacion IT a Negocio) lo que se hace especialmente critico en el caso concreto del nuevo modelo de entrega de servicios que supone el Cloud Computing en cualquiera de sus modalidades (SaaS, PaaS e IaaS) y tipologías (Publica, Privada e Hibrida).

Actualmente, a dia de hoy, en las Organizaciones IT, los departementos de Arquitectura que han comenzado a realizar de forma gradual y progresiva este enfoque de Arquitectura Empresarial no pasan mas alla que por documentar los procesos de negocio con mayor o menor detalle en relaccion con las aplicaciones. Confiemos que su avance y evolucion, se enfoque desde un punto de vista eminentemente practico, incorporando desde el primer momento en el diseño de los proyectos y de los servicios, los 4 pilares citados anteriormente y no se queden en una mera descripción teorica y/o formal desde el punto de vista documental.

Finalmente, anexo la relación de los errores mas comunes y recurrentes en la Arquitectura Empresarial, aquí.

ERRORES comunes en la Gestion de Servicios TIC !!!

Habitualmente la Gestion de Servicios TIC es una responsabilidad de gestion y de gobierno poco madura en las Organizaciones IT. Sin embargo, aquellas Organizaciones IT que ya han tomado la decision de orientarse a Servicio, han podido constatar como fruto de la experiencia la mayoría de estos errores comunes:

1.- La Gestion Tecnica de Infraestructuras es similar a la Gestion de Servicios. ERROR
La Gestión Técnica de Infraestructuras se ciñe al aspecto tecnico de las areas técnicas tanto en los proyectos como en los servicios.
La Gestion de Servicios se ciñe a los procesos y a los aspectos organizativos que hacen posible la estrategia, el diseño, la entrega, el soporte, el mantenimiento y la evolución de cada uno de los servicios.

2.- La Gestion de Servicios se acota unicamente a las Infraestructuras Tecnológicas (ya sean Infraestructuras de Sistemas, de Comunicaciones o de Seguridad). ERROR
Es posible y de hecho es conocido en el mercado y existen servicios de operación y mantenimiento de aplicaciones (mayormente si son desarrolladas a medida) incluso Servicios Gestionados 24 x 7.

3.- La Gestión de Servicios unicamente compete el nivel operativo de la Organización IT. ERROR
La Gestión de Servicios debe ser el enfoque de la Organización IT y por tanto los servicios deben gestionarse y gobernarse de principio a fin, es decir, desde su Estrategia, Diseño, Transición, Operación hasta su Mejora Continua (Catalogo de Servicios).
Las Organizaciones IT con un alto nivel de madurez realizan una gestion conjunta de proyectos y servicios como detalla aqui.

4.- Que la Organización IT este orientada a servicio, no significa que el soporte, mantenimiento y evolución de su Producción sea un unico servicio. ERROR
La Producción se debe basar en un Catalogo de Servicios siendo responsable la Oficina de Gestion de Servicios (SMO) de su gobierno y un gestor como responsable de servicio por cada uno de los servicios que lo componen. Del mismo modo que hay un unico responsable de cada uno de los proyectos del porfolio de proyectos.

5.- Es lo mismo un Servicio que una Aplicación. ERROR
Un servicio como por ejemplo el correo electrónico normalmente esta formado el 100% de sus componentes por uno o varios productos de mercado bajo el alcance de la Organización IT (tanto su utilidad como su garantia).
Una Aplicación (maxime las desarrolladas a medida) habitualmente están fuera del alcance de la Organización IT tanto su funcionalidad como sus calidades sistémicas (punto critico de las aplicaciones desarrolladas a medida) por lo que es VITAL integrarlas e integrarlas de forma correcta en el Catalogo de Servicios, mediante los roles y responsabilidades adecuados (de ahi la figura de/de los responsable/s de aplicación/es). Por esto la importancia de los requisitos no funcionales como indica aqui.

6.- Orientación a producto del resultado de los Proyectos. ERROR
En las Organizaciones IT, el resultado de los proyectos (ya sean de Desarrollo de Aplicaciones o de Infraestructuras Tecnológicas) son nuevos servicios dentro del Catalogo de Servicios de la misma, es decir, que los proyectos aunque sean gestionados mediante metodologias agiles, esta gestión no es suficiente ya que estas metodologias están orientadas a la generación de producto (utilidad y/o funcionalidad) y por tanto las calidades sistémicas (garantias) permanecen fuera del alcance sin que nadie las gestione con el riesgo que esto supone, como especifica claramente aqui.

Finalmente, animar y apoyar a todas aquellas Organizaciones IT que no esten todavia orientadas a servicio a que lo esten cuanto antes y motivar a aquellas que ya han comenzado el camino (y por tanto han tomado consciencia de la importancia del servicio y de su madurez) ya que la mejora continua es el camino hacia la perfección...

GOBIERNO IT: Gestion Conjunta de Proyectos y Servicios TIC

En las organizaciones IT de las compañias, ya sean publicas o privadas, el resultado objetivo de los proyectos suele ser la puesta en Produccion de un nuevo Servicio TIC para el Negocio. Sin embargo, de forma tradicional y bajo un modelo ya superado, las organizaciones IT se han venido dirigiendo en mayor o menor medida fundamentalmente en base a dos tipos de departamentos de forma divergente y poco coherente:

-Gestión de Proyectos
(Alto valor y alto riesgo)

- Gestión de la Producción
(Bajo valor y bajo riesgo)

Con la llegada de las buenas practicas (ITIL) y nuevas normativas de Gestion de Servicios TIC (ISO 20000), este modelo tradicional cambia y evoluciona hacia un nuevo modelo basado en la Gestión de Servicios TIC en su totalidad de extremo a extremo, es decir, los Servicios demandan Proyectos que los mejoren y los Proyecos pasan a ser nuevos Servicios de forma convergente, coherente y no disruptiva para Negocio.

Si nos fijamos en la evolución de la madurez de las Organizaciones IT orientadas a Servicios (Estrategia, Diseño, Transición y Operación) , segun el ciclo constante de la Mejora Continua, los aspectos de Estrategia, Diseño y Trasición de los Servicios se mapean y solapan de forma directa con la Gestion de Proyectos desde su momento incicial (incluso en la generacion del "Business Case" de cada proyecto). Del mismo modo que las mejoras generadas y demandadas en la Operacion de los Servicios, se convierten en Proyectos que mejoren los existentes.

Por tanto, siendo el resultado objetivo de los Proyectos, la generacion de nuevos Servicios y siendo mejorados los Servicios existentes por nuevos Proyectos; la Gestion de los Proyectos y de los Servicios debe ser conjunta entre los Project Managers (que mantienen el Porfolio de Proyectos) y los Service Managers (que mantienen el Catalogo de Servicios), dentro del mismo Gobierno de la propia Organizacion IT.

Para ayudar en esta Gestion Conjunta de Proyectos y Servicios de cara a mejorar claramente los resultados de la Oragnizacion IT para con Negocio (ya no basta con estar alineados), surgen nuevas opciones y alternativas como es el caso de la Arquitectura Empresarial (marco de trabajo TOGAF), la cual actua de "pegamento" entre ambas responsabilidades de Gestión (Proyectos y Servicios), cuyas dos funciones principales son tanto la gestion de los Procesos de Negocio, como la gestión de las Calidades Sistemicas [Manifiestas: Rendimiento, Fiabilidad y Disponibilidad; Operacionales: Manejabilidad, Calidad, Trazabilidad y Seguridad; Evolutivas: Escalabilidad, Flexibilidad, Portabilidad, Reutilidad, Extensibilidad y Mantenibilidad] de cara a cubrir no unicamente la utilidad de los Proyectos sino tambien la garantia de los Servicios.

Cabe destacar que toda esta nueva y renovada Organizacion IT es completamente compatible con la Oficina de Gestion de Proyectos (PMO) y con la Oficina de Gestion de Servicios (SMO), dentro del Gobierno IT.

La PMO dará soporte, y será responsable del mantenimiento del Porfolio de Proyectos y su correcta gestion por parte de los Project Managers al igual que gestionar sus propios indicadores; y la SMO dará soporte, y será responsable del mantenimiento del Catalogo de Servicios y su correcta gestion por parte de los Service Managers al igual que gestionar sus propios indicadores.

Finalmente, a modo resumen, indicar y exponer los distintos niveles de evolución [Bajo, Medio, Alto y Muy Alto] dentro del modelo de madurez de la Organizaciones IT orientadas a Servicios, en base al ciclo constante de la Mejora Continua: