Your SlideShare is downloading. ×
Qué hace un arquitecto de soluciones?
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Qué hace un arquitecto de soluciones?

8,649

Published on

Preenta

Preenta

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
8,649
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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
  • Transcript

    • 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
    • 8. Proceso WADI
      • Limited duration, high impact engagements
      • 9. Clear phases and decision points
      • 10. Validated repeatable process
      • 11. Flexible, modular approach
    • AS isTo Be
    • 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
    • 22. Para proyectos «Complejos»
      • Alto Riesgo
      • 23. Alta complejidad
      • 24. Sistemas críticos
    • Para proyectos «Simples»
      • Bajo Riesgo
      • 25. Baja complejidad
      • 26. Presupuestos acotados
      • 27. Por ningún motivo, tiempos de implementación acotados
    • Referencias
      Philippe Kruchten. The rational Unified Process, Pearson Education, 1999
      Sun, Developing Architectures for Enterprise Java Applications (SL-425), http://www.sun.com/training/catalog/courses/SL-425.xml
      Malan, R., and D. Bredemeyer. “The Role of theArchitect.” BredemeyerConsulting Software ArchitectureResources, June 28 2000.

    ×