11 minute read
Entrevista
El CIO o más allá
Nuestro perfil de interlocutor es el CIO o incluso responsabilidades por encima, como pueden ser los directores generales de medios. Si hablamos con un perfil muy técnico, relacionado con infraestructura o desarrollo, normalmente no tienen visión de los procesos de negocio, y si nos dirigimos a responsables de áreas de negocio, resulta complicado poder influir en la tecnología. La figura del CIO suele tener visibilidad en los procesos de negocio e influencia en sus equipos. Ese es nuestro cliente natural. En cuanto al sector, nuestros clientes son las principales referencias en banca y seguros, aunque creemos que hay un potencial muy interesante en el retail si consideramos las presiones que tienen respecto a la disponibilidad y la rapidez de respuesta. Básicamente, hablamos siempre de grandes organizaciones, con un entorno muy complejo en cuanto a infraestructura y desarrollo, que necesiten medir los procesos y poder corregirlos.
18 // ¿A qué necesidad responde Orizon? Cuando yo empecé, en 2002, había mucha conciencia respecto a la calidad o la metodología. Se comprobaban mucho los desarrollos, cuántos recursos consumían las aplicaciones, tiempos… Pero si en aquel momento había doscientas personas programando, hoy son más de 6 000. Las áreas de desarrollo han crecido de forma espectacular para poder dar respuesta a las actuales necesidades en cuanto al time-to-market. Esta aceleración no solo conlleva un aumento exponencial de los costes de desarrollo, sino también una progresiva pérdida del control sobre las aplicaciones. Incrementar el desarrollo para aumentar la velocidad se ha convertido en una obsesión. El concepto de calidad ha ido desapareciendo y se ha sustituido por términos como coste y rapidez. La derivada evidente es la falta de control y la búsqueda de la eficiencia.
¿Cuál ha sido vuestra evolución como empresa? Durante los primeros años nuestro enfoque era eminentemente técnico, proponiendo soluciones muy concretas para demostrar de forma clara y precisa los ahorros y las eficiencias obtenidas. Pero este no es un tema de conocimiento técnico, sino más bien de organización. De esta forma, hace cinco años empezamos a trabajar en dos conceptos: el diagnóstico y la automatización, todo ello con una metodología muy clara. Antes, el diagnóstico era sencillo y lo importante era dar con una solución óptima. En la actualidad, los volúmenes están descontrolados y son inmanejables en cuanto a costes y tiempos; es mucho más efectivo descubrir qué pocos cambios permiten solucionar muchos de los problemas existentes. Los análisis periódicos que se podían hacer hace unos años, con un trabajo manual, ya no sirven. Ahora hay que hacerlos de forma automática y todos los días. Por ejemplo, tenemos clientes que, en cuatro meses, han rotado completamente su mapa entero de procesos, aquellos que influyen en lo que realmente les importa: los costes, la velocidad, el tiempo de respuesta online… Se trata de dar el diagnóstico adecuado, buscar las mayores eficiencias en el menor tiempo posible. Nuestra herramienta —BOA— se encarga de hacer ese trabajo diariamente. De cara al futuro, aprovechando el conocimiento adquirido, lo que queremos es anticipar todos estos problemas y ser capaces de ofrecer la solución adecuada (con cambios en bases de datos, en ciertas partes del código…) de forma automatizada, sin intervención humana. Es lo que denomináis oficina técnica de rendimiento Este es el concepto. En los entornos en los que trabajamos, de gran volumen, la foto de la infraestructura y el software cambian diariamente. Es necesario ese recálculo diario para asegurar el rendimiento en función de los objetivos de negocio, que suelen ser siempre los mismos: ahorrar costes, ya sea de la infraestructura o del mantenimiento de las aplicaciones, conseguir el tiempo de respuesta más rápido, reducir el número de paradas o acabar los procesos batch a tiempo. Todos los días medimos esos procesos de negocio, y apuntamos a aquellas partes del código o de la infraestructura que son responsables de que aquello no funcione de forma adecuada. Para ello, diariamente se analizan terabytes de información muy técnica (definición de criterios y umbrales, relaciones de los procesos con el software, código fuente, logs de los entornos, metadatos de las bases de datos, etc.). Se trata de recalcular todo eso y sacar conclusiones en función de aquellos procesos que, de verdad, son los que pueden afectar al negocio. No solo identificamos —diariamente y de forma automatizada— qué es lo que está haciendo que algo vaya mal, sino que también proponemos la solución. Esto último, en un pequeño conjunto de casos, es algo 100% automatizado, aunque en otros casos sí se requiere una intervención manual por parte de analistas. Nuestro objetivo es que, cada vez más, esta sea también una tarea totalmente automática.
¿Qué tipo de ineficiencias buscáis? Aunque la orientación es hacia los procesos de negocio, también analizamos las ineficiencias de tecnología por separado. Poder detectarlas, y asociarlas a proveedores o a grupos de desarrollo, permite, por ejemplo, generar unos KPI acerca de la calidad de su trabajo. Esto es muy importante, pero lo es más la posibilidad de saber —dentro de un proceso de negocio y de los umbrales asociados— qué línea de código o qué acceso está influyendo en el rendimiento y, tirando del hilo, identificamos el tipo de fallo que se produjo, cuándo, en qué aplicación y de qué proveedor. Esto es posible gracias a nuestra herramienta BOA, en la que hemos invertido ya más de dos millones de euros. Construimos esta herramienta desde cero porque no había nada parecido. Creamos la metodología y los procesos, y la hemos ido mejorando de forma incremental a lo largo de los años, orientándola mucho hacia el negocio.
¿Hay reticencias respecto a esta información que capturáis? Lógicamente, nuestro trabajo está avalado por contratos de confidencialidad, pero hay que tener en cuenta que se trata siempre de datos técnicos, no de cliente. Lo que vemos son tiempos, nombres de procesos, consumo de recursos… Hasta ahora, no hemos encontrado reticencias en ninguno de nuestros clientes en España, porque se trata de un mercado que ya está maduro: estas empresas suelen tener una orientación muy clara al outsourcing y cuentan con contratos y experiencia a la hora de trabajar con proveedores externos. Es más, en algunas ocasiones, son ellos los que nos envíen los datos, ya que la herramienta de análisis está instalada en nuestro cloud, aunque en algunos casos se puede instalar también on-premise.
¿Los errores normalmente son los mismos? A alto nivel, en este tipo de empresas los procesos son muy similares, lo que sí varía es la tecnología que subyace. Eso sí, cada escenario tecnológico tiene una serie de fallos muy específicos que, además, se suelen replicar en las distintas empresas. La gran diferencia está en el umbral de tolerancia —el nivel de exigencia en cuanto a la calidad y el tiempo de respuesta— y en el modo en el que se obtienen los datos, porque cada empresa tiene modelos de infraestructuras, datos y monitorización diferentes. Pero, una vez que tenemos el dato, los procesos de negocio —y como están correlacionados con los procesos técnicos— son siempre iguales. Por ejemplo, según nuestra experiencia, menos del 1% de los procesos —en el ámbito de las infraestructuras— son responsables de la mayoría de los problemas que encontramos. Además, el 70% de esos fallos son idénticos en todas las entidades, y se estructuran en veinte tipologías muy definidas. Normalmente, todo está muy concentrado en pocos procesos, pero, como se ejecutan muchas veces, si no se corrigen generan muchas ineficiencias. Por dar algunas cifras, una empresa con un presupuesto anual de 500 millones de euros (entre desarrollo, infraestructura, etcétera) tiene un sobrecoste de entre un 10% o un 15 % en el mantenimiento de aplicaciones, y otro 15% en la infraestructura. Hablo de ahorros netos o de recortes en los niveles de crecimiento, porque en estas empresas los costes de esta
20 // área están creciendo entre un 20% y un 30% anual. Depende de dónde pongamos el umbral, se podrán contener esos gastos o reducirlos de forma neta.
Ayudamos a generar KPI de calidad que se pueden asociar a proveedores o a grupos de desarrollo ¿Garantizáis esos ahorros o eficiencias? Nos comprometemos con el resultado siempre y cuando la entidad se comprometa también con las pautas que marcamos. De hecho, tenemos algún contrato a éxito en el que, en un período determinado, nuestra remuneración se compone de un porcentaje de los ahorros conseguidos. En cualquier caso, las empresas no suelen buscar compartir los ahorros que se consiguen con nuestro trabajo. En la mayoría de los casos, no son escépticas en cuanto al resultado. Además, en cuanto lo prueban descubren que aplicar esto de forma recurrente no les compensa. Les resulta mucho más caro.
¿Hablamos de ahorros a largo plazo? El impacto que buscamos es diario y constante. A las empresas no les compensa tener un gran ahorro en un momento puntual, porque estos procesos suelen estresar mucho a la entidad. Se trata normalmente de problemas estructurales y lo que buscan es tenerlo medido y parametrizado diariamente, que sea un proceso más de la entidad y que ayude a reducir las preocupaciones. Nuestra visión es que el ciclo de desarrollo de software no acabe cuando se entrega a producción. Aún queda una validación: ver cómo afecta a nuestros procesos de negocio. Sería una nueva etapa —de posimplantación— de la que todavía no se habla, y en la que se busca validar el comportamiento, y el rendimiento, de la aplicación en relación con los procesos de negocio. Normalmente, el trabajo del equipo de desarrollo (interno o externo) concluye cuando se sube a producción, o incluso antes, cuando se entrega. La propuesta es que su responsabilidad vaya más allá, que se instale y que pase unas mediciones para asegurar que esté dentro de los estándares de la entidad. La única forma de conseguir eso en este tipo de entornos es con la automatización y la interacción diaria. Poniendo una analogía con un examen, no vale con haber estudiado mucho y haber llegado a tiempo al examen. Con eso no apruebas. Alguien tiene que corregirlo y, después, esperar las notas. Conceptualmente, sin hablar de tecnología, lo que queremos es alargar el ciclo de desarrollo, que alguien entregué un software y que después tenga que esperar las notas para saber cómo le ha ido. Si la nota es mala, si el entregable no ha pasado el examen, la idea es que la entidad cree un proceso para notificarlo y que se corrijan esas malas praxis. Ahora mismo sí se contempla el envío de incidencias cuando una aplicación no funciona o no hace lo que se le pide. Lo que no existe es una valoración en cuanto al rendimiento, pues se trata de mediciones que hay que comparar con los estándares definidos en la organización. Nosotros proporcionamos esos KPI para gestionar a los proveedores, indicándolo como criterio de selección o generando un ranking a partir de parámetros de servicio concretos (tiempos de entrega, velocidad de corrección...). Lo que es importante es corregirlo en este momento, integrando esos procesos de optimización en la cultura de la propia empresa, hacerlo a diario y automatizado. De hecho, creo que es más importante esta ayuda en la gestión del proveedor que los ahorros que se consiguen en las infraestructuras, porque hablamos de entidades que se gastan mucho dinero en horas de desarrollo, más incluso que lo que se dedica a infraestructuras. Son más importantes los KPI para medir la calidad de un desarrollo que el ahorro de recursos en infraestructura.
¿Por qué hacerlo desde una empresa externa? Hay varias restricciones para hacer esto de forma interna. Para poder montar un sistema de medición de rendimiento de un proceso de negocio se necesitan conocimientos de monitorización muy variados y especializados. Hablamos de muchas tecnologías —cloud, mainframe, entornos distribuidos...— con diferentes configuraciones y cada una con diferentes modelos de monitorización. Además, hay que ser capaces de hacer el seguimiento de todo el proceso, dominando muchas tecnologías. Ahora mismo, una operación llega al mainframe desde un canal, lo que significa trabajar con una base de datos determinada, con programas COBOL, etcétera. Pero antes, ha pasado por Oracle, por Java…, pero también un front y, por ejemplo, ha nacido en un móvil. El equipo necesario debería ser muy extenso. Nosotros ya contamos con un equipo de estas características y podemos dar este servicio no a una entidad, sino a muchas: a los clientes con los que trabajamos.
Hacia el click to consum
22 25 26 28 33 34 Cloudless computing La computación, las cargas y los datos serán libres
Sobredimensionar la nube Controlar y optimizar el gasto
La tecnología se abre camino Evolución hacia el ecosistema multicloud
SAP S/4HANA en la nube de Azure Hablamos con Domingo García-Caro, Senior Solution Speciliast en Microsoft
Sistemas operativos nativos en la nube Chrome Enterprise
36 38 42 44 46
La nube en las Administraciones Públicas Estudio de AUTELSI y Nutanix
Cloud evoluciona para adaptarse al negocio David Mañas, head of Cloud, Infrastructure & Security. T-Systems Iberia
Próximos pasos en la gestión de datos Hacia un futuro híbrido y multicloud
Migración de datos en un entorno híbrido Visibilidad, seguridad y protección
No hay madurez en el mercado Jorge Pestaña, Alliances and Cloud Business. Development Director. DXC Technology
