Capítulo 4. ¿Arquitecto de empresa o arquitecto en la empresa?
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
Los pisos superior e inferior de la Torre de Marfil
Cuando me contrató como arquitecto empresarial, jefe de arquitectura empresarial para ser más exactos, no tenía mucha idea de lo que implicaba realmente la arquitectura empresarial. También me pregunté si mi equipo debería llamarse "Pies de la arquitectura empresarial", pero esa contemplación no me gustó mucho. El motor de la tendencia a anteponer a los títulos el prefijo "jefe de" se describió acertadamente en un foro en línea con el que me tropecé:1
Este título suele implicar que el candidato quería un título de director/vicepresidente/ejecutivo, pero la organización se negó a ampliarlo. Utilizando esta ofuscación, el candidato aparece como senior ante las partes externas, pero sin ofender a los grupos internos.
No me gusta especialmente el título "jefe de xyz" porque se centra en la persona que dirige (no es un juego de palabras) un equipo en lugar de cumplir una función específica. Prefiero nombrar a la persona por lo que tiene que conseguir, suponiendo que no lo hace sola, sino que tiene un equipo que la apoya.
Dejando a un lado todos los prefijos de los títulos, cuando los informáticos conocen a un arquitecto de empresa, su reacción inicial es situar a esta persona en lo alto del ático(Capítulo 1), donde dibujan bonitos cuadros que se parecen poco a la realidad. Por tanto, para recibir una acogida más cálida por parte del personal informático, hay que tener cuidado con la etiqueta arquitecto de empresa. Pero, entonces, ¿cómo debe llamarse un arquitecto que trabaja a escala empresarial?
Arquitectura empresarial
El reto recurrente con el título arquitecto de empresa tiende a ser que podría describir a una persona que hace la arquitectura de la empresa en su conjunto (incluido el nivel de estrategia empresarial) o a alguien que hace la arquitectura de TI a nivel de empresa (en contraposición a un arquitecto departamental, por ejemplo).
Para ayudar a resolver esta ambigüedad, vamos a remitirnos al libro que define el tema, Enterprise Architecture as Strategy, de Jeanne Ross, Peter Weill y David Robertson.2 En él aprendemos lo siguiente
La arquitectura empresarial es la lógica organizativa de los procesos empresariales y la infraestructura informática que refleja los requisitos de integración y normalización del modelo operativo de la empresa.
Según esta definición, la arquitectura empresarial (EA) no es una función puramente informática, sino que también tiene en cuenta los procesos empresariales, que forman parte del modelo operativo de una empresa . De hecho, el diagrama más divulgado del libro muestra cuatro cuadrantes que representan modelos operativos empresariales con mayores o menores niveles de estandarización de procesos (uniformidad entre líneas de negocio) e integración de procesos (intercambio de datos e interconexión de procesos). Con ejemplos del sector para todos los cuadrantes, Weill y Robertson relacionan cada modelo con una estrategia adecuada de arquitectura informática de alto nivel. Por ejemplo, un programa de integración de datos y procesos puede tener poco valor si el modelo operativo empresarial es el de unidades de negocio muy diversificadas con pocos clientes comunes. Para tales empresas, la TI debería proporcionar en su lugar una infraestructura común, sobre la que cada división pueda implantar sus diversos procesos. Por el contrario, una empresa compuesta por unidades en gran medida idénticas, como una franquicia, se beneficia de un entorno de aplicaciones altamente estandarizado. La matriz demuestra perfectamente cómo la EA forja la conexión entre la empresa y la TI. Sólo si ambos están bien alineados, la TI aporta valor a la empresa.
Conectar la empresa y las TI
Conectar el negocio y la TI es más fácil si la parte empresarial de la organización también tiene una arquitectura bien definida. Afortunadamente, a medida que los entornos empresariales se hacen más complejos y los disruptores digitales obligan a las empresas tradicionales a evolucionar más rápidamente sus modelos de negocio, la noción de arquitectura empresarial ha ganado una atención significativa en los últimos años. La arquitectura empresarial traduce la forma de pensar estructurada y arquitectónica(Capítulo 8) que se guía por una visión formalizada de los componentes y las interrelaciones en el ámbito empresarial. En lugar de conectar los componentes técnicos del sistema y razonar sobre las propiedades técnicas del sistema, como la seguridad y la escalabilidad, la arquitectura empresarial describe "la estructura de la empresa en términos de su estructura de gobierno, procesos empresariales e información empresarial".3
La arquitectura empresarial define esencialmente el modelo operativo de la empresa, incluyendo cómo se estructuran e integran las áreas de negocio, derivado de la estrategia empresarial. Mientras tanto, la arquitectura de TI construye las correspondientes capacidades de TI. Si las dos funcionan perfectamente una al lado de la otra, no necesitas mucho más. En el caso más probable de que las dos no estén bien conectadas, necesitas algo que las una. Por tanto, he aquí mi propuesta de definición de arquitectura empresarial:
La arquitectura empresarial es el pegamento entre la arquitectura de negocio y la de TI.
Esta definición aclara que la EA, a diferencia de la arquitectura de TI a nivel empresarial, no es una función de TI. En consecuencia, el equipo de EA debe situarse cerca de la dirección de la empresa y no estar enterrado en lo más profundo de la organización de TI, para que pueda equilibrar las consideraciones empresariales, técnicas y organizativas.
La definición también implica que una vez que la empresa y las TI estén estrechamente interrelacionadas, no necesitarás mucha EA, que es una de las razones por las que no encuentras mucha EA en los llamados gigantes digitales.
Ejemplo 4-1.
La mayoría de los gigantes digitales no tienen departamentos de EA porque su negocio y sus TI están estrechamente interrelacionados.
¡Que no cunda el pánico! La traducción entre las necesidades empresariales y la arquitectura de TI sigue siendo un ámbito en el que perennemente escasean los talentos. Parece que la mayoría de la gente se siente cómoda en uno u otro lado de la valla, pero sólo unos pocos pueden, y eligen, jugar de forma creíble en ambos mundos. Es un buen momento para ser arquitecto de empresa.
La informática es de Marte, la empresa es de Venus
La estricta separación entre TI y negocio que suele darse en las empresas me parece problemática. Suelo bromear con que en los viejos tiempos, cuando todo funcionaba con papel en lugar de con ordenadores, las empresas tampoco tenían un departamento de "papel" separado y un CPO (Chief Paper Officer). En las empresas digitales, el negocio y la TI son inseparables; la TI es el negocio, y el negocio es la TI.
Conectar la empresa y la TI da a la EA una relevancia totalmente nueva, pero también nuevos retos. Es como añadir un ascensor a mitad de la planta que conecte a la gente de negocios en el ático con la gente de TI en la sala de máquinas, porque los ascensores respectivos no llegan del todo el uno al otro. Aunque muy valioso, a largo plazo el objetivo de un departamento de arquitectura empresarial de este tipo debe ser quedarse obsoleto, o al menos más pequeño, ampliando los ascensores respectivos. Pero no te preocupes, los rápidos cambios tanto en el entorno empresarial como en el técnico hacen improbable que desaparezca del todo la necesidad de la arquitectura empresarial.
Establecer una conexión fructífera y bidireccional entre la arquitectura empresarial y la de TI resulta más fácil si la arquitectura empresarial se encuentra en un nivel de madurez comparable al de la arquitectura de TI. Sin embargo, lo más frecuente es que la arquitectura empresarial esté aún menos madura como dominio que la arquitectura informática. Eso no se debe a que las empresas no tuvieran arquitectura; más bien, se debe a que las personas que hacían la arquitectura empresarial no se identificaban como tales, sino que eran los líderes empresariales, los jefes de división o los directores de operaciones. Además, el diseño de la empresa se atribuía más bien a la perspicacia empresarial que al pensamiento estructurado. Cuando la empresa producía artefactos similares a la arquitectura, a menudo acababan siendo "mapas de capacidades funcionales" que no incluían ninguna línea(capítulo 23).
Apoyar al negocio es el objetivo último y la razón de ser de todas las funciones empresariales. Sin embargo, situar la arquitectura de TI al mismo nivel que la arquitectura empresarial pone de manifiesto que los tiempos en que la TI era un simple receptor de pedidos que proporcionaba un recurso básico al menor coste posible (afortunadamente) han pasado. En la era digital, la TI es un diferenciador competitivo y un impulsor de oportunidades, no una mercancía como la electricidad.
Nota
Los gigantes digitales como Google o Amazon no son empresas tecnológicas; son empresas de publicidad o de distribución que saben cómo utilizar la tecnología para obtener ventajas competitivas.
Por tanto, la excusa habitual de que "Google y Amazon son empresas tecnológicas mientras que nosotros somos una compañía de seguros/un banco/una empresa manufacturera" ya no vale. Estas empresas competirán contigo, y si quieres ser competitivo, también tienes que cambiar tu visión de las TI. No es algo fácil de hacer, pero los gigantes digitales han demostrado lo poderosa que es esa visión.
Arquitectura orientada al valor
La escala y la complejidad de hacer arquitectura a escala empresarial hacen que la arquitectura informática a gran escala sea apasionante, pero también presenta uno de los mayores peligros. Es demasiado fácil perderse en esta complejidad y pasar un rato interesante explorándola sin producir nunca resultados tangibles. Tales casos son la fuente del estereotipo de que la EA reside en la torre de marfil y aporta poco valor. Por lo tanto, los equipos de EA deben tener un camino claramente articulado hacia el valor: cualquier esfuerzo que se haga debe devolverse aportando valor a la organización.
Otro peligro reside en los largos ciclos de retroalimentación. Juzgar si alguien realiza una buena EA lleva aún más tiempo que juzgar una buena arquitectura de aplicaciones. Aunque el mundo digital obliga a acortar los ciclos, muchos planes de EA siguen abarcando de tres a cinco años. Así, la arquitectura empresarial puede convertirse en un escondite para los aspirantes a cartógrafos. Por eso los arquitectos empresariales tienen que demostrar su impacto(Capítulo 5).
Tontos con herramientas
Algunos arquitectos empresariales se asocian estrechamente con una herramienta específica de EA que capta los diversos aspectos del panorama empresarial. Estas herramientas permiten un mapeo estructurado desde los procesos y capacidades empresariales, idealmente elaborados por los arquitectos empresariales, hasta activos informáticos como aplicaciones y servidores.
Nota
Asegúrate de que tus herramientas trabajan para ti, ¡y no al revés!
Bien hechas, estas herramientas pueden ser el repositorio estructurado que tiende el puente entre la arquitectura empresarial y la de TI. Mal hechas, se convierten en un interminable proceso de descubrimiento y documentación que produce un entregable al que le falta un énfasis(Capítulo 21) y que está desfasado para cuando se publica. Huelga decir que un entregable así aporta poco valor.
Visita Todos los pisos
Mi definición de EA en también implica que algunos arquitectos informáticos, que no son arquitectos empresariales, trabajan en el ámbito de la empresa. Éstos son, en gran medida, las personas a las que me refiero en este libro. Como son los técnicos que han aprendido a subir en ascensor(Capítulo 1 ) a los pisos superiores para relacionarse con los arquitectos de gestión y de empresa, son un elemento fundamental en cualquier transformación de TI.
¿En qué se diferencia ser un "arquitecto a escala empresarial" de un arquitecto informático "normal"? En primer lugar, todo es más grande. Muchas grandes empresas son conglomerados de diferentes unidades de negocio y divisiones, cada una de las cuales puede ser un negocio multimillonario y dedicarse a un modelo de negocio diferente. A medida que las cosas se hacen más grandes, también encontrarás más legado: las empresas crecen con el tiempo o mediante adquisiciones, y ambas cosas generan legado. Este legado no se limita a los sistemas, sino también a la mentalidad y la forma de trabajar de las personas. Por tanto, los arquitectos a escala empresarial deben ser capaces de desenvolverse en organizaciones(Capítulo 34) y situaciones políticas complejas .
Realizar una verdadera EA es tan complejo y tan valioso como arreglar un fallo de concurrencia de Java. Existe una enorme complejidad en todos los niveles, pero la buena noticia es que puedes utilizar patrones de pensamiento similares en los distintos niveles. Por ejemplo, los arquitectos de software tienen que equilibrar la granularidad y las interdependencias de su sistema: un monolito gigante es bastante inflexible, mientras que mil servicios diminutos serán difíciles de gestionar y pueden incurrir en una sobrecarga de comunicación significativa. Exactamente las mismas consideraciones se aplican a la arquitectura empresarial cuando se considera el tamaño de las divisiones y las líneas de productos. Por último, la EA también se enfrenta a las mismas disyuntivas cuando tiene que decidir qué sistemas deben centralizarse, lo que simplifica la gobernanza pero también puede ahogar la flexibilidad local. La arquitectura, si se toma en serio, aporta un valor significativo a todos los niveles.
Las empresas se parecen a una estructura fractal: cuanto más te acercas o alejas, más se parecen las cosas. El cortometraje Powers of 10, producido en 1977 por Charles y Ray Eames para IBM, lo ilustra maravillosamente: la película aleja un orden de magnitud cada 10 segundos desde un picnic en Chicago hasta llegar a mostrando un mar de galaxias. A continuación, se acerca hasta llegar a muestra el reino de los quarks. Curiosamente, las dos vistas no parecen tan diferentes.
1 Keith Rabois, Quora, 11 de mayo de 2010, "¿Qué suele significar "Head" en títulos de trabajo como "Head of Social", "Head of Product", "Head of Sales", etc.?", https://oreil.ly/5LmbY.
2 Jeanne W. Ross, Peter Weill y David C. Robertson, Enterprise Architecture as Strategy: Creating a Foundation for Business Execution (Boston, MA: Harvard Business Review Press, 2006).
3 Página web del Grupo de Gestión de Objetos, http://www.omg.org/bawg.
Get El ascensor de arquitecto de software now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.