Prácticas de Arquitectura en una Empresa de Servicios

1,615
-1

Published on

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

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
1,615
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Prácticas de Arquitectura en una Empresa de Servicios

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

×