Desmitificando el fabric

Desmitificando el concepto Fabric para la planificación de infraestructuras de TI

Es cierto que se suele confundir con estrategias de marketing de distintos fabricantes de tecnología.
Fabric de redes, fabric de seguridad, datacenter fabric. Cada vendor coloca un nombre grandilocuente al lado de la palabra fabric.

En las siguientes líneas intentaré sacudir algo del humo al rededor del concepto de fabric para la planificación de infraestructura de TI.

Simon Sinek escribe en su libro “empieza con el porqué” cientos de ejemplos de empresas exitosas y personas innovadores que lograron que hoy los estudiemos por su éxito. En resumen el libro distingue las preguntas “qué”, “cómo” y “por qué” y me parece una gran analogía de lo que quiero comentar en los siguientes parrafos.

Muchos de los proyectos de infraestructura de TI inician con “qué” y continúan con el “cómo”.

Ejemplos:

  • Qué: crear una red social interna para la compañia.
  • Cómo: usando desarrollo HTML5 y la nueva infraestructura de TI.
  • Qué: implementar una plataforma de e-commerce para la empresa.
  • Cómo: adquiriendo una platadorma As-a-Service.
  • Qué: implementar autservicio en la creación de nuevos ambientes de TI para desarrollo y producción.
  • Cómo: adquirir herramienta de orquestación y los servicios relacionados.

No quiero decir que detrás de los ejemplos no sepamos el “por qué”, de hecho está escondido entre líneas. O algunos dirán que está implicito. Lo damos por hecho.

Deberíamos entonces, cambiar el orden de las preguntas. Haciendo explícito siempre el “por qué” en primer lugar, el “cómo” en segundo lugar y en tercer lugar el “qué”.

Sinek nos dice que el “por qué” nos recuerda la necesidad, la solución y el propósito inicial de lo que sea que estemos encarando.

Además de tener siempre presente el propósito, definir el “por qué” en primer lugar genera conexión con terceros u otras áreas, y orienta las siguientes decisiones.

Llevándolo a nuestro tema de conversación mientras más complejo el proyecto, más importante será empezar por el “por qué” y tenerlo siempre presente.

Vuelvo al primer ejemplo. El “por qué” de la red social interna sería algo parecido a “conectar a los colaboradores, crear comunidades y compartir conocimiento en la compañia”.

Este podría ser un proyecto complejo, además debe incluir a otras áreas fuera de TI como por supuesto finanzas y recursos humanos, para la aprobación previa y socialización para su utilización posterior.

El roadmap y la planificación del mismo puede contener implementación de infraestructura base como ser networking, cómputo, seguridad, desarrollo y soporte. Si recordamos el propósito inicial en cada fase será más sencillo que cada persona, área o proveedor implicado no pierda el norte y se mantenga alineado a lo que se buscaba inicialmente.

Por eso me gusta el concepto de fabric en el que todas las piezas se integran para lograr algo. Todas las piezas se unen para un propósito. Este fabric puede por complejidad o costo prolongarse varios años. Pero el fin del fabric sigue siendo el mismo de forma transversal para todas las fases.

Otro ejemplo:

  • Por qué: Acelerar la entrega de nuevos productos y servicios digitales, aumentar la agilidad para nuevos desarrollos para liderar el mercado o ser más competitivos.
  • Cómo: Implementando una plataforma de orquestación de contenedores para automatizar el despliegue y gestión de aplicaciones
  • Qué: Implementación de Plataforma de Kubernetes
En el mismo orden de ideas, podemos traer el concepto de Security Fabric.

Un propósito general podría parecerse a “Proteger los datos sensibles de la empresa, garantizando la continuidad de las operaciones al minimizar el riesgo de brechas de seguridad minimizando la complejidad y la gesión de las herramientas de seguridad”.

Cómo lo logro: Incorporando herramientas que se integren entre sí, que permitan responder a amenazas y ataques de seguridad de manera independiente o unificada. Con la menor cantidad de plataformas por administrar.

Qué: Adquiriendo Firewalls, herramientas de endpoint protection, web and API protection, herramientas de visibilidad y trazabilidad que se integren, y puedan automatizar su respuesta y administrarse de manera centralizada.

El primer año del proyecto podríamos incorporar firewalls, el segundo herramientas de endpoint protection y el tercero el resto de soluciones. Pero siempre recordando que deben poderse integrar y automatizar la respuesta entre ellas para proteger los datos sensibles de la empresa, garantizando la continuidad de las operaciones al minimizar el riesgo de brechas de seguridad minimizando la complejidad y la gesión de las herramientas de seguridad.

La clave está en saber dónde queremos ir y cómo queremos llegar. Definiendo un “por qué” y construyendo un roadmap con hitos medibles.

Este es un artículo original del blog. Si le sirve o le parece interesante por favor compártalo.

Deja una respuesta