Los principios escritos rara vez sobreviven a la presión operativa
Muchas empresas definen principios de arquitectura… hasta que llega una decisión difícil.
Invertimos una buena cantidad de tiempo pensando y creando principios que nos ayuden a guiar las decisiones que se toman en las empresas, principalmente relacionados al uso de tecnología.
Ejemplos tenemos muchos:
→ Buy before Build
→ API first
→ Digital first
→ Standardization before Customization
→ Security by Design
→ Single Source of Truth
Pero seamos honestos…
¿Cuántas veces esos principios realmente influyen en una decisión de inversión en tecnología o una estrategía que podría impactar el top-line del negocio? o peor aun, ¿Cuántas veces nosotros mismos dejamos de seguirlos cuando existe presión del negocio, una urgencia operativa o un proyecto estratégico?
Ahí es donde empieza el verdadero problema.
La palabra “Principio” se ha subutilizado dentro de las organizaciones.
Desde la religión, la política hasta los negocios, se suelen utilizar para comunicar al exterior lo que queremos aparentar que creemos como organización. Pero en la práctica, muchas veces no los vivimos.
Google define un principio como:
“Una verdad o proposición fundamental que sirve de base a un sistema de creencias o comportamientos”.
Y también como:
“Una regla o creencia que rige el comportamiento.”
Lo interesante aquí es entender algo muy básico:
Un Principio no es un adjetivo. No es una sugerencia. No es opcional.
Es una regla fundamental. Es una forma de gobierno.
TOGAF los define como:
“Reglas y directrices generales concebidas para ser perdurables y raramente modificadas, que informan y apoyan cómo una organización cumple su misión.”
IBM menciona que:
“Los principios respaldan la misión general de la organización y guían la toma de decisiones.”
En teoría todo esto suena correcto, pero existe un problema enorme: seguimos sin entender cómo hacer que los principios funcionen en la realidad. Escribirlos es relativamente sencillo, lo complicado es mantenerlos operativos, es un documento vivo, utilizando cuando se diseña un roadmap, aparecen restricciones de presupuesto, urgencias comerciales, presión política o tecnologías nuevas.
Estamos hablando de perdida de “confianza” del comité directivo, la junta de consejo y en general de toda la organización, principios de arquitectura documentados que nadie consulta y nosotros mismos los rompemos.
A los líderes del negocio les interesa una sola cosa:
Como la tecnología impulsa el crecimiento, genera eficiencias o incrementa la resiliencia operativa del negocio. - Valor Real
Por eso principios como: “Cloud First”, “Buy vs Build”, “API First”; se vuelven irrelevantes si en la práctica cada decisión termina negociándose dependiendo del contexto político o de quién tenga más influencia.
Un principio mal diseñado genera exactamente lo contrario a lo que promete, en lugar de dar claridad: confunde. En lugar de alinear: fragmenta. Y en lugar de acelerar decisiones: genera discusiones interminables.
Por eso hay que evitar que los principios: sean tan abstractos que permitan cualquier interpretación. Sean seguidos solo por algunos equipos. Se confundan con estrategia. O generen una especie de “Torre de Babel” donde cada área interpreta algo distinto.
Los principios deberían existir para influir positivamente, crear coherencia en las decisiones que toman los líderes, alineados a la estrategía definida. Para ayudar a que cientos decisiones operativas se alineen con una misma dirección.
Quizá necesitamos regresar a algo mucho más simple.
Dos principios rectores:
❶ No hagas daño.
❷ Siempre entrega valor.
Todo lo demás son tensiones que deben equilibrarse continuamente:
⚖️ Flexibilidad vs Estandarización
⚖️ Estabilidad vs Innovación
⚖️ Gobernanza vs Empoderamiento
⚖️ Modularidad vs Integración
Los principios no solamente se declaran, se practican, se viven. Incluso cuando nadie está observando. Ahí es donde realmente empieza la Arquitectura Empresarial.
Arquitectemos el Cambio.