  |
Hace ya algún tiempo que decidí profundizar en los estándares de IT y que, de alguna manera, una comunidad promueve y hace que estos sigan siempre vivos y así, sean una referencia para la comunidad. Siempre he pensado que la adaptación de ideas también es innovar, puesto que ningún estándar encaja a la perfección en ninguna empresa y siempre hay que idear nuevas formas y maneras para su adopción… Es decir, el binomio “Organización y Estándares” no es fijo en su aplicabilidad, sino que el reto está en conocer una organización, conocer los posibles marcos de referencia que están relacionados con el negocio que la organización intenta resolver (o de los que carece) y adaptarlos en función de la conveniencia del mismo a la empresa… (adaptarlos generalmente suele ser “aligerarlos” en las fases tempranas). De ahí que profundizara y me apasionara por estándares de Arquitectura Empresarial, después de haber pasado por los diferentes estadios del mundo de la arquitectura técnica, software y de aplicaciones (previamente de haber venido del mundo de desarrollo) , todo esto dentro del ámbito de los dominios de arquitectura y conjugándolo con gestiones de proyectos, personas, proveedores, etc… haciendo que entienda un poquito mejor, la Arquitectura Empresarial en su amplio espectro y de los marcos de arquitectura que la soportan como TOGAF en concreto.
La idea de esta entrada es introducir, o al menos dejar determinadas pinceladas de asociación de estándares que ayudan / brindan una guía para que los profesionales que nos dedicamos a este mundo, sepamos donde acudir para ver si nos dirigimos hacia un espectro más o menos “seguro” o al menos “madurado con anterioridad”; ya sabemos que seguro no hay nada, pero si hay mucha gente que ha reflexionado previamente que algo vale, seguramente partiremos de una base que nos encajará para así no reinventar la rueda continuamente…
Últimamente, por diferentes razones, veo como mucha gente a la que intentaba introducir y charlar de ideas de EA hace bastante tiempo, están cada día más cercanos a las mismas, hecho que me satisface (aunque no sea por voluntarismo sino por imposición laboral). Lo que está claro es que si se hace es porque se ha decidido que es una buena inversión dotar a los profesionales con estos conocimientos. Si son los indicados o no, el tiempo lo dirá si realmente sacan valor a los conocimientos que adquieran y sobre todo, si van a saber adaptarlos, aplicarlos, comunicarlos y defenderlos.
Ahora bien, uno de los principios básicos que se defiende en el Open Group es la interoperabilidad dentro del concepto de Boundaryless Information Flow™. Ese concepto es básico para pensar que no hay barreras en la información y en la tecnología.
Para los que conozcan ya el ADM de TOGAF, saben que en la fase B, C y D es donde se genera la “Arquitectura” como tal y que la iteración en estas fases contribuye a tener finalmente una arquitectura refinada. Ahora bien, el método está ahí, pero…
¿no sería interesante averiguar si por cada una de las fases de creación de la arquitectura podemos profundizar todavía más?.
De ahí la razón de esta entrada del blog… BIF & BoKs.
BIF ya hemos “inferido” a qué se refiere…. Boundaryless Information Flow™ y BoK es un concepto más ampliamente usado y conocido… Body of Knowledge, o cuerpo de conocimiento. Entonces la pregunta concreta podría ser…
¿Existe un cuerpo de conocimiento específico para la creación de una “Arquitectura de Negocio”? ¿Y para una Arquitectura de Información y de Tecnología?
La respuesta a mi modo de ver es sí, y ahora vamos a hacer la asociación y a hacer una breve correspondencia.
FASE B: Business Architecture: BIZBOK
La arquitectura de negocio, representa una visión holística y multidimensional de capacidades, cadenas de valor e2e del delivery, estructuras informacionales y organizacionales y las relaciones entre estas vistas de negocio y estrategias, productos, políticas, iniciativas e interesados.
El esquema conceptual para BIZBOK es el que vemos a continuación
FASE C: Information Architecture: SWEBOK y DAMA-DMBOK
Recordemos que la arquitectura de la información se divide en 2 naturalezas de arquitecturas:
- La arquitectura de aplicaciones y
- La arquitectura de Datos.
Para la primera, un cuerpo de conocimiento muy amplio que podemos usar como referencia es el cuerpo de Ingeniería del Software (SWE-BOK) donde se cubre gran parte de referencias para las aplicaciones, aquí sólo señalamos los dominios al respecto de las aplicaciones software en lo que se refiere a su diseño y a su construcción.
Igualmente, un cuerpo de conocimiento muy consolidado y que debemos tener en el radar cada vez que hablemos de datos es DAMA – DMBOK. Creo que es uno de los cuerpos más completos que he visto y en breve haremos un post dedicado al mismo, ya que hace un par de meses, la organización DAMA ha sacado su versión 2
FASE D Technology Architecture: SEBOK e ITABoK:
Conjuntamente con SWEBOK, ambos cuerpos cubren mucho más que sólo la parte de la tecnología, y son un buen referente para indagar en ellos y complementar el estudio de la fase D del ADM
Lógicamente los cuerpos de conocimientos se cruzan entre ellos en diferentes dimensiones (por ejemplo los interesados/stakeholders, estrategias, diseño,…), y a su vez se entremezclan con el ADM de TOGAF; ahora bien, está en nuestra mano saber discernir y aprovechar las mejoras que cada uno defiende para luego ir contribuyendo con experiencias y valor añadido en su aplicabilidad. Pensemos en TOGAF y su ADM como la base fundamental para enriquecerlo posteriormente según deseemos hacer foco en las experiencias del dominio tecnológico donde nos especialicemos.
Hasta ahora, pensemos que sólo estamos poniendo el foco, en la iteración de creación de arquitecturas de dominio, pero para el resto de las fases del ADM, si queremos obtener una arquitectura empresarial completa, podríamos apoyarnos también en otros cuerpos de los que podríamos sacar provecho…
BABoK es el cuerpo de conocimiento de los analistas de negocio, por lo que seguro que podemos mejorar enormemente la fase de gestión de requerimientos y Change Management, y como no, el archi conocido PMBoK, nos valdría para gobernar todo el proceso de arquitectura de empresa, al igual que para conseguir el objetivo final como un proyecto más, en este caso de arquitectura.
A veces, los proyectos de arquitecturas tampoco quedan demasiado claro para determinados stakeholders que piensan que simplemente un proyecto de estas características es “comprar más herramientas”, derivando incluso a que no se disponga del empuje suficiente por parte de todos los involucrados del proyecto. Por lo tanto, está en nuestra mano hacer entender por qué son esenciales los estándares para conseguir un modelo fiable y que, en la medida de lo posible, cada arquitecto se esfuerce en fomentar la idea de la Interoperabilidad y el uso de cuerpos de conocimiento dentro de la arquitectura empresarial… Hay más cuerpos posibles a seguir, por ejemplo para pruebas de software así como EABoK focalizado en la materia que nos ocupa.
Espero que ahora, cuando decidamos profundizar en una fase del ADM en concreto, sepamos que podemos siempre recurrir a recursos específicos que nos formarán y darán una perspectiva más amplia del campo en concreto que queramos estudiar… espero haberles ayudado o al menos introducir la curiosidad para el que quiera profundizar en estos mundos.
Nos “vemos” en la próxima entrada del blog donde, intentaremos analizar el diseño usando vistas de Archimate para un campo en el que no hay nada “estandarizado” abierto entre los diferentes vendors y en el que daremos nuestra propuesta y aproximación… Diseño de BBDD NoSQL; y en el siguiente ligaremos la interoperabilidad y los datos. Esperemos que no nos demoremos tanto…los cambios son así. 🙂
EAMinds 