Estrategias y principios de EA

Hace unos días me entretuve leyendo el artículo "16 Enterprise Architecture Strategies Learned The Hard Way", que habla sobre que hay que tener en cuenta para definir y establecer una arquitectura empresarial. A continuación voy a plasmar mi parecer a cada uno de lso puntos, según mi experiencia. Intentaré no ser muy exhaustivo con cada item, de otra forma haré demasiado largo el post. Pero que da claro que cada uno de las estrategias planteadas generan una discusión bastante grande.

1. Es virtualmente imposible crear un blueprint exhaustivo de toda la empresa. Concuerdo en parte con este dicho. Creo que es muy dificil llevar a cabo una definición detallada de la arquitectura de una empresa, y si uno quiere hacerlo como primer paso para establecer una arquitectura empresarial, se esta introduciendo en una tarea que demandará mucho tiempo y esfuerzo, y cuando termine, ya estará desactualizada. Es necesario tener una metodología de creación contínuo del blueprint, que vaya enriqueciendose y creciendo poco a poco, a medida que el equipo de EA trabaja a la par de los proyectos.

2. La mejor estrategia mezcla un blueprint centrado en la empresa, con blueprints de dominio y de unidades de negocio. Como dije en el punto anterior, para crear el blueprint general, es necesario tener una estrategia que haga crecer gradualmente a los registros de activos y sus relaciones. No llevando a cabo un proyecto salomónico que nunca termine. Una buena estrategia, podría ser comenzar por unidades de negocio o dominio, para luego interrelacionarlos. Prefiero trabajar a la par de los proyectos.

3. Llevar a cabo la contabilidad de EA de manera centralizada es un factor de éxito. Estoy de acuerdo con esta afirmación, pero creo sumamente difícil que esto suceda. En lo que respecta a catalogación de activos, evaluación y seguimiento, creo que es imprescindible llevarlo a cabo en forma centralizada desde EA, pero el seguimiento de budget para llevar a cabo la estrategia, si bien es importante y ayuda a eliminar muchas trabas, es complicado a nivel organizacional.

4. Es crítica la existencia de un grupo central de EA, guiando con estándares y prácticas. Esto es fundamental. Pero la sola existencia no hace nada. Si el grupo de EA solo se dedica a generar estándares y prácticas, se convierte en un grupo de documentadores teóricos muy lindos. Es necesario que esas prácticas y estándares se relacionen con los proyectos, trabajando en conjunto y generando un circulo virtuoso entre EA y grupos de desarrollo.

5. Los arquitectos deben ser asignados a proyectos como "miembros core" 100 % de acuerdo. Es la mejor manera de que los arquitectos salgan del marco teórico definido, y se fogueen con el día a dia. Por otro lado, demuestran el valor de su trabajo al resto de la compañía. Es necesario, para lograr esto, que el grupo de EA tenga los suficientes integrantes como para afrontar la carga que esto supone.

6. EA debe medirse de dos formas: la capacidades de negocio entregadas, y los costos de los servicios. Debido a la forma en que trabaja un grupo de EA, es casi imposible generar métricas que demuestren su éxito. Una buena estrategia, es medir las capacidades de negocio brindadas como fruto del grupo de EA (o sea, medir el éxito de los proyectos en que participo EA), y por otro lado los costos asociados al grupo de EA, para obtener el rendimiento total, y demostrar el valor monetario del trabajo realizado.

7. Medir a la EA como un activo. No estoy tan de acuerdo. Al verlo como un activo, se esta comparando al grupo de EA con una máquina que tiene datos de entrada, y produce una salida, comparando solo el costo y el producto de dicho activo. Es mas profunda la medida, y tiene que tenerse en cuenta los factores limitantes de las definiciones: restricciones de tiempos, costos, restricciones técnicas etc, que limitan el éxito del trabajo de EA.

8. Para tener liderazgo en la arquitectura, es necesario tener capacidad de management, negocio y técnicos. Agregaría que es mas importante el primero y segundo que el tercero. Generalmente, el equipo de EA se encarga de mediar entre diferentes posturas, y muchas veces trabaja como un negociador o facilitador para destrabar proyectos. Pero es cierto que tienen que tener profundos conocimientos técnicos, en base a experiencias anteriores en el mejor caso. Pero sin saber como comunicarlos o transmitirlos, los conocimientos técnicos no sirven para un arquitecto.

9. Los métodos y el governance debe ser integrado al proceso actual. Si en lugar de integrarlo al proceso de trabajo actual, se crea un proceso paralelo, se dificultará la implementación, hasta hacerla imposible. Es necesario integrar las prácticas de EA al ciclo de trabajo existente, a nivel gestión de proyectos, generación de presupuestos, manejo de requerimientos IT, y formular y llevar a cabo modificaciones, en caso de ser necesarias.

10. No siempre el nombre Arquitectura Empresarial es el mejor para comunicar la función: Tal vez Planeamiento y estrategia, o Transformación empresarial es mejor. Me gusta Planeamiento y estrategia, creo que muestra lo que realiza EA, pero deja afuera aspectos técnicos. Transformación empresarial pone demasiado peso sobre el grupo de EA, pero le da la facultad de modificar la estructura organizacional, muchas veces necesario. Creo que se debe llamar Arquitectura Empresarial, pero comunicando claramente el objetivo y funciones del equipo de trbajo.

11. Las mejores empresas tienen equipos de "arquitectura de negocio" reportando al negocio, o a este e IT al mismo tiempo. Podría ser una buena decisión hacerlo depender de IT y el negocio al grupo de arquitectura, o crear un grupo de arquitectura de negocios, que modele la estrategia de negocios y trabaje muy cerca del grupo de EA, hasta como un departamento de este, para definir como esa estrategia de negocio se mapea contra las plataformas IT.

12. Las empresas líderes tienen arquitecturas de referencia para el 90% de los dominios técnicos. Es necesario contar con modelos de referencias para diferentes tecnologías y dominios técnicos, que brinden información de soporte para la implementación correcta de los proyectos, que encajen dentro del blueprint definido a nivel general. Estas arquitecturas deben definirse teniendo en cuenta los atributos de calidad y requerimientos funcionales que deben cumplirse dentro del dominio, para que puedan ser aplicados en forma exitosa.

13. Los EA seniors deben tener los skills culturales correctos y la conciencia para integrar a los socios de negocio y los referentes técnicos. Volviendo la punto 8, las habilidades blandas son muy importantes para un arquitecto empresarial. Deben poder ser el nexo entre el mundo de negocio y el mundo IT puros, y entenderse con ambos. Es necesario explotar y hacer crecer las capacidades de comunicación, negociación, coaching y liderazgo.

14. Los grupos de mayor performance mantienen un involucramiento consistente de EA en el ciclo de desarrollo, para trasladar los blueprints en la arquitectura inicial de cada proyecto, y para asegurar la estimación de costos y recursos. Relacionado al punto 9, el grupo de EA debe estar involucrados activamente en el ciclo de vida de los proyectos de desarrollo, instaurando sus políticas o prácticas para que sean llevadas a cabo dentro de cada proyecto, alineandose con la arquitectura macro definida.

15. Las organizaciones maduras destinan un 40% del tiempo de EA para planeamiento estratégico, y un 60% para participar en el ciclo de vida de proyectos. Según lo veo yo, la tarea del grupo de EA debe estar dividida en partes iguales, entre el planeamiento y la participación en los proyectos. Ya que existen momentos donde se planifica totalmente, y no se participa de ningún proyecto, pero en la participación del ciclo de desarrollo, no se realizan puramente tareas relacionadas al mismo, sino que se planifica como llevar a buen puerto el proyecto o desarrollo en cuestión, teniendo en cuenta lo planificado. Se puede decir que el arquitecto empresarias siempre tiene que estar planificando, mirando a mediano o largo plazo, y midiendo sus decisiones en base a eso.

16. La obtención de credibilidad y confianza entre el negocio e IT es un prodictor del exito de EA. Este es un tema fundamental. La credibilidad y confianza que el negocio e IT tienen de EA se va ganando paso a paso, proyecto a proyecto, mostrando resultados. No hay otra manera. No se puede imponer una arquitectura, se debe vender y demostrar su validez. Este es el punto fundamental del éxito de una EA. Si no se gana la confianza de las áreas de una empresa, la iniciativa esta destinada al fracaso tarde o temprano.