La idea central es un cuadro de dos ejes. Uno mide cuánto necesitan las unidades de negocio compartir datos; el otro, cuánto necesitan hacer las cosas del mismo modo. De las cuatro combinaciones salen cuatro modelos de operación distintos, y de cada modelo salen decisiones de sistemas opuestas entre sí.
Qué me llevé
Que esa pregunta va antes de cualquier decisión de software. Dos empresas del mismo tamaño y el mismo sector pueden necesitar lo contrario: si las unidades comparten clientes, los datos tienen que estar integrados aunque los procesos difieran; si solo comparten dueño, forzar la unificación es pagar caro por una complicación que nadie pidió. La mitad de las implementaciones que salen mal se deciden en este punto, antes de elegir producto.
El diagrama central de una página, que la alta gerencia pueda discutir sin traductor: el proceso que sostiene el negocio, los datos que se comparten, las tecnologías clave y los clientes. Es lo que intento que quede al final de un mapa de arquitectura, porque un documento de cuarenta páginas no se discute en un comité.
Y la escalera de madurez, con una advertencia que sigue vigente: no se salta de la etapa de silos a la de plataforma optimizada. El intento de saltar es donde se queman los presupuestos grandes.
Qué dejé fuera
Los casos, que son de hace veinte años, de empresas enormes y de un mundo sin nube ni interfaces de programación públicas. Y la cuarta etapa, la modularidad del negocio, que el libro presenta como destino y que no se cumplió de esa manera: lo que llegó fue otra cosa. La pregunta inicial es excelente; la escalera hay que leerla con distancia histórica.