El problema con APM

Further Faster

Figura 1 – Los productos técnicos, solos, no llegan muy lejos, y los grandes proyectos ITIL suelen terminar en sangre, sudor y lágrimas. Agile Service Management te puede llevar mucho más lejos que una solución APM aislada, en términos de valor de negocio. 

Hace unos meses, la web BSM Digest fue rebautizada como APM Digest debido, en palabras de su editor, a que APM se transformó un “término mucho más popular, al menos aquí en EEUU”. Lo cual es una verdadera pena.

Si consideramos que hace poco tiempo el punto focal de la monitorización pasaba por la red y los servidores, ¿por qué el tomar la aplicación como centro es una oportunidad perdida, cuando representa claramente un avance desde lo más hondo de la infraestructura hacia el cliente final?

El problema es en realidad, múltiple. Hay una concepción arraigada (e incorrecta) en el entorno IT que consiste en tomar a la aplicación como una representación fiel (técnicamente, un proxy) del servicio que se está dando al usuario. Desde esa óptica, el servicio es la aplicación, y si la aplicación funciona, todos unidos festejamos.

Pero la aplicación no es el servicio. De hecho, ponernos de acuerdo en qué es un servicio de negocio nos llevaría un debate, agravado por la última revisión de ITIL, que le llama servicio a cualquier cosa.

Un servicio de negocio es una actividad que se acomete con el único fin de obtener un beneficio, tangible o intangible. El servicio está compuesto por procesos: pasos que deben cumplirse para llevar a buen fin ciertas diligencias del mismo. Por ejemplo, mi servicio de negocio de venta de pólizas de seguros de vida contendrá procesos de cotización de pólizas, alta de clientes, creación y archivado de pólizas, etc.

Es altamente probable que para llevar a cabo mis actividades de venta de seguros deba confiar en más de una aplicación, y que se generen numerosos flujos digitales entre esas diferentes aplicaciones y sus módulos. Para poder representar correctamente estos flujos necesitaré comprenderlos, y para poder evaluar la actividad, las necesidades de calidad e integridad de datos y el rendimiento con los indicadores, la proactividad y la granularidad adecuada, necesitaré conocer con cierto detalle los objetivos del servicio de negocio.

A su vez, si soy capaz de representar esta información en forma adecuada para un usuario no técnico en tiempo real, inmediatamente habré aumentado la audiencia para mis dashboards y la utilidad de los mismos en uno o varios órdenes de magnitud.

Pero APM no nos exige centrarnos en ninguna de estas cuestiones a priori. De hecho, y para mi horror, un analista de la mayor consultora IT me confesó que la ventaja que veía en las herramientas de APM, a diferencia de las de BSM, era que los técnicos no necesitaban sentarse a conversar con negocio: podían monitorizar la aplicación desde el vacío.

El auge, en mi opinión, de APM por sobre BSM tiene su origen en las malas prácticas de ITIL y su cruel insistencia en tropezar una y otra vez con la piedra de la CMDB. Seguir al pie de la letra la biblia británica convierte a los profesionales de IT en Sísifos enceguecidos en triunfar donde nadie triunfó nunca.

Las implantaciones de APM típicas se desentienden de la CMDB, en algunos casos reemplazándola por Real Time Service Models (RTSM), y esto es fantástico, pero su éxito a corto plazo compromete su recorrido y amengua su potencial.

Un proyecto de Business Service Management (BSM) bien entendido, en contraposición, exige comprender el contexto de negocio y partir de un enfoque Outside-In, como el que propone fervorosa y heroicamente Ian Clayton desde todos los foros donde lo dejan exponer.

A partir de este cambio copernicano de centro del mundo (ya no es la Tierra, es el Sol: el Sol son los servicios de negocio, no la aplicación) es posible alinear realmente los esfuerzos de IT, comprender mejor y ser comprendido, producir visibilidad mucho más clara y valiosa para IT y para Negocio, y generar mucho más valor para la compañía.

No me malentiendan: las tecnologías básicas de APM son necesarias y beneficiosas, especialmente – claro- para los responsables de desarrollo de una aplicación. Pero considerar a la aplicación como centro deja simplemente demasiados puntos ciegos.

Crear visibilidad a través de una visión holística que vaya mucho más allá de la aplicación nunca fue tan necesario como en esta época de intensa competencia, donde la competencia es cruel, la expectativa alta y donde los errores no se perdonan.

Lo bueno es que nunca hubo mejor momento para implantar BSM en toda su gloria outside-in. Lo cual implica, sí, sentarse a conversar con Negocio, aprender, crecer y ser mucho más útiles. Y exitosos.

¿Tu opinión?

2 pensamientos en “El problema con APM

  1. Pingback: La CMDB ha muerto | The Visibility Blog en Castellano

  2. Pingback: Ganaste la guerra a las CMDBs | The Visibility Blog en Castellano

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s