Qué hace un arquitecto de soluciones?


Published on


Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • WORKSHOP – Understand the potential:Focus on high level challenges, business drivers and future state scenarios Identify areas that could benefit from a detailed assessment Discuss Dell’s capabilities Highlight next steps and timelines(there is a great workshop brochure on Sales Edge that gives a description of all the workshops available. It is a good learning tool plus an excellent way of introducing the breathe of our services to our customers) ASSESSMENT – Make informed decisions:Establish business requirements, Inventory and analyze existing environment Analyze the impact proposed change including cost/time savings estimates/analysis Recommend the best future state scenarioReduce risk with prescriptive guidance on how to efficiently and rapidly adopt the proposed solutionDESIGN – Lay the path for success:Deliver design specification and implementation Validate proposed solutionIMPLEMENTATION – Capture the value: Efficiently deploy the validated design into production On-site deployment & full production roll-out with comprehensive Dell project management Reporting and next steps Benefits include: Complete end to end services to realize the full benefit of IT infrastructure initiativesClear phases to help customers to make critical financial and technology decisions at each stageModular approach enables focus on customers’ top priorities
  • Qué hace un arquitecto de soluciones?

    1. 1. ¿Qué hace un Arquitecto de Soluciones?<br />Análisis “As is” “To Be”<br />
    2. 2. Agenda<br />Rol del Arquitecto<br />Análisis As isTo BE<br />¿Qué hacer con el resultado del análisis?<br />
    3. 3. Rol del arquitecto<br />
    4. 4. ¿Qué hace un arquitecto?<br />Este es un rol nuevo en las empresas.<br />No hay todavía un consenso en la definición de Arquitecto<br />Una definición simplista es que el rol del arquitecto es crear arquitecturas:<br />Visión de la arquitectura<br />Conceptualización y experimentación aproximaciones arquitectónicas <br />Definición de modelos y componentes de alto nivel<br />Validar la arquitectura candidata contra los requerimientos<br />
    5. 5. Rol del Arquitecto<br />RationalUnifiedProcess[1]<br />SUN SL-425[2]<br />Arquitecto es un rol en un proyecto de desarrollo de software el cual es responsable de:<br />Liderar el proceso de arquitectura.<br />Producir los artefactos necesarios: Documento de descripción de arquitectura<br />Modelos y prototipos de arquitectura<br />El arquitecto: <br />Visualiza el comportamiento del sistema.<br />Crea los planos del sistema.<br />Define la forma en la cual los elementos del sistema trabajan en conjunto.<br />Responsable de integrar los requerimientos no-funcionales (NRFs) en el sistema<br />
    6. 6. Competencias del Arquitecto SW[3]<br />
    7. 7. Análisis As is / TO BE<br />El inicio de un proyecto<br />
    8. 8. Proceso WADI<br /><ul><li>Limited duration, high impact engagements
    9. 9. Clear phases and decision points
    10. 10. Validated repeatable process
    11. 11. Flexible, modular approach</li></li></ul><li>AS isTo Be<br />
    12. 12. AS isTo Be<br />
    13. 13. AS isTo Be<br />System<br />To be <br />Improved<br />
    14. 14. As is<br />Primary Users<br />Las funcionalidades actuales<br />¿Cuáles son?<br />¿Se utilizan?<br />¿satisfacen las necesidades?<br />¿están todas cubiertas?<br />¿Es necesario cambiar algunas?<br />Aspectos no funcionales<br />¿cuáles son?<br />¿Satisfacen las necesidades y expectativas?<br />¿cómo se miden?<br />¿Regulaciones y políticas?<br />Disponibilidad del sistema (HA + DRP)<br />¿Accesos externos?<br />Competencias de los usuarios<br />¿saben lo que requieren saber?<br />¿Saben sacar provecho de las capacidades actuales?<br />
    15. 15. As is<br />Management Control <br />Necesidades de administración de los recursos<br />¿Cómo se «monitorea» el sistema<br />¿Están separados los roles y/o autorizaciones requeridos?<br />¿Hay Role base access control?<br />Seguridad del sistema<br />Control de acceso<br />Seguridad de los datos (Propiedad intelectual)<br />Seguridad de canales<br />Etc… <br />
    16. 16. As is<br />Workflow Tasks (orchestrations)<br />Procesos de Negocio<br />¿Tienen correlación con funcionalidades?<br />¿Las funcionalidades actuales articulan procesos de negocios?<br />¿Qué procesos son realizados por funcionalidades inconexas?<br />¿Cuellos de botella?<br />¿Hay cuellos de botella hoy?<br />¿dónde están?<br />¿hay funcionalidades que no agregan valor?<br />¿Hay funcionalidades que «estorban» en trabajo?<br />
    17. 17. As is<br />System Interaction (choreographies)<br />Procesos de Negocio<br />¿Hay procesos de negocio que cruzan las fronteras de este sistema?<br />¿Hay procesos de negocio que cruzan las fronteras de la organización?<br />Estándares de la integración<br />¿Se utiliza algún protocolo de industria? (XML, HL7, etc)<br />¿cumple con la normativa?<br />Seguridad<br />¿Se utilizan mecanismos de seguridad a nivel de canales?<br />¿Se utilizan mecanismos de seguridad a nivel de datos?<br />¿Tiene algún problema de seguridad?<br />
    18. 18. As is<br />Performance Measurements (leading and lagging metrics)<br />Proceso de Negocio (Funcional)<br />¿se capturan métricas del desempeño de los procesos?<br />¿Estas métricas son claras y útiles?<br />¿Hay reportes de la gestión?<br />Operacionales<br />¿Se tienen métricas sobre la operación del sistema?<br />¿Se tiene visibilidad del estado de los componentes del sistema?<br />¿hay alertas?<br />
    19. 19. As is<br />Business Decisions<br />¿Hay decisiones que afecten el sistema?<br />Nuevo modelo de ventas<br />Empleados Remotos<br />Fusiones<br />¿Hay acuerdos comerciales que afecten el sistema?<br />Licencias de software<br />Contratos de soporte<br />garantías<br />
    20. 20. ¿Dónde está To BE?<br />Es el resultado de todos los GAP que aparece de «AS is»<br />System<br />To be <br />Improved<br />
    21. 21. ¿Qué hacer luego?<br />El resultado del análisis<br />
    22. 22. Para proyectos «Complejos»<br /><ul><li>Alto Riesgo
    23. 23. Alta complejidad
    24. 24. Sistemas críticos</li></li></ul><li>Para proyectos «Simples» <br /><ul><li>Bajo Riesgo
    25. 25. Baja complejidad
    26. 26. Presupuestos acotados
    27. 27. Por ningún motivo, tiempos de implementación acotados</li></li></ul><li>Referencias<br />Philippe Kruchten. The rational Unified Process, Pearson Education, 1999<br />Sun, Developing Architectures for Enterprise Java Applications (SL-425), http://www.sun.com/training/catalog/courses/SL-425.xml<br />Malan, R., and D. Bredemeyer. “The Role of theArchitect.” BredemeyerConsulting Software ArchitectureResources, June 28 2000.<br />