Las estandarizaciones a menudo son vistas por los equipos de proyecto como un obstáculo superar, una suerte de mal necesario para el cual tratan de encajar en el plan de proyecto las tareas que permitan superar su rampa de adopción. Y muchas veces los clientes ven las estandarizaciones como un simple “sellito” que les va a dar una buena imagen para poder predicar en el sector que ellos son “standard-compliant”.

Estandarizaciones y proyectos: más que un obstáculo a superar, un gran facilitador a aprovechar

La realidad es que las estandarizaciones son mucho, muchísimo más que eso. Y ya no es sólo por todo lo que nos pueden simplificar la ejecución de nuestro proyecto y los desarrollos a acometer, sino también porque una estandarización internacional puede abrirnos de par en par las puertas de muchos nuevos mercados. Todo esto es así hasta el punto de que las estandarizaciones pueden ser consideradas como una de las grandes claves que han contribuido a alcanzar el actual grado de progreso tecnológico en nuestras sociedades.

Y si no que se lo pregunten a los padres de internet y todos los estándares abiertos que alumbraron, y, por cierto, que les pregunten también ya de paso acerca de cómo tuvieron que luchar contra los gigantes tecnológicos del momento, y cómo éstos intentaron adueñarse del nuevo invento con lucrativos fines comerciales y propietarios. Si esos padres de internet no hubiesen sabido ver la esencial importancia de hacer que internet se construyese sobre estándares abiertos, hoy nuestro mundo casi seguro que no sería lo que es.

El primer tema a plantearse: ¿Qué se puede estandarizar?

Pues a todo buen gestor de proyecto, la primera pregunta que le debería surgir es: “ok, está bien, voy a intentar aplicar la estandarización en mi proyecto, pero ¿Exactamente a qué tengo que sopesar si aplicar una estandarización o no?”

Bueno, lo cierto es que, por estandarizar, se puede estandarizar (casi) todo. Bien sea con estandarizaciones de mercado, bien con estandarizaciones oficiales de un cuerpo de estandarización, bien sea con procedimientos propios que el propio gestor haya desarrollado o adaptado para la casuística particular de su proyecto.

Por poner algún ejemplo, las estandarizaciones están por todos lados a nuestro alrededor. Desde la misma interfaz de red de nuestra infra con su estándar Ethernet o Wifi, hasta los protocolos de seguridad al estilo ISO27001, pasando por la metodología de proyecto, todo, todo, todo, es susceptible de estar estandarizado de alguna manera.

Así que, ¿Hay que empezar por mirar hasta cómo vamos a poder estandarizar desde las emisiones radioeléctricas de nuestro servidor y hasta cómo vamos a interactuar cada mañana con los miembros de nuestro equipo? ¿Por dónde empezar?

Pues no. Tampoco hay que volverse locos, ni entrar en una estéril fase de “parálisis por el análisis”. No se puede aspirar a estandarizar absolutamente todo en nuestro proyecto, y hay que asumir que debemos centrarnos en lo que resulte más importante para el objetivo del proyecto y nuestro cliente. Además, muchas estandarizaciones nos vendrán dadas ya “de serie”, como es sin ir más lejos el caso de las que poníamos antes de ejemplo (algo extremo) de los interfaces de red, que ya van a venir dadas por la infraestructura y/o por nuestro proveedor cloud.

A partir de este punto del artículo, hablaremos pues en algunos casos de estandarización en general, y abarcando con ello todas las posibles estandarizaciones que sean aplicables a nuestro proyecto en el plano más genérico, puesto que la mayoría de sus principales ventajas con comunes a todas ellas. Y en otros casos hablaremos de estandarizaciones muy particulares, como puede ser una metodología de proyecto, una metodología de desarrollo, una norma de seguridad informática, una arquitectura IT, o una semántica.

Este último caso de la semántica es a menudo poco conocido, y sin embargo cada vez tiene más trascendencia en nuestro actual mundo hiperconectado. Es por ello por lo que ésta la vamos a explicar con un poco más de detalle. La hiperconectividad implica que los servidores y aplicaciones se comunican entre sí y están conectados. Pero para ello no basta con ponerles un cable de red, sino que además de la capa física han de ser capaces de interoperar. Para ello deberán hablar un protocolo común como (por ejemplo HTTPS), que sería como el aire en una comunicación verbal, a través del que se transmiten cambios de presión que son sonidos vocales.

Pero eso no es suficiente. Aparte del protocolo, los sistemas han de hablar también un lenguaje común, que ya sería la semántica. En nuestro ejemplo de comunicación verbal, esto equivale a que además de hablar con sus cuerdas vocales y a través del medio del aire, dos interlocutores deben de hablar un mismo idioma. La semántica es exactamente lo mismo. Si dos sistemas no adoptan una semántica común, no van a poder entenderse en principio, y salvo que se desarrollen adaptadores o filtros semánticos que hagan de traductor (en caso de que sea posible para cada caso concreto).

Así, en todo este maremágnum de posibles estandarizaciones a adoptar para nuestro proyecto, una de nuestras primeras y más importantes tareas será la de evaluar y detectar aquellos ámbitos de estandarización que puedan ser clave para nuestro caso concreto, y que más valor nos pueden aportar. Así, por ejemplo, si nuestro sistema va a interoperar con otros sistemas, bien habrá que definir un protocolo común de llamada como puede ser el propio de HTTPS junto con llamadas REST API, y bien habrá que definir una semántica común como por ejemplo puede ser el estándar semántico HL7 para el sector salud.

Estandarizar o no estandarizar: “That is the question”

La decisión no es baladí, y a la posible dificultad de tener que adoptar, con todas las grandes implicaciones que tendrá tanto en el desarrollo del proyecto como en el producto final entregado al cliente, hay que añadir la dificultad adicional de tener que tomar la decisión más apropiada para nuestro proyecto concreto respecto a la estandarización propiamente dicha.

Además, este tipo de decisiones han de ser tomadas en las primeras (primerísimas) fases de cualquier proyecto. Para empezar, porque sus implicaciones sobre buena parte de los desarrollos son muchas y muy relevantes, y hay que tenerlas en cuenta desde el principio. No optar de inicio por una estandarización que luego puede acabar resultando necesaria supondría crear deuda técnica a espuertas (y de forma totalmente innecesaria y evitable).

Adicionalmente, está el hecho de que para estandarizar hay que dar soporte tecnológico y proveer los diseños, las plataformas y/o servicios que van a permitir tener esa estandarización en el ecosistema del proyecto. Y esto es parte de la definición de la arquitectura de proyecto, que es siempre necesario abordar como parte indispensable de las primeras fases de proyecto.

Y finalmente, estandarizar o no estandarizar es una decisión estratégica que a menudo es recomendable compartir con el cliente, ya que adoptar un estándar no sólo conlleva su impacto sobre el propio proyecto, sino que además puede no interesarle en absoluto al cliente, o el caso contrario: puede querer sí o sí ese estándar y alguno complementario más que le pueda surgir como parte del ecosistema sectorial una vez puestos a adoptar estándares.

Por otro lado, aparte de poder ser un gran facilitador para un proyecto, en la mayoría de los casos un estándar también es una garantía de interoperabilidad dentro (y fuera) del propio ecosistema del proyecto, con terceros productos de otros proveedores, o incluso con otras compañías externas. Tampoco se puede obviar el hecho de que adoptar un estándar puede tener también un aporte reputacional. Todos estos últimos factores refuerzan que, como decíamos, sea más que indicado compartir desde el primer momento la decisión sobre si estandarizar o no con los más altos responsables del proyecto en el cliente.

La primera decisión a tomar es obvia (que no simple, ni mucho menos). Hay que empezar diciendo que tampoco hay que plantearse estandarizar “porque sí”, como si se tratase de un mantra inalienable, pues puede haber casos en los que estandarizar no sea apropiado y/o no merezca la pena, por mucho prestigio que pueda dar.

Y es por ello por lo que realmente, en esta primera aproximación a la estandarización en nuestro proyecto, se debe hacer ya una pequeña fase de investigación. Hay que ver qué estándares serían de aplicabilidad al proyecto, comparar las diferentes alternativas en caso de que las haya con su aporte funcional y arquitectónico, evaluar el grado de madurez y adopción actual de cada una en el mercado, y finalmente evaluar la proyección en el tiempo que se puede estimar que tengan.

Efectivamente, puede no ser idóneo adoptar un estándar que está a punto de ser sustituido por otra alternativa, o un estándar que no goza de adopción en un mercado cuya estandarización masiva es uno de los factores que mayores ventajas traen para el conjunto de sus adoptantes.

¿Por qué estandarizar (casi) siempre que se pueda por el bien de todos?

Bueno, partamos ya de una situación en la que hemos analizado que el aporte de la estandarización para nuestro proyecto es muy bueno, que sabemos qué estándares serían los idóneos para nuestros casos de uso y nuestra estrategia, y además que son maduros y tienen una gran proyección a futuro en el mercado. Decisión clara preclara.

Aún así los factores anteriores no son los únicos a tener en cuenta a la hora de evaluar las ventajas que nos va a aportar el optar por una estandarización idónea. Los anteriores son todo factores que podrían ser considerados como más bien “de proyecto”. Pero las ventajas de estandarizar van mucho más allá, y tienen incluso un alto impacto sobre el conjunto del sector en el que se desarrolla la actividad empresarial del cliente adoptante del estándar.

¿Y por qué no decirlo? Un buen estándar de adopción masiva también puede tener un alto impacto sobre el conjunto de nuestras socioeconomías, y sobre nuestro grado de progreso tecnológico como sociedad. Recuerden el ejemplo de la introducción que les hemos puesto: gracias a los visionarios padres de internet, ahora los estándares han traído una sociedad de la información que ya es una realidad, con todo lo que se ha construido sobre ella, y sin lo cual muchos ya casi no sabrían vivir hoy en día, o al menos lo harían con muchas menos comodidades.

Pero en el mercado, esta vocación y visión estandarizadora ni mucho menos ha sido siempre la norma. De hecho, como expondremos más en detalle más adelante, en décadas pasadas la estandarización muchas veces no alcanzaba las cotas tecnológicas que debiera (lo cierto es que hoy tampoco). En diversos momentos a lo largo de la historia tecnológica el mercado ha estado seriamente amenazado, y a punto de convertirse en un “corralito” del monopolio de facto de turno. Es una lamentable situación en la que el que más pierde es el consumidor o usuario, y la sociedad como conjunto.

Así, los más senior seguro que conocieron esos tiempos en los que los estándares no eran estándares abiertos y de mercado, sino que eran más bien estándares de facto con productos que luego se vendían a precio de oro. Se comercializaban en un mercado sin apenas competencia abierta, y de los cuales era difícil escapar. De este modo, los clientes se veían abocados a seguir pagando año tras año por productos por los que les cobraban literalmente lo que el fabricante de turno quería, y que innovaban lo que igualmente les apetecía: ¿Para qué innovar si te van a seguir comprando tu producto porque no tienen opción?

Efectivamente, estándares abiertos, competencia, innovación y progreso socioeconómico son cuatro máximas que en este tema no sólo van de la mano, sino que se necesitan unas a otras para hacer realidad especialmente esa última del progreso socioeconómico. Porque los estándares de facto y propietarios realmente acababan imponiendo una uniformidad y una homogeneización en el mercado que, en cierta manera, se alguien podría pensar que también propiciaría una economía de escala.

Pero la realidad es que la cara oculta de este tipo de mercado uniforme (el mercado estandarizado a menudo también lo es) pero propietario es que, como esa uniformización se consigue con la adopción masiva de un producto comercial propietario, se está así promocionando un gran customer lock-in. Esto sólo beneficiaba al gigante tecnológico de turno que había conseguido imponer su producto como estándar de facto, y logrando colocarlo con una adopción masiva en el mercado.

Cuando la adopción masiva sin estándares abiertos es una “trampa mortal”

Estas prácticas en realidad no unificaban el mercado, ni creaban esas beneficiosas economías de escala verdaderas al calor de una estandarización abierta y al alcance de todos, tanto proveedores como clientes IT. Esas situaciones de monopolio de facto con los años siempre acaban degenerando en el mejor de los casos en una suerte de enjambre tecnológico de “Reinos de Taifas”. En él cada gran proveedor tecnológico imponía su ecosistema, con toda la rigidez y el ánimo de lucro que se le antojase.

Y eso en el mejor de los casos, porque un escenario mucho más habitual de lo deseable era que hubiese un gran proveedor por nicho de mercado, que se imponía con su producto sembrando clientes cautivos por doquier, y cayendo incluso en eliminar la competencia potencial. Así se protegían de todo aquel emprendedor e innovador que le podía amenazar su “corralito”, y trataban de expulsarlo del mercado con prácticas monopolísticas ejercidas sin piedad contra todo aquel que fuese un nuevo y prometedor jugador del mercado. Eran otros tiempos, y los reguladores pro-competencia tampoco estaban aún tan ductos en este tipo de cuidados a dispensar a todo mercado que aspire a ser sano y competitivo en beneficio de una gran mayoría de la sociedad.

Realmente, hoy en día y hasta cierto punto seguimos asistiendo a una cierta pugna entre los estándares abiertos y los estándares no abiertos de facto. Porque no los propios organismos normalizadores en los que se acuerdan internacionalmente las normas a aprobar, los organismos y empresas anglosajonas habitualmente suelen tender más bien hacia ese modelo pro-estándares de facto y mucho menos abiertos, hasta el punto de que suelen ser bastante reticentes y poner numerosos obstáculos a la hora de acordar y promulgar estándares abiertos que se acaben convirtiendo en estándares internacionales de adopción masiva.

En esas socioeconomías lo cierto es que es mucho más habitual que cada empresa haga la guerra por su cuenta, e imponga como decíamos uno de esos lucrativos estándares de facto. En esos casos, la adopción masiva no es un catalizador del mercado, pues el objetivo no es ya tanto estar en un (mal) mercado como en esos monopolios de facto, sino que lo que hay que crear es un mercado de verdad con la estandarización por bandera.

Por el contrario, si el estándar es abierto, esos riesgos (mayúsculos) se tornan ventajas en la dirección diametralmente opuesta. En vez de vernos atrapados por un estándar de facto, que en realidad es un estándar propietario por el que pagar cuantiosas “royalties”, si el estándar es abierto, su adopción nos va a permitir que migrar un producto o plataforma a otro alternativo de la competencia sea un proceso asumible. Con un estándar un cliente que quiere liberarse de un proveedor necesitará en el proceso mucho menos esfuerzo, costes, y tendrá menos quebraderos de cabeza. Así, el estándar más beneficioso debe de ser necesariamente abierto y que promocione que haya otras alternativas posibles en el mercado, porque para pagar por tu propia celda de presidio tecnológico siempre se está a tiempo.

En último lugar dentro de este apartado, y yendo más por los clientes finales que compran tecnología y la ponen en marcha, se tiene que optar por no estandarizar no sólo afecta a la libre competencia en el sentido más general y de mercado “macro”, sino que también puede tener una grave afectación en términos de microeconomía empresarial. El hecho es que, en el mercado, y especialmente en mercados “de nicho” donde las grandes tecnológicas no han puesto aún sus miras, el panorama IT suele estar muchas veces dominado por otro tipo de empresas. Suelen ser empresas de tamaño más reducido, que han desarrollado sus propias aplicaciones IT y tecnologías, muchas veces para dar servicio a su propio negocio. Muchas de estas compañías acaban viendo el filón de comercializar a terceros ese producto de su propia IT, y lo pasan a vender en el mercado a otras empresas que, lógicamente por tratarse de mercados “de nicho”, casi siempre son su propia competencia.

Esta asimetría deriva en una clara desventaja competitiva para la empresa cliente que compra su tecnología a la empresa que la desarrolla. Al ser ambas competencia del sector, en cualquier momento coinciden en un mismo mercado, o los intereses confluyen para que la empresa desarrolladora vea la oportunidad de cercenar nuestra capacidad de expandirnos y conquistar nuevos mercados. Y para ello el desarrollador y vendedor de esta IT poseerá una potente arma microeconómica: la misma tecnología que le compramos, y que, si ésta es limitada para terceros fuera del fabricante, nuestra empresa estará cautiva. Así acabaremos en una inevitable inferioridad de condiciones tecnológicas para competir con el que es a la vez nuestro proveedor y competidor. Se trata sin duda de un peligroso escenario a evitar por todos los medios.

Pero debe creerse que esta inferioridad de condiciones a la hora de competir puede llegar a ocurrir sólo cuando somos clientes cautivos de nuestra propia competencia. En absoluto. Ser cautivos de una tecnología propietaria nunca es bueno en este sentido, porque nuestra competencia puede igualmente hacer valer de forma indirecta sus intereses sobre alguno de nuestros proveedores estratégicos, y que éste pueda perjudicarnos en favor de su cliente más lucrativo dando prioridad al cliente que más le interesa por el motivo que fuere. Pero ya no es que pueda existir esa competencia desleal “indirecta” en algunos casos, sino que ese temible escenario del proveedor-competidor sobrevenirnos igualmente cuando somos clientes cautivos de una gran tecnológica.

Los colosos tecnológicos en cualquier momento pueden querer conquistar nuestro mercado natural, y entonces serán ellos mismos los que se transformen de “sólo proveedores” a ese dúo mortal de pasar a ser “proveedores y competidores”. El desenlace traería el mismo resultado que si le hubiésemos comprado su tecnología directamente a alguien que ya era nuestra competencia en el momento de la compra. Y si alguien cree a estas alturas que por ejemplo alquien como Google o Amazon nunca van a querer comerse “mi mercado”, que eche la vista atrás a lo que pensaban las entidades bancarias hace tan sólo unos pocos años, y a las intenciones de Google, Apple, Orange, Amazon&Cía y sus (ya más que) ambiciones en el sector financiero y de la banca.

Aparte de estandarizaciones de mercado, la estandarización también es aplicable internamente al día a día de tu proyecto

Pero la estandarización es un acto con cierto aspecto procedimental, y que como tal nos permite estructurar todo tipo de actividad y documentación laboral. Más allá de las estandarizaciones de mercado y/o sectoriales que nos permiten por ejemplo adoptar una norma semántica que garantice la interoperabilidad de nuestro proyecto, también hay mucho más que la estandarización como concepto puede hacer por nuestro proyecto.

Empezando por una adecuada estructura del código, con comentarios debidamente estructurados, con código bien formateado, etc. hasta la elección de qué documentar y cómo hacerlo, pasando por ejemplo por una simple elección de las carpetas en la que almacenar toda la documentación de proyecto, un gestor de proyecto puede seguir estandarizando internamente a nivel de proyecto en las tareas del día a día de los equipos.

Así, bien sea mediante la adoptar una estandarización más metodológica, o incluso de una propia a aplicar allá donde las estandarizaciones de mercado no lleguen, el objeto es que esta estandarización a nivel interno de proyecto dote de una estructura y una lógica común a todas las áreas y a todas las actividades del proyecto. Así, el propio gestor de proyecto conseguirá agilizar la búsqueda y comprensión futura de todas las actividades, entregables, y desarrollos del proyecto en el futuro, una vez hayan pasado varios meses desde que se trabajó en ello, y cuando tal vez deba consultar alguna información o re-estudiar alguna implementación para re-aplicarla.

Pero las ventajas de una estandarización a nivel interno de proyecto no sólo vienen a nivel consultivo, sino que dotar en general de una estructura estandarizada al conjunto del proyecto y de sus actividades permitirá que cualquier miembro del equipo pueda ponerse al tanto de cualquier tema ágilmente, facilitando por tanto el onboarding y la curva de aprendizaje de las nuevas incorporaciones o del propio cliente cuando el proyecto le sea entregado.

No es el objeto de este artículo seguir profundizando en este aspecto de la estandarización, y en ese ámbito finalizaremos simplemente enlazando a una magnífica serie de tres artículos (más uno extra) del compañero Víctor Madrid. En esta serie se aborda esta estandarización “de proyecto” ya desde un punto de vista técnico, que también aporta y es esencial aparte del aspecto más procedimental aquí expuesto:
1.    Validando una Arquitectura con ArchUnit - Parte 1
2.    Validando una Arquitectura con ArchUnit (Parte 2)
3.    Validando una Arquitectura con ArchUnit (Parte 3)
4.    Integrando ArchUnit con SonarQube

Estandarización y mercado: un eterno debate que no debería ser debate, y si una premisa eterna

En la calle siempre ha existido el debate, muchas veces sesgado por los intereses económicos, sobre si crear mercado en el sentido más idealista se basa en fomentar la libre competencia, o por el contrario pasa por propiciar el surgimiento de emporios empresariales de cuño nacional, que luego puedan expandirse por todo el globo y conquistar mercados por doquier.

Aunque tampoco ambas opciones así expuestas tienen por qué ser mutuamente excluyentes en teoría, lo cierto es que en la práctica puede que la existencia de colosos empresariales no tiene por qué vulnerar sistemáticamente la libre competencia, pero no es menos cierto que la proliferación de pequeñas empresas innovadoras y disruptivas es un buen indicador de la salud del mercado y de la libre competencia. Sea como fuere en cada caso particular, el hecho es que los beneficios económicos en general derivados de las estandarizaciones son múltiples y muy importantes, tanto a nivel micro-económico como también macro-económico.

Y además no olviden de que tener las pequeñas empresas disruptivas del presente garantizará poder contar con algunos gigantes del futuro. Ninguna empresa es eterna, el reemplazo empresarial es muchas veces (casi) inevitable, así que es mejor contar con buenos y sanos candidatos para tomarles el relevo a las actuales si fuese necesario. En este mundo hay que transformarse y renovarse o morir, y no dejar hacerlo a nuestro tejido empresarial sólo llevará al resultado de que vendrán otros de fuera a comerse los mercados de nuestras empresas, tanto en suelo nacional como también en el extranjero.

La competencia en el mundo de hoy siempre va a estar ahí esperando a que cometamos un error, y no optar por estándares abiertos y de mercado que sean apropiados es uno de los peores errores que se puede cometer tanto en la gestión de nuestro proyecto, como en la gestión de nuestras socioeconomías. Y además lo harán con los productos y servicios que deberíamos haber sido nosotros mismos los que hubiésemos propiciado que nuestras propias empresas hubiesen podido desarrollar por sí mismas. Y con el caldo de cultivo apropiado habrían podido innovar en un mercado sano, basado en la libre competencia. Sólo así se puede permitir que cualquiera en nuestro país pueda emprender y materializar empresarialmente una buena idea, lo cual además tiene implicaciones en la igualdad de oportunidades más justa.

Es un debate presente desde que nuestro actual sistema económico es tal, pero en los últimos tiempos ha sido soslayado y apartado de la primera plana de medios y círculos económicos. Y la estandarización como hemos visto está directamente relacionada con este debate, de hecho, yo diría hasta que es la piedra angular dentro del mismo. Porque el caso es que, si parece una premisa preclara que “no acaba de” ser lo idóneo un estándar de facto impuesto por la empresa monopolística de turno, entonces la mejor alternativa es que lo que tiene que haber sería un estándar abierto e interoperable cuyas grandísimas ventajas hemos analizado aquí hoy desde múltiples planos.

Así que, también en sus propios proyectos, no tengan miedo, venzan la resistencia al cambio, y no sean perezosos a la hora de empezar a “empollarse” ese nuevo estándar con el que han dado. Todo ello quedará compensado con creces una vez consigan la recompensa que les traerá su estándar en caso de que hayan hecho la elección apropiada. Así que, también como gestores de proyecto, mantengan viva su capacidad de aprendizaje, aguzado su sentido “arácnido” para los proyectos, y a punto su capacidad de adaptación para dar siempre (de verdad) la mejor solución a nuestros clientes.

Para conseguir el ansiado premio, “sólo” deberán esforzarse por salir de su zona de confort, no tener resistencia por enfrentarse a la rampa de adopción de un estándar que sea apropiado, saber mirar al horizonte y ver las grandes ventajas a medio (e incluso corto) plazo para su trabajo, y además tengan en mente que con ello también están poniendo su granito de arena para contribuir a la generalización de la estandarización y por hacer nuestro mundo IT un poco mejor, y que siga siendo fuente de progreso real para nuestras sociedades. ¡Suerte y a por ello!

Si te ha gustado, puedes seguir con la segunda parte: "Todo lo que la estandarización hará por tu proyecto (Parte II)"