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.