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

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

16. Definir mejores prácticas

17. Desarrollar frameworks

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?