Desde los stakeholders hasta el despliegue…¿Cómo comenzamos este recorrido?

 

Y volvió a pasar… Todos reunidos en una sala, más de 20 personas, supuestamente los que “desarrollan el producto” para que otros puedan desarrollar de una manera más productiva y “ágil”… Básicamente los que deberían haber estado desarrollando los SBBs definidos en etapas de diseño de la arquitectura… desde el líder “supremo” (gurú de todo) hasta el desarrollador, pasando como no, por el Scrum master que no hacia otra cosa que hablar del Product Owner… y no precisamente tirándole rosas. Todos sabían lo que estaban haciendo, pero de una manera totalmente egocéntrica… sin saber el porqué, ni el resultado de lo que estaban desarrollando.

Lo mejor fue lo siguiente:

• Miembro X: “…Pues eso que estás comentando que te hace falta, ya lo hice yo hace tiempo”
• Miembro Y: “Ahh sí, pues no lo he visto ni en el Confluence, ni en el JIRA, ni ningún documento explicándola… Un correo al menos ¿no? ¿Lo metiste en alguna rama del GIT para poder echarle un ojo?”
• Miembro X:” Nooo que va, lo tengo en mi local.”
• Leader Supremo: “hombre… si ves que es algo de utilidad ¿cómo es que lo tienes en tu local y cómo es que no lo comentas con el equipo?”
• Miembro X: “Es que como nadie me ha dicho si esa pieza quiere que forme parte de algo, pues vi que me hacía falta, la cree para “mi proyecto de prueba” y ahí está…Ya si alguien la quiere que me lo pida”
• Miembro Z: “pues eso ya lo había desarrollado yo y te lo dije… ¿No recuerdas que lo hablamos en la daily?”

Sin comentarios

Asumiendo que la ejecución y maneras no son correctas bajo el prisma de un proyecto ágil y que no se está usando correctamente las herramientas para proyectos agile de las que se disponían, esto es un caso real de hace unos meses haciendo un brainstorming para intentar aplicar nuevas arquitecturas…(o no tan nuevas, pero “de moda”) y ver el estado del “arte” interno.

Pero vayamos a lo nuestro; en el primer post hablamos de los ABBs y los SBB, en el segundo introducimos el concepto de Viewpoint modelling de Archimate …en este vamos a mezclar los principales BB de una organización (las personas, esa es la respuesta correcta del primer post 🙂 ), cómo aplicar un punto de vista para estos ABBs asociados al proyecto y a sus responsabilidades…!!! AHHH eso es una RACI !!! ; Pues no, usaremos diagramas para describir y posteriormente tracear todos los artefactos de la arquitectura originados, y poder averiguar el por qué se originó un proyecto en cuestión, quienes estaban vinculados al mismo, y saber cómo engrana cada pieza del puzzle para cada artefacto generado.

El propio marco de la 42010 en su metamodelo, deja claro cómo se relaciona en arquitectura los “stakeholder” y cuáles son las relaciones a tener en cuenta:

En la propia especificación de TOGAF se explica en detalle la Gestión de los Interesados. Esta gestión de interesados; igualmente lo debemos alinear o enriquecer con otros estándares y cuerpos de conocimiento (si tenemos la oportunidad) para así mejorar cada área en función de nuestra experiencia ya sea en gestión de proyectos o en arquitecturas, o en gestión de proyectos de arquitectura; en concreto me estoy refiriendo al área 10 del estándar para gestión de proyectos (PMP – PMI).

Uniendo ambos mundos y marcos de trabajo, TOGAF y PMP, y focalizándonos en lo que pretendemos “explotar” en esta entrada del post, es decir… ¿Cómo represento dentro de una arquitectura empresarial la rama más intangible como las relaciones que se crean a la hora de desempeñar un proyecto para después poder explotar el resultado del propio proyecto?

Lo primero, como siempre, es identificar los puntos de vista que queremos aplicar para solventar la situación y sobre todo el PARA QUIEN iría dirigido.

Para este menester podríamos basarnos en los siguientes disponibles en función del StakeHolder, (pensemos que siempre podemos ADAPTARLOS a nuestra organización):

Stakeholder	Key Concerns	Class	Catalogs, Matrices and Diagrams
CxO (Corporate Functions); e.g., CEO, CFO, CIO, COO	The high-level drivers, goals, and objectives of the organization, and how these are translated into an effective process and IT architecture to advance the business.	KEEP SATISFIED	Business Footprint diagram Goal/Objective/ Service diagram Organization Decomposition diagram
Program Management Office (Corporate Functions); e.g., Project Portfolio Managers	Prioritizing, funding, and aligning change activity. An understanding of project content and technical dependencies between projects supports portfolio management decision-making.	KEEP SATISFIED	Requirements catalog Project Context diagram Benefits diagram Business Footprint diagram Application Communication diagram Functional Decomposition diagram
Procurement (Corporate Functions); e.g., Acquirers	Understanding what building blocks of the architecture can be bought, and what constraints (or rules) are relevant to the purchase. Acquirers will shop with multiple vendors looking for the best cost solution while adhering to the constraints (or rules) derived from the architecture, such as standards. The key concern is to make purchasing decisions that fit the architecture.	KEY PLAYERS	Technology Portfolio catalog Technology Standards catalog
Human Resources (HR) (Corporate Functions); e.g., HR Managers, Training & Development Managers	The roles and actors are required to support the architecture and changes to it. The key concern is managing people transitions.	KEEP INFORMED	Organization Decomposition diagram Organization/Actor catalog Location catalog Application and User Location diagram
Enterprise Security (Corporate Functions); e.g., Corporate Risk Management, Security Officers, IT Security Managers	Ensuring that the information, data, and systems of the organization are available to only those that have permission, and protecting the information, data, and systems from unauthorized tampering.	KEY PLAYERS	Product Lifecycle diagram Data Dissemination diagram Data Security diagram Actor/Role matrix Networked Computing Hardware diagram Communications Engineering diagram
QA/Standards Group (Corporate Functions); e.g., Data Owners, Process Owners, Technical Standards Bodies	Ensuring the consistent governance of the organization’s business, data, application, and technology assets.	KEY PLAYERS	Process/Event/ Control/Product catalog Contract/Measure catalog Application Portfolio catalog Interface catalog Technology Standards catalog Technology Portfolio catalog
Executive (End User Organization); e.g., Business Unit Directors, Business Unit CxOs, Business Unit Head of IT/Architecture	The high-level drivers, goals, and objectives of the organization, and how these are translated into an effective process and architecture to advance the business.	KEEP SATISFIED	Business Footprint diagram Goal/Objective/ Service diagram Organization Decomposition diagram Process Flow diagram Application Communication diagram
Line Management (End User Organization); e.g., Senior Business Managers, Operations Regional Managers, IT Managers	Top-level functions and processes of the organization, and how the key applications support these processes.	KEY PLAYERS	Business Footprint diagram Organization Decomposition diagram Functional Decomposition diagram Process Flow diagram Application Communication diagram Application and User Location diagram
Business Domain Experts (End User Organization); e.g., Business Process Experts, Business/Process Analyst, Process Architect, Process Designer, Functional Managers, Business Analyst	Functional aspects of processes and supporting systems. This can cover the human actors involved in the system, the user processes involved in the system, the functions required to support the processes, and the information required to flow in support of the processes.	KEY PLAYERS	Business Interaction matrix Actor/Role matrix Business Service/ Information diagram Functional Decomposition diagram Product Lifecycle diagram Business Use-case diagram Application Use-case diagram Application Communication diagram Data Entity/Business Function matrix
IT Service Management (Systems Operations); e.g., Service Delivery Manager	Ensuring that IT services provided to the organization meet the service levels required by that organization to succeed in business.	KEEP INFORMED	Technology Standards catalog Technology Portfolio catalog Contract/Measure catalog Process/Application Realization diagram Enterprise Manageability diagram
IT Operations – Applications (System Operations); e.g., Application Architecture, System & Software Engineers	Development approach, software modularity and re-use, portability migration, and interoperability.	KEY PLAYERS	Process/Application Realization diagram Application/Data matrix Application Migration diagram Software Engineering diagram Platform decomposition Diagram Networked Computing/ Hardware diagram Software distribution Diagram
IT Operations – Infrastructure (System Operations); e.g., Infrastructure Architect, Wintel support, Mid-range support, Operational DBA, Service Desk	Location, modifiability, re-usability, and availability of all components of the system. Ensuring that the appropriate components are developed and deployed within the system in an optimal manner.	KEY PLAYERS	Platform Decomposition diagram Technology Standards catalog Technology Portfolio catalog Enterprise Manageability diagram Networked Computing/ Hardware diagram Processing diagram Environments and Locations diagram
IT Operations – Data/Voice Communications (System Operations); e.g., Network Management	Location, modifiability, re-usability, and availability of communications and networking services. Ensuring that the appropriate communications and networking services are developed and deployed within the system in an optimal manner.	KEY PLAYERS	Communications Engineering diagram
Executive (Project Organization); e.g., Sponsor, Program Manager	On-time, on-budget delivery of a change initiative that will realize expected benefits for the organization.	KEEP INFORMED	Requirements catalog Principles catalog Value Chain diagram Solution Concept diagram Functional Decomposition diagram Application and User Location diagram
Line Management (Project Organization); e.g., Project Manager	Operationally achieving on-time, on-budget delivery of a change initiative with an agreed scope.	KEEP INFORMED	Application Communication diagram Functional Decomposition diagram Environments and Locations diagram
Business Process/Functional Expert (Project Organization); e.g., Financials FICO Functional Consultant, HR Functional Consultant	Adding more detail to the functional requirements of a change initiative based on experience and interaction with business domain experts in the end-user organization.	KEY PLAYERS	Process Flow diagram Business Use-case diagram Business Service/Information diagram Functional Decomposition diagram Application Communication diagram
Product Specialist (Project Organization); e.g., Portal Product Specialist	Specifying technology product designs in order to meet project requirements and comply with the Architecture Vision of the solution. In a packages and packaged services environment, product expertise can be used to identify product capabilities that can be readily leveraged and can provide guidance on strategies for product customization.	KEY PLAYERS	Software Engineering diagram Application/Data matrix
Technical Specialist (Project Organization); e.g., Application Architect	Specifying technology product designs in order to meet project requirements and comply with the Architecture Vision of the solution.	KEY PLAYERS	Software Engineering diagram Platform Decomposition diagram Process/Application Realization diagram Application/Data matrix Application Migration diagram
Regulatory Bodies (Outside Services); e.g., Financial Regulator, Industry Regulator	Receipt of the information they need in order to regulate the client organization, and ensuring that their information requirements are properly satisfied. Interested in reporting processes, and the data and applications used to provide regulatory return information.	KEEP SATISFIED	Business Footprint diagram Application Communication diagram
Suppliers (Outside Services); e.g., Alliance Partners, Key Suppliers	Ensuring that their information exchange requirements are met in order that agreed service contracts with the client organizations can be fulfilled.	KEEP SATISFIED	Business Footprint diagram Business Service/Information diagram Application Communication diagram

Por supuesto, tenemos que tener controlado la “catalogación de motivación” que queremos tener con cada uno de los interesados de la organización y/o del proyecto (columna “Class”) para así poder gestionar convenientemente todo lo que a expectativas del interesado se refiere.

Básicamente manejamos los siguientes valores:

Y en función de esto, sabremos (o al menos tenemos una guía) cómo actuar… qué periodicidad o insistencia tenemos que tener con cada uno… y sobre todo, saber comunicar LO NECESARIO a cada uno de ellos y de la manera apropiada con el grano de detalle que cada uno requiera.

Ahora bien, si ligamos los diagramas aconsejados para la gestión de los interesados con vistas de lenguajes de arquitectura como Archimate focalizándonos en un proyecto de IT y entrega de software, podríamos usar diferentes PdV (Puntos de Vista) para definir el cómo y el qué se consigue.

Empezaremos asociando vistas del plano “Motivacional” y a partir de aquí, bajaremos “inventándonos” una necesidad que se realiza con un requerimiento el cual se solucionará ofreciendo un valor de negocio determinado (en nuestro caso recordemos que nuestro negocio es nuestra propia Arquitectura) que se implementará con un componente software y que estará desplegado en una máquina concreta. Todo usando un mismo LENGUAJE y elementos y relaciones del mismo… para un mejor entendimiento sencillo y simple de cada uno de los artefactos que componen cada diagrama puedes dirigirte aquí.

Lo que queremos hacer es un corte transversal en los planos de arquitectura incluyendo (o reflejando) que una carencia que detectamos en la organización, lo podemos solucionar y dejar reflejado en nuestro repositorio empresarial de tal manera que siempre sepamos qué originó “qué” y “por quien” si es necesario, y lógicamente los artefactos generados, su localización, owner, etc…:

Vinculando un Marco de arquitectura como TOGAF con un lenguaje de arquitectura como Archimate (versión 2.1 en este ejemplo) :

Como comenzamos el artículo referenciando a las personas que componen un supuesto proyecto y sus posibles carencias, modelaremos esas carencias y su posible solución derivada (recordemos que es un ejemplo meramente ilustrativo para hacer entender la idea y valor añadido de los diagramas) empezando por un plano transversal de Motivación:

Ponemos el foco en las metas que queremos / debemos conseguir en nuestra organización y por tanto en nuestra Arquitectura Empresarial asociada (no nos olvidemos de las palabras “Arquitectura” y “Empresa” y lo que ello comprende), para ello usamos un PdV estándar de Archimate “Stakeholder Viewpoint” focalizándonos en la meta que queremos para nuestro proyecto… Mejorar el entendimiento de todos los StakeHolder del proyecto:

A partir de ahí y focalizándonos en una composición del objetivo principal, podemos “bajar” hacia el otro PoV de motivación que origina un proyecto… Cojamos por el ejemplo el “Goal” “Ningún ABB ni SBB sin información”. Para conseguir ese objetivo mostramos cómo se podría realizar usando un PoV que plasma cómo se realizaría esa meta. PdV “Goal Realization” también del plano de extensión de motivación… :

A su vez, identificamos los requerimientos necesarios para conseguir el objetivo y los servicios de negocio que realizarán dichos requerimientos. En este ejemplo simple, hemos identificados que tenemos que asignar un “owner” con capacidad y empowerment suficiente para gobernar el repositorio de arquitectura (“Assign responssible with capabilities”) y que cada elemento de dicho repositorio tiene que estar correctamente identificado y asociado a la arquitectura para que no esté desvinculado (“SBB Description and association”)

Un problema que suele pasar continuamente cuando estamos vinculados y viciados en el mundo IT, es que cada servicio de negocio, directamente lo vinculamos a una implementación por parte de un software que lo resuelva. Grave error. Un servicio de negocio es eso, un servicio que resuelve un negocio o necesidad que se ha identificado en la empresa, ya sea implementado por un sistema software final o simplemente con una acción que de valor. Todo esto también forma parte de la AE. Por ejemplo, en este caso, hemos “simulado” un servicio de negocio de asignación de responsable que se podría resolver simplemente con una asignación y tarea por parte del departamento de RRHH de la organización y otro que sí vamos a explorar y realizarlo con un aplicativo Software. Veamos cómo podríamos definir el proceso de negocio de este segundo. Usaremos un PdV “Business Process” para tal efecto:

Ya hemos llegado al plano de arquitectura de Negocio y observamos que definimos el proceso a nivel funcional para que un analista de negocio pueda “entendernos” fácilmente… Adicionalmente incluimos elementos como Interacción entre roles, de tal manera que sabemos quiénes interactúan en el proceso, delimitando las responsabilidades igualmente. Si profundizamos y para ver quién es quién y qué roles desempeñan en el proyecto, usaremos un punto de vista “Actor Cooperation”.

En la vista anterior “Business Process”, observamos dos “Business Objects” en esta capa… Recordemos que no hablamos de Software, aquí sólo pensamos en Objetos de negocio y cómo los asociamos igualmente al proceso… En este caso “ABB” y “SBB”… reiteramos que nuestro negocio es “la arquitectura” y por tanto nuestros objetos de negocio son estos dos elementos básicos de catalogación (por simplificar el ejemplo).

Recapitulemos: Tras identificar una carencia de negocio e indicar que debemos conseguir unas metas en la organización, hemos definidos cómo se podría alcanzar esas metas y realizarlas mediante la definición de unos requerimientos vinculados y una manera que esos requerimientos se implementen (ya sea con un sistema software o sin ese sistema software). Justo en este momento ya estamos preparados para “bajar” a otro plano… El plano de Información (Aplicación y Datos).

Para ello podemos identificar un PoV que nos ayude a expresar la necesidad que queremos resolver con un sistema Software… Veamos que el servicio de la aplicación (“Update Content Repository”) ya aparece en la vista de Negocio… Digamos que lo que estamos “hilando” es una unión entre los dominios por medio de un Servicio de aplicación de tal manera que a una persona de negocio le interesa el proceso de negocio y no cómo se va a resolver a nivel de artefacto software… Esta técnica es de suma importancia para afinar en las conversaciones con los stakeholders específicos y así poder respetar y “dimensionar” correctamente las expectativas y el grado de satisfacción del interesado en concreto… ya sea un CxO, un Arquitecto o un DBA. Veamos un ejemplo simple de PdV de aplicación:

En este plano (el de Información) tenemos dos dominios… el de la aplicación (diagrama de ejemplo anterior) y el de los Datos. Vemos que en el plano de aplicación referenciamos a determinados “Data Objects” (aquellos que hemos denominado XXX data)… Pero …. ¿cómo podemos saber a qué conceptos de negocio se refieren estos data Objects? ¿Cuál es el significado de sus instancias dentro del contexto de la organización y del proyecto en cuestión que estemos tratando? Para ello podríamos usar otro PdV “Information Structure Viewpoint”

Si bajamos más a un plano de datos, cada uno de los “Data Objects” se traduciría en un elemento de Dato y su diagrama correspondiente (si aplicara obviamente). Por ejemplo, un diagrama Entidad Relación típico que reflejara el detalle de entidades, atributos y relaciones asociadas al modelo de datos en cuestión que se generaría en la fase de desarrollo.

Y ya en este punto con los objetos de datos, ¿cuál sería el siguiente paso para llegar al siguiente dominio? ¿Cómo se podrían asociar posteriormente a un artefacto de infraestructura? ¿Puedo inferir la implementación final y el despliegue de esos elementos software y las máquinas finales donde residen?? Para ello, nos movemos hacia el mundo del “hierro” desde una perspectiva de diseño software… Pensemos en dar una solución a la implementación de nuestros artefactos previamente diseñados, de tal manera que sepamos cómo es su construcción a nivel tecnológico de plataforma, cuál es su comunicación, cuáles son sus protocolos… podemos llegar hasta el nivel de profundidad que queramos… pero para no complicar esta entrada del blog simplificaré la solución…

Pensemos que la solución final podría ser de los 2 componentes de la aplicación que ideamos, uno de ellos que obtiene su información en una BBDD relacional y otro en una BBDD documental. La aplicación se ha desarrollado en Spring, por ejemplo y ambos componentes están desplegados en un Servidor de aplicaciones Jboss… Igualmente existe una comunicación con el sistema ERP de la organización que, por Riesgo y seguridad operacional, se encuentra en otra ubicación física y que, para este caso, es de donde se obtiene un fichero con los datos de los StakeHolder que necesitemos… Una solución no muy real ni optima a nivel de Arquitectura de software, pero que ideamos para reflejar un PdV (“Infrastructure usage view”) de este plano:

Y con todo ya presentado, nos preguntamos ¿¿ Hemos solucionado el problema origen?? ¿¿Podríamos ver cuáles serían los Stakeholders vinculados a un artefacto software? Y por tanto… ¿podríamos indicar a un CIO que la aplicación X desplegada usa una BBDD Oracle cuya versión está a punto de no dar soporte por el fabricante? ¿Se podría poner en contacto el CIO con los arquitectos que idearon la solución? ¿y los arquitectos con el equipo de Desarrollo?…

La respuesta a todas estas preguntas es sí… Por ejemplo, para la primera, si recordamos el PdV “Actor Cooperation View” donde asignamos la información que queríamos y vinculamos los actores y su colaboración en el proyecto, podríamos realizar búsquedas y contactar con las personas concretas para lo que sea…

Algunas herramientas permiten realizar este tipo de búsquedas. Esto es un ejemplo, en el cual podríamos ejecutar una consulta indagando desde cualquier artefacto de nuestro diseño, para recopilar la información que queremos y que necesitamos alineado con las necesidades de los diferentes stakeholders. En este caso “quienes fueron los responsables a cargo de construir y desplegar la solución que finalmente se desplegó en la máquina X”:

Desde la máquina donde desplegamos la aplicación hasta el equipo que la diseñó y construyó … y lo mejor es que todo está en nuestro Repositorio de Arquitectura representado de tal manera que se le da lo que se necesita a quien lo necesita y de una manera visual con una simple consulta, dotando de la información con la que queramos extender los elementos básicos y que adaptamos porque son necesarios para nuestra organización.

Para terminar: A cuántos repositorios documentales hubiéramos tenido que acceder para “entender” los requerimientos? ¿a cuántos documentos ofimáticos o peticiones de los mismos a las personas (que si hay suerte conocemos) y si nos dan unas presentaciones caducas o peor aún “forwards” de correos de 8 intervinientes cada uno respondiendo con diferentes colores o acrónimos sobre una misma discusión de la solución para obtener una respuesta? Y seguro que más de uno no tendría ni que opinar… ¿Cuánto tiempo nos llevaría?…y lo mejor de todo… ¿Daríamos una respuesta a tiempo? ¿Seríamos productivos? ¿Cuánto dinero pierden las organizaciones por no entender y apostar por soluciones y proyectos de Arquitectura serios y seguir con “apaños” que lo único que hacen es desvirtuar esta área de conocimiento tan importante….

En esta entrada hemos “viajado” por los planos de arquitectura y hemos usado lenguajes de arquitectura en detalle para mostrar ese viaje… Hemos visto un ápice de lo que se puede hacer usando estas técnicas de una manera correcta… Hay muchos PdV stándard y extensiones que podemos desarrollar para adecuarlo a nuestras necesidades. En futuras entradas complementaremos este post con 2 planos que no hemos podido abordar (por lo largo de la entrada). El plano de “Implementation and Migration” que existe desde la especificación 2.1 y unos nuevos dominios con nuevos artefactos que se han incorporado a la especificación en Archimate 3.0.1 recién revisada y liberada … el plano físico y estratégico… Veamos cómo lo “pintamos”… ¡! Hasta la próxima y disfruten de la AE ¡!