Brechas en TI y la analogía con un triangulo como medio de ordenamiento

Hace poco estuve realizando una asesoría que tenia como objeto la identificación de brechas entre los procesos y las tecnologías. Generalmente, existen brechas en TI, relacionadas con el uso tradicional de las tecnologías vs. la incorporacion de arquitectures orientadas en servicios y procesos. Esta diferencia representa en si misma una brecha, dado que la organizacion debe cambiar, adaptarse y promover acciones para mejorar su desempeño aplicando nuevos enfoques. Para inciar un proceso de cambio organizacional, es recomendable desarrollar las suguientes iniciativas:

1. El primer paso es establecer la direccion de TI que requiere la organización para mejorar su desempeño estrategico, táctico y operacional. Es recomendable desarrollar un "Marco de Arquitectura Organizacional" y un "Mapa Integral de Tecnologías". El primero define las disciplinas y estilos arquitectónicos que la organización debe adoptar, el segundo describe las capas tecnológicas y las practicas de gobernabilidad que seran requeridas para impulsar cambios en la organización con el objeto de disminuir las brechas presentes.  
2. El segundo paso es el desarrollo de un marco de gobernabilidad que establezca la organización, roles, responsabilidades, políticas, procesos, entre otros que requiere la organización para disminuir los riesgo en la adopción de nuevas practicas y enfoques de TI.
3. El tercer paso es desarrollar desde el punto de vista táctico los recursos y acciones que serán necesarios para cumplir con la visión, misión y objetivos estratégicos de la organización. 

En los próximos post estaré compartiendo las brechas mas comunes en las organizaciones en TI y procesos. Volviendo la tema de brechas, quiero compartir una analogia que muestra las brechas mas comunes en una organización utilizando como referencia una figura geométrica: El Triangulo (Figura anexa).

1. En las bases de triangulo tenemos los datos. En la medida que avanzamos hacia la punta mas alta del triangulo esta se convierte en información. Es común que las organizaciones no alcancen este nivel, por ende el ejercicio de toma de decisiones es costoso e ineficaz.
2. El triangulo esta dividido en dos areas: gestion y operaciones. Es comun que las organizaciones enfaticen todos sus esfuerzos en sus operaciones, pero poco en la gestión para medir su desempeño.
3. Cada una de las áreas contiene 3 perspectivas, la estratégica, táctica y operacional. Es comun que las organizaciones no desarrollen el area estrategica y tactica. En muchos casos las organzaciones no tiene un plan de tecnología integral que responda a sus necesidades estratégicas.
4. En cada una de las capas deben existir indicadores de gestion y de resultados. Estos indicadores deben disparar eventos. La mayoría de las organizaciones no identifican sus productos, servicios e indicadores. Sin estos indicadores no podemos medir, mejorar y optimizar.
5. Es común que se propicien isla en las diversas perspectivas. Es necesario establecer un marco de gobernabilidad que vincule dichas áreas.
6. En cada una de la capas deben existir brechas. Generalmente las organizaciones no disponen de mecanismos para registrar brechas y acciones de mejora, por ende la organización no tiene la capacidad de aprender.

Con esta simple analogía podemos observar algunas brechas en practicas de TI.  Saludos.

Mapa de Servicios

Existen diversos tipos de servicios que pueden ser expuestos para una plataforma de integracion (SOA) o gestión de procesos de negocio (BPM). Este mapa contempla en lineas generales la categoría de servicios que puede ser utilizada para sustentar un buen modelo de implementación.

Saludos;

Atributos de una Plataforma de integracion Corporativa

Cuando se necesita desarrollar una plataforma de integracion, es necesario conocer que parámetros deben ser utilizados para seleccionar las tecnologias que la sustentaran; ya sean libres o propietarias.

Un marco de arquitectura tecnológica debe proporcionar:

1. Simplicidad.
2. Flexibilidad y mantenibilidad (Tolerancia ante Cambios).
3. Reusabilidad.
4. Desacoplamiento.
5. Extensibilidad.

Una plataforma de integracion debe poseer los siguientes atributos:

1. Debe poseer una arquitectura de integración desacoplada, ágil, adaptable y de tecnología neutral.
2. Debe garantizar el bajo impacto ante cambios en los sistemas de soporte operacional y los sistemas de negocio.
3. Debe permitir una disminución significativa de la complejidad y dependencia tecnología de los ambientes heterogéneos.
4. Debe considerar la evolución de las tecnologías y su adecuacion.
5. capacidad de desacoplamiento mediante plug-in

Son estas las premisas que deben guiar el camino para seleccionar las tecnologías que implementaran los diversos estilos de arquitectura, basados sobre una especificación formal y sólida.

Para terminar algunas características:

1. Debe poseer capacidades de Plug-in.
2. Capacidad de interoperar con tecnologias distintas (conectores / adaptadores, etc.).
3. Debe proporcionar un modelo desacoplado entre componentes.
4. Los componentes no deben interactuar con otros componentes directamente.
5. La semántica debe estar basada en mensajes.
6. La definición de la secuencia de mensajes durante la ejecución de una operación debe estar basada en MEP.
7. Clara separación entre la lógica de negocio (procesamiento) de la lógica de comunicación.
8. Debe existir una clara separación entre los proveedores y consumidores de servicios.
9. El modelo de intercambio de mensajes debe estar basado en WSDL 1.1 o 2.0.
10. No usar metadatos propietarios en la definición de objetos de negocio (Xml Schemas).
11. Modelo de implementación no-intrusivo.
12. Ensamblado de servicios desde otro servicio, basado en reglas de negocio.
13. Soporte de servicios sincronos, asíncronos, y conversacionales.
14. Automatización de la transformación entre estructuras de datos dispares (semántica).
15. Soporte para la simulación, testing y debuging.
16. Definición del servicio con independencia de su implementación, localización o uso.
    

Consideraciones para elevar el nivel de desacoplamiento de la arquitectura:

1. Capacidades de “Inversion of Control Containers”.
2. Implementación del patrón de diseño “Dependency Injection pattern”.
3. Capacidades y soporte para arquitecturas Event-driven architecture (EDA) y service-oriented architecture (SOA).
4. Integración con JBI.
5. Estandarización de la arquitectura para el enrutamiento de mensajes.

Saludos;

Un universo de Tecnologias.

Vivimos en un entorno acelerado y exponencial, cada día es mas difícil mantener la vigilia de las tecnologías que surgen. Los gerentes de TI deben comprender un enorme universo de siglas, para poder generar valor en todos los estratos tecnologicos de una organizacion.

La realidad, es que el gerente se sumerge en el día a día, resolviendo y operando, no hay tiempo para la innovación y el cambio saludable necesario para proporcionar agilidad y eficiencia operacional.

Este universo, esta sustentado sobre una batería de ideas, conceptos, y practicas para mejorar las condiciones de negocio, haciéndolas mas flexibles y humanas, apoyando la automatizacion de procesos y toda la cadena de valores necesarios para crecer y mantenernos en un mercado tan cambiante. Es necesario y vital, promover la investigación y el conocimiento de estándares y mejores practicas como ITIL, ISO, CMM, etc.

Universo de tecnologías Claves

SOA: Estilo de arquitectura, que sustenta los servicios de una organizacion en contratos formalizados, promoviendo la reusabilidad como modelo para disminuir los costos de desarrollo, el desacoplamiento de tecnologías y la protección de la inversión.

BPM: La gestión de procesos de negocio, formaliza y estandariza los procesos de negocio, los automatiza, y desacopla las reglas de negocio.

ESB: Bus de servicios para proporcionar funcionalidades de transformación, adaptación, conexion, enrutamiento, etc. Disponibiliza servicios de integracion de alto desempeño y escalabilidad.

EDA: es una arquitectura que gestiona eventos en un marco de integracion.

MOM: Estilo de arquitectura basado en una infraestructura de mensajería sobre diversos protocolos y mecanismo de transporte.

Arquitecturas Agiles

Las organizaciones deben ser ágiles operacionalmente, deben proteger sus inversiones; deben poder evolucionar y mantenerse, sin que los cambios tecnologicos las afecten. Para cumplir con estos lineamientos, es necesario que la organizacion desarrolle arquitecturas ágiles.

Una arquitectura ágil, debe ser una desacoplada, adaptable y de tecnología neutral, la cual; no se vea afectada ante cambios de productos y tecnologías. Esta debe permitir una disminución significativa en la complejidad y dependencia tecnológica de los ambientes heterogéneos.El marco de arquitectura ágil debe proporcionar:

1. Simplicidad.
2. Flexibilidad y mantenibilidad (Tolerancia ante Cambios).
3. Reusabilidad.
4. Desacoplamiento.
5. Extensibilidad.

Para desarrollar una arquitectura ágil, es necesario contar con un conjunto de lineamientos y criterios de éxito que minimicen riegos y garanticen una especificación más formal y sólida.

Criterios de Éxito

1. Debe poseer capacidades de Plug-in.
2. Capacidad de interoperar con vendedores distintos (conectores / Adaptadores, etc.).
3. Debe proporcionar un modelo desacoplado entre componentes.
4. Los componentes no deben interactuar con otros componentes directamente.
5. La semántica debe estar basada en mensajes.
6. La definición de la secuencia de mensajes durante la ejecución de una operación debe estar basada en MEP.
7. Clara separación entre la lógica de negocio (procesamiento) de la lógica de comunicación.
8. Debe existir una clara separación entre los proveedores y consumidores de servicios.
9. El modelo de intercambio de mensajes basado en WSDL 1.1 o 2.0.
10. No usar metadatos propietarios en la definición de objetos de negocio (Xml Schemas).
11. Modelo de implementación no-intrusivo.
12. Ensamblado de servicios desde otro servicio, basado en reglas de negocio.
13. Soporte de servicios sincronos, asíncronos, y conversacionales.
14. Automatización de la transformación entre estructuras de datos dispares (semántica).
15. Soporte para la simulación, testing y debuging.
16. Definición del servicio con independencia de su implementación, localización o uso.
    

Recomendaciones y Consideraciones para elevar el nivel de desacoplamiento de la arquitectura.

1. El marco de arquitectura debe estar basado en arquitecturas SOA.
2. Debe estar basado en las especificaciones y estándares (ws-i, w3c, oasis, etc.).
3. Debe estar soportado sobre un bus de servicios y un modelo de servicios horizontal.
4. Debe tener capacidades de inversion de control “Inversion of Control Containers”.
5. Debe tener capacidades de inyeccion de dependencias “Dependency Injection pattern”.
6. Capacidades y soporte para arquitecturas Event-driven architecture (EDA) y service-oriented architecture (SOA).
7. Integración con JBI.
8. Estandarización de la arquitectura para el enrutamiento de mensajes.

Para mas informacion:

http://en.wikipedia.org/wiki/Enterprise_service_bus
http://en.wikipedia.org/wiki/JBI
http://en.wikipedia.org/wiki/Message_Exchange_Pattern
http://www.ws-i.org/
http://www.oasis-open.org/home/index.php

Saludos.

Arquitectura, Mapa y un Blueprint

Uno de los problemas más comunes en la ejecución de proyectos de software, es la ausencia de arquitectos y documentos de diseño, que establezcan las políticas y lineamientos que deben ser adoptados durante todo el proceso.

El establecimiento de estas políticas, contribuye con la disminución de riesgos, y el control de brechas funcionales y no funcionales, que podrían impactar el proyecto en variables como el costo, el tiempo de despliegue y la productividad.

Dentro de este contexto, es vital, establecer un marco de arquitectura que permitirá gobernar el proyecto de forma eficiente, proporcionando las bases para el desarrollo de una arquitectura desacoplada, ágil, adaptable, y de tecnología neutral, la cual; no se vea afectada ante cambios de tecnologías.

Pero que significa gobernar?, gobernar significa establecer políticas claras para el inicio del proyecto, la comunicación, la gestión del proyecto, control, mantenimiento, adaptación, etc. del ciclo de vida del proyecto, en tiempo de diseño, ejecución y cambios.

Dentro de este contexto, el primer paso para iniciar un proyecto, es la creación de un documento de diseño, también denominado Blueprint. Un blueprint es un documento que establece los lineamientos, políticas, y estándares que deberían ser adoptados para asegurar una correcta implementación y disminuir los riesgos de su ejecución.

Para armar el blueprint es recomendable crear un árbol de ideas base que contengan todos los elementos o nodos que deben ser gobernados. Aquí les anexo un documento que contiene un árbol de ideas, con el cual podemos comenzar para armar el bluerpint.

Vamos ahora a describir algunos de sus nodos:

1. Ambiente: Se establecen los artefactos de software que seran necesarios, variables de ambiente, estructura de directorios y posibles dependencias.
2. Lineamientos: Los lineamientos pueden estar orientados en tres áreas: Control de Proyecto, diseño de la solución y las tecnologías.
3. Agilidad: La agilidad significa como el proceso de construcción de software debe ser ejecutado para proporcionar agilidad y buenas prácticas con el objetivo fundamental de mejorar la productividad, un ejemplo de ello es XP y TDD.
4. Modelo de Implementación: En este punto, se establecen un modelo de implementación que deberá incluir por ejemplo (modelo de dominio, capas, modelo de persistencia, modelo de pruebas, modelo de servicios, Reglas de negocio, patrones de diseño , etc. ).
5. Pruebas: En este nodo, se establecen los distintos tipos de prueba que deben ser considerados durante las fases de construcción y cambios.
6. Otros: Glosario y términos de negocio.

Espero haber contribuido con este modelo de referencia para la construccion de documentos de diseño. Cualquier comentario es bienvenidos.