Seminario de Intalio BPMS, SOA y ESB en Costa Rica

Hace poco tuve la oportunidad de ir a la Universidad Nacional de Costa Rica a impartir dos seminarios "SOA y ESB" y "BPM utilizando Intalio BPMS", donde aborde diversos temas de arquitectura empresarial y gestión de procesos de negocio utilizando las alternativas Open Source y de software libre: Mule ESB, ActiveMQ, e Intalio BPMS.

Quiero agradecer la hospitalidad que los tico me brindaron durante mi estadía; a Xenia y Dinia por toda la colaboración prestada, y al Sr. Francisco por su visión y capacidad de vigilia en el tema de nuevas tecnologías. La UNA (Universidad Nacional de Costa Rica), tiene un programa de especialización en el área de las tecnologías de información y la gestión de proyectos (PMI) llamada Progestic. Progestic esta planeando incorporar la Gestión de Procesos de Negocio (BPM) como un elemento dentro de su plan integral de capacidades, para convertirse en una guía en Centro América.

Ha sido una experiencia invaluable, donde he podido compartir con la comunidad estudiantil, empresarial y de gobierno; la importancia de incluir SOA, ESB y BPM como estrategia para utilizar las tecnologías de información y comunicaciones de forma efectiva y con una orientación clara en la gestión de procesos de negocio y todas las disciplinas que lo comprende; por supuesto utilizando software libre y open source.

Muchas Gracias UNA - Progestic - Costa Rica.

Nota: Pronto estaran disponibles para la comunidad las presentaciones que utilize para incentivar la utilizacion de BPM e intalio BPMS en la comunidad universitaria.

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;

Proyectos de Integracion SOA-ESB-BPM

Hace poco tuve el honor de participar como ponente en el evento STC Foro http://www.stcforo.com/home.php, para hablar sobre el desarrollo de proyectos de integración, y he querido registrar los puntos generales de mi ponencia en este blog, para contribuir con toda la comunidad. Es necesario decir, que estas recomendaciones provienen no solo de mi autoria, sino de todo un equipo magnifico de venezolanos, que con su profesionalismo y dedicacion contribuyeron con esta ponencia.

La agenda fue muy sencilla, y cubrí los siguientes puntos:

1. Que obstáculos iniciales debe enfrentar una empresa para desarrollar un proyecto de integración?
2. Recomendaciones.
3. Algunas Reflexiones.

Que es un proyecto de integración

Un proyecto de integración es una plataforma tecnológica que sirve para disponibilizar funcionalidades existentes en sistemas heterogéneos, realizando tareas de conexión, adaptación, transporte, transformación, integración, etc, mediante servicios.

Un servicio es un artefacto de software que puede exponer una funcionalidad específica sobre diversos protocolos de transporte y lenguajes.

Que Obstáculos generales debe enfrentar un organización para desarrollar un proyecto de integración?

1. En primer lugar, las organizaciones deben entender el concepto de agilidad operacional: Agilidad es contar con una plataforma tecnológica de servicios que soporte muchos cambios, pero que estos generen poco impacto. Las implicaciones de no poseer una plataforma de integración en una organización son: alta dependencia, alto acoplamiento, poca proteccion tecnológica, grandes impactos ante un reemplazo, información redundante, alta complejidad, etc.
2. En segundo lugar soportar el constante bombardeo de los proveedores tecnológicos de estándares, tecnológias, y especificaciones que tienen como objeto primordial: "Entregar el Santo Grial: la Agilidad Operacional", términos como SOA, ESB, BPM, EDA, MOM son elementos de esa sopa de letras interminable.
3. Una vez que hemos entendido esta sopa de letras, es necesario conseguir un equilibrio donde la evaluación de aspectos como la madurez de la tecnología, comunidad, soporte, open source o propietario, matriz de funcionalidades, pruebas de concepto, etc, son vitales.
4. Otro obstáculo es la constante evolución de las tecnologías, fue en el 2004 cuando los Web services aparecieron en el escenario tecnológico, donde estarán las organizaciones en ese mapa de ruta?
5. Por ultimo, y el mas importante como vender un proyecto de integración. Vender un proyecto de integración no es fácil, a pesar de todas las ventajas que promociona tecnológicamente.

Recomendaciones para afrontar estos Obstáculos:

1. Introduzca un proyecto de integración como un componente más de un proyecto mucho mayor.
2. Utilice pilotos, y no pruebas de concepto o laboratorio, los pilotos tienen un rango mucho mas amplio, el cual nos permite evaluar todos los aspectos técnicos necesarios para exponer servicios.
3. Utilice la vigilia tecnologia y el direccionamiento como elementos claves de la estrategia organizacional.

Tips Generales:

1. Desarrollar servicios no asegura la interoperabilidad: Utilice las herramientas de la Web Services Interoperability Organization (WS-I) para verificar si un web services o servicio es interoperable.
2. El contrato nos hace flexibles, proporcionan agilidad: Eso es lo que por lo común nos venden, la verdad!, depende del modelo de implementación, por lo general; cambios en los contratos rompen las implementaciones de los servicios por lo que generalmente hay que regenerar los proxys (consumidores del servicio).
3. Con frecuencia, los servicios son adaptaciones específicas de las aplicaciones: No es fácil crear servicios reusables, pero se deben contemplar servicios con la interfase lo más ancha posible (mayor numero de atributos).
4. Es necesario establecer un equilibrio entre el conceptual y lo pragmático: aterrice el concepto que verdaderamente necesita.

Algunas Recomendaciones:

1. Aplicar Aseguramiento de Calidad previo a la Construcción de servicios (contratos ajustados, especificaciones claras antes de ir a construcción).
2. Diseñe los servicios con Interfaz “ancha” para potenciar la reusabilidad, Incluso si los servicios son diseñados “a la medida” de un cliente.
3. Codificar con herramientas de 4ta generación es bonito, fácil y aparentemente simple, pero cuando hay problemas, resolverlos es difícil.
4. Roll back: No hacer diseños complejos.
5. Logs,Logs,Logs!!! : Prepare una arquitectura reusable de manejo de Logs con niveles, homogénea y parseable.
6. Olviduese de Logs en base de datos, simplemente no es buena idea.
7. Utilice un manejo homogéneo de errores (Web Services Árbol de Excepciones (Fault)).
8. Incluir como parte del Framework capacidades de Auditoria y Monitoreo.
9. RPC mala idea, Preferir WS Document / Literal en lugar de RPC encoded.
10. Utilize Document Style para los Web Services, es la mejor práctica. No se rompen las implementaciones, orientado a mensajes, y es extensible.
11. Ir a lo Básico, no olvide las herramientas de control de versiones, manejo de incidencias,etc.
12. Viva los Xml*, evite cablear transformaciones, use tecnologías X* para transformaciones de datos en la lógica del servicio.
13. BPM es el futuro.

Reflexiones

• La verdadera integración es de la gente.

• La ausencia de un Arquitecto puede cambiar un Plan.
• La interoperabilidad es importante, utilice los tools de la WS-I.
• Crear estándares, disminuye los riesgos de implementación.
• Existe la practica generalizada de construcción de servicios específicos para los clientes, simplemente Evítelos.
• Pensamos en el desarrollo de software, pero no en como administrarlo y operarlo. No lo dejemos para e final.

Tecnologia Social

La constante evolución del mercado de las tecnologías de información, la necesidad de integración impulsada por nuevos modelos de negocio innovadores y emergentes, los marcos de arquitectura que prometen el santo grial: la agilidad operacional, están cambiando los conceptos organizacionales actuales.

Las organizaciones necesitan territorios creativos, lugares que impulsen propuestas para el desarrollo de una verdadera innovación. Estos territorios, serán los motores que generaran, aplicaran, y divulgaran nuevas tecnologías en todos los estratos de la organizacion, siempre orientada en la actividad productiva de la organización, la agilidad operacional, gobernabilidad, sus servicios, y el valor agregado.

Estas unidades, a los cuales yo llamo unidades de TI sociales, revolucionaran el modelo de organizacion actual, por el desarrollo de un ecosistema de conocimiento pragmático y creativo, un modelo de producción social de conocimiento tecnológico que pueda ser compartido y distribuido a toda la sociedad, fomentando la generación y desarrollo de emprendimientos tecnológicos externos a la organizacion.

El conocimiento debe ser compartido, distribuido, y utilizado como herramienta para aperturar las fronteras existentes en los organizaciones actuales.

Diferenciadores:

1. Estas unidades de TI, comprenden que la exploración y anticipación tecnológica, es vital para proteger las inversiones y fortalecer la infraestructura de servicios con el nivel de calidad establecido.
2. Son evangelizadoras, diseminadoras de tecnologías, estándares y arquitecturas de nueva generación.
3. Promueven la transferencia de tecnología y el conocimiento, dentro y fuera del contexto organizacional.
4. Diseminan el conocimiento y la ejecución de practicas en la organizacion.
   
5. Difunden casos de éxito para impulsar modelos de implementación sobre un marco de cooperación abiertos.
   
6. Aplican programas de investigación y desarrollo, evitan la teoría, son organizaciones pragmáticas.
   

Una gran verdad: SOA (Arquitectura orientada en servicios)

Las promesas de SOA como estilo de arquitectura, donde se promete una infraestructura de TI adaptable, ágil, y eficiente; en toda su cadena de valor, debe manejarse con mucho criterio, porque su implantación introduce cambios profundos y significativos, generando grandes riesgos, pero también una amplia gama de oportunidades.

La disminución de costos sustentada por el reuso de servicios, la protección de la infraestructura de TI través del desacoplamiento de los sistemas de soporte operacional, el desarrollo de software pensado para la integración, la disminución de costos de mantenimiento, la reducción del impacto ante el cambio, la protección de la inversión y el retorno, son algunas de las ventajas descritas como sus beneficios.

En la practica, "Hacer SOA no asegura el retorno de inversión, la interoperabilidad, el bajo acoplamiento, ni la agilidad operativa; si este no esta acompañado de lineamientos de arquitectura, estándares, y especificaciones que disminuyan los riesgos de su adopción". Esta es una verdad, que debe ser extendida a toda la comunidad empresarial.

La importancia de SOA, desde el punto de vista organizacional, es que establece el mapa de ruta preliminar para la construcción de una plataforma de servicios, un rompezabezas inteligente de integración, que prepara el camino para implementar BPM (Gestión de Procesos de Negocios).

El mensaje fundamental, es aceptar; que "es necesario contar con un marco de prácticas acertadas, nociones aprendidas, y buscar un equilibrio entre la practica (ideas pragmáticas) y la visión conceptual, antes de desarrollar un marco o mapa de servicios".

Los objetivos y la accion nacional

Hace poco, termine de leer un libro llamado "Cuentos Chinos" del conocido periodista Andrés Oppenheimer. En líneas generales se abordan temas y comparaciones entre sistemas económicos, culturas y estrategias; que incentiven el desarrollo sostenido, para que pueblo alcance la mayor suma de felicidad posible, como decía Bolívar.

Desde mi humilde perspectiva, considero que es muy fácil realizar comparaciones, en diversas áreas para decir lo que debemos hacer, el camino que debemos tomar, lo correcto, lo incorrecto. Las comparaciones tienden a evitar los problemas de mayor relevancia, porque cada experiencia, cada decisión, cada objetivo, descanso sobre escenarios, culturas y tiempos muy diversos. Yo creo firmemente que al final todo se trata de la acción.

Todo se trata de los objetivos y la acción nacional.

En América latina existe una visión muy pobre sobre la acción nacional. La acción nacional significa poner en práctica de forma pragmática y creadora, las ideas que pueden cambiar los escenarios de desarrollo actuales de una nación.

Esta claro como el agua, que nuestros países nos hemos dedicado a explotar nuestros recursos naturales, esa siempre ha sido la estrategia, la vendemos y los otros países mas desarrollados crean productos a partir de esa materia prima. Es muy sencillo desde el punto de vista económico, el problema radica en que no utilizamos estos recursos para crear productos de mayor valor agregado.

Los objetivos nunca han estado a la altura de las necesidades de desarrollo de la nación, cuando hemos escuchado a un presidente decir? "Nos convertiremos en una potencia mundial en el desarrollo de circuitos y componentes electrónicos" o "Seremos los primeros en el desarrollo de software y robótica" o "Desarrollaremos una lapto 100% venezonala, sin importar ningún componente del exterior, y me pregunto yo.... eso no es soberanía tecnológica?.

Si somos el primer exportador de aluminio, porque no hacemos barcos, artefactos electrodomésticos, piezas mecánicas, componentes electrónicos?, existen ejemplos de países que sin recursos naturales, han salido del subdesarrollo mediante la utilización del conocimiento.

El conocimiento se fue de parranda

En los países de América latina, el conocimiento no es el factor predominante de las estrategias nacionales de desarrollo, la mayoría están basadas en la extracción de materias primas, la agricultura y otras áreas de dependen de la tierra como mecanismo de desarrollo.

Seguimos viviendo en el pasado, para darles un ejemplo, el grueso de la economía mundial esta en área de servicios, luego en el sector industrial, y de ultimo el manufacturero y agrícola. Si no cambiamos nuestros objetivos, como podremos entrar en la era del conocimiento?

Un ejemplo significativo es Holanda, primer productor de flores en el mundo, pero ellos no tienen casi tierra, el clima es malísimo, no hay mucha agua, condiciones contrarias a las de un país de América latina , es increíble verdad?, la diferencia fundamental es que este país pequeño quiere, acciona, y además tiene un objetivo claro, !Ser el primero¡ y para ello utiliza la ingeniería genética, su capacidad de distribución, y el marketing, es decir "Conocimiento Aplicado y Pragmático".

Necesitamos producir Ideas

Para crear productos de mayor valor agregado, necesitamos producir ideas, y desarrollar una infraestructura que potencie la educación, las ciencias y la tecnología.

La actual infraestructura de conocimiento, no es acta para sustentar estos cambios, es anticuada, desconectada del campo profesional, es necesario y vital, contar con expertos en ingeniería genética, electrónica, biotecnología, software, nanotecnologia, robótica, etc. Para desarrollar la bomba atómica, los EEUU recurrieron a los mejores cerebros de Alemania, porque no buscamos a los mejores en todas estas áreas, modificamos toda la infraestructura universitaria, para evitar que en la universidades todavía se imparta "COBOL", "Z80", etc., tecnologías viejas.

Conclusiones

Existen muchas Estrategias para cambiar esta realidad, el problema; es que no existe una acción política contundente e innovadora que vitalice, y prenda los motores para iniciar un cambio, una transformación, una revolución.

BPM : BPMN, BPEL, BPEL4People y la Optimizacion de procesos.

BPM esta en plena ebullición, evolucionando y creciendo en su aceptación, con una rapidez significativa, BPM significa formalizar los procesos de una organización, significa manejar los objetivos de negocio de forma clara, con responsables y entregables conocidos. BPM habla sobre el diseño, la implementación y optimización de procesos, sobre la definición de procesos, no de forma funcional sino ortogonal a todas las unidades de negocio involucradas en obtener un determinado objetivo, por ejemplo: El tiempo de aprobación del otorgamiento de un trámite, no debe exceder de 4 días.

BPM es la evolución de los conocidos sistemas de workflow, BPM se adapta a un mundo de servicios (Web Services), donde workflow no tiene tanta fortaleza. BPM habla de interacciones sistema-sistemas para la orquestación de servicios y proyectos de integración; workflow habla sobre interacciones humano-sistema, orientado al flujo de documentos, transacciones, aprobaciones, escalamiento, etc. BPM esta sustentado sobre estándares como BPMN(Business Process Modelling Notation) que define la notación para el diseño de los procesos, BPEL(Business Process Execution Language) como lenguaje para la ejecución del proceso, y otros como BAM(Business Activity Monitoring) para medir el desempeño de los procesos, actividades y recursos disponibles.

La Realidad

BPM suena muy bien, pero la realidad es que su éxito no radica en conceptos tecnologicos sino es conceptos y estrategias politicas, de liderazgo y emprendimiento organizacional.

Si hicieramos algunas preguntas dentro de un contexto organizacional:

1. Las organizaciones formalizan sus procesos?
2. Las organizaciones cuenta con un indicador que responda a objetivos de negocio?
3. Las organizaciones están continuamente evaluando sus procesos para mejorar?Las organizaciones optimizan sus procesos?
   

Estas incognitas, son dificiles de responder, debido al dinamismo que las organizaciones. Para poder responderlas debemos considerar algunos aspectos:

Aspecto Político

Para implementar BPM, es necesario que las organizaciones, este comprometidas políticamente en formalizar todos sus procesos de negocio, partiendo de una estructura organizativa con su objetivos, estrategias y ambientes formalizados. Se deben establecer los objetivos de negocio de todas las unidades, sus relaciones e interacciones, se debe romper la estructura funcional de cajitas por una visión mucho más ortogonal.

Aspecto de liderazgo

Este cambio debe ser liderizado por una unidad de procesos que defina los procesos futuros requeridos para soportar los objetivos y estrategias de negocio, un modelo de transición de los que es, a lo que será, proporcionando un mapa de ruta. Esta debe monitorear el cumplimiento de los acuerdos de servicios y áreas claves de procesos, modelar los procesos e iniciar los requerimientos para automatizarlos. Analizar el comportamiento dinámico de los procesos, para optimizarlos y alcanzar los objetivos de negocio.

Optimización de procesos.

Optimizar significa mejorar algo con el nivel de recursos apropiado. La optimización de procesos, debe partir de un modelo donde se conozcan los nivel acordados de servicios (SLA), son números que tienen un significado de negocio, que puede mejorar o desmejorar. Su manejo establece un parámetro indispensable para hablar sobre optimización de procesos. La planeacion estatregica, el balanced scorecard, la inteligencia de negocio son las fuentes que debemos tomar en cuenta para usar la palabra optimización.

Algunas Recomendaciones para implementar BPM:

1. Sustente las necesidades de modelado de proceso de negocios, sobre requerimientos específicos de negocio (SLA (niveles de servicio acordados) y KPI (Areas claves de proceso)).
   
2. Modele sus procesos utilizando la notación BPMN.
   
3. Describa los procesos y eventos de negocio sobre una plataforma de integración SOA.
   
4. Identifique actividades que puedan ser automatizadas y automatícelas.
   
5. Mida el desempeño de los procesos basado en número reales.
   
6. Utilice ambas aproximaciones (BPMN- BPEL y workflow) según el tipo de interacciones necesarias.
   
7. Utilice BPMN- BPEL para la orquestación de procesos.
   
8. Utilice sistemas de workflow para las interacciones humanas, pero basadas en servicios orquestados sobre una capa BPEL.
   
9. Actualmente existe un gap entre BPM (business process management) y los sistemas de workflow, el cual pretende ser cerrado mediante la especificación BPEL4People.
   
10. Utilice un modelo estándar de datos y servicios sobre un modelo internacional, por ejemplo NGOSS.
    

Saludos.

Como desarrollar un Plan de Software Libre.

Actualmente, las empresas buscan modelos para incentivar la utilizacion de software libre y Open Source como estrategia para disminuir la dependencia tecnológica con proveedores y los costos asociados al licenciamiento y servicios.

Para impulsar y potenciar este modelo, es necesario establecer lineas de negocio claras, areas claves que agreguen valor (ROI), alcance y las áreas sobre las cuales puede evaluarse una posible aplicacion, hay que tener presente que el abanico de software libre, tal vez no es tan extenso y no cubre la mayoría de las necesidades y áreas de interés estrategico de TI.

Una idea general para comenzar un plan de migracion a software libre, es identificar en primer lugar las posibles áreas y aplicaciones que pueden ser sustituidas, los riesgos de su implantación y el ROI que puede ser obtenido (valor agregado).

Algunas Recomendaciones

1. Sensibilizar a la organización para reducir la resistencia al cambio dentro de un marco organizacional establecido.
2. Crear un grupo de acción multidiciplinario cuya función sera formular el plan.
3. Realizar inventario de los sistemas de soporte operativo (sso disponibles) /Áreas actuales % (propietario vs open source)..
4. Utilizar un marco referencias para los sistemas de soporte y de negocio operacional (OSS/BSS).
5. Desarrollar una Matriz de madurez de las alternativas oss open source disponibles (actual, futuro).
6. Desarrollar una matriz formal de evaluación de software libre.
7. Realizar Estudio de Factibilidad(económica, técnica, política, etc.) de Migración.
8. Desarrollar un mapa de ruta para iniciar la transición.
   
9. Desarrollo del Blueprint de arquitectura para cada área funcional.
10. Automatizacion de la transición.
11. Divulgar casos de exito.

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.

Sobran las palabras!

Una presentacion que demuestra que estamos viviendo tiempos exponenciales.

SOAP vs REST

Desde hace dos años he estado trabajando en proyectos de integración basados en arquitecturas orientadas en servicios (SOA) y bus de servicios empresariales. Una de las características mas resaltante de SOA, es que esta basada en contratos, donde el proveedor establece las reglas de comunicación, el transporte, y los datos de estrada y salida que serán intercambiados por ambas partes.

Los beneficios son grandes, se incentiva la reusabilidad, la independencia de la tecnología de implementación, el manejo de contratos, etc., y muchas otras.

Dentro del mundo Open Source, proyectos como Axis y Xfire nos permiten exponer un componente java como un servicio Web (Web Services), mediante un contrato establecido en un archivo WSDL, el cual describe las reglas e interacciones posibles entre el proveedor y el consumidor. Por lo general, estas tecnologías disponen de componentes de software para crear clientes que consumen los servicios, a partir de los archivos WSDL (WSDL a Java, o WSDL a .Net, o WSDL a C++) conocidos como proxys.

Este tipo de arquitectura, tiene técnicamente algunos inconvenientes, que deben ser manejadas por los arquitectos de software.

La existencia de un contrato, establece algunas brechas con una situación existente en todas las organizaciones "El Cambio". Los clientes que consumen un servicio, están atados a un contrato de operaciones y mensajes (request y respose). Esta esquema no es muy flexible, porque la implementación esta acoplada al contrato, lo que indica que si efectuamos un cambio en el mismo, por ejemplo, la adicción de un nuevo atributo al contrato, las implementaciones se rompen, afectando a todos los clientes que consumen el servicio. En conclusión "Un cambio en el contrato de un servicio, afecta a todas las implementaciones de los clientes, técnicamente tendrán que regenerar los proxys para cada servicio”.

Hace poco tuve que intentar desarrollar un modelo que permitiera desacoplar los proxys ante cambios de los contratos. En la mayoría de las implementaciones el proceso de deserealizacion (xml a objeto), es donde falla, indicando que se incluye un nuevo elemento que no puede ser mapeado a un atributo de una clase java. Este inconveniente puede resolverse en Axis, implementando un proceso de deserealizacion customizado para que no tome en cuenta atributos nuevos.

En otros escenarios, donde el desarrollador no tiene control de las generaciones de estos proxys, la cuestión se complica.

Una alternativa, es el tipo de arquitectura REST, donde a diferencia del modelo anterior, el contrato solo es de entrada, por ende tiende a ser mas flexible y apropiado para el "El Cambio".

REST (Representational State Transfer), es un estilo de arquitectura que ofrece un buen desempeño, escalabilidad y abstracción de recursos, donde cada petición HTTP contiene toda la información necesaria para responder a la petición, sin necesidad que el cliente ni el servidor tenga que recordar el estado de su comunicación.

REST se diferencia de los Web Services por:

1. REST ofrece recursos y representaciones variadas por ejemplo, xml, html, text, pdf, binarios, etc. y permite la utilización de links entre diversos recursos, por el contrario los Web Services solo manejan XML como documentos de intercambio basados en el protocolo SOAP.
2. Los servicios web no están focalizados en recursos, sino en operaciones.
3. REST depende directamente del protocolo HTTP (Hypertext Transfer Protocol), este expone siempre la misma interfase a todos los consumidores, mediante operaciones bien definidas: POST, GET, PUT y DELETE. Desde el punto de vista REST es mucho más escalable que los Web Services donde tenemos diversas interfaces, es decir diversas operaciones.
4. REST, expone sus recursos a través de un URI (Uniform Resource Identifier); y permite cambiar el estado de un recurso a través de una de operaciones genéricas para todos los consumidores.
   

Recomendaciones

1. Lo mejor es utilizar REST cuando sea necesario tener representación distinta a XML.
2. Si el criterio de la escalabilidad tiene mucho peso dentro del blueprint de arquitectura, REST es la mejor opción porque permite que todos los recursos presenten la misma interfase a los clientes.
3. SOA y Web Services, están apoyados sobre estándares y especificaciones de amplia madurez por ejemplo WS-Security, REST no cuenta por ejemplo con una amplia gama de estándares.
4. Los Web Services pueden soportar mas protocolos de transporte como JMS, SOAP, etc. REST solo conoce HTTP.
5. Si tenemos que ofrecer servicios de la sindicación de por RSS o ATOM, REST es la mejor opción.
   

En conclusión, ambas aproximaciones tienen sus ventajas y desventajas, el papel fundamental de arquitecto evaluar su utilización dentro del escenario mas apropiado para obtener un modelo de arquitectura ágil y eficiente.

Una referencia...

Pruebas en SOA(Arquitecturas orientadas en servicios)

En arquitecturas orientadas en servicios, la realización de pruebas de Web Services es crucial. El performance, interoperabilidad y la identificación de vulnerabilidades son los pilares de un buen SOA Testing. Solo su comprensión asegura que la infraestructura sea robusta, escalable, interoperable y segura.

Los tipos de pruebas mas comunes que deben ser aplicadas en este tipo de arquitecturas son:

Pruebas carga: El objetivo de las pruebas de carga es determinar el rendimiento del sistema bajo condiciones de carga que se aproximan a la realidad esperada en producción. Esto nos permite:

1. Determinar la escalabilidad del sistema en TX / seg vs. #Usuarios concurrentes.
2. Validar que el dimensionamiento de la infraestructura de hardware fue el adecuado.
3. En este tipo de pruebas, a diferencia de las pruebas de estabilidad, la carga se va aumentando cada vez más para determinar la escalabilidad del sistema.Una vez determinada la escalabilidad de la plataforma, se usa este valor para las pruebas de estabilidad.

Pruebas de Volumen: Encontrar debilidades en el sistema al momento de manejar grandes volúmenes de datos durante prolongados períodos de tiempo, el objetivo principal es determinar si la plataforma de integración se degrada o deja de funcionar al manejar grandes volúmenes de datos.

Pruebas de Estabilidad: Miden la estabilidad de los servicios con una fuerte carga sostenida en el tiempo (la carga no cambia). Los servicios no deben fallar y los tiempos de respuesta para una carga constante deben permanecer constantes. Gráfica tipo: tiempo de respuesta de un WS vs. tiempo (debe tender a líneas de pendiente 0).

Las aserciones que deben considerarse para realizar pruebas unitarias en web services son:

1. Conformidad con el XML Schema.
2. Contenido simple, Expresiones Xpath.
3. SOAP Fault.
4. Transacción por segundo (TPS).
5. Máximo Tiempos de Respuesta (Response Time).
6. Máximo numero de errores.
7. Average o promedio.

Saludos Mijanautas.

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.

Google venezolano

Necesitamos un google venezolano, un equipo de gente visionaria, que potencie la creación de un territorio creativo y de innovación, con una visión socialista e integracionista, gente que investigue y desarrolle sobre una vigilia tecnológica sistemática, gente que disemine su experiencia en todos los estratos de la sociedad, de la nación, del país.

La vigilancia tecnológica es vital y estratégica para el estado, ella estimula la innovación y la creatividad, generando ideas, productos libres, independencia tecnológica.

Necesitamos una visión de 360º

No es fácil, engranar lo filosófico, lo técnico y lo social. La socialización del conocimiento y la tecnología deben partir de un cambio en su concepción, en un ser nuevo, que impulse y propague ideas y conocimiento habilitador, pero mientras este escenario nace, se gesta, se preña, el estado debe dar un salto quántico.

El estado debe formular, planear, crear e impulsar, un modelo que genere una economía basada en la producción del conocimiento y de servicios, que permita diseminar la experiencia que enriquecerá todos los estratos de la sociedad. La experiencia potenciara y empoderara al ciudadano hacia un cambio, no es proporcionar Internet a los ciudadanos, es incentivar su comprensión como mecanismo para mejorar su nivel de vida y cubrir sus necesidades básicas.

Uno de los más grandes problemas en la sociedad, es el comportamiento natural de la mayoría de los ciudadanos, empresas, y su identificación con el mercado, el deseo que mueve todos las acciones es mercantilista, por ende el conocimiento y la experiencia tienen precio, el problema con este modelo es que la experiencia no se diversifica, no se disemina, solo se esfuma, aunado a la gran brecha entre el conocimiento que se imparte en las universidades y la realidad global tecnológica empresarial en continua evolución y demanda.

Porque no podemos diseminar la experiencia, poner el conocimiento de TI al alcance de todos los ciudadanos, es decir socializar el conocimiento para cubrir necesidades estratégicas. El estado debe impulsar una transformación tecnológica sobre bases sociales, y sustentado sobre un profundo conocimiento técnico, lleno de experiencia, excelencia, talento, innovación y sobre todo de praxis. El primer paso, es crear un gobierno eficiente, eficaz, y transparente, que proporcione mejores servicios, donde el ciudadano entiende, participa, coopera y desarrolla una visión del uso de las TIC para mejorar su vida, una economía de conocimiento.

Este discurso, ya es común, pero a pesar de ello, no se deslumbran avances y cambios significativos en el manejo del conocimiento y el gobierno electrónico.

Necesitamos una Visión 360º

Para cambiar este escenario, es necesario crear una visión de 360º grado, un mapa nacional de servicios que deben ser prestados a los ciudadanos, un mapa de servicios para coordinar las relaciones entre entidades de gobierno, por ejemplo un servicio catastral genérico, servicios de salud, servicios que suministren información sobre los indicadores de la gestión de gobierno, que permitan la planificación estratégica: e-decisiones, e-información, e-participación, e-cooperación, y e-política.

Este mapa de servicios nacionales, sus interacciones y reglas puede iniciarse como un piloto, que pueda crear una reacción viral, en todos los entes y organizamos nacionales. La experiencia generada en todo el proceso debe ser la semilla para iniciar la transformación en los ciudadanos, debe ser replicado, diseminado en el estado, evitando redundancia de esfuerzo y acelerando su adopción en cada uno de los estratos de TI del estado.

Esta infraestructura de servicios, debe ser flexible, ágil, eficiente, efectiva, segura e interoperable. Para construirla solo debemos utilizar estándares, especificación y arquitecturas como SOA, BPM, BPEL, ESB, EDA, MOM, etc. Debemos crear un "Plan Estrategicos de Transformación Tecnologica", basado en un marco integrado de arquitecturas.

Con una visión de 360º y una infraestructura de TI basada en servicios, los países no desarrollados podrán avanzar en la creación de una sociedad basada en el conocimiento y en las Tecnologías de Información, un gobierno electrónico, un ciudadano electrónico, un país electrónico.

Para mas informacion:

http://www.soacenter.com
http://www.looselycoupled.com
http://www.bpmi.org
http://www.bpmg.org
http://soa.omg.org
http://www.oasis-open.org
http://www.ws-i.org

Necesitamos jugadores que hagan avanzar la innovación!

Las ciencias son el principal motor para iniciar la transformación de una nación en una sociedad moderna e interconectada, donde el ciudadano tiene una mayor compresión de las tecnologías de información y comunicaciones y el estado provee todos los servicios necesarios para mejorar su nivel de vida.Dentro de este escenario, la Ingeniería de software es uno de los pilares más importantes para el desarrollo de la nación, su principal producto es el conocimiento habilitado.

Son conocidas las oportunidades del país, si se incluye como un competidor en el escenario mundial y sus proyección en la industria del software.

La Realidad

La nación ha creado una infraestructura de organizaciones para afianzar e implementar el Plan Nacional de Ciencia y Tecnología. Desde mi punto de vista existen muchas brechas en la visión y en los lineamientos hay esbozados.

El plan debería orientarse en la necesidad de desarrollar otras industria de carácter estrategico, y definitivamente el software proporciona los mayores niveles de implementación, debido a una de sus principales características : No son un commodity.

La realidad, es que no existen programas serios que apoyen a empresas e innovadores que deseen cambiar este escenario, solo existen interés económicos que están por encima de los interés nacionalistas.

Todavía existen grandes oportunidades de mejora!

Venezuela es un país cuyo principal producto de exportación es el petróleo, el país necesita encausar y producir una revolución digital, que permita a la nación desarrollar una nueva industria sobre las tecnologías de la información y comunicaciones. Existen en el mundo muchos países industrializados que han optado por formar una industria digital.

El estado necesita realizar un cambio de políticas para poder adaptarse y responder a las nuevas tendencias mundiales de la industria que se encuentra en constante evolución y fomentar la creación de otra industria que surja como alternativa a la petrolera. Necesitamos cambiar la tendencia actual en la cual somos consumidores y no productores de tecnología.

Necesitamos producir patentes, necesitamos poder adaptarnos a la velocidad del cambio tecnológico, necesitamos formar una economía del conocimiento, innovación, tendencia a la exportación, en conclusión necesitamos jugadores que hagan avanzar la innovación.

El estado venezolano debe formar un conjunto de estrategias para acelerar la infraestructura del gobierno electrónico, su posicionamiento dentro del mercado mundial como proveedor de software, y la creación de una base de conocimiento y su distribución.

Una Salida?

Nuestra organizacion, ha desarrollo un proyecto de estado para revertir esta situación, y aprovechar nuevas oportunidad con una visión nacionalista y de independencia. Mijao formula estrategias, aceleradores y visores que permitirá transformar la infraestructura tecnológica de la nación con un modelo innovador de producción nacional.

Mijao

Mijao es un proyecto estratégico de estado, cuyo objetivo es iniciar en la nación una revolución digital efectiva y abierta, que transforme y sustente los pilares en el área de las tecnologías de información y comunicaciones en los próximos años; contribuyendo con el desarrollo integral de la nación, apoyando sus procesos, aumentando sus niveles de eficiencia, fortaleciendo su capacidad y desarrollo tecnológico, y proporcionando un modelo productivo, social e integracionista.

Este proyecto desarrolla un anillo de estrategias que permitirán a la nación adoptar medidas concretas y aplicables para lograr la construcción de un framework nacional.

En las proximas entregas, conversaremos sobre este tema. Saludos.

El espíritu emprendedor y el Territorio Creativo.

Cada día requerimos de nuevas prácticas de innovación y diversas maneras de pensamiento. El desarrollo de estas capacidades tiene que comenzar con la incubación del espíritu emprendedor, una energía creativa vital, que surge en un ambiente donde la dirección es un arte, con equipos con grandes atributos o habilidades como el talento, la perseverancia, la diligencia, la integridad, etc.

La innovación debe estar basada en una visión inspiradora del futuro, de lo que puede ser, sobre lo que podemos cambiar o revolucionar. Dentro de este escenario el espíritu emprendedor nace de una energía creativa, con un fin último: mejorar los aspectos de la vida diaria y cotidiana de la sociedad.

El espíritu empresarial debe penetrar en todos los estratos de la sociedad y en sus diversas áreas, es necesario crear un territorio creativo con alta energía emprendedora que nos permita desarrollar una visión de futuro.

Venezuela líder mundial en tecnología e innovación. La siembra petrolera?

Estudiando el progreso de países como la china y estados unidos, su historia, su cultura y modelos de desarrollo, he recopilado un conjunto de conceptos e ideas que pienso pueden contribuir con el logro de este sueño: “Venezuela líder mundial en tecnología e innovación”.

A lo largo de los años, los países en desarrollo han definido estrategias para ascender en la escala tecnológica, pasando por tres etapas o escalas: agricultura, manufactura, y servicios. Cada unas de las etapas, esta acompañada de políticas claras y constantes que han convertido a estos países en los lideres actuales en tecnología e innovación mundial.

En América latina, nos enfrentamos a un futuro incierto; continuamos siendo el gran proveedor de materia prima (agricultura, extracción minera) para los países desarrollados, sin tener una participación significativa en la generación de tecnología. Extraemos hierro, y luego compramos barcos hechos con la misma materia prima.

Si queremos cambiar este modelo, es vital que nuestra operación económica este sustentada sobre las industrias de uso intensivo de conocimiento, esta debe ser el área de mayor peso estratégico, sin abandonar las áreas de agricultura y manufactura. Debemos construir una infraestructura humana, educativa y organizacional para sustentar una producción compleja y crear capacidades que permitan convertirnos en una fuerza política de primer orden.

Como venezolano me he preguntado, que estrategias podemos implementar para que nuestro país pueda incursionar en las áreas de uso intensivo de tecnología, y convertirnos en un líder mundial en tecnología e innovación, y llegar a ser exportadores netos de tecnología.

Una base importante la iniciar la transformación de la nación, es exigir la transferencia tecnológica como condición para la inversión extranjera, fomentar la originalidad y crear una infraestructura que estimule la inventiva desde todos los niveles de educación; por ende debemos modernizar el plan de estudios y realizar cambios significativos en los modelos para proporcionar conocimiento a toda la población, Convertir los centros de educación superior, en incubadoras de conglomerados tecnológicos con alto espíritu empresarial, maximizar el empleo de centros de investigación y financiar proyectos y productos donde se demuestre la capacidad de aplicación en circunstancias practicas de negocio, establecer incentivos para evitar la repatriación de talentos, apoyar la investigación independiente, crear conglomerados globales y diversificados de tecnología, desarrollo de un sistema financiero y de capitales de riesgo, a fin de fomentar la innovación, apoyar las empresas estratégicas que son insumos claves para otros sectores.

Ahora mas que nunca vemos la vigencia del celebre articulo escrito por Arturo Uslar Pietro “Siembra Petrolera”,y me pregunto como venezolano si las políticas en este sentido no llevan por el camino correcto, la nación estas sembrando el petróleo?, hemos logrado crear una base que nos permita especializarnos en otras áreas?, Estamos enfocados en las industrias de carácter estratégico?

Para finalizar, como dice un proverbio chino no importa de qué color sea el gato, lo importante es que case ratones, esta hermosa visión de país debe ser compartida por el estado, e implementada por los gobiernos.

Saludos.

El Software Factory y la Investigacion

Muchas empresas hoy en día, quieren construir un software factory (fabrica de software) que les permita ser más competitivos y eficientes en la construcción de artefactos de software y cumplir con las tres variables: tiempo, costos y esfuerzo de forma óptima, y todo esto sin encarecer la calidad de sus productos.

Una vía para lograr estos objetivos gerenciales es contar con estándares, modelos de implementación, y productos generados a través de una profunda y constante línea de investigación. La investigación es muy necesaria, debido al dinamismo y el desarrollo constante de la ingeniería de software. Cada día surgen tecnologías, arquitecturas, estándares, especificaciones, componentes que mejoran y disminuyen en conjunto el número de líneas de código y el esfuerzo.

Las organizaciones deben adaptarse, y los arquitectos deben asumir su rol: mantenerse en constante vigilia tecnológica y permear esos conocimientos a todos los estratos tecnológicos.

La realidad, es que no todos los clientes están dispuestos a pagar la investigación. Ese es el gran problema, la mayoría de las empresas por lo general tienen métodos de desarrollo de software de muy bajo nivel comparado con las empresas que ven en la investigación un mecanismo para decrementar sus costos y proteger su inversion.

Hace poco, nuestro grupo desarrollo, creo un framework llamado Jerano, cuyo objetivo era implementar nuestro primer software factory. Hoy quiero hablar sobre nuestra experiencia en su realización y todos los inconvenientes que tuvimos que enfrentar.

En primer lugar tuvimos que seleccionar cuales eran las tecnologías Open Source que deberían ser parte de nuestro framework, quisimos seleccionar las tecnologías con mayor presencia en el area y una madurez comprobada.

Para armar un software factory, es importante en primer lugar establecer lineamientos de arquitectura de software, por ejemplo cuales son las capas que serán utilizadas y que tecnología debe implementar un servicio especifico. Decidimos utilizar spring como framework para la inyección de dependencias, el madurísimo Struts para el control de las capas de presentación, negocio y modelo (MVC). Unos de los problemas a los cuales nos enfrentamos en sobre el tema de seguridad. Acegi fue definitivamente el framework con mayores características y funcionalidades, además ya viene integrado con spring.

En la capa de presentación, utilizamos tecnologías Web 2.0 ajax, a traves de un framework llamado prototype.

Próximamente incluiré un marco de arquitectura mas detallado para contribuir con la comunidad.

Saludos Mijanautas!!!!.