Oracle Enterprise Architect, Oracle
Llevo trabajando como Arquitecto muchos
años (unos 15), con diferentes apellidos, de Sistemas, de Soluciones,
Empresarial,… y siempre me enfrento a la misma pregunta: “¿pero vosotros
realmente qué hacéis?”
Para explicarlo, me serviré de
situaciones en las que se podrá ver reflejado cualquiera que lleve ya algunos
años en este sector. El primer ejemplo, es una reunión de cualificación de una
oportunidad en un cliente de Sector Público que necesita una solución de
Gestión de Expedientes, a la que acude el responsable comercial acompañado de
un técnico experto en un área tecnológica concreta. Durante la reunión, los
responsables de diferentes áreas del cliente exponen su problemática de índole
tecnológica e incluso funcional, ya que la solución requerida tiene
condicionantes importantes sobre funcionalidad de Gestión de Expedientes. El
experto técnico, en el área de su experiencia, se siente cómodo pero en el
resto de áreas no entiende la importancia de los diferentes requisitos y
condicionantes. Al finalizar la reunión el responsable comercial se da cuenta
de que la reunión requería involucrar a otros expertos que hubieran podido
cubrir el resto de áreas, y en cambio, también se da cuenta de que por ser una
reunión preliminar, no requería un nivel de profundidad tal que necesitara la
presencia de expertos. ¿Cómo se hubiera solucionado esta reunión? Involucrando
a un Arquitecto Empresarial de Sector Público que entendiera la problemática de
este tipo de soluciones y que tuviera conocimientos básicos de las tecnologías
implicadas. A veces, este tipo de reuniones presentan un problema de amplitud
de los temas a tratar y no de profundidad técnica. En sucesivas iteraciones, se
podrían coordinar reuniones temáticas donde tratar temas de una tecnología
concreta.
Otro ejemplo, tiene que ver con el
desarrollo de un proyecto de despliegue de una solución compuesta por Base de
Datos, Servidor J2EE, Gestión Documental, y requisitos importantes de
Seguridad. Durante las reuniones de avance del proyecto en la fase de análisis,
el Jefe de Proyecto se da cuenta de que el nivel de detalle incluido en el documento
de requisitos, no es suficiente para entender la solución de forma global y
para saber cuáles son los subsistemas que serían necesarios y así poder
identificar correctamente los subsistemas con los requisitos que se deben
cubrir. El Jefe de Proyecto, decide incorporar un Arquitecto, que mediante
varias reuniones con el cliente y con los expertos técnicos de cada área
tecnológica, establece una serie de diagramas donde describe la funcionalidad
que debe cubrir la solución y su descomposición en subsistemas con las
interacciones entre ellos y los requisitos claramente identificados en cada
subsistema. Con estos diagramas los expertos técnicos pueden empezar a trabajar
de una forma clara y precisa. El Jefe de Proyecto está contento porque ve que
están bien identificadas todas las tareas que se deben realizar y que su Plan
de Proyecto refleja fielmente la realidad de los desarrollos y despliegues.
No hay comentarios:
Publicar un comentario