lunes, 10 de octubre de 2011

Un ESB, muchos buses.

Basado en el libro, donde se dice que el mejor esquema de integración es aquel basado en mensajería, o al menos es el que mas problemas puede resolver, puedo decir desde mi experiencia personal que es completamente cierto.
Es cierto que cada problema es diferente y en cada situación, las necesidades de integración pueden atacarse de maneras distintas dependiento de la naturaleza del problema, con un esquema basado en mensajería se resuelven la mayoría de los retos que se plantean en una necesidad de integración.
Hoy en día las herramientas para proveer este tiopo de soluciones. Por necesidades laborales, llevo algún tiempo trabajando con la suite de herramientas de IBM y quiero compartir mi experiencia sobre ello.
IBM cuenta principalmente con 3 productos que actuan como ESB.
  • WebSphere ESB el cual es totalmente basado en tecnología Java y esta soportodado (dependiente) en el servidor de aplicacion WAS. Esta es quizas la mejor opción cuando se trata de integrar aplicaciones escritas en el mismo lenguaje(java) y que su esquema de su formato de mensajería este basado en estandares SOAP, WS, XML, y tecnologías relacionadas.

  • WebSphere Message Broker Es el mas apropiado cuando se trata de integrar aplicaciones en tecnologias heterogéneas. Tiene muchas facilidades para convertir mensajes de un formato a otro y convertir tambien protocolos heterogeneos. Es el apropiado para implementar patrones de integración complejos.

  • WebSphere DataPower Es el mas poderoso en cuanto a desempeño se trata. WebSphere DP es un appliance (Hardware) donde se pueden definir transformaciones de XML y tambien conversión de protocolos de comunicación. Dado su alto poder de procesamiento es el preferido cuando se requiere minimizar la latencia adicionando una capa de integración. En general es recomendable implementar patrones simples en esta tecnología.



  • Por fortuna, he tenido la oportunidad de trabajar con las 3 herramientas y es importante saber escoger cual usar en cada momento.
    Espero sea de ayuda la información aca expuesta.

    BPMN 2.0 = Holy Grail?

    El libro BPMN 2.0 de Thomas Allweyer, provee de una concienzuda exploración al estándar BPMN 2.0, su semántica y aplicación en el diseño de procesos de negocio. Luego de la lectura de sus capítulos me quedo una impresión general del poder expresivo de la notación y su semántica. Así mismo, los comentarios de diseño del autor, son en mi opinión enriquecedores, particularmente en lo que respecta a los problemas a los que uno se enfrentara un diseñador durante su uso. Luego de la lectura me inquietaron algunos puntos respecto a BPMN 2.0.

    En primera medida, creo que la notación ofrece un lenguaje visual altamente rico, pero a su vez complejo. En este sentido me cuestiono si al modelar un proceso típico, es empleado todo el abanico de elementos que este ofrece. Por otro lado, un mayor número de elementos de la notación puede finalmente entrar en conflicto con una de sus filosofías, el ser lingua franca para la representación de modelos de negocio. Creo que BPMN 2.0 puede ser de difícil acceso (y comprensión) para el público en general -si uno peca por ser muy detallista en sus modelos, lo cual puede ser muy probable. Lo anterior representa una debilidad en mi opinión, pues toda la responsabilidad en este sentido recae sobre el modelador, pues BPMN 2.0 aporta poco en términos de restricciones sobre el modelaje los procesos de negocio.

    Ahora con respecto a los modelos ejecutables, la semántica de BPMN 2.0 y su potencial expresivo, sin duda es muy alto, pero considero que las notaciones simplificadas como los eventos de inicio y final, así como los gateways implícitos, hacen más complejo entender el detalle del comportamiento de un proceso, pensado para ejecución. En este sentido, entiendo el ánimo de BPMN 2.0 de ofrecer expresiones que son visualmente más simples (y accesibles para quienes es presentado el proceso), pero en mi opinión pueden terminar confundiendo a quien tiene interés en el detalle del proceso y su consistencia.

    domingo, 9 de octubre de 2011

    Patrones de Integración

    Integración en Aplicaciones (Bernarnd y Laurent)



    El libro ilustra y es escrito de manera clara asumiendo un conocimiento inicial básico. Es un libro muy completo, que va más allá de patrones de integración presentando al lector una amplia gama de temas y de comparaciones entre los diferentes estilos, también se proporciona conocimiento y propone  formas de uso de la mensajería para solucionar diferentes problemas de manera efectiva, y proporciona una manera clara por medio de pasos para poder tener éxito en la implantación de las técnicas de integración. Me gusta especialmente la forma en que Bernard y Laurent diseña cada modelo usando el lenguaje y los estilos visuales para delimitar las secciones de forma natural del patrón, esto aumenta significativamente la legibilidad y el entendimiento de la idea de integración.
    El libro es muy independiente de la tecnología, ya que se enfoca más hacia la generalización de la idea, ilustrando las ideas de los patrones y maneras de integración sin tener que ligarse con una tecnología o herramienta, lo que permite una generalización del conocimiento para poder aplicarlo a cualquier tecnología si ésta lo permite.
    El problema por menor que le vi al libro es que eran muy largos sus capítulos,  lo que hacía que me perdiera el hilo, pero en general el lenguaje utilizado era bastante entendible, lo que si puede mejorase es  en ser más concreto y resaltar las características más importantes, ya que se pueden quedar en medio de las frase históricas, preguntas, etc.

    lunes, 12 de septiembre de 2011

    Propuesta de innovación VehiAlpes


    Para esta iteración, la propuesta está encaminada hacia las dos fuerzas de negocio: Venta (v) y Postventa (p). Para cada una  se propone una opción innovadora, con base en una perspectiva de poder, en la cual VehiAlpes asume el control de la información de clientes, ofreciendo beneficios a sus socios.

    Para venta se propone cotización y venta a través de móvil, y para postventa, un portal corporativo CRM ERP, inspirado en el modelo del portal de Audi Colombia, para la propuesta de mecánica prepagada. Los esfuerzos para la implementación y entrega de la solución se encmainarán principalmente en esta alternativa.



    En la entrada después de esta, se modelan algunos procesos usando BPMN.

    Procesos Vehialpes

    Registro de clientes (Pagina web)

    Consulta de clientes

    Garantía de clientes

    lunes, 5 de septiembre de 2011

    Comentarios en la implementación de proyectos BPM.

    El BPM como disciplina de administración ofrece un medio para alcanzar los objetivos estratégicos bajo una visión centrada en los procesos. Al igual que otras disciplinas como la reingeniería de procesos (BPR), la administración de la calidad total (TQM) y Six-Sigma, que tienen un común el mismo propósito, BPM no es el santo grial, pues al igual que las anteriores su implementación en las organizaciones es un problema difícil.

    En principio BPM requiere de procesos funcionales, que puedan ser optimizados. En este sentido BPM potencia la eficiencia solo si ya hay eficacia. Lo anterior representa un aspecto primario a la hora de evaluar la implementación de un proyecto BPM.

    Cuando se tiene alguna certeza de la eficacia de los procesos, el siguiente aspecto se deriva de la pregunta ¿Por dónde empezar? Una causa frecuente de fracasos en las iniciativas BPM, se deriva de no contar con claridad en este punto. Es común sub-dimensionar o sobre-dimensionar el alcance de los proyectos BPM, lo que deriva a percibir un valor no correlacionado con el esfuerzo invertido y el incumplimiento de los objetivos. En este sentido establecer los objetivos de forma clara y realizable dado un presupuesto de recursos es de vital importancia.

    Otro aspecto clave gira alrededor de la gente. La administración del cambio es una parte integral del BPM. La razón está en que son las personas las que finalmente implementan e interactúan con los procesos. Muchos problemas a la hora de aplicar BPM sobre los procesos deriva de la resistencia de la gente al cambio; no importa que tan bien diseñada y alineada es la estrategia del proyecto BPM, si la gente se opone el proyecto finalizará bajo tierra.

    Jeston y Nelis, en observación de la dificultad y complejidad de BPM, proponen un marco (framework) metodológico para la adopción del BPM como disciplina organizacional. Este marco consta de diez fases: Estrategia Organizacional, Arquitectura de procesos, despegue, entendimiento, innovación, personas, desarrollo, implementación, realización de valor y desempeño sostenible. Las anteriores dan en general un tratamiento iterativo a los proyectos BPM, buscando su consolidación en la organización hasta hacer del proceso parte de la rutina organizacional y enfatizando en el mejoramiento continúo como capacidad objetivo.

    En mi opinión, el marco propuesto por Jeston y Nelis, integra la administración del cambio como una parte integral del BPM, pero debería abordarse con mayor profundidad, pues no ofrece una metodología más detallada para construir estrategias en este sentido. Como bien lo indican los autores, la administración del cambio es un proceso transversal a las fases de marco y cuya misión es permitir el avance, en particular en la fase de implementación, en la cual el proceso representa el mayor impacto. Así mismo puntualizan en la importancia de involucrar a los stakeholders que son impactados por el proyecto.

    El involucrar a los stakeholders y empoderar a las personas en la organización son estrategias generales claves en la administración del cambio. Aunque es fácil decir que esto es lo que hay que hacer, en mi experiencia lograr estos puntos es increíblemente difícil y creo que ahí esta una de las debilidades del marco, pues no explica cómo abordar estos problemas. Creo que en este sentido es imperativo entender las posiciones de los stakeholders y las personas en la organización y estimar que implica para estos la realización del proyecto.

    El cambio implica desbalances entre los aportes y las retribuciones que espera cada stakeholder. Ejemplos en los cuales las personas en la organización no sentirán motivación para ayudar al cambio son la inserción de nuevas responsabilidades, el incrementar su exposición al riesgo o simplemente quedar en una posición que a su criterio es desfavorable frente a otros en su mismo nivel. Creo que en un proyecto BPM se debe integrar este tipo de análisis e incluir la negociación como una fase adicional anterior al despegue del proyecto. Lo anterior esta dado por la necesidad de definir y asegurar compensaciones adecuadas y consensuadas frente al impacto derivado del cambio y así lograr la aceptación y participación proactiva (ponerse la camiseta) de los involucrados, mitigando enormemente los riesgos.

    BPMN Method & Style


    Para aprender BPMN en detalle pueden existir muchas formas distintas de lograrlo. Pagar cursos, tomar cursos en la web, comprar libros, buscar manuales, etc. Lo valioso del aporte que se hace en esta lectura es como tomar en cuenta la práctica de alguien quien ya ha sufrido con la implementación y como solucionar y dar un mejor enfoque a esos problemas con los que se puede uno enfrentar día a día.

    Existe un problema grande que se refleja en la perdida de semántica entre un proceso en BPMN y su implementación en un lenguaje de orquestación de procesos como BPEL. Se supone que esto es uno de los problemas que se pretende resolver en la versión 2.0 de la especificación. Personalmente no he tenido oportunidad de verlo en acción pero al menos la promesa de valor es bastante interesante. Existían problemas en la traducción entre un proceso escrito en BPMN y su contraparte en BPEL pero era aún mas fuerte el problema de hacer la conversión a la inversa, en otras palabras, era casi imposible.

    En BPMN 2.0 es posible ejecutar el proceso sin necesidad de hacer una conversión a BPEL, esto lo he visto personalmente a modo de demo en IBM BPM 7.5 que recoge lo mejor del mundo de WebSphere Process Server y WebSphere Lombardi.