La estandarización es buena para NetOps
A veces se considera la estandarización como un ataque a la innovación. Verse obligado a abandonar un buffet políglota y adoptar un menú más limitado suena asfixiante, sin duda. Esto puede deberse a que a menudo la estandarización se asocia con normas de cumplimiento normativo que tienen nombres que suenan oficiales, como ISO 8076.905E, y que conllevan listas de verificación, auditores y comités de supervisión.
La realidad es que hay muy pocos estándares (de hecho, ninguno que pueda recordar) que rijan la elección de lenguajes, protocolos y marcos por parte de las organizaciones empresariales. Lo que impulsa la estandarización en la empresa son consideraciones más prácticas, como la disponibilidad de talento, la sostenibilidad y el costo total de propiedad durante la vida útil (a menudo considerable) del software y los sistemas.
Los estudios han demostrado que la vida útil promedio del software durante los últimos veinte años es de alrededor de 6 a 8 años. Curiosamente, la longevidad tiende a aumentar para los programas más grandes, medidos en líneas de código (LOC). Los sistemas y el software con más de un millón de LOC parecen tener una vida útil de más de una década, con una duración de entre 12 y 14 años. Si bien puede descartarse esto como irrelevante, es importante darse cuenta de que, al fin y al cabo, los sistemas de automatización de red son software y sistemas. Requieren el mismo cuidado, alimentación y mantenimiento que el software que sale de su organización de desarrollo. Si va a tratar su canal de producción como código, entonces tendrá que aceptar que un porcentaje significativo de ese canal automatizado será código.
A lo largo de la vida útil de ese software o sistema, es probable que varios grupos de operadores y desarrolladores sean responsables de actualizar, mantener, operar e implementar cambios en ese software o sistema.
Y esto es exactamente lo que está en el corazón del impulso hacia la estandarización, especialmente para NetOps a medida que se lanzan al desarrollo y mantenimiento de sistemas para automatizar y orquestar la implementación y operación de la infraestructura de servicios de aplicação y redes.
Los silos son para las granjas
Si usted (o su equipo) elige Python mientras otro elige PowerShell, en realidad está construyendo un silo operativo que impide compartir habilidades. Dado que el desafío número uno que enfrenta NetOps, según se informó en el Estado de la automatización de red 2018, fue la falta de habilidades (según lo informado por el 49 %), parecería una tontería crear fricción adicional al introducir múltiples lenguajes y/o conjuntos de herramientas. Asimismo, es una mala idea elegir lenguajes y conjuntos de herramientas para los que no se cuenta con una fuente local de talento. Si otras organizaciones y universidades cercanas enseñan Python y usted elige usar PowerShell, tendrá dificultades para encontrar personas que tengan las habilidades que necesita para trabajar en ese sistema.
Es raro que una organización se estandarice en un solo idioma, pero sí tiende a estandarizarse en solo unos pocos. NetOps debería inspirarse en los estándares de desarrollo y DevOps, ya que esto ampliará aún más el grupo de talentos.
El tiempo para obtener valor es valioso
Muchas organizaciones de NetOps ya se encuentran en una situación difícil cuando se trata de satisfacer las demandas comerciales y de DevOps para lograr la continuidad. La lamentable realidad de NetOps y la automatización de redes es que se trata de un ecosistema heterogéneo con muy poca integración preempaquetada disponible. En la encuesta sobre el estado de la automatización de la red, descubrimos que esta "falta de integración" era el segundo desafío más citado para la automatización, con un 47 % de NetOps de acuerdo.
La estandarización de conjuntos de herramientas e infraestructura cuando sea posible (como los servicios de aplicação ) brinda una oportunidad de reducir la carga de integración en toda la organización. Lo que un equipo desarrolla, otros pueden aprovecharlo para reducir el tiempo necesario para generar valor en otros proyectos de automatización. La reutilización es un factor importante para mejorar el tiempo necesario para obtener valor. Vemos la reutilización en la proclividad de los desarrolladores hacia el código abierto y en el hecho de que entre el 80 y el 90 % de las aplicações actuales están compuestas por componentes de terceros o de código abierto. Esto acelera el desarrollo y reduce el tiempo para obtener valor. El mismo principio se puede aplicar a la automatización de la red aprovechando las integraciones existentes.
Establecer una cultura de compartir y reutilizar en todos los dominios operativos para aprovechar los beneficios de la estandarización.
Impulsando la innovación
En lugar de impedir la innovación, como algunos creen inicialmente, la estandarización puede ser un catalizador para la innovación. Al estandarizar y compartir software y sistemas entre dominios operativos, se cuenta con un conjunto más sólido de mentes y experiencias capaces de colaborar en nuevos requisitos y sistemas. Está creando un grupo de talentos dentro de su organización que pueden aportar información, generar ideas e implementar nuevas características y funcionalidades sin tener que pasar por un ciclo de incorporación que a veces es largo.
La estandarización también acelera la implementación gracias a la familiaridad. Cuanto más trabajes con el mismo lenguaje, bibliotecas y conjuntos de herramientas, más capaz te volverás. Esto significa una mayor productividad que implica dedicar menos tiempo a desarrollar nuevas ideas y más tiempo a considerar cómo diferenciarse y agregar valor con nuevas capacidades.
La estandarización es una oportunidad
Al principio, la estandarización puede resultar sofocante, en especial si el lenguaje o conjunto de herramientas que uno prefiere no está incluido en el equipo. Pero adoptar la estandarización como una oportunidad para construir una base sólida para los sistemas y el software de automatización beneficia al negocio y ofrece a NetOps nuevas oportunidades para agregar valor en toda la cadena de herramientas de implementación continua.
Pero no se debe estandarizar sólo por el hecho de estandarizar. Tenga en cuenta las habilidades existentes y la disponibilidad de talento local. Encuesta a universidades y otras empresas para comprender el estado actual de la automatización y las habilidades y el talento de las operaciones para asegurarse de que no sea la única organización que adopta un lenguaje o conjunto de herramientas determinado.
Para obtener los mejores resultados a largo plazo, no trate la estandarización como si fuera seguridad y la deje hasta que haya completado una implementación. Adopte la estandarización desde el comienzo de sus iniciativas de automatización para evitar verse afectado por una deuda operativa y arquitectónica que lo agobiará y dificultará la estandarización posterior.
Con la estandarización, al igual que con la seguridad, más vale pronto que tarde.