Category Archives for "Crisis"

El valor de Devops para un negocio

Print

Cuando hablamos de Devops, tenemos tendencia a centrarnos en las tecnología, herramientas y procesos utilizados. Básicamente es porque quién hablamos de ello somos gente que formamos parte de los equipos de desarrollo o de operaciones. Pero que valor aporta Devops para un negocio?

En el post anterior “Devops ROI” vimos los conceptos generales que permiten justificar la inversión en tecnología, el ahorro en costes de horas de trabajo y el ahorro en caídas del sistema. Pero Devops aporta otras ventajas o valor difícil de cuantificar en términos monetarios. Hoy en día, donde todos o la mayoría de los negocios son negocios basados en tecnología, este valor puede ser el hecho diferencial entre una empresa u otra.

La implantación de Devops nos permite impactar directamente en mejorar como distribuimos un producto al cliente, cambiar el producto rápidamente para satisfacer las necesidades del cliente o como recuperamos después de un fallo que afecta al cliente.

Un producto en si mismo no es nada hasta que un cliente lo utiliza. Es por ello que es importante reducir el tiempo de lanzamiento de un producto, y aquí es donde la automatización actúa como un multiplicador, permitiendo la colaboración de todos los equipos involucrados en la creación de un producto.

De la misma forma que un producto no sirve de nada si no lo utiliza un cliente, las mejores funcionalidades son aquella que utiliza el cliente. De nada sirve tener un producto con un montón de funcionalidades que no se utilizan. Es por ello que todos los esfuerzos deben focalizarse sobre las funcionalidades que utilizan los clientes, pero como sabemos que funcionalidades va a utilizar el cliente si aún no la hemos lanzado? Devops permite cambiar el enfoque en que priorizamos las funcionalidades de un producto. Pasamos de un enfoque basado en lo que el propietario o la gente de marketing quiere que tenga el producto a un enfoque basado en lo que el cliente quiere que tenga el producto. Para ello, la frecuencia de desarrollo y el uso de test A/B sobre grupos de clientes nos permiten conocer que funcionalidades y mejoras que quieren los clientes.

Por otro lado, todo y que a todos nos gustaría que un producto nunca fallara, tenemos que asumir que en el mundo real el fallo forma parte del ciclo de vida de un producto, falla la tecnología y fallamos nosotros. Todo y que con la automatización de los procesos de testing y deploy se reduce el número de fallos, debemos entrenarnos en la gestión del fallo para reducir el tiempo de recuperación ante fallo o MTTR (Mean Time To Repair). La reducción del tiempo de recuperación ante un fallo mejora la satisfacción del cliente.

En resumen, aplicar Devops permite reducir el tiempo de lanzamiento de un producto, distribuir al cliente aquello que desea el cliente, y mejorar la satisfacción del cliente.


Source: jmgriscom

Nueva Web en Orbal

web-orbal

Una web llena de recursos para vosotros

web-orbal

Siempre he dicho que una imagen vale más que cien palabras, y por eso creo que lo mejor es que se vea lo que estamos haciendo.

Estamos haciendo un punto de encuentro donde un Responsable Informático pueda encontrar la mayor cantidad de recursos sobre ello, videos, white papers, e-books

Y mientras vamos populando este apartado, podéis ver nuestro nuevo site, desde donde podréis ver lo que hacemos, nuestras novedades, etc.

captura-de-pantalla-2016-09-25-a-las-18-39-52

Os esperamos pronto por www.orbal.es

Take care,

JM

 


Source: jmgriscom

¿Cúal es la inversión de nuestra empresa en IT?

Hay una serie de métricas que un CIO tiene que tener muy claras si quiere que su departamento esté a la altura de las circunstancias y que el desempeño de su cargo no sea cuestionado (entre otras).

Uno de los primeros conceptos que tiene que tener en cuenta un responsable de un Departamento de IT es que esta gestionando un presupuesto más o menos elevado, pero que no ha solicitado ni precisa el Departamento de IT.

Si, parece mentira pero es así. El 80 o 90% del presupuesto del Departamento de IT está dedicado a dar servicio a nuestros clientes internos, los otros Departamentos, para que ellos a su vez, den servicio a los clientes de la empresa.

Lo primero que debiera tener claro el CIO es este concepto y defenderlo, lo segundo, conocer que porcentaje usa cada Departamento del 80% en cuestión y lo tercero (ya vamos para nota) que cada mes hubiera una nota interna o “factura” donde le indicáramos a cada Departamento en lo que ha incurrido. Al lado, para compensar la situación, una evaluación del servicio.

Esto, para las empresas que trabajan con una contabilidad de centros de costes será relativamente fácil, porque la cultura ya estará implantada, en las que no, pues pasito a pasito y empezar a clarificar quién es el responsable del presupuesto y quién es el que lo está explotando en verdad.

Estoy preparando un post donde además hablaremos sobre como confeccionar un presupuesto anual “por concepto y destino”, pero ahora volvamos al post original. Volvemos…

Si Vd. CIO de la empresa X le preguntara que porcentaje de los ingresos de su empresa se invierten en IT, ¿me sabría contestar? ¿Y si le pregunto cual es la media de su sector, o la media general?.

Antes de que dejes de leer este post déjame decirte que es muy fácil conocerlo (facturación anual y OPEX incluyendo amortización del Depto de IT y hacer una operación) y muy importante saberlo.

¿Por qué? Porque cuando venga el momento de poner presupuestos sobre la mesa, si sabemos ese dato y comparamos nuestra inversión en frente de la sectorial, tendremos argumentos en lenguaje de negocio para defender el proyecto, porque así se defienden los proyectos, en lenguaje de negocios, y demostrando que la inversión o ROI de nuestro proyecto es menor que los beneficios que va a aportar.

Sí, ya sé, y lo sé por experiencia (10 años como CIO) que hay muchos puntos “difíciles” en los proyecto, “intocables” que tendremos que volver “tocables”, poniendo un valo, y puntos “incuantificables” que volveremos “cuantificables”, porque nuestro CIO va a discutir un punto crítico “que gano si pongo en marcha este proyecto”.

Si esto lo podemos “indexar” al cuadro de lo que se gasta la industria en IT, tendremos otro punto de apoyo.


Acabo de ver el cuadro de Gartner y lo cierto es que continúo pensando que es bajo el “Share” de IT en los ingresos de la empresa.

El sector financiero está invirtiendo un 6.3% y el de Software e internet un 6,7, mientras que el general de la industria es un 3.3%. Ojo con confundirnos. Veamos que el sector de la energía tiene tan sólo un 1.1%, Igual con el 1.3% de las químicas. ¿sobre que cantidad de ingresos?

Tengamos un momento para hacer estos cuatro números y comparémonos con el cuadro o con nuestros colegas (si es posible). El paisaje nos dará mucha información.

Me encantaría que me dejárais algun comentario al respecto.

Hasta la semana que viene

Take care,

JM


Source: jmgriscom

Retorno de la inversión (ROI) en Devops

design-process-thumb

El calculo de cualquier retorno de inversión se basa en el ahorro esperado. Cuando analizamos el retorno de inversión de implantar prácticas como DevOps, es difícil cuantificar este ahorro en términos monetarios. Hay dos aspectos que nos pueden ayudar a entender los ahorros que obtenemos al implantar DevOps: ahorro de costos en horas de trabajo y ahorro de costos de caídas del sistema.

Por lo que hace al ahorro de coste en las horas de trabajo, podemos clasificar el trabajo de cualquier departamento de TI o desarrollo en dos tipos, trabajos planificados y trabajos no planificados, donde los trabajos planificados son aquellos que están destinados a aportar valor a nuestros clientes, en cambio, los trabajos no planificados son aquellos que se realizan a causa de errores o incidencias que hay de resolver de inmediato. Implantar prácticas de Devops permite reducir el tiempo de trabajo no planificado. Pero cual es el coste del trabajo no planificado?

En el informe anual que publica Puppet “State of Devops Report” del 2016, se plantea la siguiente formula para calcular el exceso de coste que supone el trabajo no planificado.

Cost del exceso de trabajo = Personas * Salario medio * Beneficios * Porcentaje de tiempo dedicado a trabajo extra.

• Número de personas: total de personas del equipo técnico.
• Salario medio: según un artículo de computerworld, que hace referencia a un informe de Addeco, el sueldo medio del sector TIC en España oscila entre los 30.000 y 60.000 euros anuales.
• Beneficios: es el coste de los variables o incentivos que perciben los trabajadores a más a más del sueldo, como tickets restaurant, mutuas, etc.. Podemos estimar un factor de 1.2 sobre el sueldo medio.
• Porcentaje de tiempo de trabajo extra: según el informe de Pupper “State of Devops Report” del 2016, para una empresa media este está entre un 10% y un 32%.

Para poner un ejemplo del coste de trabajo extra o trabajo no planificado realizado, ponemos que tenemos un equipo de 10 personas. El cálculo seria el siguiente:

Coste de exceso de trabajo = 10 * 45.000,00€/año * 1.2 * 22% = 540.000,00€/año * 22% = 118.800,00€/año

A este coste, debemos añadir el coste de las caídas de servicio, coste que varia mucho en función de la naturaleza de la organización y que no es fácil de calcular. Todo y la dificultad de calcular el coste de las caídas, es interesante ver la aproximación que se hace en el informe de Puppet,donde se plantea una formula para estimar el coste de las caídas de servicios.

Coste del “downtime” = Frecuencia de Deploys * Porcentaje de caídas * Tiempo medio de recuperación * Coste por hora de caída

• Frecuencia de deploys o despliegues que se realizan en el entorno de producción y que pueden ser causa de caídas del sistema.
• Porcentaje de caídas producidas por cambios en el sistema.
• Tiempo medio de recuperación o MTTR (Mean Time To Recover) que corresponde al tiempo medio que el equipo de operaciones tarda en recuperar los sistemas ante una caída.
• Coste de por hora de caída. Este dependerá mucho de lo crítico que sea el sistema caído.

Aquí las prácticas de Devops nos ayudan a reducir el tiempo de recuperación de los sistemas ante caídas y a reducir el porcentaje de errores producidos por cambios en el sistema.

Podéis encontrar más información en el informe de Puppet “2016 State of Devops Report”


Source: jmgriscom

El futuro de La Cloud

Leo  “Por ello un 41% de las compañías españolas ya utiliza la nube de alguna forma, según un estudio llevado a cabo por IDC. Esta cifra es muy superior al 15% de 2011 y aumentará hasta alcanzar el 52% en 2014, según sus previsiones

Había quien se las creía muy felices con este crecimiento “imparable”, pero claro sólo Jano, el Dios de pasado y del futuro es el que tiene “los datos” en el bolsillo…

No hay duda que la crisis ha vuelto a las empresas recelosas, defensivas, y “mirando hacia adentro” y más sobre su core business que no sobre procesos como los de TI. Que sí, que lo entienden y les gusta lo del “pago por uso”, pero lo miraremos más adelante.

Personalmente no creo que todo sea eso. Creo que falta confianza y una nueva cultura.

Sin duda que AWS, Microsoft y Google son los “chicos grandes” del patio. Pero tuvieron su parte visionaria y “su desierto del Sahara” para llegar a donde están. Vamos a decir que Microsoft supo darse cuenta del cambio del viento y hizo un viraje importante apostando por Azure.

Vuelvo a ver el informe IDC de este año y aunque más comedido, sigue haciendo “push” hacia “La Cloud”. 

Mi punto de vista.

El TI que hay ahora en Cloud, según mi visión, nace de 3 orígenes:

  • La TI de La Cloud. En este grupo pondríamos toda aquella infraestructura que “como va a dar servicio a La Cloud, ¿dónde la vamos a poner si no?”
  • La TI que nació en La Cloud. Generalmente son empresa muy nuevas, que han tenido un CIO visionario y ha pensado ¿Por qué no nacemos con la TI en Cloud?
  • Las grandes empresas, que ya tienen subcontratada la TI y la tienen de Cloud.

El resto pues está en ello. Mirando al de al lado, a ver que ha hecho, leyendo si ha pasado esto o aquello en tal CPD…

Voy a hacer un par de preguntas para demostrarlo. Cuantos CIOs conocen la calificación de los CPD según TIER y cuando conocen las 5 claves para considerar que un servicio Cloud?. Los que consiguen contestar correctamente las dos preguntas son aquellos que se han planteado alguna vez mover su TI a un CPD o a La Cloud!

He sido CIO de una aseguradora durante 10 años y los entiendo perfectamente (me gustó un artículo hace mucho tiempo ¿Porqué los CIOs no confían en las montañas rusas? ) y el problema es siempre el mismo.

Como decía el primer punto es la falta de confianza. ¡Pero es que no hay que poner todos los huevos en el mismo cesto! ¿ y como lo vamos a hacer?  Pues poco a poco y sin equivocarnos…..

Particularmente creo que hay varios “approaches” al tema. En primer lugar, haga un diseño de todo su TI, incluyendo el “on-premises” y el “off-premises”, con eso Vd tendrá la visión de su Cloud Híbrida. Así sin darse cuenta Vd. verá que dispone de un “pool” de recursos inside y otro offside.

Momento muy bueno para plantearse ¿Por qué no hacemos las copias aquí en local y un “copy job” en off-site?  ¡Un primer paso para disponer de una Cloud Híbrida!

el futuro de la cloudEsto nos podría conllevar a “Si tengo los datos allí, los puedo levantar en un DR con cierta facilidad, no?”

En un momento de “pico” de trabajo, Vd puede alquilar y aprovisionar infraestructura en remoto para, por ejemplo, tener desarrollo en la Cloud, o bien convertir todo en un DRaaS, enlazando la copia con la recuperación en una plataforma remota.

La última estrategia que he visto es quedando el hardware “local” con ciertos años, contratar los servicios generales en cloud, siendo los servicios locales que son los de respaldo (pero este caso es rara avis…. )


Por ello entiendo que el modelo que se debe plantear es un movimiento “smooth”, donde además el modelo permita ir paso adelante, paso atrás (Clouds Híbridas!)

Sé que varios de Vdes. están esperando por la cultura….  Verán, allá por 1987 yo era un técnico que mi función era, dentro de una gran industria química, forma y “vender” el uso de los PCs bajo es escepticismo de mis compañeros del IBM 4381 que creían que esos “ordenadores” eran simples juguetes. Lo mismo pasaba en los departamentos. ¡Había 1 ordenador y una impresora por departamento! Hasta que llegó, y llegó la cultura del PC y yo iba arriba y abajo instalando PCs ¡1 por mesa! quien lo hubiera  imaginado nunca!!!

Y esta es mi conclusión. Sí señores, la crisis ha ahogado mucho a la Cloud, pero no ha habido programas y estrategias de atraer los servicios de TI de una forma “gradual” hacia la Cloud. Cuando llegue la cultura de Cloud, recuerden mis palabras.

Take care,

Source: jmgriscom