Capability Assessment: Seremos capaces de afrontar la nueva Arquitectura Empresarial?

Uno de los aspectos claves en la puesta en marcha de un proyecto de Arquitectura Empresarial (Enterprise Architecture) usando TOGAF es la preparación, madurez y disposición de una organización para crecer, evolucionar y adoptar el cambio.

No existe ninguna organización (entendida como un todo) que esté preparada al 100% para realizar este cambio cualitativo. El motivo es muy fácil, las organizaciones están vivas, así como el mercado y tienen procesos internos con objetivos, plazos, y actividades a lo largo de toda su cadena de valor. Por lo tanto, que esta paso preliminar no le desanime, transforme los resultados en una oportunidad de mejora durante su proyecto.

TOGAF recomienda evaluar varios aspectos antes de comenzar la definición de nuestra Arquitectura Empresarial. Es importante comprender que no es necesario evaluar todos, ya que dependerá del alcance de nuestro proyecto. Por otro lado, se trata de entender la preparación de la organización, su madurez, y no realizar una evaluación simplemente para dar el ok al proyecto. TOGAF recomienda evaluar los siguientes aspectos con el nivel de detalle que crea oportuno el arquitecto empresarial:

1. Business Capability Assessment: Básicamente evalúa la capacidad de negocio organizativa de la arquitectura actual y de la pretendida futura a nivel de estrategia corporativa de negocio.
2. IT Capability Assessment: Evalúa la situación actual y futura de los procesos de cambio y operacionales, así como el impacto que tendría una transformación IT en la organización.
3. Architecture Maturity Assessment: Evalúa las distintas arquitecturas presentas y su reusabilidad, así como la documentación y el conocimiento de las mismas (estándares, modelos de referencia y su uso en la organización).
4. Business Transformation Readiness Assessment: Madurez a nivel de organización, riesgos, asunciones y dependencias de la transformación.

Sobre el papel, al realizar este análisis, sería de esperar que muy pocas organizaciones estén preparadas para llevar a cabo la definición de una nueva arquitectura… Permítanme exponerles un ejemplo: Conozco una gran corporación que tras este análisis se dedicó a ir mejorando los aspectos que peor habían resultado después de la evaluación: su objetivo era estar preparada, sin embargo, este hecho se convirtió en un problema, y es que invirtió varios años en esta tarea y pronto olvidó el objetivo final, que era definir la nueva arquitectura acorde a su estrategia de negocio. Estuvo documentando, y evaluando sus capacidades para luego desestimar el proyecto por aburrimiento (y es que la gestión del cambio, cuenta y mucho).

Entendamos este análisis como una herramienta muy útil que ofrece TOGAF para entender la organización y adelantar posibles riesgos, necesidades de formación y dependencias que nos encontraremos en la puesta en marcha de la arquitectura, pero nunca como un ´pasa o no pasa´ para comenzar el proyecto de Enterprise Architecture.

Demos a la organización lo que necesita para que la nueva Arquitectura sea útil en la consecución de la estrategia y haga la vida más saludable a sus trabajadores.

Segmentos: Arquitectura Empresarial

Segmentos: Es que mi organización es muy grande...

Es bien conocido que TOGAF permite afrontar segmentos de las organizaciones: áreas con suficiente entidad en las que se puede aplicar un enfoque segmentado en las fases B, C y D del ciclo ADM.

Tratémoslo con un ejemplo muy ilustrativo: El Universo tiene unas leyes y teorías generales que se cumplen en toda su extensión. Son las mismas leyes físicas para galaxias, sistemas, cúmulos globulares o nebulosas y se reconocen como universales. Una vez que vamos bajando a nivel de detalle y en nos fijamos en los sistemas solares, planetas, satélites naturales, asteroides y sus características podremos estudiar y analizar sus propiedades y características, así como de su comportamiento: por ejemplo la composición de la atmósfera de un planeta que será distinta a la de otro, aunque esté regida poa las mismas leyes. El estudio de las mismas, dentro de la generalidad de las leyes, se realiza de manera local e individual debido sus particularidades. Pero al final estas propiedades particulares son parte del universo y se rigen bajo esas leyes universales.

En el caso de la Arquitectura Empresarial, cada organización tiene su propia estrategia corporativa (leyes universales) que competen a todos los departamentos y áreas. Esta estrategia, contexto, visión arquitectónica general a nivel de negocio, sistemas de información y tecnología es válida para toda la organización. Ocurre que en grandes empresas, tienen áreas y unidades suficientemente grandes como para ser abordadas de manera aislada, independiente y como un segmento de la arquitectura empresarial en las fases B, C, y, D en las distintas iteraciones que se realicen durante el ciclo ADM. Su tratamiento podrá realizarse por segmentos pero sin olvidar que las fases Preliminar y A del ciclo se realizarán para toda la organización (universo).

Una vez estén definidas y documentadas las arquitecturas con sus artefactos, se deberían poner en común para cada segmento e integrarlas en una única arquitectura, para movernos a lo que en TOGAF se denomina la Capability Architecture que comienza en la fase E del ciclo ADM. TOGAF sugiere que se terminen las fases B, C y D de todos los segmentos, aunque esto suponga mucho tiempo o un impacto en la estrategia, lo cual tiene sentido en cuanto a ahorro de costes y evitar redundancias o duplicidad de actividades. Sin embargo las compañías con entes vivos que necesitan tener resultados y avanzar para alcanzar su estrategia por lo que se podrían aceptar esos malos menores con tal de obtener resultados y reducir el gap entre la arquitectura actual y la objetivo para ese segmento, que recordemos que tiene entidad propia y se puede considerar como “grande”.

Otras metodologías como la FSAM (Federal Segment Architecture Methodology) están diseñadas para ir segmento por segmento desde el principio al fin, sin necesidad de abordar toda la organización de golpe.

Por lo tanto, si su organización es muy grande y le preocupa abordarla como un todo tiene al menos 2 soluciones, trabajar por segmentos secuenciales con un equipo de arquitectos empresariales  o bien diseñar varios equipos que puedan trabajar en paralelo durante las fases B, C y D.

La importancia de conocer nuestros límites y saber manejar cosas “pequeñas”

La importancia de conocer nuestros límites y saber manejar cosas “pequeñas”

El ser humano tiene sus límites y, en particular, cada uno de nosotros tenemos los nuestros que difieren de los del vecino. De la misma forma las organizaciones tienen los suyos, pero no sólo en las factorías de software, call centers of fuerza de ventas, también lo tienen en las oficinas de proyecto (PMO), estrategia, e incluso en el board de directors.

Muchas organizaciones fracasan en su estrategia porque no son capaces de entender dónde están sus límites, cuáles con sus capacidades como organización, y por establecer objetivos inalcanzables o irrealistas que se convierten en auténticas losas rígidas, inflexibles y desmotivadoras para los empleados, partners y proveedores.

TOGAF habla de Architecture Capabaility Framework como una serie de técnicas y herramientas para conocer nuestros límites y establecer procedimientos, normas y políticas que gobernarán nuestra transformación, desde las fases preliminares del ciclo ADM (Architecture Development Methodology), hasta las fases finales F.Migration Planning, G. Implementation Governance, o H. Architecture Change Management.

Desde mi experiencia, muchas organizaciones son capaces de avanzar en el ciclo ADM pese a tener limitaciones de recursos, presupuesto o información en la elaboración de la target architecture, incluso definen con éxito los proyectos e iniciativas que cubren el gap entre la arquitectura actual y la arquitectura objetivo (business, information systems, and technological), pero donde rotundamente fracasan es en su puesta en marcha, implementación y control y monitorización.

Es normal que se identifiquen cientos de proyectos/iniciativas como resultado del ciclo ADM. Yo suelo deccir que no sé manejar 200 cosas distintas, que enseguida pierdo el control de muchas de ellas. Sin embargo sí puedo gestionar y controlar 20 ó 30. La agrupación de Proyectos en Programas facilita esta labor.

Recordemos la definición que da el Project Management Institute (PMI) en el libro ”The Standard of Program Management” (2^nd Edition) relativa a programas y proyectos: En concreto, define Programa de la siguiente manera: 

• “A Program is a related group of projects managed in a coordinated way to obtain benefits and control not available from managing them individually”. Que básicamente viene a decir que un Programa es una serie de proyectos relacionados en los que si se coordina su ejecución se obtendrían más beneficios que si se ponen en marcha individualmente.

Un Enterprise Architect aporta mucho valor añandido en la fases E. y F. del ciclo ADM si es capaz de agrupar proyectos relacionados entre ellos en programas que sí sean manejables. Muchos equipos fracasan porque no son capaces de entender esto y, en concreto, muchos líderes y ‘decision makers’ de grandes corporaciones naufragan ante una lista interminable de proyectos con dependencias que no entienden, costes agregados y plazos que van más allá de sus expectativas de permanencia en el puesto.

Hagamos la vida más fácil y conozcamos nuestras limitaciones y las de nuestra organización para hacer realidad nuestros objetivos.

El valor de los Viewpoints en TOGAF

El valor de los viewpoints…

Hoy en día nos dedicamos a representar sistemas desde un punto global que cubren las necesidades y preocupaciones (concerns) de negocio de los stakeholders. Preparamos vistas (views) de negocio, de sistemas de información, tecnológicas… con la idea diseñar de la manera más clara posibles las funciones de ese sistema en cuestión.

Todo esto está bien y es estupendo cuando realmente se hace. Chapeau!

Respecto a lo enunciado anteriormente aclaremos dos conceptos dentro del mundo de TOGAF:

• un Sistema es una colección componentes organizados de manera estructurada para realizar una o varias funciones específicas.
• Concerns es definido por TOGAF como los intereses clave y cruciales de los stakeholders relacionados con el sistema y que determinarán la aceptación del propio sistema.

Que es lo que ocurre en el mundo real? Pues que muchas veces los stakeholders no entienden estas vistas y no responden a sus necesidades específicas de negocio. En concreto, en muchas ocasiones no tendrían necesidad de verlas y es que un stakeholder quiere ver el sistema desde su propio punto de vista de negocio para ver cómo va a dar respuesta a sus necesidades (concerns). Y ya que en el mundo real puede haber muchos stakeholders, TOGAF  propone una serie de Viewpoints específicos para dar respuesta a este problema tan habitual. 

No nos asustemos, no hace falta crear tantos Viewpoints como stakeholders!

Las Viewpoints de TOGAF son vistas con una perspectiva de negocio específica. Hay un clásico ejemplo de un sistema aéreo con dos stakeholders: el piloto y el controlador aéreo. Ambos utilizan el mismo sistema pero tienen intereses de negocio distintos y un buen Enterprise Architect les facilitara unos Viewpoints específicos para cada uno derivado de la Vista del sistema con la que trabaja el EA. Al final el sistema diseñado dará respuesta a sus concerns y el sistema estará diseñado para realizar una serie de funciones en las que ambos roles participarán de otra manera.

El Enterprise Architect siempre busca la respuesta a una necesidad de negocio desde un punto de negocio aplicando las diferentes arquitecturas empresariales: Business, Applications, Data and Technology. El gran EA es el que sabe elegir que Viewpoints son los mejores para dar respuesta a los stakeholders.

No olvidemos que si hacemos bien esta tarea, la aceptación del sistema será mucho más fácil.

Y usted a qué ha venido?

Y usted a que ha venido?

Nada me desespera más desde el punto de vista profesional que el responsable de un proyecto estratégico con inmenso calado organizativo se olvide de los objetivos del proyecto y se pierda en el tiempo mirándose el ombligo.

Sin ir más lejos diré que un amigo me ha contado que esta semana ha recibido la llamada de un cliente que lleva 9 meses intentando cerrar una actividad de la fase B. Business Architecture del Architecture Model Development (ADM). Por este motivo, están parados los proyectos definidos en la fase F. Migration Plan. Podría tener sentido si afecta de manera crítica a los outputs de la fase F., pero no es el caso.

En resumen, esta organización ha congelado la implantación de todos los proyectos e iniciativas hasta que se finalice la actividad de la Business Architecture.

Dónde están todas esas explicaciones, workshops, y horas de trabajo concienciando a todo el mundo de que el objetivo es dar una respuesta a nivel de business, information systems y technology a las necesidades de negocio derivadas de la Vision y Misión corporativas? Sin perderse en las mismas, claro.

Sé que algunos pensareis que esta entidad solo está abocada al fracaso y a desaparecer, pero por desgracia es una entidad pública, nunca pasa nada.

Es importante que el Enterprise Architect tenga siempre en mente que el principal Output de la Phase A del ADM (Architecture Vision) es tener una idea preliminar de nuestras Arquitecturas Objetivo, y que el objetivo del EA es precisamente alcanzar esa visión sin perderse en algunos de los pasos del ADM y sin conseguir salir del mismo. Vamos que alguno se cree que las iteraciones pueden ser infinitas en el tiempo. Pues no, hombre no.

Cuántas veces a lo largo del día me pregunto: Y usted a qué ha venido?

Pues eso, que me gustaría poner el cartel de área restringida...

Ponga un Enterprise Architect en su vida

No es algo nuevo que el mercado anglosajón nos marque la tendencia de incluir nuevos roles para trabajos especializados. En concreto en el mundo de la tecnología o de las ICT es muy habitual. No estamos hablando únicamente de niveles CxO, sino también en posiciones estratégicas de las empresas.

Relacionados con el mundo del Enterprise Architecture podemos encontrar, al menos (puede ser una lista muy extensa), los siguientes:

• Application Architect: Cuando una aplicación empieza a crecer y el clave en el desarrollo del negocio, es habitual encontrar un Application Architect con dedicación exclusiva. En algunas situaciones se habla de Lead Developers. Este role es habitual en los países hispano hablantes y específicamente en España, aunque uno no sabe qué fue primero si el huevo o la gallina, es decir, parece que lo más habitual es que un desarrollador avanzado se convierta en application architect con el tiempo. 

• Solution Architect: Cuando las aplicaciones se complican aún más y empiezan a aparecer muchos interfaces, interdependencias con otras aplicaciones y con la infraestructura hablamos de Solution Architects. 

• Enterprise Architect: Cuando una organización por su tamaño es muy grande y es necesario tener una visión global de las distintas arquitecturas, así como de su relación con la estrategia tecnológica de la empresa, es aconsejable incorporar un Enterprise Architect, que suele trabajar a niveles de CxO, no sólo como asesor, sino también en la definición de las distintas arquitecturas que se desarrolarán en el tiempo para alcanzar la misión estratégica corporativa. 

• Principal Enterprise Architecture: En ocasiones la arquitectura empresarial es tan compleja o requiere un esfuerzo muy alto en su definición que varios arquitectos componen un mismo equipo, en el que uno lidera: el Principal Enterprise Architect y tiene uno o varios architects a los que supervisa y pueden tener: 

1. Business Enterprise Architect: Estos escasean por desgracia en España y son aquellos que acercan la estrategia de negocio a la arquitectura tecnológica de las organizaciones. En muchas grandes corporaciones los miembros de la PMO, juegan este papel pero sin conocimientos técnicos ni de integración de arquitecturas por lo que las áreas de negocio y las tecnológicas viven una frustración continua e insatisfacción por los resultados. Trabajan con descomposiciones funcionales de servicios de negocio, matrices tipo organización/rol o servicio/función, actor/rol, proceso/evento/control, etc.
2. Information / Data Architects: Para definir modelos de datos, sus relaciones, descripciones, reglas de negocio, diagramas de clase, diseminación, jerarquías, ciclo de vida de los datos, etc.
3.  Application Architects: Ya mencionados anteriormente y elaboran las matrices de interacción de aplicaciones, interfaces, casos de uso, etc.
4. Technology Architects: Aquellos que definen los estándares y portfolio tecnológicos, así como la tecnología estándar a usar en los sistemas y aplicaciones. Este perfil sí existe en España y es fácil de encontrar en las grandes corporaciones.

Queda claro que los Enterprise Architects están muy solicitados en grandes empresas y agencias gubernamentales de USA, UK, Australia, y Middle East entre otros. En concreto, certificaciones como TOGAF, o conocimientos en DOGAF, FEA o FSAM se empiezan a solicitar con más asiduidad.

Sin embargo, para cuándo tendremos en España, Centroamérica y Sudamérica una situación simular? En Méjico por su proximidad a USA sí es fácil encontrarlos pero en el resto, por desgracia, su presencia va con cuentagotas y casi siempre aparecen porque son requeridos por multinacionales americanas o británicas. 

Enterprise Architecture según The Open Group, por cierto, algunos lo llaman Arquitectura Empresarial...

The Open Group hace una aproximación formal a la definición de ‘Enterprise Architecture’ (Arquitecture Empresarial) afirmando que es un marco de trabajo que aporta soluciones a las necesidades de los stakeholders (personas cuyos intereses se ven afectados por la arquitectura de la empresa) y asegura una transformación suave de la organización y sin sobresaltos, facilitando modelos de negocio, de aplicaciones, de información y datos, y tecnológicos, así como su evolución en el tiempo.

Respecto a esta definición me gustaría dar mi punto de vista y aclarar varias cosas:

1.  La acepción moderna del término stakeholder, muy utilizado hoy en día, parece emerger en el Tavistock Institute de Londres a comienzos de los años 70. Sin embargo la aplicación del término ha ido evolucionando, por lo que desde mi punto de vista podemos considerar las siguientes definiciones en nuestro ámbito de Enterprise Architecture:

• El PMBOK®, en su cuarta edición define stakeholder en el ámbito de la gestión de proyectos como una persona u organización que tiene intereses que pueden verse afectados positiva o negativamente durante el transcurso y la finalización de un proyecto.
• The Open Group habla de ‘System Stakeholder’ como aquel individuo, equipo u organización cuyos intereses y preocupaciones están relacionados por alguna vía con un sistema.

2.  Cuando hablamos de marco de trabajo (framework) y herramientas, en el caso concreto de TOGAF, consideramos no sólo la metodología propuesta para hacer una aproximación a la arquitectura empresarial, si no también tenemos que considerar:

• Las definiciones de todos sus conceptos relativos a la arquitectura empresarial.
• El enfoque metodológico o ADM (Architecture Development Method) que va más allá de la propia metodología, que detalla paso a paso como crear la arquitectura .
• Un conjunto de guías y técnicas para aplicar con éxito la metodología.
• El metamodel en que se organiza los componentes de TOGAF y sus contenidos: matrices, diagramas y catálogos que se agrupan generando los building blocks (soluciones) de las arquitecturas.
• También se incluyen modelos de referencia, taxonomías y modelos organizativos para gobernar la organización en la evolución de sus arquitecturas.

3.  'Transformación suave…' Este término me encanta, sin duda es uno de mis favoritos, porque cuesta encontrar cambios en las distintas arquitecturas que no provoquen problemas, tiranteces entre las distintas áreas o imprevistos no previstos. Todos hemos tenido experiencias tensas y muy tensas en todos los sectores y compañías de cualquier tamaño. No debemos olvidar que una de las obligaciones del Enterprise Architect es realizar estas transiciones ‘as much smooth as possible’.

Estoy seguro que muchos de vosotros os habrá venido a la cabeza la famosa Gestión del Cambio, pero ojo, no se trata sólo de eso, si no de transiciones arquitectónicas en los niveles de business, information system y technological architecure.

4.  Por último, me gustaría que nos centráramos la coletillas final: ‘…y su evolución en el tiempo’. El término anglosajón empleado: Blueprint, hace referencia a los planos que utiliza un arquitecto en cada momento para la construcción. Su uso y aplicación en el ámbito empresarial me parece certero y exacto, pero ojo, en la vida real, hay retrasos, imprevistos y limitaciones que podrán impactar en nuestro plan de migración.

A veces es bueno leer las definiciones en detalle y sin prisas para tratar de entender de qué estamos hablando. OS aseguro que muchos CIOs, CTOs y CEOs hablan de Enterprise Architecture como una nueva tendencia de definir estrategia o una metodología de mejora de la calidad de los sistemas… Saber de lo que hablamos es tan sólo el primer paso para que nos escuchen con atención, nos respeten y piensen que lo que decimos puede tener sentido. A esto yo lo llamo romper estereotipos.

Bienvenidos al 'maravilloso' mundo de Enterprise Architecture en general y de TOGAF en particular

Comienzo este blog, que espero que contenga una colección de artículos útiles, entendibles y que aporten valor añadido a todos aquellos interesados en la teoría y práctica de Enterprise Architecture, y en particular de TOGAF®.

La primera decisión que he tomado ha sido la del idioma. Me cuesta trabajo escribir acerca de TOGAF®, Enterprise Architecture u otros frameworks en un idioma que no sea el inglés, pero creo que ahora es un buen momento para aportar mi granito de arena a la divulgación en español. Lo que si haré será introducir en inglés todos los términos propios de TOGAF® durante el discurso en español, ya que en muchas ocasiones no hay una traducción directa, y en otros, aun existiendo la traducción, no se entenderá prácticamente nada. Así que por favor, si alguien se siente ofendido por darle un bofetón a nuestro querido idioma, le pido disculpas ya que lo que intento es dar un mensaje más claro y acercar el mundo anglosajón y el de los hispano hablantes para el desarrollo de las mejores prácticas de Enterprise Architecture. No me atrae la idea de traducir todos los artículos, pero lo que si haré es escribir de vez en cuando en inglés.

Asimismo, no pretendo ser un académico, ni un teórico, sino más bien una persona ‘práctica’ que aplica las mejores ‘prácticas’ en un entorno en el que, aunque se valora mucho la formación, metodologías y distintos enfoques de estrategia, por desgracia se va demasiado deprisa como para mirar un poco más allá de lo que pasará en nuestras organizaciones en unos cuantos meses.

Así que, si te ves reflejado en las declaraciones escritas abajo y tienes interés en derribarlas, seguramente este blog te ayudará a abrir un poco tu mente y a mirar un poco más allá (por deferencia omito el nombre de los autores de las mismas, pero tampoco resultan tan raras, no crees?):

• “La vida real es muy distinta, en los libros siempre compila”
• “Lo que único que me interesa es aplicar la metodología y ya está, que bastante tenemos con lo que tenemos”
• “La teoría está muy bien, pero no hay ninguna teoría que te explique cómo es la práctica”
• “Con la experiencia que tenemos no nos hace falta un manual de 500 páginas escrito por alguien con otra cultura y que no conoce los intereses de mi compañía”
• “Desde luego, los americanos son unos cracks creando términos con siglas ininteligibles”
• “Todo esto está muy bien, pero  al que se lo tienes que contar es al CIO de mi organización”

Por último, si queréis conocer algo más sobre mí, podéis consultar mi biografía en el menú del blog.