• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Qué hace un arquitecto de soluciones?
 

Qué hace un arquitecto de soluciones?

on

  • 7,674 views

Preenta

Preenta

Statistics

Views

Total Views
7,674
Views on SlideShare
6,998
Embed Views
676

Actions

Likes
0
Downloads
0
Comments
0

3 Embeds 676

http://jpgarcia.cl 545
http://jpgarcia69.wordpress.com 129
http://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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? Qué hace un arquitecto de soluciones? Presentation Transcript

  • ¿Qué hace un Arquitecto de Soluciones?
    Análisis “As is” “To Be”
  • Agenda
    Rol del Arquitecto
    Análisis As isTo BE
    ¿Qué hacer con el resultado del análisis?
  • Rol del arquitecto
  • ¿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
  • 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
  • Competencias del Arquitecto SW[3]
  • Análisis As is / TO BE
    El inicio de un proyecto
  • Proceso WADI
    • Limited duration, high impact engagements
    • Clear phases and decision points
    • Validated repeatable process
    • Flexible, modular approach
  • AS isTo Be
  • AS isTo Be
  • AS isTo Be
    System
    To be
    Improved
  • 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?
  • 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…
  • 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?
  • 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?
  • 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?
  • 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
  • ¿Dónde está To BE?
    Es el resultado de todos los GAP que aparece de «AS is»
    System
    To be
    Improved
  • ¿Qué hacer luego?
    El resultado del análisis
  • Para proyectos «Complejos»
    • Alto Riesgo
    • Alta complejidad
    • Sistemas críticos
  • Para proyectos «Simples»
    • Bajo Riesgo
    • Baja complejidad
    • Presupuestos acotados
    • 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.