Preenta

1. ¿Qué hace un Arquitecto de Soluciones? Análisis “As is” “To Be”

2. Agenda Rol del Arquitecto Análisis As isTo BE ¿Qué hacer con el resultado del análisis?

3. Rol del arquitecto

4. ¿Qué hace un arquitecto? Este es un rol nuevo en las empresas. No hay todavía un consenso en la definición de Arquitecto Una definición simplista es que el rol del arquitecto es crear arquitecturas: Visión de la arquitectura Conceptualización y experimentación aproximaciones arquitectónicas Definición de modelos y componentes de alto nivel Validar la arquitectura candidata contra los requerimientos

5. Rol del Arquitecto RationalUnifiedProcess[1] SUN SL-425[2] Arquitecto es un rol en un proyecto de desarrollo de software el cual es responsable de: Liderar el proceso de arquitectura. Producir los artefactos necesarios: Documento de descripción de arquitectura Modelos y prototipos de arquitectura El arquitecto: Visualiza el comportamiento del sistema. Crea los planos del sistema. Define la forma en la cual los elementos del sistema trabajan en conjunto. Responsable de integrar los requerimientos no-funcionales (NRFs) en el sistema

6. Competencias del Arquitecto SW[3]

7. Análisis As is / TO BE El inicio de un proyecto

9. Clear phases and decision points

10. Validated repeatable process

12. AS isTo Be

13. AS isTo Be System To be Improved

14. As is Primary Users Las funcionalidades actuales ¿Cuáles son? ¿Se utilizan? ¿satisfacen las necesidades? ¿están todas cubiertas? ¿Es necesario cambiar algunas? Aspectos no funcionales ¿cuáles son? ¿Satisfacen las necesidades y expectativas? ¿cómo se miden? ¿Regulaciones y políticas? Disponibilidad del sistema (HA + DRP) ¿Accesos externos? Competencias de los usuarios ¿saben lo que requieren saber? ¿Saben sacar provecho de las capacidades actuales?

15. As is Management Control Necesidades de administración de los recursos ¿Cómo se «monitorea» el sistema ¿Están separados los roles y/o autorizaciones requeridos? ¿Hay Role base access control? Seguridad del sistema Control de acceso Seguridad de los datos (Propiedad intelectual) Seguridad de canales Etc…

16. As is Workflow Tasks (orchestrations) Procesos de Negocio ¿Tienen correlación con funcionalidades? ¿Las funcionalidades actuales articulan procesos de negocios? ¿Qué procesos son realizados por funcionalidades inconexas? ¿Cuellos de botella? ¿Hay cuellos de botella hoy? ¿dónde están? ¿hay funcionalidades que no agregan valor? ¿Hay funcionalidades que «estorban» en trabajo?

17. As is System Interaction (choreographies) Procesos de Negocio ¿Hay procesos de negocio que cruzan las fronteras de este sistema? ¿Hay procesos de negocio que cruzan las fronteras de la organización? Estándares de la integración ¿Se utiliza algún protocolo de industria? (XML, HL7, etc) ¿cumple con la normativa? Seguridad ¿Se utilizan mecanismos de seguridad a nivel de canales? ¿Se utilizan mecanismos de seguridad a nivel de datos? ¿Tiene algún problema de seguridad?

18. As is Performance Measurements (leading and lagging metrics) Proceso de Negocio (Funcional) ¿se capturan métricas del desempeño de los procesos? ¿Estas métricas son claras y útiles? ¿Hay reportes de la gestión? Operacionales ¿Se tienen métricas sobre la operación del sistema? ¿Se tiene visibilidad del estado de los componentes del sistema? ¿hay alertas?

19. As is Business Decisions ¿Hay decisiones que afecten el sistema? Nuevo modelo de ventas Empleados Remotos Fusiones ¿Hay acuerdos comerciales que afecten el sistema? Licencias de software Contratos de soporte garantías

20. ¿Dónde está To BE? Es el resultado de todos los GAP que aparece de «AS is» System To be Improved

21. ¿Qué hacer luego? El resultado del análisis

23. Alta complejidad

25. Baja complejidad

26. Presupuestos acotados