Los CIO líderes están haciendo en la arquitectura empresarial “sólo lo suficiente” para equilibrar la velocidad con conocimientos estratégicos a largo plazo para un mejor valor comercial.

En Vault Health, el CTO Steve Shi comienza el trabajo de arquitectura empresarial (EA) con un estudio del sitio de toda la infraestructura de datos, aplicaciones, sistemas y TI, pero lo restringe a dos semanas con entrevistas de una hora sobre cada función.

Los clientes, ya sean empleados o aquellos que pagan por un producto o servicio, deben “amar” el resultado de este enfoque mínimo viable de EA, dice Shi. “Si no obtiene la aceptación de los clientes, perderá impulso y, si pierde impulso, será más difícil continuar iterando después del lanzamiento mínimo viable”, señala.

Al igual que muchos líderes de TI, Shi está tratando de lograr un equilibrio entre los estudios arquitectónicos complejos que no se utilizan y los informes de EA básicos que carecen del alcance y la profundidad suficientes para proporcionar un valor duradero. Encontrar ese equilibrio requiere mantenerse cerca de las necesidades comerciales, reducir el trabajo pesado, definir el alcance del proyecto correctamente y establecer y hacer cumplir los estándares y principios arquitectónicos correctos. Aquí hay cinco pasos que recomiendan los CIO que son veteranos del proceso.

Manténgase cerca del negocio

Mantener una comunicación estrecha con las partes interesadas de la empresa es la única forma de saber dónde una arquitectura empresarial mínima viable puede ayudar mejor a la empresa e impulsar la financiación para continuar con las evaluaciones de EA a medida que cambian las necesidades de la empresa.

En Carrier Global Corp., el CIO Joe Schulz mide el éxito de EA mediante métricas comerciales, como la forma en que la productividad de los empleados se ve afectada por la calidad de las aplicaciones o las interrupciones del servicio.

“No consideramos la arquitectura empresarial como un sólo grupo de personas que son los guardianes, que son de naturaleza más teórica sobre cómo debería funcionar algo”, dice Schulz. Utiliza informes y conocimientos generados por la herramienta LeanIX de EA para describir la interconectividad del ecosistema, así como las capacidades de los sistemas en toda la cartera para identificar redundancias o brechas. Esto permite que el proveedor global de soluciones de construcción inteligente y cadena de frío “democratice gran parte de la toma de decisiones… (para) aportar la mejor capacidad de pensamiento e inversión en toda nuestra organización”.

George Tsounis, director de tecnología de la firma de tecnología y servicios de bancarrota Stretto, recomienda usar EA para “establecer confianza y transparencia” al informar a los líderes empresariales sobre el gasto actual en TI y las áreas donde las plataformas no están alineadas con la estrategia comercial. Eso hace que las futuras conversaciones relacionadas con EA sean “mucho más fáciles que si el arquitecto empresarial trabaja en un silo y no tiene esa relación”, afirma.

Recortar la burocracia

Los cuestionarios extensos y las entrevistas basadas en plantillas son una parte familiar, y a menudo no deseada, de los esfuerzos de EA. Los practicantes mínimos viables de EA sugieren eliminar cualquier pregunta que no brinde información esencial y permita la retroalimentación de los usuarios.   

Gregor Hohpe, director de estrategia empresarial del hiperescalador en la nube Amazon Web Services, sugiere pasar de procesos de EA “pesados, en gran medida unidireccionales” a conversaciones más simples, rápidas e iterativas con usuarios comerciales.

En la firma de servicios financieros State Street, el arquitecto jefe global Aman Thind trata de agilizar el proceso de EA haciendo sólo preguntas precisas y relevantes, en lugar de todo en una plantilla de EA. Centrarse en las preguntas más esenciales puede reducir al menos a la mitad el tiempo requerido para la revisión y presentación de la arquitectura y hace que el proceso sea mucho más efectivo, asevera. Por ejemplo, el marco que utiliza una aplicación SaaS para ofrecer la interfaz de usuario es menos importante que los procedimientos de gestión de acceso e identidad que determinan cómo interactúan los usuarios con ella.

Junto con el uso de verificaciones de cumplimiento automatizadas y plataformas de autoservicio, Hohpe recomienda eliminar “listas interminables de estándares que en gran medida se ignoran”, realizar reuniones de revisión en las que todos los documentos se sometan a ingeniería inversa del resultado preferido del equipo respectivo, reuniones de “alineación” en temas de valor agregado y “generar tapices gigantes a partir de herramientas de EA de gran peso que nunca se utilizan para la toma de decisiones”.

En Vault, una empresa de atención médica digital, Shi considera que la herramienta de observabilidad de aplicaciones New Relic es valiosa para acelerar el trabajo de EA al proporcionar visibilidad instantánea de toda la arquitectura.

 También utiliza nuevos términos y procesos para evitar retrasos comunes y crear conciencia sobre su enfoque novedoso. Un ejemplo es un “informe del sitio” que pide a los usuarios que visualicen el producto final de EA. Esto ayuda a definir los requisitos críticos, como la cantidad de transacciones y los tipos de procesos que debe admitir una aplicación, “viniendo del lado del cliente y trabajando hacia atrás”. En lugar de utilizar un proceso de “uno y listo” para pedirles a los usuarios que acuerden una decisión tecnológica crítica por adelantado, Shi los desafía a confirmar o revisar las “hipótesis de desarrollo”, como la cantidad de llamadas a la base de datos que un sistema debe admitir cada día. Este enfoque acelera el acuerdo sobre las opciones de componentes como las bases de datos, asevera.

Durante el lanzamiento de la aplicación, Shi evita un plan de proyecto genérico a favor de lo que él llama “un plan de macro secuenciación específico” de pasos construidos alrededor de hitos como las pruebas alfa y beta y sus hitos de validación asociados. Esto define, para cada etapa de la implementación, el éxito en términos comerciales, como los ingresos o la tasa de adopción de usuarios, y las lecciones aprendidas del proceso de soporte que reducen los costos continuos de soporte. También les recuerda a todos, dice, que “el proyecto no termina hasta que sabemos que la arquitectura ha entregado un valor medible al cliente”.

Ámbito de aplicación correcto

Si usted asume demasiado en un proyecto de EA mínimamente viable y quedará desactualizado antes de que se complete, entregando resultados demasiado tarde para satisfacer y recibir financiamiento futuro de los líderes empresariales. Pero si estrecha demasiado, no ofrecerá la visión integral de la tecnología y el negocio necesarios para aprovechar al máximo las inversiones en TI. Alcanzar el equilibrio adecuado a menudo requiere centrarse en una aplicación o punto débil en el negocio o en un área donde los requisitos cambian rápidamente debido a nuevas necesidades comerciales o reglamentarias.  

El analista principal asociado de Gartner Inc., Nolan Hart, llama al alcance adecuado de EA “la menor cantidad de entregables, como puntos de vista, modelos de referencia y patrones de diseño, que ayudan a garantizar la entrega oportuna y compatible de productos y soluciones”. En lugar de dedicar demasiado tiempo a comprender la arquitectura actual, recomienda “primero comprender los resultados deseados”. No tiene ningún valor, dice, “perderse documentando su arquitectura disfuncional actual por los siglos de los siglos”.

Shi recomienda que un EA mínimo viable considere “todo, desde la interfaz de usuario hasta las API que vinculan los sistemas a la arquitectura de datos, en lugar de un solo componente o servicio en silos”. La arquitectura propuesta también debe poder probarse a escala de producción, dice, y manejar los mismos requisitos máximos que el sistema al que reemplaza.

El alcance adecuado también se aplica a la organización de EA. En lugar de un grupo de EA dedicado, Carrier creó centros de excelencia para necesidades clave como CRM, servicio de campo, ERP, análisis y capacidades de fábrica digital. Estos centros brindan una base simplificada de componentes centrales que le permiten innovar rápidamente sin requerir un ejercicio de EA para evaluar plataformas separadas para cada unidad de negocios, señala Schulz.

Si un grupo dentro de una empresa no está interesado en un proyecto de EA mínimo viable, “hay muchas otras personas que se tomarán su tiempo”, dice Hart. Haga coincidir esa demanda con las habilidades de un grupo de EA para determinar “de tres a cinco tipos de servicios que puede ofrecer para brindar esos resultados comerciales con un enfoque mínimo viable”.

Establecer y hacer cumplir las normas

Servicios web de Amazon

Hacer cumplir los principios de diseño, junto con un enfoque en las necesidades comerciales, puede ayudar a acortar los “argumentos filosóficos sobre qué solución es la mejor”, dice Tsounis. Los principios que recomienda incluyen “siempre trate de crear la solución más simple posible, no haga demasiada ingeniería, permita la máxima reutilización en toda la organización, aproveche los patrones de diseño arquitectónico establecidos, así como los servicios basados ​​en la nube antes de construir algo nuevo”.

Las arquitecturas y estándares de referencia en áreas como la ciberseguridad, el gobierno de datos, la gestión de producción y las mejores prácticas de implementación proporcionan un “libro de jugadas listo para usar” para crear de manera eficiente aplicaciones componibles que son robustas, compatibles y resistentes por diseño, dice Thind. Dichas arquitecturas, construidas con microservicios que están “muy bien definidos… en términos de sus API, su escalabilidad y cómo interoperan”, permiten que una empresa reemplace cualquier microservicio sin afectar a ningún otro, creando así un diseño preparado para el futuro. 

Hohpe dice que algunos estándares sofocan la innovación mientras que otros la impulsan. Por ejemplo, las interfaces uniformes son esenciales para crear arquitecturas fáciles de adaptar. Sin embargo, los estándares demasiado estrictos pueden conducir a malas elecciones tecnológicas. Recuerda un equipo de aplicaciones que eligió XML como interfaz de componentes en lugar de protocolos de comunicación más rápidos. Cuando se le preguntó por qué, el equipo respondió que el equipo de arquitectura lo requería, aparentemente sin considerar el efecto perjudicial del análisis XML en el rendimiento de la aplicación.

Empezar en alguna parte

Por lo menos designe un “…un arquitecto jefe, un ejecutivo que evalúe los estándares generales, la gobernanza general, las plataformas generales y la disciplina general del diseño de aplicaciones desde arriba. El simple hecho de tener ese puesto señala la importancia de la arquitectura para toda la empresa e inculca los comportamientos correctos que necesitamos para crear organizaciones de TI eficientes e innovadoras”, sugiere Thind.

Comenzar una arquitectura empresarial viable mínima puede comenzar simplemente “haciendo un balance”, dice Thind, identificando gastos excesivos como “¿por qué tenemos seis aplicaciones diferentes para el mismo proceso, cinco contratos diferentes (para) la misma herramienta de BI, múltiples contratos de datos de mercado con el mismo alcance, clústeres de Hadoop 24×7 para informes mensuales, etc.”. Pero incluso ese mínimo esfuerzo viable puede generar grandes beneficios. “El simple hecho de garantizar que se utilice la herramienta correcta para el trabajo correcto y que haya estandarización y mejores prácticas en torno a su uso puede tener un impacto considerable en el resultado final y generar menos deuda técnica, requisitos de soporte reducidos y permitir una innovación más rápida”, aseveró.

Robert Scheier, CIO.com