Prácticas de Arquitectura en una Empresa de Servicios

  • 1,473 views
Uploaded on

Una descripción de las prácticas y de una experiencia exitosa en la implementación de una área de arquitectura informática.

Una descripción de las prácticas y de una experiencia exitosa en la implementación de una área de arquitectura informática.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,473
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
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

Transcript

  • 1. Prácticas de Arquitecturaen una Empresa de Servicios
    Andrés Camilo Bustamante
    Mayo de 2006
  • 2. Agenda
    Los retos de un área de tecnología en una empresa de servicios
    Estrategias para ofrecer valor a las áreas de negocio
    Prácticas de arquitectura
    Preguntas
  • 3. Los retos de un área de tecnología
    En abstracto: Apoyar al negocio
    Apoyo táctico (procesos operativos)
    Apoyo estratégico (procesos de planeación y de toma de decisiones)
    Apoyar la continuidad del negocio
  • 4. Los retos de un área de tecnología
    En concreto:
    Proveer (no importa la fuente) software para mejorar la eficiencia de la compañía, trasladando la eficiencia a los clientes o accionistas
    Proveer (si importa la fuente), de manera confiable y oportuna, la información necesaria para apoyar los procesos de planeación y de toma de decisiones
    Garantizar la continuidad de los procesos de la compañía a través de hardware y software capaz de ofrecer alta disponibilidad a pesar de errores y fallas de cualquier magnitud
  • 5. Los retos de un área de tecnología
    Todo esto se debe realizar:
    Cumpliendo un presupuesto (Costos)
    Ofreciendo soluciones rápidamente (Tiempo)
    Ofreciendo soluciones confiables (Calidad)
    Somos equilibristas; tratamos de mantener el equilibrio entres costo, tiempo y calidad para todos los proyectos y durante la operación
  • 6. Los retos de un área de tecnología
    Los costos de operación es algo en lo que muy pocas veces piensan las empresas de software y sobre lo que piensan mucho las empresas de servicios
    Las áreas de tecnología se convierten en áreas estratégicas en cuanto dejan de entregar software aislado y comienzan a entregar soluciones de negocio (producto vs desarrollo a la medida)
  • 7. Estrategias para ofrecer valor a las áreas de negocio
  • 8. Estrategias para ofrecer valor
    Proveer soluciones
    Compra de productos de software (Caja negra)
    Desarrollo a la medida vía tercerización
    Desarrollo a la medida interno
    Esquemas mixtos
    Algunas fases del ciclo se desarrollan internamente
    Algunas fases del ciclo son desarrolladas por proveedores
    Con tantos esquemas ¿cómo mantener la coherencia y cumplir con los retos?
  • 9. La arquitectura como estrategia para ofrecer valor
    Tres pilares
    Infraestructura
    Estándares tecnológicos
    Plataforma de integración
    Herramientas y esquemas de administración
    Especificaciones
    Arquitectura (software, telco y hardware)
    Modelo de integración
    Gobierno
    Coordinación, revisión y reporte
    Políticas y normativas
    Mejores prácticas (patrones y frameworks)
    Documentación y publicación
  • 10. La arquitectura como estrategia para ofrecer valor
    Si se trabaja sistemáticamente en infraestructura, especificaciones y gobernabilidad se podrán entregar soluciones de negocio
    Estas soluciones deberán ser equilibradas (TCQ) durante su construcción y operación
    Deberán cumplir con la calidad esperada por el negocio (disponibilidad, desempeño, confiabilidad)
  • 11. La arquitectura como estrategia para ofrecer valor
    Un equipo de arquitectura dentro de una empresa de servicios es fundamental para apoyar a la gerencia de un área de tecnología en el esfuerzo de entregar valor al negocio
    Los esfuerzos aislados pueden resultar interesantes pero a la larga no serán efectivos a nivel general
  • 12. Prácticas de Arquitectura
  • 13. Prácticas de Arquitectura
    Definir el “estilo” de arquitectura general que gobernará el diseño de las soluciones:
    SOA (Muy parecido a broker)
    MVC como meta patrón
    Definir la infraestructura y los lineamientos para su utilización
    Servidor de aplicaciones J2EE
    Ambiente .NET
    Servidor, seguridad, telco
  • 14. Prácticas de Arquitectura
    Definir los procesos de desarrollo
    Metodología
    Lenguaje de modelado (UML y estilos)
    Métricas
    Plasmar las mejores prácticas en frameworks
    Implementación de patrones
    Utilización eficiente de lógica no funcional
    Mejorar curva de aprendizaje
  • 15. Prácticas de Arquitectura
    Documentar, publicar y divulgar normas, políticas y lineamientos
    Para la situación actual
    Para situaciones transicionales
    Para situaciones objetivo
    • Evaluar constantemente nuevas tecnologías
    • 16. Definir mejores prácticas
    • 17. Desarrollar frameworks
    • 18. Publicar lineamientos
  • Prácticas de Arquitectura
    Evaluación de arquitecturas de soluciones
    En primer lugar entender el objetivo del negocio, después viene la tecnología
    Cada proyecto es responsable de la arquitectura de la solución, un arquitecto acompaña al proyecto
    Para proyectos que no tienen acompañamiento permanente se realizan evaluaciones de arquitectura (revisiones informales o formales)
    Es fundamental evaluar la arquitectura técnica con los expertos de esta área (administradores de servidores, telco, seguridad, calidad)
  • 19. Prácticas de Arquitectura
    Aprender las lecciones
    Cada proyecto deja lecciones que no se deben dejar solamente en la memoria de los participantes, deben ser documentadas y divulgadas (incluso implementadas como patrones, si es el caso)
    Los arquitectos no se las saben todas, es mejor aceptar que no se sabe y aprender nuevas o mejores maneras de hacer las cosas
  • 20. Prácticas de Arquitectura
    Ser un elemento facilitador y no una traba para los proveedores
    Cada proveedor tiene su propia manera de hacer las cosas, esto hay que aceptarlo. Sin embargo se debe asegurar que todo proveedor cumpla con el estilo de arquitectura, con las normar, políticas y lineamientos
    Explicar la infraestructura con la que ya cuenta la compañía, presentar los ambientes y contextualizar sobre las prácticas de desarrollo
  • 21. ¿Preguntas?