2021, MAYO 27
Te invitamos a participar de este webinar donde te mostraremos los pasos necesarios para que comiences a utilizar y aprovechar esta poderosa plataforma.
Enterprise Architect te permitirá rápidamente tener control sobre los activos organizacionales y la trazabilidad entre ellos, pudiendo obtener ágiles respuestas ante los cambios.
Adicionalmente, te permitirá compartir y difundir información a mayor cantidad de partes involucradas en el negocio.
Observa cómo otros Bancos de la región ya lo hicieron. Te mostraremos los resultados y principales beneficios que ellos ya están obteniendo.
1. LA IMPORTANCIA DE UN “EPICENTRO DE ACTIVOS”:
– La importancia de reunir, normalizar y gobernar los activos de la organización, como también la mayor cantidad de información que represente y especifique el dominio del negocio.
– ¿Cómo identificar estos activos? ¿Cómo inyectarlos rápidamente en una base de datos centralizada?
– ¿Cómo trazarlos entre ellos y mantenerlos actualizados?
2. SIN TRAZABILIDAD NO HAY ANÁLISIS DE IMPACTO:
– Compartiremos una técnica probada de análisis de impacto para mejorar la velocidad y efectividad de las respuestas ante los cambios constantes del negocio (o para tener respuestas oportunas ante auditorias).
– Todas las capas de la arquitectura empresarial interrelacionadas mediante una trazabilidad de punta a punta. Desde el negocio hasta la infraestructura, incluyendo la convivencia con metodologías ágiles.
3. INFORMACIÓN AL INSTANTE PARA LAS PARTES INTERESADAS:
– Irradiación de información al instante en forma expansiva involucrando y satisfaciendo a todas las partes interesadas del negocio.
– ¿Cómo lograr que las especificaciones en general (arquitecturas, diseños, procesos, integraciones, roadmaps, catálogos, etc.) se mantengan “vivas” y accesibles?
– Te mostramos cómo se puede generar un espacio de colaboración dinámica, de manera que la información esté al alcance de quien la necesite en el momento en el que la necesite.
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.
Enterprise Architect ® y Sparx Systems ® son marcas registradas propiedad de la compañía Australiana Sparx Systems Pty. Ltd. como así también todos los logos y logotipos relacionados a esos productos.