Cartas a un enemigo silencioso

Estimad@s lector@s

No me he desviado del carácter puramente técnico de éste blog. El título no es algún pseudo-ensayo de un aspirante a columnista. Sin embargo, el título es la que considero por ahora, la mejor manera de resumir el objetivo de éste post: empezar a arrojar luz sobre un enemigo silente que ha establecido un régimen en la mentalidad de todos los que hacemos parte del mercado de tecnología empresarial para hacernos pensar que es ésta la única manera concebida de hacer que la innovación surja y la tecnología funcione. Les hablo de la complejidad.

Allá por 1962 el venerado Herbert A. Simon estableció una definición de complejidad en su trabajo seminal titulado “The Architecture of Complexity” que va mas o menos así: un sistema complejo es uno compuesto de varias partes que interactúan entre sí de formas no simples. Otra característica de tales sistemas es que si conocemos sus componentes y lo que pueden hacer por separado, no es trivial inferir lo que hacen cuando se unen en un sistema completo.

De acuerdo con Simon, una de las principales estructuras de complejidad presentes en la naturaleza, las organizaciones y en general en nuestro universo es la jerarquía. Un sistema se considera jerárquico cuando se puede descomponer en diferentes subsistemas, los cuales a su vez se pueden seguir descomponiendo en otros. ¿Hasta cuándo descomponer? Lamentablemente en cada contexto, los diseñadores -o la naturaleza- definen lo que consideran una unidad fundamental debajo de la cual no hay más subdivisiones. Aunque la complejidad surge nada más con la presencia de la jerarquía, hay mayor grado de complejidad a medida que se amplía el número de subsistemas en los cuales se divide un sistema completo.

Todo lo anterior, y mucho más presente en el trabajo de Simon, no pasaría de ser un importante descubrimiento en la psicología organizacional de no ser porque allí se pone en evidencia un hecho muy importante: la complejidad cuesta, y cuesta mucho. Tiene un efecto profundo y duradero en los individuos y las organizaciones, reduciendo drásticamente su capacidad de agregar valor y exceder las expectativas que sus clientes o interlocutores tienen de ellos.

El costo de la complejidad: una parábola

Para ayudar a aclarar el tema, Herbert A. Simon incluyó en su articulo una parábola magnífica que resumo aquí: dos relojeros, uno de nombre Hora y el otro, Tempus. Los dos excelentes en su oficio y muy exitosos pues el teléfono de la oficina de cada uno sonaba con frecuencia con clientes del otro lado haciendo nuevos pedidos. Todo parecía ir bien, sin embargo después de un tiempo, Hora prosperó cada vez más con su negocio, pero Tempus fue decayendo hasta que tuvo que cerrar su local. ¿Que pasó?

tempushora

Bien, los dos fabricaban el mismo tipo de reloj: una obra de arte compuesta de mil piezas. Sin embargo, Tempus trabajaba con cada componente pieza por pieza y tenía que terminar cada reloj en una sola sesión, entonces cada vez que sonaba el teléfono y debía contestar -lo cual era cada vez más frecuente- las piezas se desarmaban y debía iniciar desde cero. Por otro lado, Hora tenía las mismas 1000 piezas pero había diseñado su reloj de tal manera que podía agrupar 10 piezas y convertirlas en un subcomponente. A su vez, podía luego unir 10 de esos subcomponentes y convertirlos en una pieza mayor, y con 10 de esas piezas mayores tenía un reloj completo. Esto es, el diseño de Hora abstraía la complejidad inherente del reloj.

A través de unos cálculos matemáticos sencillos documentados en el artículo del profesor Simon, y que tienen en cuenta la probabilidad que cada relojero tiene de ser interrumpido, se llega a un estimado en que a Tempus le tomaba 4.000 veces más tiempo completar un reloj que a Hora. Pensémoslo un momento, el pobre manejo que hizo Tempus de la complejidad en ésta historia, hace que mientras un relojero satisface los requerimientos de 4.000 clientes, Tempus sólo satisface a uno.

Aterrizaje en IT

Entendido, ¿y ésto que tiene que ver con tecnología?

Todo.

Permítame ilustrarlo con un diagrama que elaboré en el que, después de un buen tiempo de experiencia en campo en el diseño, implementación y operación de servicios de nube pública, privada e híbrida; condenso sin exageraciones lo que sería una arquitectura promedio para una nube sin que necesariamente aplique para un solo fabricante:

Cloud_arch_complex

Dependiendo el fabricante de elección, pueden haber más o menos componentes pero, al menos en mi experiencia, estos son los ingredientes promedio para una nube en un entorno enterprise. Y esto es sólo para proveer IaaS; otros modelos de servicio requerirán más componentes.

A la luz de las ideas del profesor Simon, este es un sistema complejo en toda su gloria: una jerarquía con múltiples subcomponentes que se interrelacionan entre sí de formas no triviales y para los que, si se toman por separado, no es elemental inferir exactamente qué es lo que hace el sistema completo.

¿Cuál es el costo de la complejidad en éste contexto?

Veámoslo por etapas:

Ciclo de ventas

Los que hacemos parte de esta etapa, estamos inmersos en un sistema que prácticamente premia la complejidad. Entre más componentes se agreguen mayor beneficio. Cada componente tiene decenas de features pero muy comúnmente se incluyen sólo por uno de esos features; lo demás permanece sin uso pero si requiriendo mantenimiento. Este aspecto parece poco visible desde esta etapa y ciertamente poco nos afectaría que nuestra flamante solución resulte en una enorme carga operacional, pero por el bien del beneficio a largo plazo de nuestras marcas y nuestros clientes, creo que un comercial o preventa sensato, debería pensar en esto.

Diseño

En esencia, la labor de diseño consiste en capturar exitosamente los Requerimientos del cliente, minimizar los Supuestos a través del levantamiento de información y un enfoque consultivo, identificar y documentar de manera anticipada los Riesgos y reconocer las Restricciones del proyecto. Entonces, cuando hay tantos componentes disimiles que pueden hacer tantas cosas e interactuar de tantas maneras entre sí, surge una complejidad que cuando menos, significa más tiempo en la etapa de Diseño y también una mayor probabilidad de dejar Riesgos sin contemplar o no lograr que el amplísimo mundo de Requerimientos -léase deseos– de un cliente, frente a las innumerables opciones que brinda el software se encuentren en una solución que realmente agregue valor y sea viable de implementar y operar.

Implementación

Esta es interesante. Las unidades de servicios profesionales -especialmente las de muchos fabricantes- son parte de éste esquema pues la estabilidad del trabajo y del nivel de ingresos está directamente relacionada con la complejidad que se le ha vendido a un cliente. Entre más compleja una solución, más sofisticado parece el consultor y mejor pagado es. Por otro lado, así como a Tempus le sucedía, la incapacidad de abstraer la complejidad hace que el trabajo sea serializado y obedezca a unas directrices de diseño que a todas luces favorecen la agregación de subsistemas y características a costa de tiempo de implementación.

El proyecto de nube de gran escala que más rápido he visto concluir ha tomado 5 meses. Eso en horas, y teniendo en cuenta solo un 70% facturable, daría unas 560 horas. Si éste es Tempus confeccionando su reloj y Hora tarda 4.000 veces menos, eso serían poco más de 8 minutos. ¿Habrá un día una manera de entregar un servicio como éstos para un entorno enterprise en un tiempo como ése? El tiempo lo dirá.

Operación

Esto se pone peor. Con una considerable cantidad de elementos disimiles por entender -para lo cual quizá requieran entrenamiento formal y servicios profesionales- y operar, la calidad de vida para quienes trabajan en ésta área se reduce con el tiempo. Esto lo he visto suceder en diferentes verticales y diferentes geografías y lo más frustrante es ver que parecemos aceptar que así es como son las cosas: es necesario correr listas de chequeo “preventivas” sobre todos y cada uno de los componentes, tratando de alinearnos con un evento de naturaleza cuasi aleatoria como lo es una falla en el software o hardware, y además contar con matrices de escalamiento, turnos rotativos, ventanas de mantenimiento, servicios profesionales para hacer actualizaciones (no quisiera vivir para ver uno más de éstos) y, en suma, consumir la vida tratando de evitar lo inevitable: el software eventualmente funciona y el hardware eventualmente falla. El problema aquí es que en un sistema complejo, el procedimiento para la resolución de problemas difiere de componente a componente y esto significa menor cumplimiento de SLAs, mucho mayor OPEX y en suma, mucha menor eficiencia.

Conclusión

Todo lo que escribo aquí es producto de muchas horas de reflexión solitaria al respecto de mi labor y el mercado de tecnología en el que me he desempeñado por años y, como espero hayan notado, no se trata de ningún fabricante en particular. ¿Cuál es el punto, cual es el objetivo entonces? Este es mi blog personal y como tal, es eso precisamente; una ventana también a lo que pasa por mi mente y que considero relevante compartir. ¿Este post va a cambiar en algo el status quo? Seguro que no. Pero al menos podrá ser útil para que otros más tomemos conciencia de cómo nos hemos convertido en mercaderes de la complejidad y que cada uno, desde su rol, puede hacer algo para abstraerla. No se trata de remover la complejidad o ignorarla pues ésta es una característica inherente de nuestro universo: con el tiempo todo evoluciona hacia lo complejo. Sin embargo, el desafío de las mayores mentes de la naturaleza – nosotros- en uno de los medios profesionales de mayor énfasis en el conocimiento – la tecnología- es que logremos absorber la complejidad y traducirla para las masas. Yo creo que ese si es el verdadero mérito intelectual en ésta profesión.

Saludos!

 

 

 

 

Advertisements

Mi experiencia en el VCAP-CIA

El pasado lunes, Pat Gelsinger (VMware CEO) compartió una definición de valentía: ser decisivo en tiempos de incertidumbre. Bueno, debo decir que las circunstancias que en últimas me llevaron a tomar y aprobar el examen VCAP-CIA darían para pensar que algo de valentía hay en m, pues llegue el sábado pasado a San Francisco para VMworld y fue allí en la habitación del hotel donde decidí aprovechar el descuento, programar el examen para el día siguiente (!!) y terminar de estudiar en menos de 24 horas el 48% del blueprint, que era lo que me faltaba. Habiendo tardado alrededor de 3 meses estudiando el primer 52% (con toda la práctica necesaria) la tarea por momentos me pareció que había sido un gran error.

Finalmente presenté el examen y después de intensas 4 horas, esta es mi experiencia y mis recomendaciones:

1. Si ha leído previamente que uno de los factores más importantes para el éxito en un examen VCAP es la administración del tiempo, yo agregaría a ello la habilidad de desarrollar múltiples (entre 2 y 3) preguntas al mismo tiempo. Esto tiene que ver con que, al menos en mi experiencia, me había tomado 2 horas en resolver nada mas 8 preguntas, restaban 24 y la regla de tres simplemente daba para reprobar el examen por contestar solo la mitad. Fue allí que empecé a desarrollar tres preguntas a la vez anotando en la pizarra que Pearson suministra en el examen los números de esas preguntas para tener una rápida referencia visual y no olvidar responder ninguna a medida que avanzaba en las demás. Esta técnica salvó mi resultado en el examen.

2. Si ha leído previamente que el examen toca TODO el blueprint ha leído bien. No subestime ningún skill o habilidad que allí vea pues todas sin excepción serán evaluadas.

3. Recuerde que vCloud Director corre en un ambiente Linux por lo que debe sentirse a gusto con la linea de comandos y sin importar la tarea, siempre las man pages y la ayuda de los comandos evita que tenga que aprender de memoria comandos u opciones de los mismos.

4. El examen, como lo indica su versión de prueba o mock disponible en my.learn.vmware.com esta pensado para simular un ambiente de producción por lo que no debe temer considerarlo como tal y operarlo con el cuidado y proactividad necesarias.

Utilicé como principal recurso de estudio la guía de virtualizationexpress.com y el laboratorio que mi empleador me ha suministrado.

Sin mas, estoy feliz y sorprendido de haber aprobado. Se puede lograr mucho cuando estas bajo presión 😉

Saludos

vExpert 2014: ¡gracias totales!

La noticia me tomó por sorpresa.

Había aplicado al programa VMware vExpert para el Q2 de 2014 en el track de Customer, y aunque rellené los campos en el formulario, realmente no pensé nunca que me fueran a seleccionar, menos aún contemplando la labor de algunos de los demás profesionales en la lista publicada.

Sólo tengo palabras de gratitud para mi esposa, porque comprende mi interés y pasión por la computación en general, y la virtualización en particular.

También que ésta sea una oportunidad para agradecer públicamente a Dios, cuya gracia y amor me han traído hasta aquí.

Los escenarios de participación y aporte a la comunidad en que he podido estar presente, han sido creados o promovidos por la comunidad #vBrownBag a quienes extiendo mi agradecimiento.

El reconocimiento me convierte en el tercer vExpert de mi país, y ésto solo renueva mi compromiso por permanecer relevante y aportar en alguna medida a la comunidad de tecnología de la región.