WEBINAR

¿Cómo comenzar a gobernar la Arquitectura Empresarial con Sparx EA?
- Casos BANCA -

2021, MAYO 27

Reproducir vídeo

preguntas y respuestas

Se debe determinar ese canal. Tenemos un servidor que es algo tangible, nos podemos conectar al servidor y determinar cómo vamos a leer los puertos y cómo deseamos modelarlos dentro de nuestro epicentro de activos. ¿Hacemos un nodo y con ese nodo los puertos? ¿Cómo los mantenemos? Básicamente aplica la receta del primer y segundo paso de la solución SparxEA, que es: “Cómo se define un activo”. En todos los casos puede hacerse una PoC (prueba de concepto) real sobre las necesidades particulares y determinar cómo realizar esta exportación planteada.

Al igual que la pregunta anterior, esto también refiere a decisiones de modelado. Por un lado se define lo que está sucediendo en la realidad, y por otro lo que se desea reflejar en modelos y la forma en la que se hará. Dependiendo del lenguaje que deseemos usar, debemos reflejar la realidad de cierta forma. Primero debe decidirse si queremos que sea un activo, y luego cómo deseamos que sea su relación con otras cosas. 

Es muy determinante definir qué documentos deben ser, pero podemos establecer que un sistema tiene módulos, que posibilitan un desglose del mismo en submódulos. La pregunta que debe hacerse es: ¿Queremos modelar sistemas, subsistemas (si amerita), módulos? Quizás incluso podemos llegar al concepto de función, y la función puede modelarse por ejemplo como un requisito, como un caso de uso o como una historia de usuario. Con estos elementos podemos tener una taxonomía de cómo está compuesto un sistema, el cual expone servicios o microservicios. Debemos poder ubicar los mismos en el nivel correspondiente del sistema y decidir luego los parámetros de modelado. Para tomar esas decisiones siempre es importante definir quién espera consumir esta información. Si la documentación se realiza por cuestiones de normas o buenas prácticas, probablemente estemos perdiendo la posibilidad de contestarme por qué y para quién la hago.

Repositorios diferentes sí puedo tener, pero se debe definir primero dónde se desea visualizar las bases de datos con las que contamos. También es importante saber qué relación tienen entre sí las diferentes bases de datos, para poder reunir la información y visualizarla. Es recomendable tener una sola base de datos que tenga la función de reunir y exponer. El Dashboard visto en este webinar, perteneciente a la solución EAPRO, utiliza una base de datos para mostrar la información. 

Existe una funcionalidad nativa de la herramienta, que permite justamente, de una base de datos existente (conectando por ODBC) obtener un conjunto de tablas, SP, secuencias, numeraciones, etc. Utilizando complementos y addins, hemos aplicado ingeniería sobre esta información obtenida para tratar de encontrar vínculos de otra naturaleza que nos son de utilidad, y que en la funcionalidad de ingeniería nativa no podíamos obtener. Tratamos de que estas funcionalidades complementarias no sean manuales, sino automáticas, ya que el mantenimiento se torna imposible.

Totalmente. La respuesta va a depender de cuántos activos decidí administrar y gobernar en mi/s base/s de datos. Si tengo los activos modelados, relacionados entre sí de forma clara y limpia, bien definida y estudiada, es muy probable que pueda dar respuesta a la mayoría de las preguntas que me hagan. 

Si hiciéramos una línea del tiempo dentro de un proyecto, vamos a suponer que tenemos siempre una media de esfuerzo medido en horas de trabajo. Lamentablemente, cuando herramientas como Enterprise Architect no son bien utilizadas, son consideradas una carga extra al esfuerzo de trabajo. Nosotros intentamos en las primeras dos o tres semanas que el esfuerzo del trabajo propuesto al cliente sea muy poco en comparación a su esfuerzo habitual. Es decir, nosotros hacemos el trabajo más complicado al tomar información existente e intentamos generar un fuerte impacto inyectándola en los repositorios, modelando y trazando elementos, creando catálogos de activos, mapas de procesos, etc. De esta forma minimizamos el esfuerzo del cliente, pero maximizamos el valor percibido. Luego se debe definir cómo el cliente va a adecuar el esfuerzo de la implementación a su esfuerzo promedio acostumbrado, con lo cual logramos una implementación exitosa. En resumen, en las primeras 12 semanas puede tenerse ya un marco base totalmente funcionando, el cual sirve como acelerador porque define paso a paso lo que se debe ir haciendo y dónde hacerlo. Con lo cual en la segunda semana de trabajo ya se observa el valor, en la doceava semana el cliente está trabajando por sí solo, y a partir de ahí el resto depende de la madurez de cada uno.