Beneficios de TI: ¿Por qué algunas empresas nunca pueden lograr los beneficios de su inversión?

Beneficios de TI: ¿Por qué algunas empresas nunca pueden lograr los beneficios de su inversión?

Lograr los beneficios de una inversión en TI es mucho más que solo comprar o implementar una tecnología. Aprende cómo puedes estar preparado para eso.

Si hay una sola verdad que este año ha proporcionado a la mayoría de las empresas es que vivimos en un mundo digital. Ya no es el futuro.

Para estar preparados para este presente, la mayoría de las empresas de todos los sectores han invertido mucho en tecnología. Han escuchado todos los beneficios que los últimos desarrollos en tecnología han proporcionado a algunas empresas y les gustaría obtener los mismos beneficios.

Pero después de un tiempo, intentaron implementar los mismos principios y herramientas y no están viendo los beneficios. Seguro, vieron alguna mejora, pero nada comparado con lo que esperaban. ¿Por qué está sucediendo esto? ¿Por qué algunas de estas empresas no están siendo capaces de desbloquear estos logros?

Una herramienta es una herramienta, nada más.

Cualquier principio o herramienta tecnológica, no importa si estamos hablando de un nuevo paradigma como la contenedorización o sin servidor, o una herramienta como una plataforma de gestión de API o una nueva arquitectura impulsada por eventos, son solo herramientas en manos de las personas.

Y, al final, lo que más importa es la forma en que esas personas trabajan y cómo usan las herramientas que tienen a mano para lograr los beneficios óptimos. Las empresas tienen computadoras desde hace quizás 30 años, ¿recuerdas cómo era el uso inicial de esas computadoras? ¿Crees que la gente en ese momento las usaba al nivel óptimo? Entonces, aquí es lo mismo.

No deberías esperar que solo porque has instalado una herramienta, implementado una nueva tecnología o comprado una nueva aplicación SaaS, en ese momento exacto la vida de tu empresa va a cambiar y vas a desbloquear todos los beneficios que vienen con ella. Es la misma historia que una agenda no te hará más productivo solo porque tienes una.

Sí, es un requisito, pero esto está lejos de ser el único paso que necesitas dar para poder lograr el éxito de esa inversión.

Lo que importa es tu forma de pensar

Un nuevo paradigma en TI requiere una forma diferente de pensar, una sensación de confianza en este paradigma para poder desbloquear esos beneficios.

Si no lo haces de esa manera, serás tú quien detenga el progreso y bloquee los beneficios que puedes obtener. Y eso siempre es difícil al principio. Al principio, si tenemos una fórmula hecha en Excel y la misma en papel, creemos que la del ordenador estaba equivocada.

Hoy es al revés. Sabemos con certeza que el ordenador lo está haciendo bien, así que tratamos de encontrar nuestro propio error para obtener el mismo resultado.

Algunos gerentes de TI ahora tienen la misma sensación con otras técnicas y tratan de gestionarlas y controlarlas usando los mismos principios que siempre han aplicado. Y seamos honestos: Eso es normal y es humano porque todos tratamos de usar los patrones que conocemos y los que han demostrado ser exitosos en el pasado cuando enfrentamos algo similar.

Pero, seamos honestos: ¿Crees que Netflix o Uber tuvieron éxito usando los mismos patrones y reglas que han estado usando en el camino? Por supuesto que no.

Pero tal vez pienses que no es una comparación justa porque tu empresa o tu sector no está en juego y en medio de una revolución, solo necesitas pequeños cambios para obtener esos beneficios. No necesitas hacer todo desde cero. Y eso es cierto.

Al final, lo que es relevante es si estás listo para dar el salto de fe al vacío. Para introducirte en la jungla solo con tu intuición y el conocimiento que has adquirido hasta ahora para guiarte durante ese camino.

Sé un investigador

En realidad, el salto al vacío es necesario, pero esto se refiere más a la forma en que piensas. Es estar listo para abrir tu mente y dejar atrás algunos prejuicios que puedas tener. Al final, esto es más similar a ser Marie Curie que a Indiana Jones.

Los investigadores y científicos siempre necesitan estar abiertos a una forma diferente de hacer las cosas. Tienen sus bases, su experiencia, el conocimiento de todo lo que se ha hecho en el pasado, pero para ir un paso más allá necesitan pensar fuera de la caja y estar abiertos a cosas que no eran ciertas hace varios años o cosas que no eran la forma correcta de hacerlo hasta ahora. Porque estás yendo más allá de lo que nadie ha ido.

TI es similar, no estás entrando en lo desconocido, pero dentro de tu empresa tal vez seas tú quien necesite guiar a todos los demás durante esa ruta y estar abierto a pensar que tal vez las viejas reglas no se aplican a esta nueva revolución y estar listo para dejar algunas prácticas antiguas para desbloquear mayores beneficios.

Resumen

Al final, cuando adoptas una nueva tecnología, necesitas pensar en las implicaciones que esa tecnología requiere para hacerla exitosa o incluso optimizar los beneficios que puedes obtener de ella.

Pensar en otros que han recorrido ese camino y aprender de sus aciertos y sus errores, para que puedas estar preparado y también ser realista. Si no vas a realizar el cambio que la tecnología requiere en tu organización, la inversión no tiene sentido. Necesitas trabajar primero en preparar a tu organización para estar lista para el cambio, y ese momento es el momento de introducirte en la jungla y obtener todos los beneficios que te están esperando.

¿Quieres ser un mejor administrador de sistemas? ¡Aprende a programar!

¿Quieres ser un mejor administrador de sistemas? ¡Aprende a programar!

Estamos viviendo tiempos en los que se escucha hablar de DevOps en todas partes, cómo se deben eliminar las barreras entre estos dos mundos como Desarrollo y Operaciones, pero todos estos discursos se basan en el punto de vista del desarrollador y del negocio, pero nunca desde el punto de vista del Administrador.

Venimos de una época en la que los equipos de operaciones estaban divididos en varios niveles de escalamiento donde cada nivel debía estar menos poblado y más capacitado que el anterior. Así que tenemos un primer nivel con personas con conocimientos básicos que trabajan 24×7 cubriendo cualquier tipo de incidente que pudiera ocurrir. En caso de que ocurra algo, intentan resolverlo con el conocimiento (generalmente más documento que conocimiento…) y en caso de que algo no funcione como se espera, lo derivan a un segundo nivel con más conocimiento sobre la plataforma donde probablemente sean un equipo de guardia para manejar eso y vamos a tener tantos niveles como se desee. ¿Cómo encaja todo esto con DevOps, CI & CD y demás…? Ok, bastante fácil…

El Nivel 1 hoy en día no existe: Las herramientas de monitoreo, CI & CD y demás, hacen innecesario este primer nivel, porque si puedes crear un documento con los pasos a seguir cuando algo sale mal, estás escribiendo código pero dentro de un Documento, así que nadie te detiene para entregar una herramienta automatizada para hacer eso. Entonces, en inglés sencillo, los operadores de primer nivel de ayer ahora son scripts. Pero todavía necesitamos nuestros equipos de operaciones, nuestro servicio 24×7 y demás… seguro, porque de vez en cuando (más a menudo de lo que nos gustaría) sucede algo fuera de lo normal y eso necesita ser gestionado.

Entonces, la automatización nunca va a reemplazar a L2 & L3, así que vas a necesitar personas capacitadas para manejar incidentes, tal vez podrías tener un equipo más pequeño a medida que automatizas más procesos, pero nunca puedes deshacerte de la parte del conocimiento, ese no es el punto. Aquí, podemos discutir si este equipo podría ser el equipo de desarrollo o un equipo mixto de ambos mundos, y eso podría ser correcto. Cualquier enfoque es válido con esto. Así que, hemos implementado todos nuestros nuevos y elegantes procesos de CI & CD, herramientas de monitoreo y las plataformas parecen estar funcionando sin ninguna ayuda y soporte hasta que algo realmente extraño sucede. Entonces, ¿qué hacer con esa gente? Por supuesto, enseñar las habilidades para ser valiosos como L2 & L3, así que tienen que ser mejores operadores / administradores de sistemas / cualquier palabra que más te guste. ¿Y cómo pueden hacer eso?

Como dije antes, estamos pasando de un mundo donde los equipos de Operaciones trabajan basados en procedimientos escritos y tienen su imaginación limitada para mirar más allá de su protocolo aprobado, pero eso ya no es la forma en que L2 & L3 trabaja. Cuando te enfrentas a un incidente, el procedimiento es bastante similar a cazar un error, o si escapamos del mundo de TI, es como resolver un crimen. ¿Cuáles son las similitudes entre resolver un crimen y gestionar una plataforma? Ok, enumerémoslas:

  1. – ¿Qué? — ¿Qué le pasó a mi sistema? Comienzas con las consecuencias del problema, probablemente un rastro de error en el registro, probablemente otro sistema llamándote porque tu sistema no está disponible… Ok, aquí lo tienes, este es tu cadáver.
  2. ¿Cuándo? — Cuando sabes que algo salió mal, comienzas a encontrar la causa raíz, y comienzas a buscar rastros de registros para encontrar el primero que generó el problema, incluso descartas los rastros de registros que son consecuencias del primero, y tratas de encontrar cuándo todo comenzó a fallar. Para hacer eso, necesitas buscar evidencias sobre el fallo y demás… Así que ahora, estás investigando, buscando evidencias, hablando con testigos (sí, tus rastros de registros son los testigos más confiables que vas a encontrar, rara vez mienten. Es como si estuvieran en el estrado frente a un juez)
  3. ….. ¿Y ahora? ¿Cómo & Por qué? — Y ese es el punto difícil, cómo & por qué, son los siguientes pasos como lo haces en una caza de errores, pero la principal diferencia aquí, es cuando el equipo de desarrollo está cazando un error, pueden correlacionar las evidencias que recopilan en el paso dos, con el código fuente que construyeron para saber cómo y por qué todo salió mal… Pero en tu caso, como administrador de sistemas probablemente te enfrentas a un sistema propietario o no tienes acceso al código o cómo enfrentarlo incluso si fuera de código abierto… y probablemente ni siquiera tienes acceso al código fuente del equipo de desarrollo… Entonces, ¿cómo resuelves esto?
  • Ok, probablemente la mayoría de ustedes están pensando algo como: Conocer el producto y tu plataforma. Ser un operador certificado del producto que estás gestionando, conocer todo el manual del producto, y demás… Y eso podría ser útil, porque eso significa que sabes mejor cómo funcionan las cosas a un nivel alto… pero… seamos claros: ¿Alguna vez encontraste en un curso de certificación, o examen o documentación o lo que sea, información de tan bajo nivel que podría ayudarte en el caso específico que estás enfrentando…? En caso de que la respuesta a mi pregunta sea sí, tal vez no estás enfrentando un error difícil, sino un error de configuración principal…
  • Entonces… ¿qué podemos hacer? Como dice el título: Aprende a programar. Pero probablemente estás pensando, ¿cómo puede estar relacionado saber programar con cazar un error cuando no tengo acceso al código ni siquiera para echar un vistazo? Y… ¿aprender a programar en qué lenguaje? ¿en los componentes que se gestionan en mi plataforma? ¿en java? ¿en Go? ¿En node.js? ¿En C++? ¿En x86? ¿Todos ellos? Ok… tienes razón, tal vez la pregunta no es simplemente aprender a programar, pero esa es la idea: Aprende a programar, aprende a diseñar, aprende a arquitectar soluciones… ¿Quieres saber por qué? Ok, veamos. En toda mi carrera he estado trabajando con muchos productos diferentes, diferentes enfoques, diferentes paradigmas, diferentes lenguajes base, todo diferente, pero todos comparten una cosa, que todos los sistemas hoy en día comparten: Están construidos por personas.

Sí, cada pieza de software, cada servidor, cada programa, cada página web, cada todo está construido por una persona, como tú y como yo…

Si piensas que todos los productos y piezas de software están hechos por genios, estás equivocado. ¿Eres consciente de cuántas piezas de software están disponibles? ¿Crees que existen tantos genios en todo el mundo? Por supuesto, son personas capacitadas y algunas de ellas son realmente brillantes, y es por eso que generalmente siguen el sentido común para arquitectar, diseñar y construir sus soluciones.

Y ese es el punto que podemos usar para resolver nuestro caso y resolver nuestro asesinato, porque con las evidencias que tenemos y las ideas de construir soluciones, tenemos que pensar: Ok, ¿cómo habría construido esto si yo fuera el encargado de esta pieza de software? Y vas a ver que tienes razón casi todo el tiempo…

Pero me falta otro punto importante que dejamos sin respuesta antes… ¿Aprender a programar en qué lenguaje? En el que tu plataforma está basada: Si estás gestionando una plataforma basada en OSGi, aprende mucho sobre desarrollo en java y desarrollo y arquitectura OSGI, vas a encontrar que todos los problemas son lo mismo… Una dependencia entre dos módulos OSGI, y una sentencia Import-package que debería estar allí… la otra en la que alguien carga los paquetes o alguna sentencia Export-Package que debería estar allí…

Lo mismo, si estás ejecutando una aplicación de escritorio .NET, aprende mucho sobre desarrollo .NET y serás lo suficientemente capacitado para no necesitar un documento para saber qué hacer, porque sabes cómo debería funcionar esto… y eso te llevará a por qué está sucediendo esto.

Y con todas esas preguntas respondidas, solo queda una cosa. Necesitas poner en marcha un plan para mitigar o resolver el problema, para que el problema nunca vuelva a suceder. Y con todo eso, presentamos nuestra orden de arresto al incidente.

Finalmente estás en la parte del juicio, cuando presentas tus evidencias, tu teoría sobre cómo y por qué sucedió esto (el motivo :P) y deberías poder convencer al jurado (el cliente) más allá de una duda razonable, y finalmente terminas con la sentencia que pediste para el error/fallo/incidente que es el plan de mitigación, y tu plataforma es un mundo mejor con un incidente menos caminando libre.

Lo que describimos aquí es cómo hacer un análisis post-mortem y probablemente para la mayoría de ustedes esto es algo diario que hacen, pero todo el tiempo en los clientes cuando trabajamos en colaboración con el equipo de operaciones, notamos que no siguen este enfoque, por lo que están atascados porque no tienen un documento que nos diga cómo hacer (paso a paso) en estas situaciones extrañas.

Así que, me gustaría terminar con un himno para resumir todo esto: Cuando te enfrentas a un incidente: «Mantén la calma, aplica el sentido común y comienza a leer los rastros de registros!!»