¿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 ;-)

Que es eso de DevOps? y DevSecOps?

El pasado 8 de Junio tuve el placer de ser invitado y poder participar como ponente en el Congreso #AGILE17, dentro del conjunto de eventos y jornadas que organiza el itSMF a lo largo del año,

En este caso concreto, el reto para mi era doble, debido as su vez a la calidad y al numero de ponentes como podeis ver en la agenda del mismo:

Desde el primer momento que me hicieron la propuesta mi idea era (y finalmente asi fué) tratar de un modo lo mas pragmatico posible, saliendo de los aspectos teoricos o retoricos, la práctica (que es lo que cuenta)  de llevar a cabo la nueva cultura y la nueva forma de trabajo, de DevOps, tanto en el sentido del Delivery, es decir, en la entrega, como en el sentido del Feedback, es decir, en el retorno o en la retroalimentacion para cerrar el circulo de Lemiscata, que no deja de ser el ciclo de vida de DevOps, tanto para los proyectos , como para los mantemimientos,

Eso si, poniendo foco y especial atención, quizas algo mas, en lo que creo que es lo que menos evidente, de lo que menos se habla y por tanto, lo menos conocido y extendido, que es el sentido de Feedback, la parte del retorno, con ejemplos concretos incluidos,

Sin embargo, no me parecia suficiente ni completo, por lo que decidi y asi lo propuse al congreso (finalmente aceptado) incluir el hecho de abordar en la misma sesion, de forma integrada, la tematica acerca de DevSecOps, tan poco conocida y tan poco explicada, sin embargo, no por ello, menos importante o relevante actualmente,

Por este motivo, el titulo de la presentacion es el que aparece en la agenda del congreso:

De nuevo, muchas gracias al Congreso #AGILE17 y al itSMF, por darme la oportunidad de poder contarlo,

Para los que no pudisteis asistir, dejo aqui la presentacion que utilice para apoyarme en ella durante la sesion que pude impartir:

DevOps (y DevSecOps) e ITSM, el Feedback de Produccion y Seguridad a Desarrollo from Victor M. Fernández

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

Como agilizar una Organización TIC y no morir en el intento !!!

Hola a todos,

En esta ocasión, me gustaría contar mi punto de vista, base de mi experiencia, en lo que se refiere al importante reto de Agilizar una Organización TIC (incluyo la C que a mucha gente se le olvida ;-), con todo lo que ello supone en su propia naturaliza y actividades, independientemente del peso de cada una de ellas:

1. Pilotos y/o Pruebas de concepto
2. Proyectos
3. Soporte y Mantenimiento (Correctivo, Adaptativo, Perfectivo y Evolutivo)
4. Governance 

Al decir Agilidad, no me refiero al Agilismo ni a su movimiento, que en la practica se acaba traduciendo en deprisa, corriendo, mal... y otra vez lo mismo, de forma repetitiva, o en algo peor, como se explica en este otro enlace: "El oportunismo de Agilismo"; sino a Agilidad de verdad, es decir a ser ágiles y poner todo el foco que podamos en aportar VALOR a nuestro cliente cuanto antes y con aproximaciones sucesivas consecutivas (ya sean sprints, iteraciones, fases o como queramos llamarlas) sin por ello tener que poner en riesgo ni la Calidad ni la Seguridad, de lo que hacemos ni de su resultado.

De ahí, que sea de los que opina, que en este sentido DevOps, supera y trasciende a Agile, ya que es mucho mas completo e integrador, como mínimo, al estar orientado a servicio de extremo a extremo y a promover el flujo continuo como gestión conjunta de proyectos y servicios. Motivo por lo que pienso que DevOps, como enfoque practico de Lean IT, parece que ha llegado para quedarse.  

Teniendo claro lo anterior, mi listado de puntos clave, podría ser algo así:

- Anticipación 

Mantenerlos alertas y pendientes, de forma periódica y continua, a la escucha de las nuevas tecnologías que aparecen en el sector y en la industria, para, entre otras cosas, ver en que medida podemos aprovecharlas y/o pueden aportar a nuestro negocio,

La idea de fondo es ir armando aquellas nuevas actividades que vienen a medio y largo plazo y ver como gestionarlas de la mejor manera posible sin que sea fruto de la improvisación o de una "política" de hechos consumados,

- Capacitación 

Capacitar y capacitarnos en las nuevas tecnologías que si o si sabemos que van a incorporarse, antes o después, a nuestro negocio, a través de un plan continuo con hitos concretos, que no sea o que no se convierta en algo asilado o inconexo de forma puntual, presionados por la urgencia y/o la emergencia de una u otra situación, 

Esto aplica igualmente a las habilidades que necesitamos adquirir e ir adquiriendo, asimismo de forma gradual y progresiva, posiblemente de forma integrada, dentro del posible plan anterior,

- Colaboración 

Fomentar y potenciar la colaboración de los equipos de trabajo en todo momento, ya que son los que sacan el trabajo adelante; en muchas ocasiones fruto de los puntos anteriores, sin por ello dejar de lado la mejora continua y constante,

Esto parece mas un tema cultural de trabajo sobre la actitud de las personas, que de la implantación de uno u otro conjunto de herramientas, aunque si bien es cierto que disponer de unas buenas herramientas, ayuda y mucho, ya lo creo,

- Captación 

Capturar todo el conocimiento posible, de todo el trabajo resultado de los 4 conjuntos de actividades citadas inicialmente en este articulo,

Siendo muy importante que no se produzca al final o a posteriori, sino justo al revés, al contrario, cuanto antes mucho mejor para todos, ya que nos evitaremos errores, re-trabajo y lo podremos reutilizar en cualquier momento,

La idea aquí, no es solo capturar el máximo posible del conocimiento sino además hacerlo posible mediante modelos repetibles, de forma clara y sencilla,

- Automatización 

Tratar de conseguir cuanto antes, automatizar, sin riesgo o con un nivel de riesgo bajo, asumible por la organización y por el negocio, aquellas tareas que sean repetitivas. Esto tiene especial sentido en las actividades de mantenimiento (ya sean de Desarrollo y Aplicaciones o de Tecnología e Infraestructuras) y es la pieza angular sobre la que pivotan todos los procesos de Integración Continua (CI) que posteriormente posibilitan la Entrega Continua (CD),

Hay que recordar que no se trata de llegar a tener el 100% porque si, sino mas bien ir construyendo, siempre que se pueda automatizar con criterio y control de la situación, con el objetivo de Agilizar,

- Monitorización

No se trata de la visión operacional, de únicamente de monitorizar todas las piezas de la tecnología  y de la infraestructura que componen las aplicaciones y los servicios de negocio, sino de monitorizar las aplicaciones y los servicios de negocio en si mismas, en su propio desempeño y rendimiento, tanto de tiempos de respuesta, operaciones, concurrencia, transacciones, etc... con todo aquello que podamos ya sean mediante la experiencia de usuario, el uso de robots, etc...

En este sentido las herramientas de inteligencia operacional incorporan un gran avance por su versatilidad y dinamismo, haciendo posible abordar aspectos que sin ellas serian mucho mas complejos,

Lógicamente todo ello requiere un importante entendimiento y a su vez apoyo de la Dirección, ya que en muchas ocasiones, los problemas van a ser mas de tipo organizativo, entre áreas y departamentos, que de la gestión de los propios equipos de trabajo, aunque siempre podremos hacer algo y mejorar en nuestro propio espacio dentro de la organización, sabiendo que no se trata de construir el mundo ideal, sino de tratar de gestionar y ejecutar las cosas mejor con los medios que tengamos a nuestro alcance y/o apoyarnos en las ampliaciones que sean necesarias, que muchas veces lo son,

Espero que os sirve de ayuda, para mi ha sido y es todo un aprendizaje y por supuesto, continua siéndolo, todo un desafío !!!

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í.