Porque los proyectos BPM (Business process management) fallan?

Describir  las causas que originan la falla de proyecto BPM (Business process management) seria una actividad muy extensa, sin embargo he recopilado un conjunto de errores, malas practicas, consideraciones que inciden directamente en el éxito de un proyecto BPM. Desde hace algunos años he participando en proyectos BPM de diversos tamaños, estados, fases y condiciones, he podido constatar y registrar un conjunto de inhibidores que están afectando el éxito BPM en diversas organizaciones a nivel nacional e internacional.

BPM en esencia es una disciplina que permite que una organización pueda racionalizar y mejorar de forma continua el uso de sus recursos (gente, procesos, tecnología)  mediante la medición en tiempo real de indicadores y métricas relacionadas con el cumplimientos de sus objetivos estratégicos  tácticos y operacionales. BPM transforma y rediseña organización funcionales a orientadas en procesos, organizaciones inteligentes!!!

Describo a continuación algunos factores que inciden que proyectos BPM fallen. Espero que sea de utilidad para gerentes, arquitectos y directores que tengan entre sus planes la adopción BPM.

Factores Generales:

1. Mucho énfasis en tecnológica y poca en metodología.
2. Ausencia de políticas que garanticen la disminución de riesgos de ejecución al inicio.
3. Ausencia de una arquitectura de software clara y sencilla.
4. Arquitectura y diseño inconsistente.
5. Falta de comprensión de la disciplina BPM, su enfoque, su esencia.
6. Ausencia de las dimensiones mínimas de análisis que deben estar presentes para asegurar una descripción y modelado adecuado de los procesos.
7. Ausencia de un marco metodológico para el análisis y descripción de procesos.
8. Soluciones BPM que son utilizadas como si fueran un IDE de desarrollo.
9. Falta de comprensión entre BPM y las disciplinas SOA, ESB, BRE, entre otras.
10. Falta en la concepción de orquestación de servicios vs orquestación de procesos.
11. Ausencia de una arquitectura orientada en servicio en proyectos BPM.
12. Ausencia de un enfoque multidisciplinario de análisis y descripción de procesos.
13. Falta del criterio "zapatero a su zapato".
14. Poca experiencia en la definición y uso de patrones BPMN.
15. Uso inadecuado de la sintaxis y semántica de la notación gráfica BPMN 2.0. (Técnicas de modelado de procesos pobres).
16. Falta del criterio "Primero modelar luego construir".
17. Procesos muy grandes e ingobernables (divide y vencerás).
18. Procesos que no se modelan sobre una perspectiva de automatización.
19. Mal dimensionamiento de los componentes de una solución BPM.
20. Una aplicación no es el proceso.
21. Inexperiencia de proveedores.

Saludos;

Preguntas que debemos hacernos en un proyecto de Integracion SOA, ESB, BPM

He leído muchas veces la importancia de hacer buenas preguntas; en ese sentido, cuando abordamos proyectos de integración se presentan muchos problemas por no tomar en cuenta variables que son importantes para una buena implementación. Aquí algunas preguntas que como arquitectos debemos hacernos cuando necesitemos enfrentarnos a servicios de integración.

1. Que protocolo de transporte disponibiliza el servicio?  (Por ejemplo: HTTP, HTTPS, JMS, SMTP, TCP/IP)
2. Que protocolo de comunicación utiliza el servicio?. (Por ejemplo: HTML, XHTML, SOAP, XML, JSON)
3. Qué tipo de patrón de mensajería utiliza el servicio?  (Por ejemplo: Síncrono o Asíncrono)
4. El acceso al servicio requiere autentificación y autorización?
5. Qué tipo de seguridad utiliza el servicio? (Por ejemplo: ws-security, token, request).
6. El servicio tiene asociada alguna política? (Por ejemplo: Solo puede ser invocado desde una direccion ip especifica, algunos datos deben estar encriptados, el response time del servicio no puede exceder de 200 ms, solo puede ser invocado una sola vez al día).
7. Como se gestionaran los errores que pueden presentarse en el servicio? (Por ejemplo: soap faults, xml, texto, entre otros.)
8. Qué tipo de notificación deberá ser aplicada al generarse una excepción de disponibilidad del servicios (timeout, no disponible, entre otros). Por ejemplo: sms, correo electrónico.
9. Quien será el responsable o gestor de servicio? (Por ejemplo: nombre, correo electrónico, teléfono, entre otros)
10. El servicio requiere algún tipo de transformación (mapeo) o utilización de alguna expresión de salida?
11. Cuáles son los datos que pueden ser provistos por el servicio?
12. El servicio requiere algún componente transaccional?
13. Se debe aplicar alguna estrategia de cache en el servicio?
14. Como se gestionará la auditoria y logging del comportamiento del servicio en tiempo de ejecución?
15. Cual será el Service Level agreement del servicio? (Por ejemplo: timeresponse minimo)
16. Cual será la disponibilidad del Servicio?
17. Cuentan con un formato para especificar los servicios proveedores?
18. Cuál es el grado de complejidad del servicios?
19. Cuál es el tiempo estimado para su desarrollo?
20. Que recursos son necesarios para desarrollar los servicios?

Saludos;

Proyecto Challenge DevFactory

Desde hace un año y no con la frecuencia que quisiera, he estado  involucrando a niños, estudiantes y profesionales para que aprendan técnicas y métodos para el desarrollo de software basado en el  pensamiento de diseño. El desafió, ninguna de las personas tiene ningún tipo de conocimiento en ingeniería de software. Aquí algunas imágenes que transmiten por si solas.

Los invito a revisar las técnicas del pensamiento de diseño e incorporarlas en sus áreas de competencia!!

Pueden los jovenes apreder a desarrollar software sin una formacion formal?, que piensan ustedes!!!!;

Recomendaciones para abordar un proyecto BPM con Bonita BPM (Entrenamiento Bonita Open Solution BPM y API)

Hace algunas semanas desarrolle un programa de formación SOA/BPM que incluyo un entrenamiento intensivo en el modelado y automatización de procesos mediante la solución Bonita Open Solution. Durante esta transferencia de conocimiento y experiencias registre un conjunto de recomendaciones que fue enriquecido con los participantes y sus distintas contribuciones; el cual quisimos compartir con la comunidad con el objeto de incentivar no las herramientas tecnológicas sino las consideraciones metodológicas y políticas que deben establecerse.

Recomendaciones para abordar proyectos BPM con  Bonita Open Solution

1. La actividad de análisis y modelado de procesos debe realizarse de forma multidisciplinaria. Los procesos no se modelan en un solo día y con una solo perspectiva.
2. Los procesos pueden ser modelados por coreografía u orquestación, sin embargo para iniciar les recomiendo adoptar la orquestación.
3. Las tecnologías BPM no son herramienta de desarrollo, por ende se debe evitar en la medida de lo posible escribir código bajo sus diferentes características.
4. El proceso debe ser tratado como un prototipo, por ende debe pasar por diversas revisiones para ir dividiendo las responsabilidades por ejemplo: identificar  procesos utilitarios e invocarlos mediante actividades de llamada, o la utilización de timers y contadores para la gestión de acuerdos de servicios.
5. La gestión de excepciones debe siempre incluirse en los procesos, para asegurar que las instancias no se interrumpan durante excepciones en la disponibilidad de un conector o servicio.
6. Se recomienda que la mayoría de la lógica de integración, de datos o de reglas resida en servicios web que pueden ser invocados desde conectores o scripts groovy.
7. Los procesos pueden utilizar formularios, sin embargo existe la posibilidad de utilizar formar externas que invoquen procesos  mediante el api de servicios REST de bonita. Con esta aproximación existe mayor control de la interfaces. Otra opción es generar los formularios con bonita y modificarlos según las necesidades.
8. Utilice procesos utilitarios para notificaciones, cambio de estatus de documentos, escalamiento, entre otros.
9. Cuando modele utilice como máximo tres procesos por diagrama.
10. Utilice patrones para la gestión de errores en la invocación de servicios web, con el objeto de evitar que el ciclo de vida del proceso sea interrumpido por la falta de disponibilidad de un servicio.

Saludos;

From Mijao Blog

From Mijao Blog

From Mijao Blog

From Mijao Blog

4 lenguajes de programación (PHP, PYTHON, JAVA, GROOVY) y un Web Services – Programa BPM/SOA

Hace algunas semanas realice un programa de formación BPM/SOA, donde se abordaron diversas técnicas y métodos para el desarrollo de servicios de datos y decisión (reglas). El equipo técnico al cual impartí el entrenamiento contaba con una experiencia relevante en diversos lenguajes; lo cual enriqueció la actividad. Durante el entrenamiento, el equipo me plateo crear varios consumidores de servicios web bajo SOAP en diferentes lenguajes, lo cual me pareció una excelente práctica para ver los diferentes modelos de implementación para consumir servicios web.

En este post, podremos observar varias formas de consumir servicios web con diversos lenguajes:

PHP - NUSOAP

@include_once("nusoap/nusoap.php");
$oSoapClient = new nusoap_client('http://10.100.14.232:9763/services/tramiteCRUD?wsdl');
$respuesta = $oSoapClient->call("select_with_key_tramite_operation",array("tramite_id" => 2 ));
print_r($respuesta);
?>

PYTHON

from suds.client import Client
url = 'http://127.0.0.1:9764/services/tramiteWSS?wsdl'
client = Client(url)
print client.service.obtenerIdTramitesParIDs('1')

JAVA

package ve.gob.tramites.services.mppi.client;
import org.apache.axis2.AxisFault;
import ve.gob.tramites.services.mppi.TramiteCRUDStub;
import ve.gob.tramites.services.mppi.TramiteCRUDStub.Insert_tramite_operation;

public class Consumidor{
 public static void main(String[] args) {
  try {
   TramiteCRUDStub stub =new TramiteCRUDStub();
   Insert_tramite_operation objTramiteInsert=new Insert_tramite_operation();
   objTramiteInsert.setTramite_id(20);
   objTramiteInsert.setEstatus("ESTATUS PRUEBA");
   objTramiteInsert.setOrigen("ORIGEN PRUEBA");
  stub.insert_tramite_operation(objTramiteInsert);
  } catch (AxisFault e) {
   System.out.println("Ha ocurrido una Axis exception");
  } catch (Exception e) {
   System.out.println("Ha ocurrido una excepcion.");
  }
 }
}

PHP5 - SoapClient

$parametros['id']=2;
$client = new SoapClient("http://10.100.16.65:9763/services/tramiteidWS?wsdl",$parametros);
$respuesta = $client->selectId($parametros);
print_r($respuesta);
?>

Groovy

import wslite.soap.*
def client = new SOAPClient('http://localhost:1021/orden')
def response = client.send(SOAPAction: '') {
    body 
    { 
        'bam:createOrden'('xmlns:bam':'http://bam.service/') 
        { 
             'orden'('xmlns:bam':'http://bam.service/') 
             {  
                      campo1('I');
                      campo2('S');
                      campo3('A'); 
                      campo4('B');
             }             
        } 
    }
}
println response.envelope.Body.createOrdenResponse.return;

Felicitaciones al equipo por su alto nivel técnico, su proactividad, trabajo en equipo y su disposición a compartir con la comunidad su conocimiento. Este post es de ustedes!!!!

From Mijao Blog

Business Process Management (BPM) Reflexiones y Recomendaciones

Actualmente existen diversos enfoques de gestión organizacional; uno de los más comunes en el funcional, el cual sigue prevaleciendo sobre modelos de última generación más efectivos, eficientes y agiles. En este sentido, el enfoque orientado en procesos se ha convertido en la opción urgente para mejorar el desempeño organizacional; para resumir, una organización funcional no tiene la capacidad de medir, mejorar y optimizar sus acciones porque no realiza énfasis en los procesos, solo en sus actividades. Una organización BPM se comparta como un carro de carrera en fórmula 1, con un equipo que mide todas las variables necesarias para ganar.

En todas las organizaciones donde he realizado asesorías y consultorías BPM han persistido los siguientes hallazgos:

1. No existe una clara definición y caracterización de procesos.
2. No se entiende la diferencia entre un proceso y un procedimiento.
3. Los procesos no están alineados y vinculados a un objetivo organizacional.
4. Los procesos no están alineados y vinculados a un producto o servicio.
5. Los procesos no tiene asociados acuerdos de servicios.
6. Los procesos no tiene asociados indicadores.
7. Los procesos no pueden ser monitoreados y medidos.
8. La mayoría de los procesos no son transversales, solo se ven los árboles y no el bosque.
9. Los procesos no tiene asociadas políticas.
10. Los procesos no tiene asociados procedimientos.
11. El levantamiento de procesos no se realiza sobre un enfoque participativo y multidisciplinario.
12. El levantamiento de procesos se realiza sin métodos y técnicas que faciliten su especificación.
13. El levantamiento de procesos no se basa en la comprensión profunda de modelos y prácticas que evitaran modelar el desastre.
14. Los procesos no son categorizados o clasificados.
15. No existe una notación estándar para el modelado de procesos.

Establecer acciones para cerrar cada una de estas brechas sería muy extenso para describirlas en este blog, sin embargo comparto algunas recomendaciones que contribuirán con ejercicios de mayor valor en esta materia.

Recomendaciones

1. Describa y caracterice un proceso para estandarizar y homologar el lenguaje antes de iniciar cualquier iniciativa.
2. Comunique de forma clara y concisa la diferencia entre una actividad,  un proceso y un procedimiento a su equipo. Es diversas asesorías en las que he participado he encontrado inconsistencias, procesos que son actividades y viceversa.
3. Evalué el nivel de profundidad en la descripción de sus procesos que requiere. Comience con descripciones generales y luego vaya realizando una inmersión mayor de forma iterativa.
4. Recuerde que cada proceso debe estar asociado a la entrega de un producto o servicio.
5. Recuerde que cada proceso debe estar asociado al cumplimiento de un objetivo organizacional.
6. Evalué y seleccione la herramienta de modelado de procesos que más se adapte a sus necesidades.
7. Establezca una categorización de procesos: macroprocesos, procesos, subprocesos. Es importante establecer una organización mínima de sus procesos para posteriormente mapearlos.
8. Defina los indicadores de desempeño y resultado de sus procesos para medirlos, mejorarlos y optimizarlos antes de ir a la automatización.
9. La actividad de modelado de procesos requiere de técnicas y métodos no tradicionales.
10. Realice énfasis en la descripción de políticas (normas y directrices), son ellas las que establecen las fronteras y condiciones de sus procesos.
11. Modele primero la ruta de éxito y luego enriquezca.

Saludos;

Entrenamiento Mule ESB en Banco Central de Venezuela

Hace algunos meses tuve la experiencia de dictar un entrenamiento de Mule ESB en el Banco Central de Venezuela para un proyecto integración de gran envergadura. Durante el intercambio de experiencias en el campo de integración, el equipo de trabajo enriqueció muchos conceptos, que quisimos compartir con la comunidad.  Mule ESB es una plataforma de integración ligera basada en Java que permite conectar  aplicaciones de forma rápida y sencilla, actuando como un sistema de transporte e intercambio de datos. En líneas generales se utiliza un bus de servicios cuando se requiere:

1. La creación y alojamiento de servicios web reutilizables en un contenedor de servicios ligero.
2. El enrutamiento de mensajes, para enrutar, filtrar, agregar, y redirigir mensajes entrantes o salientes basados en su contenido o en reglas.
3. La transformación e intercambio de datos a través de distintos formatos y protocolos de transporte.
4. Servicios de mediación para el manejo de formatos, mensaje y protocolos, además de lógicas de integración.

Cuando debemos utilizar un ESB?

1. Cuando se requiere la integración de 3 o más aplicaciones o servicios.
2. Cuando se requiere conectar más aplicaciones en un futuro.
3. Cuando es necesario utilizar más de un tipo de protocolo de comunicación.
4. Cuando se requiere capacidades de enrutamiento de mensajes, tales como bifurcación y agregación de flujos de mensajes, o enrutamiento basado en contenido.
5. Cuando es necesario  publicar los servicios destinados al consumo de otras aplicaciones

Recomendaciones para el uso de Mule ESB

1. El patrón de intercambio seleccionado para un flow o flujo incide en el número de hilos que mule utiliza para la ejecución de servicios de integración. Si el patrón es Request-Response, este se desarrolla sobre un solo hilo; si el patrón es Onew-Way se desarrolla sobre un pool de hilos (inbound, core y outbount). Es necesario considerar esta política durante el diseño de los servicios.
2. Por defecto Mule ESB solo gestiona 16 hilos, por ende, es importante monitorear el número de hilos y aumentarlo según la demanda de un servicio de integración específico.
3. Mule ESB proporciona patrones de configuración, que están optimizados para casos comunes de procesamiento de mensajes. Los cuatro patrones de configuración incluidos en Mule son: Servicio simple (componente que expone servicios web SOAP/ JAX-WS , beans, REST/JAX-RS, JAXB, XML y el contenido de simples componentes POJO), Web Service Proxy ( Proxies de servicios web remotos que pueden realizar transformaciones), Bridge ( establecen un canal de comunicación directo entre un endpoint de entrada y uno de salida), por ultimo Validador (Valida los mensajes entrantes contra un filtro de aceptación definido. Devuelve una respuesta ACK o NACK sincrónica y envía mensajes válidos de forma asíncrona).
4. Utilice el Scope Pool para ajustar el desempeño de un servicio de integración mediante pool de objetos.
5. Utilice wiretap para realizar auditorías en los flows o flujos de servicios.
6. Si requiere utilizar multiples entradas en un mismo flow utilice composite source.
7. Si requiere establecer rutas alternativas al fallar una rama de ejecución utilice first successfull.
8. Si requiere reorganizar la secuencia de mensajes utilice un resequencer.
9. Si va a realizar mapeo recomiendo utilizar smooks y dozer.
10. La información del header de un mensaje en el inbound no se propaga al siguiente flow, solo de outbound a inboud, considere esta característica cuando diseñe sus servicios.

Agradezco al equipo que con su participacion y observaciones enriquecieron los talleres.

Ejemplo: Como enviar un mensaje a multiples destinos.
 

 Ejemplo: Como realizar el procesamiento de una coleccion de datos.

 Ejemplo: Como exponer un servicio web implementado en un POJO.

  Ejemplo: Como filtrar el mensaje entrante de un servicio.

  Ejemplo: Como realizar auditorias a un servicios de integracion:

Saludos;

WSO2 e Interoperabilidad, una Plataforma Middleware en Panamá

Hace algunas semanas realice un taller sobre la  plataforma middleware empresarial WSO2 en Panamá dentro de un proyecto de Interoperabilidad y Gobierno Electronico de alta escala que se esta desarrollando actualmente. WSO2 esta conformada por un amplio numero de componentes con nivel de madurez suficiente para ser considerado como modelo para introducir las disciplinas SOA, ESB y BRE en una organizacion. En este post, voy a compartir algunas apreciaciones relacionadas con el despliegue de estos componente. Para comenzar una pequeña introducción.


WSO2 Carbon es una plataforma middleware empresarial, 100%  OpenSource y basada en estándares empresariales, que permite a desarrolladores orquestar procesos de negocio, crear aplicaciones y desarrollar servicios;  utilizando WSO2 Carbon Studio y una amplia gama de servicios empresariales y  técnicos que se integran con legados, paquetes y aplicaciones de software  como servicio (SaaS). La plataforma WSO2 Carbon es una colección de componentes totalmente  independientes que pueden ser agregados o eliminados de una solución dinámicamente. Este comportamiento se logra mediante el uso del marco  de trabajo denominado Open Services Gateway Initiative (OSGi).

WSO2 Data Services
WSO2 permite la creacion de servicios de datos, conocidos como "Data Services" con un amplio espectro de posibilidades de conexion con diversas fuertes de datos como hojas de calculo, base de datos, entre otros. Con este componente podemos desplegar servicios SOAP y REST de una forma sencilla y elegante, sin grandes esfuerzos de desarrollo, sin embargo cuando requerimos implementar servicios de generación de UUID o correo electrónico; esta no es la mejor opcion.

WSO2 Rule Services
De igual forma, provee desde mi punto de vista unos de los mejores componentes que son los "WSO2 rules Services", conocidos como "Rule Services" o servicios de decision, una forma muy sencilla y elegante  de tomar reglas de negocio elaboradad mediante Drools y exponerlas como servicios de decisión. Drools es un motor de reglas de negocio que permite la gestion de reglas en un entorno multi usuario de manera controlada a traves de interfaces de usuarios amigables. WSO2 Business Rules Server ofrece la gestión de reglas de negocio para un entorno SOA sobre la base de una sólida plataforma de alojamiento de reglas de negocio. WSO2 Business Rules Server permite que las reglas de negocio sean encapsuladas en un lenguaje sencillo y directo, el cual es más familiar para los analistas de negocio.

WSO2 Governance Registry
Otro componente que recomiendo es la utilización del WSO2 gobernent que proporciona el nivel adecuado para soportar la gobernabilidad SOA (es obtener el máximo rendimiento del entorno SOA y asegurarse de crear servicios de alta calidad). Con este componentes, podemos: crear y mantener un conjunto de políticas SOA, permitir la aplicación de estas políticas en tiempo de diseño y permitir la aplicación de estas políticas en tiempo de ejecución.

Por ultimo, recomiendo la evaluación de la plataforma WSO2 por la sencillez y elegancia de gestión, la cual puede ser utilizada para acelerar una implementacion SOA organizacional.





Saludos;

Ley de Interoperabilidad Venezolana, una ley innovadora, creativa y actual

Actualmente, los intercambios de información entre las instituciones publicas de muchos países se están desarrollando sobre una amplia variedad de formatos, tipos e interacciones, lo cual ha impulsado el crecimiento y proliferación de practicas no estandarizadas que han contribuido con la desarticulación de los organismos responsables en la prestación de servicios al ciudadano.


En este sentido, el estado venezolano ha reconocido la responsabilidad de prestar servicios de interoperabilidad para garantizar la prestación de servicios públicos integrados mas eficientes para los ciudadanos. Esta ley garantizara la articulación de las instituciones publicas para responder a las necesidades de los ciudadanos, instituciones y el estado utilizando las tecnologías de informacion como principal medio.

En esencia, la ley garantizara el desarrollo de servicios de información adaptados a las necesidades de los ciudadanos y a los procesos institucionales, disminuyendo las dificultades de integración entre los sistemas de información presentes en el sector publico y privado.

En la Gaceta Oficial N °39.945 de fecha 15 de junio de 2012, fue publicado el Decreto N°9.051 mediante el cual se dicta el Decreto con Rango, Valor y Fuerza de Ley sobre el Acceso e Intercambio Electrónico de Datos, Información y Documentos entre los Órganos y Entes del Estado. El presente Decreto con Rango, Valor y Fuerza de Ley, tiene por objeto establecer las bases y principios que regirá el acceso e intercambio electrónico de datos, información y documentos entre órganos y entes del Estado, con el fin de garantizar la implementación de un estándar de interoperabilidad.

Desde este link se puede tener acceso a la ley:
http://www.cnti.gob.ve/images/stories/documentos_pdf/go_interoperabilidad.pdf

Como venezolano he aportado mi granito de arena en la conformación de esta ley, integrando en ella conceptos asociados a las disciplinas y estilos de arquitectura SOA, ESB y BPM. Entre los elementos de mayor importancia:

La Ley  incorpora diversas disciplinas y estilos de arquitectura de TI en su contenido.
La ley incorpora el concepto de servicio.
La ley incorpora conceptos relacionados con Gobernabilidad SOA.
La ley incorpora conceptos relacionados con Bus de Servicios.
La ley incorpora conceptos relacionados con Web Semántica y Nube de datos.

Saludos y felicitaciones al personal técnico y gerencial del Centro Nacional de Tecnologías de Informacion y al Centro Nacional de Innovación Tecnológica por la iniciativa y la contribución que han realizado por mejorar los servicios públicos en el Estado Venezolano. Una iniciativa creativa, innovadora y de valor!!!

Intalio y Bonita BPM en el Ecuador

Hace algunas semanas estuve de nuevo en Ecuador impulsado la utilización de las disciplinas BPM, SOA, ESB y BRE para la creación de organizaciones gestionadas por procesos. En esta oportunidad el Organismo de Acreditación Ecuatoriano (OAE) esta desarrollando los primeros pasos para cambiar su modelo de gestión funcional a uno orientado a la medición en tiempo real de indicadores que puedan mejorar sustancialmente sus procesos de decisión. El marco de arquitectura propuesto esta conformado por un conjunto de tecnologías que de forma integral permitirán que la institución pueda conformar un marco de interoperabilidad robusto, escalable y fiable.


De la experiencia obtenida en dicha consultoria, quise compartir con la comunidad algunas recomendaciones que pueden ser utilizadas en implementaciones a gran escala de proyectos BPM-SOA organizacionales; estas recomendaciones pueden ayudarlo a facilitar su comprensión.

Algunas recomendaciones para utilizar Bonita BPM e Intalio.

1. Evite modelar los procesos sobre la premisa que el motor de procesos debe exponer servicios web. El motor de procesos debe orquestar servicios, pero no es recomendable utilizarlo como una plataforma para la creacion de servicios, como decimos en Venezuela "zapatero a su zapato".
2. Utilice Data Services como medios para exponer servicios web relacionados con medios persistentes como base de datos, hojas de cálculos, archivos, entre otros.
3. Utilice servicios "Rule Services" para gestionar sus reglas de negocio. Los Rule Services también son conocidos como servicios de decisión.
4. Utilice un bus de servicios para integrar sus servicios de datos, reglas, integración o procesos mediante un enfoque de proxys.
5. Es importante establecer una diferencia entre servicios de datos e integración. Los últimos generalmente son implementados en un bus de servicios.
6. Establezca los "Process Services", servicios web que son expuestos por un motor de procesos como Bonita BPM o Intalio.
7. Utilice correlaciones en sus procesos para tener control de las instancias que requiere ejecutar, sin embargo, recomiendo utilizar como maximo dos correlaciones por diagrama, esto evitara que los diagramas de procesos se extiendan en una sola representación, contribuyendo con una mejor comprensión.
8. Divide y vencerás. tome los procesos y separelos en subprocesos independientes.
9. Importe los procesos, con esta opciones no tendrá problemas con el acceso a fuentes de datos; como xml schemas.
10. Defina mensajes Request y Response separados para cada mensaje.
11. Utilice el poder de la API REST de Bonita o la correlaciones de BPEL para controlar las tareas asociadas a los procesos y el orden de ejecución.
12. Utilice lienzos para plasmar las ideas y conceptos durante los talleres de análisis de procesos:

Saludos;

Interoperabilidad en Panamá

Las practicas de gobierno electrónico e interoperabilidad han venido siendo abordadas por muchos países en nuestro continente, sin embargo en la mayoría de estas iniciativas sigue prevaleciendo un enfoque dirigido a la construcción de portales como medio de información para el ciudadano, practica importante; sin embargo no suficiente para mejorar los servicios a los ciudadanos. Los ciudadanos requerimos que los tramites sean ágiles, efectivos y eficientes, requerimos que las instituciones estén integradas y compartan su conocimiento. Para cubrir dicha necesidad, los estados debe impulsar políticas en el área de interoperabilidad como el desarrollo de portales únicos de tramites, quejas, datos, instrumentos legales, entre otros.

En este sentido, hace días tuve la oportunidad de dictar una charla sobre interoperabilidad y Mule ESB en Panamá, específicamente a la Autoridad Nacional para la Innovación Gubernamental, entidad responsable de la modernización del Estado, mediante el uso de las Tecnologías de Información y Comunicaciones (TICs). Este organismo actualmente esta desarrollando el proyecto "Panamá Sin Papel" (PSP) el cual permitirá la integración de los servicios de tramitación publica panameños. En este proyecto se incluyeron disciplinas de ultima generación como SOA, ESB, BPM, software libre y open source.

Agradezco a todos los actores y sobre todo a la organización venezolana que esta llevando tan importante iniciativa dentro del gobierno panameño por la invitación. Desde aquí mucha energía y felicitaciones por el profesionalismo y dedicación desarrollado.

Recomendaciones de Arquitectura (Escalabilidad, Disponibilidad, Fiabilidad )

Cuando desarrollamos software, la arquitectura es el  elemento mas importante de su diseño, ya que este sostendrá y soportara todas las funciones en tiempo de diseño y ejecución de la solución. Lamentablemente (según mi experiencia)  siguen proliferando arquitectura monolíticas y rígidas afectando el desempeño; por ejemplo de muchas portales que terminan fuera de servicio por un numero de accesos concurrentes mínimo e irrisorio.

Esta situación se presenta con mucha frecuencia por la falta de planteamientos dirigidos y centrados en  asegurar escalabilidad, disponibilidad, fiabilidad, entre otros aspectos. Hace poco estuve trabajando en un compendio especifico sobre las practicas de arquitectura que deben ser consideradas cuando desarrollamos software de alta demanda. Aquí una pequeña pero importante relación de las mejores practicas y recomendaciones que utilizo para evaluar cual es el patrón de arquitectura de software mas idóneo para una solución. El objetivo es diseñar arquitecturas de software escalables, robustas y profesionales.

Algunas Recomendaciones:

1. Para satisfacer la demanda de escalabilidad de la solución no almacene los datos en una ubicación centralizada. Los datos pueden estar distribuidos en diversos nodos.
2. Utilice una estrategia de memoria caché para disminuir el acceso a base de datos innecesarios. Esta estrategia por ejemplo puede representar una reducción del 50% en la utilización de CPU.
3. Para garantizar disponibilidad, considere una estrategia de cache para almacenar los datos en memoria permitiendo mayor fiabilidad y disponibilidad de servicios.
4. Utilice de forma intensiva plataformas de mensajería asíncrona para que los servicios de la solución puedan escalar de forma independiente.
5. Utilice balanceadores de carga estándar para enrutar el tráfico entrante a servicios. Esta estrategia puede ser utilizada cuando los servidores no conserven un estado transaccional (Espejos). Si se requiere de mayor capacidad de procesamiento, simplemente puede anadir más servidores de aplicaciones.
6. Divida las fuentes de datos para reducir los tiempo de consultas.
7. No utilize una base de datos monolítica, en cambio sugiero utilizar grupos y funciones de aplicación independientes, permitiendo que cada grupo escale de forma independiente el uno del otro, de acuerdo a las demandas y el consumo de recursos. Además, este enfoque permite aislar y racionalizar las dependencias de recursos.
8. Divida las cargas de trabajo en unidades manejables, donde cada unidad individual conserve una buena relación precio-rendimiento. 
9. Gestione diversos ambientes, por ejemplo: desarrollo, calidad y producción.
10. Utilice ambientes virtualizados.
11. Evalue la utilización de base de datos NoSQL "ya es tiempo :) ".

Espero que estos puntos puedan influenciar la adopción de practicas en el establecimiento de un buen diseño de arquitectura.

Saludos,

Intalio BPM y Bonita BPM - Procesos Orientados en Eventos

Desde hace algun tiempo he estado inmerso en el enfoque BPM y en los metodos y herramientas disponibles para desarrollar las disciplinas y conceptos que la integran. He tenido la oportunida de participar en proyectos medianos y grandes cooperando en diversas aristas en soluciones BPM basadas en software libre y open source, entre las mas importantes Intalio y Bonita.

En este post, voy a compartir una vision poco desarrollada en proyectos de modelado y automatizacion de procesos, "BPM orientado en Eventos". Generalmente cuando vemos los entrenamientos y demostraciones de productos propietarios o en software libre la mayoría están enfocadas en el desarrollo de aplicaciones orientadas en procesos, donde la solucion tiene la capacidad de generar formas para el ingreso de informacion y controlar el flujo de tareas. Esta perspectiva es la tradicional, sin embargo en organizaciones donde ya existe una arquitectura de aplicaciones entregando diversas funcionalidades se requiere contar con un método que permita capturar los diversos eventos que pueden ser generados por estas aplicaciones evaluando por ejemplo acuerdos de servicios en procesos de larga duracion. Un ejemplo de un escenarios es la activacion de un servicio especifico que requiere de la intervencion de diversas aplicaciones e interacciones humanas.

Intalio + Bonita + Mule ESB
Generalmente como arquitectos o desarrollador no utilizo soluciones con funcionalidades similares, sin embargo en un proyecto ejecutado recientemente realice la integracion de 2 soluciones BPM que a primera vista no parecen complementarse, sin embargo como venremos mas adelante en posible que esto ocurra  ;sustentado en el análisis de sus debilidades y fortalezas entorno al uso de un estandart o practica de TI.

BPM orientado en Eventos
Bajo este paradigma, se reconoce en primera instancia que las aplicaciones pueden generar eventos; la solucion BPM estaría simplemente escuchado eventos generados por aplicaciones y registrandolos por ejemplo en un motor de persistencia NoSQL que permita la construccion de un cuadro de mando para la toma de decisiones.

En intalio este comportamiento puede ser implementado mediante el uso de correlaciones que esta soportando por el lenguaje BPEL desde hace años, contando con un nivel de madures aceptable. Una correlacion es un método que permite pasar datos a una instancia especifica de un proceso mediante un identificador único para la instancia. En este ultimo existen dos tipos de conrrelaciones implicitas y explicitas. En  este ejemplo podemos observar dos modelos sencillos de implementacion bases para el uso de correlaciones y el control de acuerdos de servicios.

En este ejemplo se puede observar un proceso que puede recibir y producir eventos. Inicialmente el proceso (instancia) espera por un registro, posteriormente se establece un acuerdo de servicio (SLA) o la recepción de una decisión.

En este ejemplo, el uso de correlaciones con la nuevas características de Intalio.

En Bonita actualmente no existe un control directo de este comportamento, sin embargo es posible modelarlo mediante actividades humanas que son ejecutadas de forma automatica, o la utilizacion de un modelo de persistencia donde se almacenen las diversas instancias de procesos . Uno de las fortalezas de Bonita en la existencia de una API basada en servicios REST que proporciona mayor usabilidad y control sobre las instancias. Aquí un ejemplo de un proceso modelado en Bonita BPM basado en la gestión de eventos.

Generalmente podríamos decir que ambos entornos son excluyentes; sin embargo en un proyecto he utilizado Intalio como solución para la orquestacion de servicios web descritos mediante BPEL y soportando en Apache ODE; y Bonita BPM como solución para el control de eventos. Ambas soluciones pueden ser integradas en un enfoque que permita aprovechar las áreas con mayores fortalezas en cada una. En Intalio el uso del lenguaje BPEL y los estandares ws-* y en Bonita la facilidad de utilización de servicios  REST para el control de las instancias.

Saludos;

La poca conocida disciplina de Gestión del Cambio

Introducir un cambio de paradigma organizacional requiere generalmente un esfuerzo cuantioso y mirar variables que generalmente no son consideradas por la gestión de proyectos. Muchas organizaciones fallan en su intensión de introducir proyectos que establecerán nuevas prácticas y nuevos valores organizacionales, por la omisión de incorporar la disciplina de gestión de cambio.

La gestión de cambio es una disciplina muy poco conocida y practicada en las organizaciones, siendo esta desde mi punto de vista imprescindible como una acción para disminuir los riesgos de forma sustancial en cualquier proyecto. Por ejemplo, crear una cultura de calidad entorno prácticas de TI (ITIL y COBIT) debe estar acompañado de un enfoque de gestión de cambio.

Cuantos proyectos organizacionales fallan por la existencia de un mal liderazgo, por la falta de participación y colaboración, por la ausencia de personas no comprometidas con los objetivos, poca comprensión del valor y aporte de las diversas iniciativas; y podría seguir con diversas variables que están incluso entorno a nuestros comportamientos y actitudes sociales.

Que mide la disciplina de gestión de cambio?

La gestión de cambio es un componente fundamental en cualquier iniciativa para el desarrollo de programas o proyectos, esta ayuda a:

1. Medir el grado de liderazgo en cada uno de los componentes que integran la iniciativa.
2. Medir el grado de la efectividad de la comunicación (claridad, sencillez, comprensión, entre otros).
3. Contribuir continuamente con la alineación, evitando la generación de conversaciones, ideas, entre otros fuera del contexto y los objetivos planteados.
4. Medir el grado de contribución (participación y colaboración) de los participantes en un programa o proyecto.
5. Medir el grado de compromiso por las acciones y la visión estratégica establecida.
6. Comunicar continuamente las desviaciones en los enfoques y objetivos planteados.
7. Identificar brechas y recomendar acciones de mejora para mejorar la alineación y la efectividad del trabajo en equipo.
8. Evaluar es estado y grado de contribución de las habilidades y destrezas requeridas para cada uno de los componentes que integran la iniciativa.
9. Medir el grado de  entendimiento y comprensión de los objetivos, beneficios y actividades planteadas.

Algunas Recomendaciones

1. Inserte la disciplina de gestión de cambio como un componente mas en la formulación de un proyecto organizacional.
2. La gestión de cambio es un componente fundamental en cualquier proyecto, evitando que se desarrollen desviaciones que puedan afectar el ciclo de vida del proyecto.
3. En esencia esta disciplina considera por ejemplo: 
• Cual debe ser mensaje?, 
• El mensaje es sencillo y claro?
• Se comprenden los beneficios?
• Se comprende que objetivos apoya?
• Quien obstaculiza y porque?
• Hay participación y colaboración?
• Porque no se cumplen los objetivos?: falta de alineación?, falta de habilidades?, 
• Existe un enfoque y visión compartida?
• entre muchas otras preguntas.

Saludos;

Reflexiones en tu primer añito Ariana, Bienvenido el 2012!!!

Hoy es un día especial, mi hija cumple su primer añito, y quise celebrarlo compartiendo con la comunidad algunas reflexiones y experiencias.

Su llegada a mi mundo me ha hecho reflexionar, ahora juego, veo comiquitas y pienso en su futuro, seguro como lo hicieron nuestros padres, sin embargo esta época es distinta, nuestros hijos estan constantemente siendo sometidos a nuevas tendencias, tecnologías,y debemos como padres adaptarnos y decidir que es bueno  o malo para ellos.

Mi hija se enfrentara a una sociedad y generación distinta, la generación que debe reflexionar y construir. Ya no estamos en la era de la informática o del conocimiento, sino en la era del pensamiento, de la refundacion o el rediseño”. Nuestros hijos deberán rediseñar nuestro mundo, lamentablemente les dejamos un mundo con muchas inconsistencias donde no ha proliferado el menos común de los sentidos: el sentido común.

Su mundo estará centrado en innovar y crear nuevos modelos que sean sostenibles y sustentables, dejemos pues que nuestros hijos (las mariposas) jueguen y nosotros (las orugas) permitamos que experimenten y desarrollen habilidades creativas. Como padres debemos hablarles sobre innovación, resultados, trabajo en equipo, liderazgo, curiosidad y muchos mundos mas, pero sobre todo como escuche hace poco "Debemos contarles muchas historias", porque somos el resultado de las historias que nos cuentan.

Esta imagen resume el cambio que ha generado tu llegada en nuestra casa!!!
Te amo Ariana Isabella.

Social BPM - BPM Social - una pequeña introducción

Es innegable el impacto que han tenido las tecnologías sociales como facebook, twitter en nuestra sociedad. Su aplicación actual ha estado enfocada al desarrollo de redes sociales, medios que han permitido que personas compartan, participen y colaboren sobre diversos contextos sociales, intereses y objetivos comunes. Ejemplo de ellos son las redes familiares, educativas, profesionales, de negocios, entre muchas otras.

Tecnologías Sociales dentro de las organizaciones

Actualmente existe un fuerte debate sobre el uso de las tecnologías sociales en un entorno organizacional y como pueden ser utilizadas para generar valor. Ya existen organizaciones que están incorporando el uso de tecnologías sociales, por ejemplo en procesos de reclutamiento donde estas tecnologías han permitido ubicar prospectos ("talentos") que comparten habilidades y destrezas similares en dominios específicos. Las organizaciones están comenzado a incorporar tecnologías sociales en casa.

BPM y las tecnologías Sociales

BPM es actualmente uno de los principales enfoques organizacionales para impulsar el desarrollo de organizaciones gestionadas por procesos, procesos que generalmente son considerados como una secuencia de actividades gobernadas por ramas, bucles condicionales y reglas. En esta ecuación, las interacciones humanas no han sido consideradas.

Un proyecto BPM organizacional sera mas consistente y efectivo si incluye la información no estructura.  En este sentido; coincido en muchos análisis  que plantean que la información no estructurada como ideas, conversaciones y opiniones, son en esencia el lugar donde se plantean y conciben nuevas estrategias e iniciativas de mejoras organizacionales, por ende deben ser consideradas en una estrategia de mejora continua.

Debemos reconocer, que el flujos de tareas en una organización son en esencia actividades sociales, estando conformadas por patrones de comunicación, participación y colaboración.

BPM Social o Social BPM

BPM Social es un enfoque basado en la creciente adopción de herramientas y técnicas sociales y su utilización en un contexto BPM, incorporando el conocimiento no estructurado generado por el intercambio y colaboracion de profesionales en diversas aristas. BPM social se convertirá según los expertos en una tendencia centrándose en la racionalización de los recursos y eficiencia mediante canales sociales.

Algunas Conclusiones

1. Definitivamente las tecnologías sociales iran sumergiendose dentro de las organizaciones para permitir que sus integrantes participen, colaboren y compartan sobre un enfoque común.
2. Las tecnologias sociales iran emergiendo y cambiando los modelos de gestion organizacionales.
3. El reto de BPM social estará centrado en identificar como extraer la utilidad de conversaciones, opiniones y puntos de vista en torno a procesos.
4. BPM Social es un enfoque que permite considerar las actividades no estructuradas como una base para generar valor hacia la mejora de procesos.

Recomendaciones 

1. Si la organizacion establecer como objetivo el desarrollo de un proyecto BPM, incluya las tecnologías sociales como un componente.
2. Utilice las tecnologias sociales para enriquecer y proporcionar un contexto útil a proyectos BPM.

Utilizar las tecnologías sociales dentro de un contexto organizacional representa en si misma un cambio de paradigma. Este requiere que la organización este convencida del poder y contribución que las tecnologias sociales pueden representar. En ese aspecto, concuerdo que la informacion y el conocimiento gestionado en las organizaciones no es estructurado, por ende es importante que la organización lo reconozca y establezca acciones para considerar el aporte que puede generar.

Bienvenido BPM Social!!!

Como desarrollar un Blueprint de Arquitectura de Software

Desde hace años he participado como arquitecto jefe en diversos proyectos de software desde aplicaciones web sencillas a soluciones de alta demanda, escalabilidad y desempeño, siendo la arquitectura un componente necesario, prioritario y vital.

Cuando se inicia el desarrollo de un proyecto de software es necesario conceptualizar en primera instancia el desarrollo de un "Blueprint de Arquitectura", el cual es un documento que describe y establece un conjunto coherente de criterios y recomendaciones de diseño arquitectónico que deberan ser utilizadas para garantizar el desarrollo de una arquitectura desacoplada, ágil, adaptable y de tecnología neutral para la solucion. Como arquitecto de software, este es un insumo que no puede falta al iniciar un proyecto de software.

Generalmente este documento está conformado por cuatro secciones. En la primera se establecen los requisitos y  atributos de calidad que deberán ser garantizados por la arquitectura de la solución como: simplicidad, flexibilidad, tolerancia ante cambios, reusabilidad, desacoplamiento, entre otros. En la segunda sección se describen las disciplinas y estilos de arquitectura que soportarán la plataforma de software y hardware de la solución, los estándares y normas abiertas que deben ser utilizados para facilitar la interoperabilidad entre los módulos de la solución, la división por capas, topología de servicios y la propuesta general arquitectónica de la solución. En la tercera sección se describen las Soluciones de Software y Hardware Propuestas. Por último, se plantean diversas recomendaciones en referencia al cumplimiento de los atributos de calidad establecidos.

El objetivo general del blueprint de arquitectura es describir el estilo de arquitectura y los marcos tecnológicos que sustentarán la plataforma de servicios de la solución. Entre sus principales objetivos:

• Describir los componentes que integran la arquitectura de software y hardware de la solución.

• Establecer las premisas generales que sustentarán el desarrollo de una arquitectura ágil y eficiente para la solución.

• Describir los criterios de calidad que deben ser garantizados para el desarrollo de una arquitectura de software y hardware ágil y eficiente para la solución.

• Establecer las disciplinas y estilos de arquitectura que soportarán la plataforma de software y hardware de la solución.

• Establecer los estándares y normas abiertas que deben ser utilizados para facilitar la interoperabilidad entre los módulos de la solución.

• Describir las estrategias de interconexión e integración que proveerán la capacidad de intercambio de información entre los componentes de la solución.

• Describir las alternativas tecnológicas propuestas para el desarrollo de la solución.

• Establecer los criterios generales para proporcionar una infraestructura de alta disponibilidad, segura, eficiente y escalable para la solución mediante un conjunto de recomendaciones.

Anexo un mapa de las areas que debemos considerar cuando diseñamos la arquitectura de software de una solucion.

Saludos;

Hacia una Ley de Interoperabilidad

Desde hace años, he estado impulsado la necesidad y urgencia del desarrollo de una plataforma de  servicios de interoperabildiad para el Estado Venezolano. La "PIN" como la llamo es un medio, que permitirá que se establezcan las condiciones necesarias para el desarrollo y adopción de políticas, principios, estándares, normas y procedimientos para el acceso e intercambio electrónico de datos e información entre los órganos,   ciudadanos y entes de un Estado.

Desde mi punto de vista no han existido avances consistentes en Venezuela e incluso en América Latina dado que en la mayoria de países no se ha definido como una necesidad la prestación de servicios de interoperabilidad. En el campo del gobierno electrónico sigue persistiendo la idea que la creación y difusión de información mediante portales como principal acción, sin embargo los medios y políticas para el intercambio de datos e información no han sido una realidad en muchos de nuestros países.

Es mi país, existen grandes brechas en el intercambio de información, sin embargo el conocimiento es el verdadero reto. Como pueden los entes gubernamentales tomar decisiones sin un modelo de información homologado que responda a los intereses de las sociedades, y no a simples reportes de gestión?. Como podemos evaluar la mejora en una área especifica si no tenemos la capacidad de ver el bosque?. Como podemos realizar un ejercicio de tomas de decisiones ágiles y consistentes si en nuestros países todavía domina el Universo del Excel o el Calc?. Como podemos mejorar si no tenemos la capacidad de medir?. Porque no empezamos a evaluar tecnologías que permitan la medición en tiempo real?. Como podemos avanzar si no existe una política concreta para la gestión de conocimiento en TI?

Una plataforma de interoperabilidad puede convertirse en un medio para conocer de forma consistente el estado en tiempo real de las acciones de gobierno de un Estado, construyendo un canal que nos permita evaluar si vamos a buen puerto, sin estamos cumpliendo con las metas que requiere la sociedad, si somos efectivos y eficientes en nuestra gerencia.

Sobre sus componente generales
Una plataforma de interoperabilidad esta conformado por diversos componentes que la integran, entre los mas importantes:

1. Una plataforma integrada de consulta de datos, que contribuya con la reutilización de datos, información y funcionalidades en un estado.
2. Una plataforma integrada de mediación de servicios de interoperabilidad la cual contribuirá con la mediación y la orquestación de servicios.
3. Un mapa nacional de servicios de información interoperable, que proveerá un único punto de acceso a los diferentes servicios de información interoperables provistos por los órganos y entes del Estado, fomentando paulatinamente su conocimiento, reutilización, integración e interoperabilidad.
4. Una plataforma integrada de automatización de procesos interinstitucionales, que podrá administrar el ciclo de vida de procesos transversales de interés estratégico para el Estado.

El Futuro que desearía para mi hija, para mi país, para mi continente
Actualmente estoy trabajando en una propuesta técnica que aborda inclusive elementos de gestión de cambio porque estoy convencido que la calidad de vida de una sociedad esta profundamente ligada al uso efectivo, eficiente e inteligente de las tecnologías de informacion. Reflexionando en este sentido, yo desearía para mi país:

1. Que cada institución desarrolle y adopte los estilos de arquitectura y disciplinas requeridas para asegurar la interoperabildiad de sus sistemas de informacion.
2. Que cada institución pueda compartir conocimiento sobre su perspectiva.
3. Que el estado establezca políticas consistentes y de altura para garantizar la aplicacion de normas.
4. Que el ciudadano común tenga acceso a portales únicos e integrados como: denuncias.pais tramites.pais, datos.pais.
5. Que el estado pueda medir en tiempo real la gestión de sus instituciones y el cumplimiento cualitativo y cuantitativo de sus políticas.
6. Que el estado cuente con un modelo de informacion agnóstico que responda a las necesidades de sus ciudadanos.
7. Que el estado cuente con plataforma de interoperabilidad por sectores: Plataforma Nacional de Interoperabilidad para Alimentacion, Plataforma Nacional de Interoperabilidad para Vivienda, Plataforma Nacional de Interoperabilidad para Seguridad, Plataforma Nacional de Interoperabilidad para Tramites.
8. Que el estado pueda medir, mejorar y optimizar procesos transversales de interés estratégico.   

En Venezuela hemos comenzado a dar pasos

Hace meses tuve la oportunidad de desarrollar desde el punto de vista técnico y arquitectónico un borrador de propuesta de ley de Interoperablidad para el Estado Venezolano, el cual esta siendo impulsado por el Ministerio del Poder Popular para Ciencia, Tecnología e Industrias Intermedias. Una propuesta que contiene elementos innovadores que podrían a futuro convertirse en una referencia a nivel latinoamericano.

La propuesta de ley permitirá a grades rasgos:

1. Garantizar el desarrollo de un estándar común de interoperabilidad en el Estado.
2. Establecer las condiciones necesarias para el desarrollo y adopción de políticas, principios, estándares, normas y procedimientos para el acceso e intercambio electrónico de datos e información entre los órganos y entes del Estado.
3. Promover el desarrollo de servicios de información interoperables adaptados a las necesidades de los ciudadanos y los procesos del Estado.

Como ciudadano de esta tierra, felicito todas las iniciativas que se están dando desde el Centro Nacional de Tecnologías de Información (CNTI) y el CNIT (Centro Nacional de Innovación Tecnológica) instituciones que están dando los primeros pasos hacia el fin ultimo: "Una plataforma Nacional de Interoperabilidad dirigida a mejorar la calidad de vida de sus ciudadanos mediante el uso efectivo, eficiente e inteligente de las TI". Desde aquí muchas energías positivas!!!

Saludos;

SOA, ESB y BPM en el Ecuador (Integrando Mule ESB e Intalio BPM)

Hace poco tuve la oportunidad de viajar a Ecuador e impulsar la adopción de las disciplinas y estilos de arquitectura SOA, ESB y BPM en un entorno organizacional mediante transferencias tecnológicas con el apoyo de soluciones en software Open Source como Mule ESB, Intalio BPM y capacitaciones sobre Gobernabilidad SOA y BPMN2. Me resulto muy grata la estadía. Agradesco a Hugo Chamba y a Brighitt por su hospitalidad y colaboración, Lianet, Juanka y todo el equipo que labora en una organización que esta dando pasos fuertes en la adopción y puesta en practica de estas disciplinas en el Ecuador.

En dichos talleres pudimos compartir en áreas como:

1. Interoperabilidad, estilos y disciplinas de arquitectura SOA (Service Oriented Architecture), ESB (Enterprise Services Bus), BRE (Business Rule Engine), CEP (Complex Event Processing) y BPM (Business Process Management).
2. Introducción al desarrollo de “Blueprints de Arquitectura de Software”.
3. Modelado de procesos mediante la notación gráfica BPMN 2.0, técnicas, patrones y mejores prácticas.
4. Utilización de Eclipse IDE para el desarrollo de proyectos orientados en servicios (SOA).
5. Despliegue de un Bus de Servicio Empresarial mediante MULE ESB; desarrollo de servicios web para protocolos SOAP / REST e integración con Spring Framework.
6. Despliegue de un Sistema de Gestión de procesos de negocio (BPMS) mediante Intalio BPMS.
7. Modelado de procesos para el proyecto de la Fuerza Aérea Ecuatoriana (FAE) – Reclutamiento y Selección de Aspirantes a Oficiales y Aerotécnicos.
8. La importancia de los Marcos de Gobernabilidad y Arquitectura SOA en un entorno de planificación estratégica.
9. Formación Especializada en Intalio BPMS para la gestión de correlaciones, looping sub-process y timers. 

Pronto pondré a a disposición de la comunidad el material que utilice para realizar las transferencias tecnológicas.

Gracias Hugo por la hospitalidad. Espero que sigamos impulsando la adopción y aplicación de las tecnologías de informacion en nuestros países, enriqueciéndonos con ambas experiencias. Muchos Éxitos!!!

Organizaciones que aprenden - Aprendizaje Organizacional

En los últimos años los avances tecnológicos han sido increíblemente exponenciales, cambiando la vida de las sociedades y sus organizaciones de una forma que nunca pudo ser imaginada, por ejemplo empresas pequeñas pueden irrumpir en diversas áreas y cambiar incluso las sociedades. Este escenario ha generado mayor competencia, mayor complementariedad, mayor globalización, mayor intensidad. Las organizaciones que puedan adaptarse y aprender en este medio tendrán definitivamente mayor éxito.

En este post quise escribir sobre un tema poco abordado “El Aprendizaje Organizacional”. Son pocas las organizaciones que cuentan con políticas claras y consistentes para el aprendizaje organizacional. Es muy común que la organización centren sus esfuerzos en los beneficios de sus productos y servicios, y poco en las estratégicas necesarias para asegurar su adaptación en un medio tan cambiante, exigente y dinámico.

Nuestras sociedades requieren nuevas organizaciones, organizaciones con mayor conocimiento, con mayor capacidad de cambio, flexibilidad y velocidad para responder al cumplimiento de sus objetivos estratégicos, sobre todo en las organizaciones públicas donde generalmente existen grandes retrasos en estas capacidades.

Porque deben existir políticas de aprendizaje organizacional?

1. Las organizaciones que aprenden más rápido son capaces de adaptarse y con ello conseguir una ventaja estratégica y mejor desempeño.
2. Las organizaciones que aprenden son capaces de aprovechar el conocimiento colectivo de su talento humano. Esta capacidad, combinada con la mejora continua de sus procesos, su tecnología, y la gestión del conocimiento, permitirá crear y desarrollar “Superorganizaciones”.
3. Las organizaciones que aprenden mejoran continuamente su desempeño.
4. Las organizaciones que aprenden están más conscientes de sus debilidades y fortalezas. 
5. Las organizaciones que aprenden desarrollan un esfuerzo constante y amplio para que la informacion y el conocimiento fluya, crezca y genere valor.
6. Las organizaciones que aprenden definen el conocimiento como la informacion en acción.

Algunas Recomendaciones

1. Desarrolle un programa de aprendizaje organizacional continuo, que permita que el personal pueda registrar brechas y oportunidades de mejora en su entorno laboral.
2. Promueva mediante políticas que su talento humano pueda capacitarse a través del  aprendizaje autodirigido.
3. Utilice la tecnología para aumentar la velocidad de aprendizaje y la gestión del conocimiento.
4. Desarrolle un Programa Organizacional de medición, mejora y optimización de procesos continuo.

"El aprendizaje en el interior de la organizaciones debe ser igual o superior a los cambios que 

ocurren fuera de la organización o la organización muere”.