martes, 8 de noviembre de 2011
lunes, 7 de noviembre de 2011
DISEÑANDO CON UN PROPOSITO
Los datos son representaciones simples de la vida real. Cuando se visualizan los datos, en realidad se visualiza lo que nos rodea y el mundo en general.
El como se diseñan las graficas afecta la manera como los lectores habran de interpresar la informacion que hay por debajo.
Cada vez que se presente una imagen, por muy clara que esta sea, se debe dar algo de informacion al respecto, puesto que esto ayuda a generar un contexto y hace que el lector entienda mejor la idea expresada. En otras palabras, como diseñadores no podemos asumir que el lector sepa todo lo que queremos expresar con nuestras graficas.
Adicionalmente, un buen manejo del color puede ayudar a dirigir la atencion del lector en el camino correcto (proporcionando un contexto), pero siempre esta la opcion de utilizar tonos neutrales si asi se desea.
Cada vez que se diseña algo, se debe tener en cuenta el publico principal que hara uso de ese algo. Esto es asi, puesto que las desiciones en cuanto a visualizacion de la informacion, los colores, las figuras utilizadas y demas, tendran un significado e impacto diferente segun el publico objetivo. Hay que diseñar y hacer retroalimentacion teniendo en cuenta lo anterior. En ultimas, todo se reduce a la historia que se quiere contar y a quien se le quiere contar.
Cuando se tiene mucha informacion para trabajar en diseño y no se tiene idea por donde empezar, lo mejor que se puede ahcer es preguntarse Que se quiere saber? Que patrones se quieren conseguir? cuales son las relaciones espaciales? con la respuesta a las anteriores preguntas, se puede volver a mirar la informacion que se tiene y saber si se puede hacer algo con ella o si se necesita mas.
El como se diseñan las graficas afecta la manera como los lectores habran de interpresar la informacion que hay por debajo.
Cada vez que se presente una imagen, por muy clara que esta sea, se debe dar algo de informacion al respecto, puesto que esto ayuda a generar un contexto y hace que el lector entienda mejor la idea expresada. En otras palabras, como diseñadores no podemos asumir que el lector sepa todo lo que queremos expresar con nuestras graficas.
Adicionalmente, un buen manejo del color puede ayudar a dirigir la atencion del lector en el camino correcto (proporcionando un contexto), pero siempre esta la opcion de utilizar tonos neutrales si asi se desea.
Cada vez que se diseña algo, se debe tener en cuenta el publico principal que hara uso de ese algo. Esto es asi, puesto que las desiciones en cuanto a visualizacion de la informacion, los colores, las figuras utilizadas y demas, tendran un significado e impacto diferente segun el publico objetivo. Hay que diseñar y hacer retroalimentacion teniendo en cuenta lo anterior. En ultimas, todo se reduce a la historia que se quiere contar y a quien se le quiere contar.
Cuando se tiene mucha informacion para trabajar en diseño y no se tiene idea por donde empezar, lo mejor que se puede ahcer es preguntarse Que se quiere saber? Que patrones se quieren conseguir? cuales son las relaciones espaciales? con la respuesta a las anteriores preguntas, se puede volver a mirar la informacion que se tiene y saber si se puede hacer algo con ella o si se necesita mas.
Patrones de Visualización en el Tiempo
El manejo de datos de series de tiempo es muy común en la actualidad. La generación de estadísticas en temas como cambios en la opinión pública, cambios en la población, y el crecimiento de las empresas, son ejemplos de este tipo de análisis de datos.
Puede observarse este tipo de manejo, para los casos en que se requiere identificar las situaciones que han cambiado en el tiempo. El análisis de los datos discretos y continuos, asociados a tipos de gráficos, son de gran utilidad para estos casos, dado que de acuerdo con el tipo de datos y su comportamiento, es posible identificar tendencias o cambios a través del tiempo.
Identificar lo que se busca en el tiempo:
Puede observarse este tipo de manejo, para los casos en que se requiere identificar las situaciones que han cambiado en el tiempo. El análisis de los datos discretos y continuos, asociados a tipos de gráficos, son de gran utilidad para estos casos, dado que de acuerdo con el tipo de datos y su comportamiento, es posible identificar tendencias o cambios a través del tiempo.
Identificar lo que se busca en el tiempo:
De los aspectos más comunes, analizados en las series de tiempo, o temporales, es la tendencia de los datos. Identificar un aumento o disminución, para encontrar las pautas que permiten profundizar y determinar puntos de datos individuales, con el fin de obtener una imagen completa. Es fácil detectar un único valor de un punto en el tiempo asociándolo a un día, pero si se realiza un análisis más profundo, es posible visualizar los sucesos que se presentaron antes y después, para obtener una mejor comprensión de lo que significa un valor único, y cuanto más sepa acerca de sus datos, se tendrá mayor precisión sobre la historia del mismo.
Adicionalmente, debemos tener en cuenta dentro del análisis:
• Identificar Valores Atípicos
• Identificar periodos del tiempo fuera de lugar.
• Determinar qué sucedió en estos periodos.
• Identificar Picos y caidas.
Los datos temporales se pueden clasificar como discretos o continuos. Saber a qué categoría pertenecen los datos puede ser de gran utilidad para decidir la forma de visualizar la información. En el caso discreto, los valores son los puntos específicos o bloques de tiempo, y hay un número finito de valores posibles. Por ejemplo, el porcentaje de personas que pasan una prueba cada año es discreta. La gente toma la prueba, y eso es todo. Estos resultados no cambian después, y la prueba es tomada en una fecha específica. Algo así como la temperatura, sin embargo, es continua. Se puede medir en cualquier momento del día, durante cualquier intervalo, y está cambiando constantemente.
La exploración de los patrones en el tiempo, está tan arraigada en nuestro día a día que muchos aspectos de la visualización de datos temporales son bastante intuitivos. Entendemos que las cosas cambian y evolucionan, la parte más difícil es averiguar en qué medida y el aprendizaje de lo que se debe buscar en los gráficos.
Es fácil revisar algunas líneas en un gráfico e identificar que algo es cada vez mayor, esta visualización permite obtener rápidamente una visión general de los datos. Pero es posible llegar más lejos, utilizando la visualización como una herramienta de exploración. Aumentar una determinada zona de tiempo y analizar la razón de un cambio en un periodo de tiempo, pero en ningún otro lugar, o por qué se produjo un aumento en un día diferente. Es entonces cuando el comportamiento de los datos es interesante, de modo que se pueda explicar los detalles de los datos gráficos. Resaltando las partes que presentan cambios y que permiten concluir, detallando los puntos específicos que hacen particular el comportamiento, con el objetivo de tener la base de un análisis en profundidad.
Adicionalmente, debemos tener en cuenta dentro del análisis:
• Identificar Valores Atípicos
• Identificar periodos del tiempo fuera de lugar.
• Determinar qué sucedió en estos periodos.
• Identificar Picos y caidas.
Los datos temporales se pueden clasificar como discretos o continuos. Saber a qué categoría pertenecen los datos puede ser de gran utilidad para decidir la forma de visualizar la información. En el caso discreto, los valores son los puntos específicos o bloques de tiempo, y hay un número finito de valores posibles. Por ejemplo, el porcentaje de personas que pasan una prueba cada año es discreta. La gente toma la prueba, y eso es todo. Estos resultados no cambian después, y la prueba es tomada en una fecha específica. Algo así como la temperatura, sin embargo, es continua. Se puede medir en cualquier momento del día, durante cualquier intervalo, y está cambiando constantemente.
La exploración de los patrones en el tiempo, está tan arraigada en nuestro día a día que muchos aspectos de la visualización de datos temporales son bastante intuitivos. Entendemos que las cosas cambian y evolucionan, la parte más difícil es averiguar en qué medida y el aprendizaje de lo que se debe buscar en los gráficos.
Es fácil revisar algunas líneas en un gráfico e identificar que algo es cada vez mayor, esta visualización permite obtener rápidamente una visión general de los datos. Pero es posible llegar más lejos, utilizando la visualización como una herramienta de exploración. Aumentar una determinada zona de tiempo y analizar la razón de un cambio en un periodo de tiempo, pero en ningún otro lugar, o por qué se produjo un aumento en un día diferente. Es entonces cuando el comportamiento de los datos es interesante, de modo que se pueda explicar los detalles de los datos gráficos. Resaltando las partes que presentan cambios y que permiten concluir, detallando los puntos específicos que hacen particular el comportamiento, con el objetivo de tener la base de un análisis en profundidad.
Resumen del capítulo 1 del libro Visualize This - Nathan Yau
El autor enuncia en este capítulo diferentes consejos que debemos tener en cuenta a la hora de elaborar gráficos de representación de la información de manera adecuada.
El primer aspecto a tener en cuenta es que el compendio de información (que normalmente tiende a ser numérica) nos cuenta una historia o un comportamiento en particular. Hay diversas metas que se persiguen con la visualización de la información, los cuales pueden ser:
- Lograr un mayor entendimiento de la información a través del resaltamiento de los aspectos más importantes a mostrar, lo mismo que el uso de diferentes colores pueden lograr la distinción de diferentes partes de la información.
- En algunos casos, se requiere hacer atractiva la importancia de los datos más que los datos en sí, por lo que se recurre a elementos visuales para lograr ese plasmar esta idea en el espectador (como por ejemplo un gráfico de burbujas que muestre el crecimiento de los usuarios de internet en los departamentos o estados de un país).
- No siempre los datos se requieren visualizar de una forma en particular con motivos estrictamente relacionados con actividades de negocio, sino para también mostrar tendencias de la vida diaria (por ejemplo, un gráfico de barras que muestra el aumento de la cantidad de fanáticos de videojuegos en los últimos 10 años).
- Hay casos en los que la visualización estadística de la información se usa para mostrar el impacto que un evento causa en un entorno para lograr generar reacción entre las personas, como por ejemplo, hacer uso de gráficos comparativos de emisiones de gases contra cambios en temperatura combinados con el uso de fotos reales de descongelamiento en zonas donde anteriormente había demasiado hielo, con el propósito de mostrar el impacto causado por el efecto del calentamiento global.
El segundo aspecto tiene que ver con que queremos lograr que los espectadores encuentren cuando queremos mostrar gráficamente un conjunto de datos. En este caso, pueden ser diferentes elementos, los cuales pueden ser:
- Patrones y/o tendencias: Se busca en el elemento visual las zonas donde hay cambios graduales o repentinos. En algunos casos, resulta util determinar si se requiere mas especificidad o genericidad en los gráficos para poder detectar estos elementos, por ejemplo, el comparativo de uso de tráfico de red en una empresa en un dia (separado por horas), en una semana (separado por dias), o en un mes (separado en dias o semanas).
- Relaciones: Se pueden usar los gráficos para establecer comparaciones o contrastes de un fenómeno que se desea analizar.
- Datos cuestionables: Se busca elementos muy "disonantes" cuando se va construyendo el gráfico. Al encontrar estos elementos, se puede determinar si estos datos son confiables o no. Al hacer esta depuración, el gráfico terminará siendo más consistente con respecto a lo que se quiere reflejar.
El tercer aspecto a tener en cuenta tiene que ver con el diseño. Este también, se puede dividir en diferentes factores:
- La codificación: Este aspecto tiene que ver con el significado del uso de elementos usados en el gráfico como la opacidad de un color, o el significado de diferentes colores, o el significado de algún símbolo utilizado. Si no se clarifica la simbología utilizada, resulta ser confuso comprender lo que se pretender visualizar a través del gráfico.
- Ejes de coordenadas: Los ejes de coordenadas tienen que tener las etiquetas que indiquen qué es lo que se pretende delimitar (longitud, area, volumen, cantidad, etc) de lo contrario resultará incomprensible entender las variables tenidas en cuenta para visualizar y comparar la información .
- Verificar la geometría de las figuras utilizadas teniendo en cuenta aspectos como la proporcionalidad (facilita mucho la estimación del valor representado si se hace uso adecuado), y las reglas del tipo de gráfico (como por ejemplo, en un gráfico de torta la suma de todos los porcentajes debe ser igual a 100% o el gráfico queda mal construido).
- La inclusión de las fuentes de donde se obtiene la información: Esto añade total credibilidad a los datos que son visualizados, si no se incluye los usuarios del gráfico dudarán de la confiabilidad de la información.
- De acuerdo al tipo de audiencia, seleccionar el mejor tipo de gráfico. Gráficos extremadamente detallados para una presentación corta puede ser contraproducente, pero puede ser muy util cuando se desean mostrar los resultados de un estudio detallado de algún fenómeno.
Y por último, el autor recomienda siempre en todo gráfico que se vaya a realizar formular la pregunta que intenta resolver el gráfico, realizar una investigación previa del tema, y finalmente, aclarar el propósito del gráfico y el público al que va a estar dirigido.
martes, 1 de noviembre de 2011
lunes, 31 de octubre de 2011
Servicio de Refactoring
Problema
Después de su primera entrega, el rendimiento de imprevistos y los requisitos empresariales pueden demandar más de un servicio de lo que es capaz de proporcionar. Reemplazar el servicio completo puede no ser deseable, especialmente cuando varios programas tienen alrededor dependencias ya establecidas en su contrato de servicios establecidos.
Solución
Refactoring de software es una práctica de ingeniería de software por la cual el software existente puede ser mejorado gradualmente sin afectar la forma en que se
se comporta. Cuando se aplica al diseño de servicios, este enfoque ofrece más oportunidades para los servicios para evolucionar dentro de una organización sin interrumpir a sus consumidores existentes. Con la aplicación de este modelo la lógica y la aplicación de un servicio puede ser optimizado con regularidad, mejora, o incluso mejorado, mientras que se conserva el contrato de servicio.
Aplicación
La práctica de software Refactoring permitir que los programas se mejoren a través de una serie de pequeñas mejoras que se siguen para preservar sus interfaces y comportamiento en general. Al limitar el ámbito de aplicación de estas mejoras, el riesgo asociado a un impacto negativo en los consumidores se minimiza.
Impacto
El Refactoring de la lógica de servicio existente o de la tecnología introduce la necesidad que el servicio que experimenta cambios de diseño, remodelación, y los ciclos de repetición de pruebas a fin de asegurar que la actual
garantía expresadas en el contrato de servicios (que incluye SOA) puede seguir siendo cumplido como se esperaba.
Relaciones
La medida en que se puede aplicar el servicio de Refactoring depende de cómo el servicio en sí mismo fue diseñado en primer lugar. Es por eso que existe una relación directa entre este modelo y el Servicio Normalización.
La abstracción y la independencia obtenida por la aplicación exitosa de los patrones permite que los servicios de forma individual gobernado y evolucionado con el mínimo impacto los programas de los consumidor
Patrones de composición de capacidades
Estos patrones establecen posibles mecanismos que permitan ensamblar y/o componer la lógica de servicio debidamente estructurada a través del uso de los patrones de identificación y definición de servicios.
A continuación, se enuncian los 2 patrones representativos de composición:
1. Composición de capacidades: Cuando se requiere ofrecer una capacidad que requiere del uso de lógica que procede de otro contexto funcional, se crea un servicio capaz de invocar una o más capacidades que son ofrecidas por otros servicios para suplir la necesidad.
Las ventajas que ofrece es la reutilización de servicios en diferentes contextos, aparte de la reducción de esfuerzos de programación. El principal inconveniente es la pérdida de autonomía del servicio (pues requiere de la disponibilidad de otros servicios), seguido de la sobrecarga del sistema (al tener que usar invocación externa).
2. Recomposición de capacidades: El objetivo principal es maximizar el reuso de servicios independientes para estructurar la solución de diferentes problemas de negocio. Esto es posible a través del establecimiento de capacidades genéricas de servicio, las cuales se satisfacen mediante la invocación secuencial de un conjunto limitado de servicios.
Notificación de terminación
Problema
Como los servicios evolucionan con el tiempo, las diversas condiciones y circunstancias que pueden conducir a la necesidad de retirar un contrato de servicios, una parte de un contrato de servicio, o la totalidad del servicio en sí.
En las empresas de TI más grandes especialmente al hacer los servicios accesibles a las organizaciones externas asociadas, puede ser difícil de comunicar a los consumer owners en espera de la terminación de un servicio o cualquier parte de su contrato de manera oportuna.
Falta de reconocimiento de un retiro previsto conducirá inevitablemente a situaciones de error en tiempo de ejecución, donde los programas de los consumidores desconocen que tratan de invocar el servicio y son rechazados.
Solución
Los contratos de servicio están equipados con detalles de terminación, permitiendo a los consumidores estar al corriente del retiro anticipado del contrato
Aplicación
Este patrón es comúnmente aplicado para complementar el contenido del contrato técnico con anotaciones legibles que simplemente proporcionar la fecha de terminación. Sin embargo, para los Contratos de servicios web, también existe la opción de aprovechar el lenguaje WS-Policy para expresar las notificaciones de terminación a través de las afirmaciones de la política ignorable.
Impacto
Todas las técnicas explicadas requieren el uso de extensión no-estándar de contenido de los contratos de servicio. Esto se debe a que no existe un estándar de la industria para expresar la información de finalización. Notificación de la terminación depende de la existencia y la aplicación exitosa de los estándares de gobierno y por lo tanto tiene una dependencia directa en versiones canónicas
Relaciones
Tanto el cambio Compatible y Capacidad de Proxy pueden conducir la necesidad de la notificación de terminación.
Algunos patrones SOA
PROXY CAPABILITY
Cómo puede un servicio sujeto a la descomposición, continuar soportando a los clientes afectados por la descomposición?
PROBLEMA.
Si un servicio establecido necesita ser descompuesto en múltiples servicios, su contrato y sus clientes existentes pueden ser impactados.
SOLUCION
El contrato del servicio original se preserva, incluso si la capacidad lógica es separada al volver la capacidad establecida un proxy.
APLICACIÓN
Las lógicas de fachada necesitan ser introducidas para redirigir las peticiones y respuestas entre el proxy y las nuevas capacidades localizadas.
IMPACTO
La solución practica proporcionada por este patrón resulta en la medida de la des normalización del servicio.
PRINCIPIO
Service Loose Coupling
ARQUITECTURA
Servicio.
CAPACIDAD DESCOMPUESTA
Cómo puede un servicio ser asignado para minimizar las posibilidades de desconstrucción de capacidades lógicas?
PROBLEMA
La descomposición de un servicio para con su implementación puede requerir la descomposición de la lógica en sus capacidades, las cuales pueden ser disruptivas y hacer que la preservación del contrato del servicio sea problemática.
SOLUCION
Los servicios con tendencia a la descomposición futura pueden ser equipados con una serie de capacidades granulares que pueden hacer mas fácil la descomposición.
APLICACIÓN
Servicios adicionales de modelado son llevados a utilizados para la definición granular, haciendo posible la capacidades distribuidas.
IMPACTO
Hasta que el servicio ha sido eventualmente descompuesto, puede ser presentado por un contrato extremamente cargado que permanece con el siempre y cuando las capacidades del proxy sean soportadas.
PRINCIPIOS
Contratos de servicio estandarizados, Abstracción de servicios.
ARUITECTURA
Servicios.
CAPACIDADES DISTRIBUIDAS
Cómo puede un servicio preservar su contexto funcional mientras también cumple con capacidades de procesamiento de requerimientos especiales?
PROBLEMA
Una capacidad que pertenece a la zona interna de un servicio puede requerir requerimientos de procesamiento únicos que no pueden ser acomodados por él la implementación por defecto del servicio, pero separando la capacidad lógica del servicio comprometerá la integridad del contexto del servicio.
SOLUCION
La lógica que está por debajo del servicio está distribuida, por tanto esto permite que la implementación lógica de una capacidad con requerimientos especiales de procesamiento pueda estar separada físicamente, mientras sigue siendo representada por el mismo contrato de servicio.
APLICACIÓN
Se mueve la lógica y se añade el proceso intermedio para actuar en llave ente la lógica que se ha movido y la lógica principal del servicio.
IMPACTO
La distribución de la lógica de las capacidades conlleva a una saturación del rendimiento asociado con la comunicación remota y la necesidad para un nuevo proceso intermedio.
PRINCIPIOS
Servicios de contrato estandarizados. Autonomía de Servicios.
Cómo puede un servicio sujeto a la descomposición, continuar soportando a los clientes afectados por la descomposición?
PROBLEMA.
Si un servicio establecido necesita ser descompuesto en múltiples servicios, su contrato y sus clientes existentes pueden ser impactados.
SOLUCION
El contrato del servicio original se preserva, incluso si la capacidad lógica es separada al volver la capacidad establecida un proxy.
APLICACIÓN
Las lógicas de fachada necesitan ser introducidas para redirigir las peticiones y respuestas entre el proxy y las nuevas capacidades localizadas.
IMPACTO
La solución practica proporcionada por este patrón resulta en la medida de la des normalización del servicio.
PRINCIPIO
Service Loose Coupling
ARQUITECTURA
Servicio.
CAPACIDAD DESCOMPUESTA
Cómo puede un servicio ser asignado para minimizar las posibilidades de desconstrucción de capacidades lógicas?
PROBLEMA
La descomposición de un servicio para con su implementación puede requerir la descomposición de la lógica en sus capacidades, las cuales pueden ser disruptivas y hacer que la preservación del contrato del servicio sea problemática.
SOLUCION
Los servicios con tendencia a la descomposición futura pueden ser equipados con una serie de capacidades granulares que pueden hacer mas fácil la descomposición.
APLICACIÓN
Servicios adicionales de modelado son llevados a utilizados para la definición granular, haciendo posible la capacidades distribuidas.
IMPACTO
Hasta que el servicio ha sido eventualmente descompuesto, puede ser presentado por un contrato extremamente cargado que permanece con el siempre y cuando las capacidades del proxy sean soportadas.
PRINCIPIOS
Contratos de servicio estandarizados, Abstracción de servicios.
ARUITECTURA
Servicios.
CAPACIDADES DISTRIBUIDAS
Cómo puede un servicio preservar su contexto funcional mientras también cumple con capacidades de procesamiento de requerimientos especiales?
PROBLEMA
Una capacidad que pertenece a la zona interna de un servicio puede requerir requerimientos de procesamiento únicos que no pueden ser acomodados por él la implementación por defecto del servicio, pero separando la capacidad lógica del servicio comprometerá la integridad del contexto del servicio.
SOLUCION
La lógica que está por debajo del servicio está distribuida, por tanto esto permite que la implementación lógica de una capacidad con requerimientos especiales de procesamiento pueda estar separada físicamente, mientras sigue siendo representada por el mismo contrato de servicio.
APLICACIÓN
Se mueve la lógica y se añade el proceso intermedio para actuar en llave ente la lógica que se ha movido y la lógica principal del servicio.
IMPACTO
La distribución de la lógica de las capacidades conlleva a una saturación del rendimiento asociado con la comunicación remota y la necesidad para un nuevo proceso intermedio.
PRINCIPIOS
Servicios de contrato estandarizados. Autonomía de Servicios.
Patrón de Identificación de Versión
Este patrón hace referencia a la forma en que los consumidores pueden estar notificados de las actualizaciones de versión del contrato de servicio.
Problema
Solución
Problema
Si un contrato, que por lo general ya ha sido publicado, está sujeto a la compatibilidad o a cambios incompatibles, cualquier modificación a su contenido, justifica una nueva versión del contrato. Sin un medio de asociación entre versiones que han generado cambios que afectan la compatibilidad entre un servicio y sus consumidores actuales y nuevos, se genera un riesgo permanente, dado que el servicio se vuelve menos detectable a los diseñadores de los consumidores, de modo que el diseño del servicio incrementa la dificultad para su gobernabilidad y evolución.
Solución
El contrato de servicio puede ser diseñado para expresar los identificadores de versión, que permite al consumidor determinar con seguridad si se trata de una versión compatible con el servicio. El uso de los identificadores de versión apoya aún más, la simultaneidad de contratos a fin de manejar el control de versiones, lo que permite a un consumidor elegir el contrato correcto, basado en su versión expresa.
Aplicación
Las versiones se suelen identificar de forma numérica, a través de valores que se incorporan al contrato de servicio, ya sea como anotaciones legibles o como una extensión efectiva de la operación técnica de contenido. La versión más común es a través del formato numérico con decimal, donde el primer dígito representa el número de versión principal, y los dígitos siguientes al punto decimal representan menores números de versión.
El significado de los números de versión realmente depende de los convenios celebrados por una estrategia global de versiones. A continuación se relacionan dos enfoques comunes:
• La cantidad de trabajo: Los números de versión mayor y menor se utilizan para indicar la cantidad de esfuerzo requerido en cada cambio. El incremento de un número mayor representa una cantidad importante de trabajo, mientras que el menor aumento de los números de versión representan mejoras de menor importancia.
• Garantía de compatibilidad: Números de versión mayor y menor se utilizan para expresar compatibilidad. El sistema más común se basa en que un aumento en el número de versión principal se traducirá en un contrato que no es compatible con versiones anteriores, mientras que los incrementos en el número de versión menor son compatibles con versiones anteriores. Como resultado de ello, no se espera que los incrementos de versión secundaria afecten a los consumidores existentes.
El significado de los números de versión realmente depende de los convenios celebrados por una estrategia global de versiones. A continuación se relacionan dos enfoques comunes:
• La cantidad de trabajo: Los números de versión mayor y menor se utilizan para indicar la cantidad de esfuerzo requerido en cada cambio. El incremento de un número mayor representa una cantidad importante de trabajo, mientras que el menor aumento de los números de versión representan mejoras de menor importancia.
• Garantía de compatibilidad: Números de versión mayor y menor se utilizan para expresar compatibilidad. El sistema más común se basa en que un aumento en el número de versión principal se traducirá en un contrato que no es compatible con versiones anteriores, mientras que los incrementos en el número de versión menor son compatibles con versiones anteriores. Como resultado de ello, no se espera que los incrementos de versión secundaria afecten a los consumidores existentes.
Se debe tener en cuenta que estos dos sistemas de identificación pueden ser combinados de manera que el número de versión incremental continúe indicando los cambios compatibles o incompatibles, al tiempo que representa la cantidad de trabajo que entró en los cambios.
Impacto
Los sistemas de identificación de versión y las convenciones suelen ser específicos para un inventario de servicios determinado y por lo general parte de una estrategia de versiones estandarizadas, según versiones canónicas. Como resultado, ellos no están estandarizados a nivel de la industria y por lo tanto, cuando se expresadan como parte del contrato técnico, imponen la necesidad constante de diseñar el servicio para que los consumidores puedan comprender el significado de los identificadores de versión y la programación de quienes consumen, según se requiera.
Cuando los servicios están expuestos a nuevos consumidores o a nivel externo, aplican los mismos requisitos, pero la aplicación necesaria de las normas puede ser más difícil de lograr.
Cuando los servicios están expuestos a nuevos consumidores o a nivel externo, aplican los mismos requisitos, pero la aplicación necesaria de las normas puede ser más difícil de lograr.
Relaciones
Este patrón se aplica comúnmente como resultado del manejo de Versiones canónicas, y contempla una parte esencial en el proceso de generar un Cambio Compatible. La identificación de la versión hace referencia principalmente a otros modelos de contrato de control de versiones.
Este patrón se aplica comúnmente como resultado del manejo de Versiones canónicas, y contempla una parte esencial en el proceso de generar un Cambio Compatible. La identificación de la versión hace referencia principalmente a otros modelos de contrato de control de versiones.
Patrón de Cambio Compatible
Este patrón hace referencia a la forma de modificar un contrato de servicio sin impactar a los consumidores.
Problema
Después de la implementación inicial de un servicio que hace parte de un inventario de servicio activo, sus capacidades estarán disponibles como un recurso de empresa. Por lo tanto, los consumidores estarán habilitados para invocar e interactuar con el servicio a través de su contrato con el fin de aprovechar sus capacidades a través de su consumo.
Como resultado, se genera dependencia de forma natural, entre el contrato de servicio y los programas para el consumidor. Si se requiere efectuar modificaciones al contrato, el cambio puede generar el riesgo de afectar a los consumidores existentes que fueron diseñados de acuerdo con un modelo original.
Como resultado, se genera dependencia de forma natural, entre el contrato de servicio y los programas para el consumidor. Si se requiere efectuar modificaciones al contrato, el cambio puede generar el riesgo de afectar a los consumidores existentes que fueron diseñados de acuerdo con un modelo original.
Solución
Siempre que sea posible, los cambios a los contratos de servicios establecidos deben asegurar la compatibilidad con las versiones anteriores de los contratos y con los consumidores actuales. Esto permite que el contrato de servicio pueda evolucionar de acuerdo con las necesidades, evitando el impacto negativo en las composiciones y dependencias de los programas para el consumidor.
Aplicación
Hay una variedad de técnicas mediante las cuales se puede aplicar este modelo, en función de la naturaleza del cambio requerido en el contrato. El propósito fundamental de este modelo es evitar tener que imponer cambios incompatibles de un contrato de servicios con las versiones anteriores, de las que dependen sus consumidores.
A continuación se mencionan los cambios que en general se requieren para los contratos de servicios Web y que pueden requerir compatibilidad con versiones anteriores:
• Adición de una nueva operación para una definición de WSDL
• Cambiar el nombre de una operación existente
• Extracción de una operación existente
• Cambio del MEP de una operación existente
• Adición de un mensaje de error a una operación ya existente
• Adición de un Nuevo tipo de puerto
• Adición de un elemento de mensaje nuevo esquema o atributos
• Eliminación de un elemento de mensaje de esquemas existentes o atributo
• La modificación de la restricción de un esquema de mensaje
• Adición de una nueva política
• Adición de afirmaciones políticas
• Adición de afirmaciones ignorable Política
A continuación se mencionan los cambios que en general se requieren para los contratos de servicios Web y que pueden requerir compatibilidad con versiones anteriores:
• Adición de una nueva operación para una definición de WSDL
• Cambiar el nombre de una operación existente
• Extracción de una operación existente
• Cambio del MEP de una operación existente
• Adición de un mensaje de error a una operación ya existente
• Adición de un Nuevo tipo de puerto
• Adición de un elemento de mensaje nuevo esquema o atributos
• Eliminación de un elemento de mensaje de esquemas existentes o atributo
• La modificación de la restricción de un esquema de mensaje
• Adición de una nueva política
• Adición de afirmaciones políticas
• Adición de afirmaciones ignorable Política
Impacto
Cada vez que un contrato de servicio ya publicado cambia de versión, se requiere un esfuerzo adicional, para asegurar que el cambio se representa como una nueva versión del contrato, que ha sido debidamente expresado y comunicado a los consumidores actuales y futuros.
Este patrón puede eventualmente transformarse en contratos robustos que son más difíciles de mantener. Además, estas técnicas a menudo conducen a la necesidad de una notificación de terminación, lo que puede aumentar tanto el contenido del contrato y mayor trabajo para el gobierno del servicio.
Este patrón puede eventualmente transformarse en contratos robustos que son más difíciles de mantener. Además, estas técnicas a menudo conducen a la necesidad de una notificación de terminación, lo que puede aumentar tanto el contenido del contrato y mayor trabajo para el gobierno del servicio.
Relaciones
Para aplicar este patrón consistentemente a través de múltiples servicios, se requiere la presencia de un sistema de versiones oficiales, que esté muy bien estandarizado de acuerdo con las versiones canónicas. Adicionalmente, este modelo depende de la identificación de la versión, con el fin de asegurar que los cambios estén bien expresados y podrán exigir la notificación de terminación para una transición de contenido del contrato, informando a los consumidores de las nuevas versiones.
lunes, 24 de octubre de 2011
Ecosistema de servicios planeados y diagrama proceso bpel montado versión inicial
A continuación se provee el link con el archivo excel que contiene la especificación de servicios que se tienen planeados para implementar el proceso que hace uso del patrón propuesto. Se recomienda descargar el archivo en vez de usar el visor integrado, ya que en el visor no aparecen todas las columnas.
Vínculo archivo de ecosistema de servicios
A continuación se muestra el diagrama BPEL inicial del proceso que aplica el patrón propuesto, ya aplicado en el caso de VehiAlpes. En este caso, el proceso funciona para recibir inserciones/actualizaciones de clientes que compran un vehículo o que van a recibir servicios de mantenimiento provenientes de un taller.
Se muestran algunos de los servicios web definidos que se tienen que invocar (estan presentes todos los relacionados con el manejo de Clientes).
Vínculo archivo de ecosistema de servicios
A continuación se muestra el diagrama BPEL inicial del proceso que aplica el patrón propuesto, ya aplicado en el caso de VehiAlpes. En este caso, el proceso funciona para recibir inserciones/actualizaciones de clientes que compran un vehículo o que van a recibir servicios de mantenimiento provenientes de un taller.
Se muestran algunos de los servicios web definidos que se tienen que invocar (estan presentes todos los relacionados con el manejo de Clientes).
MODELADO ORIENTADO A SERVICIOS
Un modelo de diseño de software no hace referencia solamente a la definición clara de un direccionamiento que permita identificar la solución a los requerimientos actuales de una organización. Este modelo debe abarcar requerimientos de negocio, ambientes tecnológicos y estrategias de negocio, que pueden ser concebidas como premisas no negociables, de modo que el modelo pueda ofrecer herramientas y mecanismos que permitan establecer comunicación entre los servicios y sus correspondientes consumidores, generando un ecosistema correctamente coordinado.
Modelo General de Diseño Lógico Orientado a Servicio
Es el modelo enfocado en resolver un problema que se presenta en la organización. Utilizando para ello una estrategia y una ruta de acción que provee perspectivas que permiten visualizar los diferentes aspectos concernientes a la solución propuesta, ofreciendo artefactos tangibles para una implementación orientada a servicio.
Relación de Diseño Lógico Orientado a Servicio
Las relaciones con consumidores y servicios son influenciados principalmente, por requerimientos tecnológicos y de negocio que implican interacción de colaboración e intercambio de mensajes.
Conceptos que aportan a la estrategia de relación del diseño lógico orientado a servicios:
1. Aislamiento del servicio
2. Conocimiento compartido
3. Propagación del mensaje
4. Mensaje de autorización y autenticación
5. Contrato de servicio
6. Intermediarios y mediación.
MÉTODOS DE RELACIONES DE DISEÑO
Estructura de Composición de Diseño Lógico Orientado a Servicio
La composición de diseño lógico orientado a servicio es un paquete de software que, generalmente es modelado por patrones predefinidos.
Elementos de la composición de diseño orientada a servicios: Bloques de construcción, Elementos de Soporte y estrategias de diseño.
Estilos de Composición de Diseño orientado a Servicios: Estilo de composición de diseño circular, Estilo de Composición Jerárquico, Estilo de composición de diseño de Red, Estilo de composición de Diseño estrella.
Estrategias de Composición de Diseño Lógico: Estrategia de Reusabilidad, Estrategia de distribución de servicio y pérdida de acomplamiento, Estrategia de alineamiento de granularidad de diseño lógico y Estrategia de Interoperabilidad de Diseño Lógico.
martes, 18 de octubre de 2011
Patrones SOA
Para la construcción de aplicaciones orientadas a servicios que utilizan Arquitecturas SOA, se han desarrollado patrones clasificados bajo las siguientes categorías:
Los patrones fundamentales de inventario
Inventario de la empresa (ERL)
Cómo puede la exposición de los servicios maximizar recomposición dentro de la organización.
Inventario de dominio (ERL)
Cómo puede la exposición de los servicios maximizar la recomposición en toda la empresa cuando no es posible la normalización.
Servicio de Normalización (ERL)
Cómo puede un inventario de servicios evitar la lógica de servicio redundante.
Lógica de centralización (ERL)
Cómo evitar el mal uso de la lógica de servicio redundante.
Servicio de Capas (ERL)
Cómo crear un inventario de servicios, organizado sobre la base de similitud funcional
Canónica Protocolo (ERL)
Cómo evitar protocolo puente mediante los servicios.
Canónica de esquema (ERL)
Cómo evitar la transformación de los datos del modelo mediante los servicios.
Patrones de la capa de lógica de inventario
Utilidad de la abstracción (ERL)
Cómo unificar los conceptos de negocio comunes y la lógica de negocio centralizada que debe funcionar de forma separada, debe ser reutilizable, y debe regirse de forma independiente.
Entidad de abstracción (ERL)
Cómo puede la lógica de negocio independiente ser dividida, reutilizable, y regirse de forma independiente.
Proceso de abstracción (ERL)
Cómo puede la lógica de los procesos agnósticos ser separada y gobernada de forma independiente.
Patrones de inventario de centralización
Proceso de centralización (ERL)
Cómo se puede gobernar de forma centralizada la lógica de procesos abstraida.
Esquema de centralización (ERL)
Cómo diseñar contratos para evitar la representación redundante de los datos.
La centralización política (ERL)
Cómo se pueden normalizar las políticas y ser aplicadas consistentemente a través de múltiples servicios.
Reglas de centralización (ERL)
Cómo se pueden abstraer las reglas de negocio para ser regidas de forma centralizada.
Patrones de inventario de la aplicación
Protocolos Dual (ERL)
Cómo puede un inventario de servicios superar las limitaciones de su protocolo canónico sin dejar de ser estandarizadas.
Recursos canónicos (ERL)
Cómo se puede evitar la disparidad de recursos innecesarios de infraestructura.
Estado del repositorio (ERL)
Cómo pueden los datos de estado de servicio ser persistidos por periodos, sin consumir recursos de servicio en tiempo de ejecución.
De estado de Servicios (ERL)
Cómo se pueden conservar los datos del estado del servicio y ser manejados sin consumo de recursos en tiempo de ejecución.
Grid Service (Chappell)
Cómo se puede aplazar los datos del estado de servicio para permitir escalar y mantenerse tolerante a fallos.
Inventario de puntos finales (ERL)
Cómo puede un inventario de servicios estar protegido contra el acceso externo y a la vez ofrecer capacidades de servicio a los consumidores externos.
Utilidad de capas de Dominio Cruzado (ERL)
Cómo puede la lógica de utilidad redundante evitarse a través de los inventarios de servicio de dominio.
Patrones de inventario de Gobierno
La expresión canónica (ERL)
Cómo pueden los contratos de servicios permitir la comprensión e interpretación de manera consistente.
La centralización de metadatos (ERL)
Cómo pueden los servicios de metadatos ser centralizdos y gobernados de manera pública.
Versiones canónicas (ERL)
Cómo pueden los contratos de servicio dentro del mismo inventario de servicio ser versionados con un impacto mínimo.
Los patrones fundamentales de servicio
Descomposición Funcional (ERL)
Cómo puede un problema empresarial de orden mayor, ser resuelto sin tener que crear un órgano independiente de la lógica de la solución.
Servicio de encapsulación (ERL)
Cómo puede la lógica de solución estar disponible, como un recurso de la empresa.
Agnóstico de contexto (ERL)
Cómo puede la lógica de servicios múltiples posicionarse como un recurso eficaz de la empresa.
No agnóstico Contexto (ERL)
Cómo puede una sola función lógica de servicio posicionarse como un recurso eficaz de la empresa.
Agnóstico Capacidad (ERL)
Cómo generar la lógica de múltiples servicios de forma efectiva consumible y compuesta.
Servicio de patrones de implementación
Servicio de Fachada (ERL)
Cómo puede un servicio adaptarse a los cambios de su contrato, al tiempo que permite la ejecución del servicio básico y la lógica para evolucionar de forma independiente.
Implementación redundante (ERL)
Cómo incremetar la fiabilidad y la disponibilidad de un servicio.
Servicio de replicación de datos (ERL)
Cómo puede ser preservada la autonomía de servicios, cuando los servicios necesitan tener acceso a orígenes de datos compartidos.
El aplazamiento parcial del Estado (ERL)
Cómo pueden los servicios ser diseñados para optimizar el consumo de recursos mientras que aún permanecen con estado.
La validación parcial (Orchard, Riley)
Cómo evitar hacer validación innecesaria de datos.
Mediador de interfaz de usuario (Utschig, Maier, Trops, Normann, Winterberg)
Los patrones fundamentales de inventario
Inventario de la empresa (ERL)
Cómo puede la exposición de los servicios maximizar recomposición dentro de la organización.
Inventario de dominio (ERL)
Cómo puede la exposición de los servicios maximizar la recomposición en toda la empresa cuando no es posible la normalización.
Servicio de Normalización (ERL)
Cómo puede un inventario de servicios evitar la lógica de servicio redundante.
Lógica de centralización (ERL)
Cómo evitar el mal uso de la lógica de servicio redundante.
Servicio de Capas (ERL)
Cómo crear un inventario de servicios, organizado sobre la base de similitud funcional
Canónica Protocolo (ERL)
Cómo evitar protocolo puente mediante los servicios.
Canónica de esquema (ERL)
Cómo evitar la transformación de los datos del modelo mediante los servicios.
Patrones de la capa de lógica de inventario
Utilidad de la abstracción (ERL)
Cómo unificar los conceptos de negocio comunes y la lógica de negocio centralizada que debe funcionar de forma separada, debe ser reutilizable, y debe regirse de forma independiente.
Entidad de abstracción (ERL)
Cómo puede la lógica de negocio independiente ser dividida, reutilizable, y regirse de forma independiente.
Proceso de abstracción (ERL)
Cómo puede la lógica de los procesos agnósticos ser separada y gobernada de forma independiente.
Patrones de inventario de centralización
Proceso de centralización (ERL)
Cómo se puede gobernar de forma centralizada la lógica de procesos abstraida.
Esquema de centralización (ERL)
Cómo diseñar contratos para evitar la representación redundante de los datos.
La centralización política (ERL)
Cómo se pueden normalizar las políticas y ser aplicadas consistentemente a través de múltiples servicios.
Reglas de centralización (ERL)
Cómo se pueden abstraer las reglas de negocio para ser regidas de forma centralizada.
Patrones de inventario de la aplicación
Protocolos Dual (ERL)
Cómo puede un inventario de servicios superar las limitaciones de su protocolo canónico sin dejar de ser estandarizadas.
Recursos canónicos (ERL)
Cómo se puede evitar la disparidad de recursos innecesarios de infraestructura.
Estado del repositorio (ERL)
Cómo pueden los datos de estado de servicio ser persistidos por periodos, sin consumir recursos de servicio en tiempo de ejecución.
De estado de Servicios (ERL)
Cómo se pueden conservar los datos del estado del servicio y ser manejados sin consumo de recursos en tiempo de ejecución.
Grid Service (Chappell)
Cómo se puede aplazar los datos del estado de servicio para permitir escalar y mantenerse tolerante a fallos.
Inventario de puntos finales (ERL)
Cómo puede un inventario de servicios estar protegido contra el acceso externo y a la vez ofrecer capacidades de servicio a los consumidores externos.
Utilidad de capas de Dominio Cruzado (ERL)
Cómo puede la lógica de utilidad redundante evitarse a través de los inventarios de servicio de dominio.
Patrones de inventario de Gobierno
La expresión canónica (ERL)
Cómo pueden los contratos de servicios permitir la comprensión e interpretación de manera consistente.
La centralización de metadatos (ERL)
Cómo pueden los servicios de metadatos ser centralizdos y gobernados de manera pública.
Versiones canónicas (ERL)
Cómo pueden los contratos de servicio dentro del mismo inventario de servicio ser versionados con un impacto mínimo.
Los patrones fundamentales de servicio
Descomposición Funcional (ERL)
Cómo puede un problema empresarial de orden mayor, ser resuelto sin tener que crear un órgano independiente de la lógica de la solución.
Servicio de encapsulación (ERL)
Cómo puede la lógica de solución estar disponible, como un recurso de la empresa.
Agnóstico de contexto (ERL)
Cómo puede la lógica de servicios múltiples posicionarse como un recurso eficaz de la empresa.
No agnóstico Contexto (ERL)
Cómo puede una sola función lógica de servicio posicionarse como un recurso eficaz de la empresa.
Agnóstico Capacidad (ERL)
Cómo generar la lógica de múltiples servicios de forma efectiva consumible y compuesta.
Servicio de patrones de implementación
Servicio de Fachada (ERL)
Cómo puede un servicio adaptarse a los cambios de su contrato, al tiempo que permite la ejecución del servicio básico y la lógica para evolucionar de forma independiente.
Implementación redundante (ERL)
Cómo incremetar la fiabilidad y la disponibilidad de un servicio.
Servicio de replicación de datos (ERL)
Cómo puede ser preservada la autonomía de servicios, cuando los servicios necesitan tener acceso a orígenes de datos compartidos.
El aplazamiento parcial del Estado (ERL)
Cómo pueden los servicios ser diseñados para optimizar el consumo de recursos mientras que aún permanecen con estado.
La validación parcial (Orchard, Riley)
Cómo evitar hacer validación innecesaria de datos.
Mediador de interfaz de usuario (Utschig, Maier, Trops, Normann, Winterberg)
Cómo puede una solución orientada a servicios proveer una constante e interactiva experiencia de usuario.
Servicio de los patrones de seguridad
Excepción de blindaje (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)
Cómo puede un servicio evitar la divulgación de información sobre su implementación interna, cuando se produce una excepción.
Detección de mensajes (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)
Cómo puede un servicio ser protegido de una entrada incorrecta o malintencionada.
Subsistema de confianza (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)
Cómo puede un consumidor impedir que un servicio sea aludido y evitar el acceso directo a sus recursos.
Servicio de Guardia del perímetro (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)
Cómo pueden los servicios que se ejecutan en una red privada estar disponibles a consumidores externos sin exposición externa de recursos.
Servicio de Patrones de Diseño Contrato
Contrato de centralización (ERL)
Cómo se puede evitar el acoplamiento del consumidor para la implementación.
Contrato de desnormalización (ERL)
Cómo puede facilitar un contrato de servicio a los consumidores con programas que tienen diferentes requerimientos de intercambio de datos.
Los contratos simultáneos (ERL)
Cómo puede facilitar un servicio multi-consumidor los requisitos de acoplamiento y referirse a la abstracción, al mismo tiempo.
Contrato desacoplado (ERL)
Cómo puede un servicio expreso tener capacidades independientemente de su aplicación.
Validación de la abstracción (ERL)
Cómo pueden ser los contratos de servicios diseñados para adaptarse más fácilmente a cambios de validación lógica.
Servicio de los patrones de seguridad
Excepción de blindaje (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)
Cómo puede un servicio evitar la divulgación de información sobre su implementación interna, cuando se produce una excepción.
Detección de mensajes (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)
Cómo puede un servicio ser protegido de una entrada incorrecta o malintencionada.
Subsistema de confianza (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)
Cómo puede un consumidor impedir que un servicio sea aludido y evitar el acceso directo a sus recursos.
Servicio de Guardia del perímetro (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)
Cómo pueden los servicios que se ejecutan en una red privada estar disponibles a consumidores externos sin exposición externa de recursos.
Servicio de Patrones de Diseño Contrato
Contrato de centralización (ERL)
Cómo se puede evitar el acoplamiento del consumidor para la implementación.
Contrato de desnormalización (ERL)
Cómo puede facilitar un contrato de servicio a los consumidores con programas que tienen diferentes requerimientos de intercambio de datos.
Los contratos simultáneos (ERL)
Cómo puede facilitar un servicio multi-consumidor los requisitos de acoplamiento y referirse a la abstracción, al mismo tiempo.
Contrato desacoplado (ERL)
Cómo puede un servicio expreso tener capacidades independientemente de su aplicación.
Validación de la abstracción (ERL)
Cómo pueden ser los contratos de servicios diseñados para adaptarse más fácilmente a cambios de validación lógica.
Patrones de herencia de encapsulación
Legado Wrapper (Erl, Roy)
Cómo los servicios de envoltura con contratos atípicos pueden prevenir la propagación indirecta del consumidor a la aplicación de acoplamiento.
Multi-canal de punto final (Roy)
Cómo puede ser centralizada y consolidada la lógica fragmentada legada y duplicada para la entrega de diferentes canales.
Archivo Gateway (Roy)
Cómo puede la lógica del servicio interactuar con otros sistemas que sólo pueden compartir la información mediante el intercambio de archivos.
Servicio de Patrones de Gobierno
Cambiar compatible (Orchard, Riley)
Cómo puede un contrato de servicio efectuar modificaciones sin afectar a los consumidores.
Identificación de la versión (Orchard, Riely)
Cómo pueden los consumidores estar al tanto de la versión del contrato de servicio de información.
Terminación Notificación (Orchard, Riley)
Cómo puede ser comunidado a los programas consumidores, el vencimiento de un contrato de servicio.
Servicio de refactorización (ERL)
Cómo se puede desarrollar un servicio sin afectar a los consumidores ya existentes.
Servicio de descomposición (ERL)
Cómo puede la granularidad de un servicio ser incrementada con posterioridad a su ejecución.
Proxy Capacidad (ERL)
Cómo puede un servicio sujeto a la descomposición continuar apoyando a los consumidores afectados por la descomposición.
Capacidad de descomposición (ERL)
Cómo puede un servicio de ser diseñado para minimizar las posibilidades de capacidad de descomposición lógica.
Capacidad distribuida (ERL)
Cómo puede un servicio preservar su contexto funcional al mismo tiempo que cumple requerimientos especiales de capacidad de procesamiento.
Patrones de la capacidad de Composición
Capacidad de Composición (ERL)
Cómo puede la capacidad de servicio resolver un problema que requiere la lógica fuera de los límites del servicio.
Capacidad de recomposición (ERL)
Cómo puede la misma capacidad ser utilizada para ayudar a resolver múltiples problemas.
Servicio de mensajería Patrones
Servicio de mensajería (ERL)
Cómo pueden los servicios interoperar sin formar conexiones persistentes, estrechamente unidas.
Mensajería de metadatos (ERL)
Cómo pueden los servicios ser diseñados para procesar los datos específicos de la actividad en tiempo de ejecución.
El servicio del Agente (ERL)
Cómo puede la lógica event-driven ser separada y gobernada de forma independiente.
Enrutamiento intermedio (Little, Rischbeck, Simon)
Cómo pueden los factores dinámicos en tiempo de ejecución afectar la ruta de un mensaje.
Estado de mensajería (Karmarkar)
Cómo puede un servicio recordar un estado de sesión, mientras participa en interacción de estado permanente.
Servicio de rellamada (Karmarkar)
Cómo puede un servicio tener comunicación asíncrona con sus consumidores.
Instancia de servicio de enrutamiento (Karmarkar)
Cómo pueden los consumidores contactar e interactuar con las instancias de servicio sin necesidad de lógica de procesamiento de propiedad.
Asíncrono Queue Server (Little, Rischbeck, Simon)
Cómo puede un servicio y sus consumidores manejar aislamiento de fallas y evitar bloqueo innecesario de recursos.
Reliable Messaging (Little, Rischbeck, Simon)
Cómo los servicios permiten una comunicación fiable cuando se implementan en un ambiente poco fiable.
Por eventos de mensajería (Little, Rischbeck, Simon)
Cómo pueden los consumidores de servicios recibir una notificación automática de un evento de servicio en tiempo de ejecución.
Patrones de composición de Aplicación
Subcontrolador Agnóstico (ERL)
Cómo pueden los agnósticos, cross-entidad lógica de la composición ser separados, reutilizados, y gobernados de forma independiente.
Composición de la Autonomía (ERL)
Como pueden las composiciones ser implementadas para reducir la pérdida de autonomía.
Transaction Service Atómica (ERL)
Cómo puede una transacción con la capacidad de rollback ser propagada a través de mensajería basada en los servicios.
La compensación de transacciones de servicios (Utschig, Maier, Trops, Normann, Winterberg, Loesgen, Little)
Cómo pueden las excepciones de composición en tiempo de ejecución ser consistentemente ajustadas sin requerir servicios de bloqueo de los recursos.
Servicio de Patrones de Interacción de Seguridad
Confidencialidad de los datos (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)
Cómo pueden los datos dentro de un mensaje ser protegidos para que no sean revelados a personas ajenas, al mismo tiempo que son transferidos.
Los datos de autenticación de origen (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)
Cómo puede un servicio verificar que un mensaje proviene de un emisor conocido y que el mensaje no ha sido alterado en tránsito.
Autenticación directa (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)
Cómo puede un servicio verificar las credenciales proporcionadas por el consumidor.
Autenticación negociado (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)
Cómo puede un servicio eficiente verificar las credenciales de los consumidores, si el consumidor y el servicio no confían unos en otros o si el consumidor requiere el acceso a múltiples servicios.
Patrones de transformación
Los datos del modelo de transformación (ERL)
Cómo pueden interoperar los servicios cuando se utilizan diferentes modelos de datos para el mismo tipo de datos.
Data Transformation Format (Little, Rischbeck, Simon)
Cómo pueden los servicios interactuar con los programas que se comunican con diferentes formatos de datos.
Legado Wrapper (Erl, Roy)
Cómo los servicios de envoltura con contratos atípicos pueden prevenir la propagación indirecta del consumidor a la aplicación de acoplamiento.
Multi-canal de punto final (Roy)
Cómo puede ser centralizada y consolidada la lógica fragmentada legada y duplicada para la entrega de diferentes canales.
Archivo Gateway (Roy)
Cómo puede la lógica del servicio interactuar con otros sistemas que sólo pueden compartir la información mediante el intercambio de archivos.
Servicio de Patrones de Gobierno
Cambiar compatible (Orchard, Riley)
Cómo puede un contrato de servicio efectuar modificaciones sin afectar a los consumidores.
Identificación de la versión (Orchard, Riely)
Cómo pueden los consumidores estar al tanto de la versión del contrato de servicio de información.
Terminación Notificación (Orchard, Riley)
Cómo puede ser comunidado a los programas consumidores, el vencimiento de un contrato de servicio.
Servicio de refactorización (ERL)
Cómo se puede desarrollar un servicio sin afectar a los consumidores ya existentes.
Servicio de descomposición (ERL)
Cómo puede la granularidad de un servicio ser incrementada con posterioridad a su ejecución.
Proxy Capacidad (ERL)
Cómo puede un servicio sujeto a la descomposición continuar apoyando a los consumidores afectados por la descomposición.
Capacidad de descomposición (ERL)
Cómo puede un servicio de ser diseñado para minimizar las posibilidades de capacidad de descomposición lógica.
Capacidad distribuida (ERL)
Cómo puede un servicio preservar su contexto funcional al mismo tiempo que cumple requerimientos especiales de capacidad de procesamiento.
Patrones de la capacidad de Composición
Capacidad de Composición (ERL)
Cómo puede la capacidad de servicio resolver un problema que requiere la lógica fuera de los límites del servicio.
Capacidad de recomposición (ERL)
Cómo puede la misma capacidad ser utilizada para ayudar a resolver múltiples problemas.
Servicio de mensajería Patrones
Servicio de mensajería (ERL)
Cómo pueden los servicios interoperar sin formar conexiones persistentes, estrechamente unidas.
Mensajería de metadatos (ERL)
Cómo pueden los servicios ser diseñados para procesar los datos específicos de la actividad en tiempo de ejecución.
El servicio del Agente (ERL)
Cómo puede la lógica event-driven ser separada y gobernada de forma independiente.
Enrutamiento intermedio (Little, Rischbeck, Simon)
Cómo pueden los factores dinámicos en tiempo de ejecución afectar la ruta de un mensaje.
Estado de mensajería (Karmarkar)
Cómo puede un servicio recordar un estado de sesión, mientras participa en interacción de estado permanente.
Servicio de rellamada (Karmarkar)
Cómo puede un servicio tener comunicación asíncrona con sus consumidores.
Instancia de servicio de enrutamiento (Karmarkar)
Cómo pueden los consumidores contactar e interactuar con las instancias de servicio sin necesidad de lógica de procesamiento de propiedad.
Asíncrono Queue Server (Little, Rischbeck, Simon)
Cómo puede un servicio y sus consumidores manejar aislamiento de fallas y evitar bloqueo innecesario de recursos.
Reliable Messaging (Little, Rischbeck, Simon)
Cómo los servicios permiten una comunicación fiable cuando se implementan en un ambiente poco fiable.
Por eventos de mensajería (Little, Rischbeck, Simon)
Cómo pueden los consumidores de servicios recibir una notificación automática de un evento de servicio en tiempo de ejecución.
Patrones de composición de Aplicación
Subcontrolador Agnóstico (ERL)
Cómo pueden los agnósticos, cross-entidad lógica de la composición ser separados, reutilizados, y gobernados de forma independiente.
Composición de la Autonomía (ERL)
Como pueden las composiciones ser implementadas para reducir la pérdida de autonomía.
Transaction Service Atómica (ERL)
Cómo puede una transacción con la capacidad de rollback ser propagada a través de mensajería basada en los servicios.
La compensación de transacciones de servicios (Utschig, Maier, Trops, Normann, Winterberg, Loesgen, Little)
Cómo pueden las excepciones de composición en tiempo de ejecución ser consistentemente ajustadas sin requerir servicios de bloqueo de los recursos.
Servicio de Patrones de Interacción de Seguridad
Confidencialidad de los datos (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)
Cómo pueden los datos dentro de un mensaje ser protegidos para que no sean revelados a personas ajenas, al mismo tiempo que son transferidos.
Los datos de autenticación de origen (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)
Cómo puede un servicio verificar que un mensaje proviene de un emisor conocido y que el mensaje no ha sido alterado en tránsito.
Autenticación directa (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)
Cómo puede un servicio verificar las credenciales proporcionadas por el consumidor.
Autenticación negociado (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)
Cómo puede un servicio eficiente verificar las credenciales de los consumidores, si el consumidor y el servicio no confían unos en otros o si el consumidor requiere el acceso a múltiples servicios.
Patrones de transformación
Los datos del modelo de transformación (ERL)
Cómo pueden interoperar los servicios cuando se utilizan diferentes modelos de datos para el mismo tipo de datos.
Data Transformation Format (Little, Rischbeck, Simon)
Cómo pueden los servicios interactuar con los programas que se comunican con diferentes formatos de datos.
Protocolo de puente (Little, Rischbeck, Simon)
Cómo puede un servicio intercambiar datos con los consumidores que utilizan diferentes protocolos de comunicación.
Los patrones de diseño comunes Compuesto
Orquestación (Erl, Loesgen)
Co-existencia de aplicaciones de proceso de la abstracción, el Repositorio de Estado, la centralización de procesos, transacciones y servicios de compensación, se puede ampliar con Servicio de Transacción Atómica, centralización de reglas, y de transformación del modelo de datos.
Enterprise Service Bus (Erl, Little, Rischbeck, Simon)
Coexistencia de aplicaciones de cola asincrónica, enrutamiento intermedio, y el patrón de Service Broker compuesto, que puede ser extendido a través de la mensajería de confianza, la política de centralización, centralización de reglas y mensajería por eventos.
Service Broker (Little, Rischbeck, Simon)
Co-existencia de aplicaciones de transformación de modelos de datos, transformación de formato de datos, y el Protocolo de puente.
Bus del esquema canónico (Utschig, Maier, Trops, Normann, Winterberg, Erl)
Co-existencia de aplicaciones de Enterprise Service Bus, Contrato desconectado, la centralización del contrato, y el esquema canónico.
Punto final oficial (ERL)
Aplicación conjunta de la lógica y contrato de centralización.
Federados capa de punto final (ERL)
Aplicación conjunta de punto final oficial, normalización de servicios, el Protocolo de Canonizacíon, esquema canónico, y su forma canónica.
Tres capas de inventario (ERL)
Aplicación conjunta de la abstracción de utilidad, la abstracción de Entidad, y la abstracción del proceso.
Cómo puede un servicio intercambiar datos con los consumidores que utilizan diferentes protocolos de comunicación.
Los patrones de diseño comunes Compuesto
Orquestación (Erl, Loesgen)
Co-existencia de aplicaciones de proceso de la abstracción, el Repositorio de Estado, la centralización de procesos, transacciones y servicios de compensación, se puede ampliar con Servicio de Transacción Atómica, centralización de reglas, y de transformación del modelo de datos.
Enterprise Service Bus (Erl, Little, Rischbeck, Simon)
Coexistencia de aplicaciones de cola asincrónica, enrutamiento intermedio, y el patrón de Service Broker compuesto, que puede ser extendido a través de la mensajería de confianza, la política de centralización, centralización de reglas y mensajería por eventos.
Service Broker (Little, Rischbeck, Simon)
Co-existencia de aplicaciones de transformación de modelos de datos, transformación de formato de datos, y el Protocolo de puente.
Bus del esquema canónico (Utschig, Maier, Trops, Normann, Winterberg, Erl)
Co-existencia de aplicaciones de Enterprise Service Bus, Contrato desconectado, la centralización del contrato, y el esquema canónico.
Punto final oficial (ERL)
Aplicación conjunta de la lógica y contrato de centralización.
Federados capa de punto final (ERL)
Aplicación conjunta de punto final oficial, normalización de servicios, el Protocolo de Canonizacíon, esquema canónico, y su forma canónica.
Tres capas de inventario (ERL)
Aplicación conjunta de la abstracción de utilidad, la abstracción de Entidad, y la abstracción del proceso.
lunes, 17 de octubre de 2011
lunes, 10 de octubre de 2011
Servicios de Integración
Los servicios que se tienen que tener en cuenta para la integración entre aplicaciones se muestran a continuación:
A. Transporte y Conectividad: El objetivo es la transmisión de la información requerida entre las palicaciones.
1. Transporte de datos: Normalmente implica el uso de un bus de comunicación multicanal. Los servicios se pueden dividir en:
-Database Management Systems (DBMS): Si hay varias aplicaciones que comparten parte de un modelo de datos común representado en un motor de manejo de bases de datos, se puede intercambiar datos en común debido a que cada aplicación tiene acceso al modelo común.
-Transferencia de archivos: Se utilizan manejadores de transferencia de archivos, los cuales son capaces de recibir y enviar datos almacenados en archivos (como FTP por ejemplo). Algunos dejar configurar disparadores (triggers), que ante la llegada de un archivo puede invocar comandos sobre la máquina que lo recibió. Gracias a ello, una aplicación puede conocer cuándo le envía información otro programa para así efectuar diferentes acciones de procesamiento.
-Sistemas de mensajería interaplicación (MOMs): Se efectúa una comunicación a nivel de aplicación, a través del envío de mensajes, los cuales son gestionados por el MOM a través del uso de colas, el manejo de transacciones, las opciones de recuperación ante fallos, persostencia, monitoreo etc. Para poder hacer uso de un MOM debe modificarse a fondo la aplicación, definiendo la interacción con el MOM.
-Internet: A través del uso de esta red, se puede realizar intercambio de información entre aplicaciones a través del uso de protocolos como HTTP, SMTP, SOAP, eMS (EbXML Messaging Service), RNIF, EDIINT, etc.
2. Conectividad: Se usan buses de comunicación para poder transmitir tanto datos como eventos. Para conectar infraestructuras de intercambio de información con las aplicaciones, se puede hacer uso de adaptadores, los cuales permiten ese enlace, a través de la invocación de eventos sobre la infraestructura desde un programa.
3. Supervisión del transporte de la información Captura información de los eventos y datos transmitidos, con el fin de identificar fallos y/o compromisos, con el fin de identificar fallo o compromisos en el transporte de los datos y eventos.
B. Adaptación de la Información: A veces los datos o eventos recibidos no son comprendidos por una aplicación, por lo que se requieren mecanismos para que la misma pueda interpretarla. Estos mecanismos se muestran a continuación:
1. Transformación: Cuando se reciben eventos o datos que contienen información necesaria para desencadenar otros eventos o envío de información diferente.
Esto es posible a través de la definición de unas reglas de transformación:
a. A nivel de formatos de datos
- Formato plano: Datos que tienen una posición y tamaño fijo dentro del archivo.
- Formato plano, posición variable: Antes de cada dato se coloca la longitud del mismo.
- Formato plano, con delimitador: Se usa un caracter especial para indicar la separación entre uno y otro.
- Jerárquico: Hay datos que pueden considerarse compuestos, es decir, que son conformados por la unión de datos simples.
- Formato XML: Para la definición de elementos de datos estructurados usando etiquetas.
b. Transformación sintáctica: Cambia la representación de un evento para ser interpretado o procesado por la aplicación que hace uso de él.
c. Transformación semántica: Se modifica el significado de toda o parte de la información recibida de un evento base, para la creación de otros eventos que se van a introducir en un sistema de información. Durante la creación de estos eventos, puede resultar necesaria la realización de cálculos sobre los datos recibidos.
2. Enrutamiento: La idea es determinar quién va a recibir o procesar la información de un evento que es enviado por una aplicación. Para ello, se pueden utilizar mecanismos como el de publicación/suscripción. Normalmente, estas decisiones pueden ser administradas por un sistema de enrutamiento,
3. Almacenamiento: En algunos casos, los eventos se tienen que almacenar temporalmente, usando sistemas de archivos, bases de datos o manejadores de colas.
4. Realizar la definición de las reglas de transformación, enrutamiento y almacenamiento.
5. Supervisión de los intercambios de información: Puede ser posible mediante la generación de alertas, ya sea enlazadas a los errores disparados o deducidos de las reglas de verificación.
C. Automatizando los procesos de negocio: Si el intercambio de información es dependiente de alguna clasificación o de una serie de múltiples pasos se puede modelar en un motor de BPM. Para ello, se pueden definir los sguientes pasos:
1. Modelar los procesos de negocio: Implica la definición de actividades, relaciones, roles, el inicio y fin del proceso, las aplicaciones y datos intercambiados.Estas actividades pueden ser tanto manuales como automáticas.Se puede hacer uso de una notación como BPMN para realizar la descripción y el modelaje.
2. Ejecutar los procesos de negocio: Esta actividad se puede dividir en:
a. Orquestamiento de actividades. Consiste en la ejecución ordenada de las actividades, recuperando los resultado de cada paso, aplicando las reglas para cambiar o tomar una decisión, asegurarse que las actividades sucesivas sean enviadas con los datos o eventos requeridos, enviar información al módulo de monitoreo, y realizar la administración de cada paso. Este orquestamiento puede ser realizado por un motor de ejecución de procesos, la cual puede requerir que se de una descripción de cómo se va a realizar esta orquestación usando lenguajes como BPEL (Business Process Execution Language).
b. Ejecutando las reglas de negocio: Usando un motor de reglas de negocio, se establecen los lineamientos para lograr el avance de un proceso por un camino dado.
c. Supervisar los procesos de negocio: Es importante conocer el curso de las instancias de los procesos, para identificar puntos de falla y puntos de mejora de los procesos.
D. Mediación e integración: Los roles e interacciones dentro del proceso se deben definir estableciendo los niveles de procesos de negocio y de integración, definiendo los procesos de intercambio, y la interacción entre subniveles.
E. Escoger la arquitectura de intercambio: Se establece si la comunicación va a ser asíncrónica (a destiempo) o sincrónica (la interacción es bidireccional y acordada), y si los servicios e información a ofrecer va a distribuirse de manera centralizada (a través del uso de HUBs, que replican la información enviada por una aplicación a las demás aplicaciones conectadas), o de manera distribuida (usando buses de servicio, que establece un puente de comunicación punto a punto entre aplicaciones ofreciendo servicios de interpretación/traducción para mayor facilidad en la interpretación de la información.
A. Transporte y Conectividad: El objetivo es la transmisión de la información requerida entre las palicaciones.
1. Transporte de datos: Normalmente implica el uso de un bus de comunicación multicanal. Los servicios se pueden dividir en:
-Database Management Systems (DBMS): Si hay varias aplicaciones que comparten parte de un modelo de datos común representado en un motor de manejo de bases de datos, se puede intercambiar datos en común debido a que cada aplicación tiene acceso al modelo común.
-Transferencia de archivos: Se utilizan manejadores de transferencia de archivos, los cuales son capaces de recibir y enviar datos almacenados en archivos (como FTP por ejemplo). Algunos dejar configurar disparadores (triggers), que ante la llegada de un archivo puede invocar comandos sobre la máquina que lo recibió. Gracias a ello, una aplicación puede conocer cuándo le envía información otro programa para así efectuar diferentes acciones de procesamiento.
-Sistemas de mensajería interaplicación (MOMs): Se efectúa una comunicación a nivel de aplicación, a través del envío de mensajes, los cuales son gestionados por el MOM a través del uso de colas, el manejo de transacciones, las opciones de recuperación ante fallos, persostencia, monitoreo etc. Para poder hacer uso de un MOM debe modificarse a fondo la aplicación, definiendo la interacción con el MOM.
-Internet: A través del uso de esta red, se puede realizar intercambio de información entre aplicaciones a través del uso de protocolos como HTTP, SMTP, SOAP, eMS (EbXML Messaging Service), RNIF, EDIINT, etc.
2. Conectividad: Se usan buses de comunicación para poder transmitir tanto datos como eventos. Para conectar infraestructuras de intercambio de información con las aplicaciones, se puede hacer uso de adaptadores, los cuales permiten ese enlace, a través de la invocación de eventos sobre la infraestructura desde un programa.
3. Supervisión del transporte de la información Captura información de los eventos y datos transmitidos, con el fin de identificar fallos y/o compromisos, con el fin de identificar fallo o compromisos en el transporte de los datos y eventos.
B. Adaptación de la Información: A veces los datos o eventos recibidos no son comprendidos por una aplicación, por lo que se requieren mecanismos para que la misma pueda interpretarla. Estos mecanismos se muestran a continuación:
1. Transformación: Cuando se reciben eventos o datos que contienen información necesaria para desencadenar otros eventos o envío de información diferente.
Esto es posible a través de la definición de unas reglas de transformación:
a. A nivel de formatos de datos
- Formato plano: Datos que tienen una posición y tamaño fijo dentro del archivo.
- Formato plano, posición variable: Antes de cada dato se coloca la longitud del mismo.
- Formato plano, con delimitador: Se usa un caracter especial para indicar la separación entre uno y otro.
- Jerárquico: Hay datos que pueden considerarse compuestos, es decir, que son conformados por la unión de datos simples.
- Formato XML: Para la definición de elementos de datos estructurados usando etiquetas.
b. Transformación sintáctica: Cambia la representación de un evento para ser interpretado o procesado por la aplicación que hace uso de él.
c. Transformación semántica: Se modifica el significado de toda o parte de la información recibida de un evento base, para la creación de otros eventos que se van a introducir en un sistema de información. Durante la creación de estos eventos, puede resultar necesaria la realización de cálculos sobre los datos recibidos.
2. Enrutamiento: La idea es determinar quién va a recibir o procesar la información de un evento que es enviado por una aplicación. Para ello, se pueden utilizar mecanismos como el de publicación/suscripción. Normalmente, estas decisiones pueden ser administradas por un sistema de enrutamiento,
3. Almacenamiento: En algunos casos, los eventos se tienen que almacenar temporalmente, usando sistemas de archivos, bases de datos o manejadores de colas.
4. Realizar la definición de las reglas de transformación, enrutamiento y almacenamiento.
5. Supervisión de los intercambios de información: Puede ser posible mediante la generación de alertas, ya sea enlazadas a los errores disparados o deducidos de las reglas de verificación.
C. Automatizando los procesos de negocio: Si el intercambio de información es dependiente de alguna clasificación o de una serie de múltiples pasos se puede modelar en un motor de BPM. Para ello, se pueden definir los sguientes pasos:
1. Modelar los procesos de negocio: Implica la definición de actividades, relaciones, roles, el inicio y fin del proceso, las aplicaciones y datos intercambiados.Estas actividades pueden ser tanto manuales como automáticas.Se puede hacer uso de una notación como BPMN para realizar la descripción y el modelaje.
2. Ejecutar los procesos de negocio: Esta actividad se puede dividir en:
a. Orquestamiento de actividades. Consiste en la ejecución ordenada de las actividades, recuperando los resultado de cada paso, aplicando las reglas para cambiar o tomar una decisión, asegurarse que las actividades sucesivas sean enviadas con los datos o eventos requeridos, enviar información al módulo de monitoreo, y realizar la administración de cada paso. Este orquestamiento puede ser realizado por un motor de ejecución de procesos, la cual puede requerir que se de una descripción de cómo se va a realizar esta orquestación usando lenguajes como BPEL (Business Process Execution Language).
b. Ejecutando las reglas de negocio: Usando un motor de reglas de negocio, se establecen los lineamientos para lograr el avance de un proceso por un camino dado.
c. Supervisar los procesos de negocio: Es importante conocer el curso de las instancias de los procesos, para identificar puntos de falla y puntos de mejora de los procesos.
D. Mediación e integración: Los roles e interacciones dentro del proceso se deben definir estableciendo los niveles de procesos de negocio y de integración, definiendo los procesos de intercambio, y la interacción entre subniveles.
E. Escoger la arquitectura de intercambio: Se establece si la comunicación va a ser asíncrónica (a destiempo) o sincrónica (la interacción es bidireccional y acordada), y si los servicios e información a ofrecer va a distribuirse de manera centralizada (a través del uso de HUBs, que replican la información enviada por una aplicación a las demás aplicaciones conectadas), o de manera distribuida (usando buses de servicio, que establece un puente de comunicación punto a punto entre aplicaciones ofreciendo servicios de interpretación/traducción para mayor facilidad en la interpretación de la información.
PATRONES DE INTEGRACION EMPRESARIAL
Crear aplicaciones de negocios es difícil, y hacer que esta maneje todo un negocio es casi imposible. Luego distribuir funciones del negocio entre diversas aplicaciones provee la flexibilidad de escoger lo mejor de cada área de la empresa, sin embargo encontrar todo esto en una solución no es posible, puesto que cada empresa es distinta.
Estos, entre otros, son los problemas que se presentan en las empresas, haciendo necesaria la integración de las aplicaciones, de manera que esta sea eficiente, confiable y segura en el intercambio de datos entre diferentes aplicaciones empresariales.
RETOS DE INTEGRACION.
• Para la integración empresarial se requiere un cambio importante en las políticas corporativas.
• Debido a su amplio espectro, los esfuerzos de integración tienen profundas implicaciones en el negocio, volviendo a las soluciones empresariales una parte vital del negocio.
• Hay un control limitado en la integración de las aplicaciones, puesto que hay demasiado software legado que no puede ser modificado o enlazado adecuadamente con la solución de integración.
• Hay pocos estándares establecidos para llevar a cabo una integración de soluciones y en algunos casos (como el del WebService en XML) solo se ofrece una solución parcial.
• Las diferentes mezclas de tecnología y la naturaleza distribuida de las soluciones empresariales hacen el desarrollo de estas un reto en sí mismas.
ALGUNOS TIPOS DE INTEGRACION
Portal de información: reúnen información de múltiples fuentes en un solo lugar evitando con esto que el usuario tenga que abrir diferentes aplicaciones para lograr su objetivo.
Replicación de datos: nos permite mantener la integridad de diversos de los datos de diversos sistemas utilizando replicación de información.
Función de negocio compartida: evita la redundancia de funciones entre diversas aplicaciones mediante la exposición de dichas funciones como una función de negocio compartida que se implementa una vez y está disponible como un servicio para todos los demás sistemas.
Arquitectura orientada a servicios (SOA): SOA difumina la línea entre integración de aplicaciones y aplicaciones distribuidas. En SOA las funciones de del directorio de servicios y la interfaz de comunicación son elementos importantes para la arquitectura.
Procesos de negocio distribuidos: nos permite coordinar las aplicaciones en un entorno distribuido, permitiendo administrar la ejecución de cada una de estas entre múltiples sistemas.
Integración entre negocios: nos permite agrupar en un solo lugar los servicios de diferentes empresas para lograr un objetivo en particular.
ESTILOS DE INTEGRACION
La integración empresarial es la tarea de hacer que diferentes aplicaciones separadas trabajen juntas para producir un conjunto de funcionalidades. Para lograr lo anterior, se debe seguir una serie de criterios para lograr el objetivo principal.
Emparejamiento de aplicaciones: las aplicaciones integradas deben minimizar las dependencias entre ellas de manera que cada una pueda evolucionar sin provocar problemas a la otra.
Simplicidad de integración: cuando se integren aplicaciones, los desarrolladores deben luchar por minimizar el cambio de la aplicación y minimizar la cantidad de código requerido para la integración.
Tecnología de integración: evitar el casarse con un proveedor de tecnología de integración porque esto incrementa los problemas para el desarrollador y el entendimiento que este tiene de las herramientas.
Formato de los datos: las aplicaciones integradas deben tener un formato de intercambio de datos común o un traductor intermedio para unificar las aplicaciones que insisten en tener formatos propietarios o diferentes a los acordados.
No percepción de tiempo en los datos: el tiempo entre la compartición de la información y el uso de la misma entre aplicaciones integradas debe ser mínimo.
Datos o funcionalidad?: las aplicaciones integradas no deben compartir solo datos, sino funcionalidad entre ellas.
Asincronia: las aplicaciones integradas deben estar en capacidad de ejecutarse de manera asíncrona, de manera que el incorrecto funcionamiento de una, no termine por afectar a todo el sistema.
OPCIONES DE INTEGRACION DE APLICACIONES
Transferencia de archivos: hacer que cada aplicación produzca archivos para que las demás usen, y esta a su vez pueda usar lo que las demás aplicaciones produzcan.
Base de datos compartida: hacer que las aplicaciones guarden la información en un lugar común.
Invocación de procesos remotos: hacer que cada aplicación exponga algunos de sus procedimientos para que puedan ser invocados remotamente, y al mismo tiempo hacer que otras aplicaciones puedan invocar estos para ejecutar una labor de sistema e intercambio de información.
Mensajería: hacer que cada aplicación se conecte a un sistema de mensajería común, comparta información y ejecute funciones mediante el uso de mensajes.
SISTEMA DE MENSAJES
Los sistemas de mensajes hacen las aplicaciones “loosely coupled” al comunicarlas asíncronamente, haciendo la comunicación más confiable por que las dos aplicaciones no necesitan estar ejecutándose al mismo tiempo.
Canales: zona por donde se transmiten los mensajes, conectando al que envía con el que recibe.
Mensaje: paquete atómico que puede ser transmitido por un canal.
Entrega en varios pasos: un sistema de mensajes entrega estos directamente entre el que envía y el que recibe, requiriendo en muchas ocasiones el hacer alguna transformación en el mensaje antes de ser este enviado.
Enrutamiento: aplicación que determina como debe navegar el paquete en la red de canales de la empresa para llegar a su destino.
Transformación: filtro que formatea el mensaje de forma que el receptor lo pueda leer sin inconvenientes al recibirlo.
EndPoint: puente que permite a las aplicaciones el enviar y recibir mensajes entre sistemas de mensajes.
Pipes and Filters: pasos de proceso individuales (filters) están directametne relacionados mediante unos canales de mensajes (pipes). El “pipe” permite a un componente el enviar un mensaje dentro de este, de manera que pueda ser consumido posteriormente por otro proceso que puede ser desconocido por el componente inicial.
Pipeline processing: permite a cada unidad el ejecutar su propio hilo de proceso. Cuando una unidad ha completado el procesamiento de un mensaje, puede entonces enviar un mensaje al canal de salida y empezar un nuevo proceso, sin esperar que el proceso padre haya terminado. Si se compara con el modelo secuencia, el rendimiento del sistema se ve ampliamente incrementado.
Procesamiento en paralelo: mejora el rendimiento del sistema al lanzar varios procesos a que funcionen paralelamente, haciendo que las tareas más costosas en cuanto a tiempo se puedan realizar más rápida eficientemente, pero esta aproximación puede hacer que los mensajes se ejecuten de un modo “out-of-order”.
Estos, entre otros, son los problemas que se presentan en las empresas, haciendo necesaria la integración de las aplicaciones, de manera que esta sea eficiente, confiable y segura en el intercambio de datos entre diferentes aplicaciones empresariales.
RETOS DE INTEGRACION.
• Para la integración empresarial se requiere un cambio importante en las políticas corporativas.
• Debido a su amplio espectro, los esfuerzos de integración tienen profundas implicaciones en el negocio, volviendo a las soluciones empresariales una parte vital del negocio.
• Hay un control limitado en la integración de las aplicaciones, puesto que hay demasiado software legado que no puede ser modificado o enlazado adecuadamente con la solución de integración.
• Hay pocos estándares establecidos para llevar a cabo una integración de soluciones y en algunos casos (como el del WebService en XML) solo se ofrece una solución parcial.
• Las diferentes mezclas de tecnología y la naturaleza distribuida de las soluciones empresariales hacen el desarrollo de estas un reto en sí mismas.
ALGUNOS TIPOS DE INTEGRACION
Portal de información: reúnen información de múltiples fuentes en un solo lugar evitando con esto que el usuario tenga que abrir diferentes aplicaciones para lograr su objetivo.
Replicación de datos: nos permite mantener la integridad de diversos de los datos de diversos sistemas utilizando replicación de información.
Función de negocio compartida: evita la redundancia de funciones entre diversas aplicaciones mediante la exposición de dichas funciones como una función de negocio compartida que se implementa una vez y está disponible como un servicio para todos los demás sistemas.
Arquitectura orientada a servicios (SOA): SOA difumina la línea entre integración de aplicaciones y aplicaciones distribuidas. En SOA las funciones de del directorio de servicios y la interfaz de comunicación son elementos importantes para la arquitectura.
Procesos de negocio distribuidos: nos permite coordinar las aplicaciones en un entorno distribuido, permitiendo administrar la ejecución de cada una de estas entre múltiples sistemas.
Integración entre negocios: nos permite agrupar en un solo lugar los servicios de diferentes empresas para lograr un objetivo en particular.
ESTILOS DE INTEGRACION
La integración empresarial es la tarea de hacer que diferentes aplicaciones separadas trabajen juntas para producir un conjunto de funcionalidades. Para lograr lo anterior, se debe seguir una serie de criterios para lograr el objetivo principal.
Emparejamiento de aplicaciones: las aplicaciones integradas deben minimizar las dependencias entre ellas de manera que cada una pueda evolucionar sin provocar problemas a la otra.
Simplicidad de integración: cuando se integren aplicaciones, los desarrolladores deben luchar por minimizar el cambio de la aplicación y minimizar la cantidad de código requerido para la integración.
Tecnología de integración: evitar el casarse con un proveedor de tecnología de integración porque esto incrementa los problemas para el desarrollador y el entendimiento que este tiene de las herramientas.
Formato de los datos: las aplicaciones integradas deben tener un formato de intercambio de datos común o un traductor intermedio para unificar las aplicaciones que insisten en tener formatos propietarios o diferentes a los acordados.
No percepción de tiempo en los datos: el tiempo entre la compartición de la información y el uso de la misma entre aplicaciones integradas debe ser mínimo.
Datos o funcionalidad?: las aplicaciones integradas no deben compartir solo datos, sino funcionalidad entre ellas.
Asincronia: las aplicaciones integradas deben estar en capacidad de ejecutarse de manera asíncrona, de manera que el incorrecto funcionamiento de una, no termine por afectar a todo el sistema.
OPCIONES DE INTEGRACION DE APLICACIONES
Transferencia de archivos: hacer que cada aplicación produzca archivos para que las demás usen, y esta a su vez pueda usar lo que las demás aplicaciones produzcan.
Base de datos compartida: hacer que las aplicaciones guarden la información en un lugar común.
Invocación de procesos remotos: hacer que cada aplicación exponga algunos de sus procedimientos para que puedan ser invocados remotamente, y al mismo tiempo hacer que otras aplicaciones puedan invocar estos para ejecutar una labor de sistema e intercambio de información.
Mensajería: hacer que cada aplicación se conecte a un sistema de mensajería común, comparta información y ejecute funciones mediante el uso de mensajes.
SISTEMA DE MENSAJES
Los sistemas de mensajes hacen las aplicaciones “loosely coupled” al comunicarlas asíncronamente, haciendo la comunicación más confiable por que las dos aplicaciones no necesitan estar ejecutándose al mismo tiempo.
Canales: zona por donde se transmiten los mensajes, conectando al que envía con el que recibe.
Mensaje: paquete atómico que puede ser transmitido por un canal.
Entrega en varios pasos: un sistema de mensajes entrega estos directamente entre el que envía y el que recibe, requiriendo en muchas ocasiones el hacer alguna transformación en el mensaje antes de ser este enviado.
Enrutamiento: aplicación que determina como debe navegar el paquete en la red de canales de la empresa para llegar a su destino.
Transformación: filtro que formatea el mensaje de forma que el receptor lo pueda leer sin inconvenientes al recibirlo.
EndPoint: puente que permite a las aplicaciones el enviar y recibir mensajes entre sistemas de mensajes.
Pipes and Filters: pasos de proceso individuales (filters) están directametne relacionados mediante unos canales de mensajes (pipes). El “pipe” permite a un componente el enviar un mensaje dentro de este, de manera que pueda ser consumido posteriormente por otro proceso que puede ser desconocido por el componente inicial.
Pipeline processing: permite a cada unidad el ejecutar su propio hilo de proceso. Cuando una unidad ha completado el procesamiento de un mensaje, puede entonces enviar un mensaje al canal de salida y empezar un nuevo proceso, sin esperar que el proceso padre haya terminado. Si se compara con el modelo secuencia, el rendimiento del sistema se ve ampliamente incrementado.
Procesamiento en paralelo: mejora el rendimiento del sistema al lanzar varios procesos a que funcionen paralelamente, haciendo que las tareas más costosas en cuanto a tiempo se puedan realizar más rápida eficientemente, pero esta aproximación puede hacer que los mensajes se ejecuten de un modo “out-of-order”.
INTEGRACIÓN DE APLICACIONES
Las necesidades demandadas por un mundo globalizado han hecho que la información manejada por las empresas tenga que ser compartida con otras y sus clientes, por lo tanto, se han tenido que diseñar estrategias de intercambio de información de los diferentes sistemas de información que reciben y procesan estos datos.
Cuando se quería integrar adecuadamente información manejadas los dos o más aplicaciones de uso interno, nació la Integración Empresarial de Aplicaciones (EAI) y las conexiones A2A (aplicación a aplicación). Posteriormente, nació la necesidad de compartir información básica con empresas colaboradoras (o partners), por lo que surgieron los sistemas orientados a mensajeria (MOMs) y la arquitectura B2B.
Conforme han ido creciendo en tamaño las empresas, va surgiendo la necesidad de monitorear las actividades realizadas en sus procesos misionales, por lo que nacieron herramientas de monitoreo. que son conocidas como BAM (Business Activity Monitoring); pero a la vez los procesos misionales se han ido tornando más complejos, involucrando muchos actores internos y externos en el desarrollo de los mismos. Por lo tanto, se pueden utilizar dos estrategias para poder lograr un intercambio adecuado de la información manejada:
- Proveer servicios estandarizados consumibles por aplicaciones, a través del uso de la arquitectura orientada a servicios (SOA).
- Usar la metodología de modelamiento de procesos de negocio para entender y dirigir las actividades de los procesos de negocio0 en los que también puede existir intercambio de información entre aplicaciones.
La problemática principal para el departamento de TI de una empresa es lograr la comunicación de la información requerida entre las aplicaciones a través del uso de un lenguaje común. Para ello se identifica primero qué problema de integración es al que se tiene que enfrentar (propagación de datos, procesos multipaso, aplicaciones compuestas).Luego, hay que clasificar las aplicaciones actuales (en aplicaciones de procesos de lotes, transaccionales, cliente/servidor, web, tiempo real y paquetes de sofware). Finnalmente, teniendo toda la información previa recopilada, se puede determinar cuál puede ser la mejor estrategia de integracióm (EAI, A2A, B2B, BPM, SOA).
Cuando se quería integrar adecuadamente información manejadas los dos o más aplicaciones de uso interno, nació la Integración Empresarial de Aplicaciones (EAI) y las conexiones A2A (aplicación a aplicación). Posteriormente, nació la necesidad de compartir información básica con empresas colaboradoras (o partners), por lo que surgieron los sistemas orientados a mensajeria (MOMs) y la arquitectura B2B.
Conforme han ido creciendo en tamaño las empresas, va surgiendo la necesidad de monitorear las actividades realizadas en sus procesos misionales, por lo que nacieron herramientas de monitoreo. que son conocidas como BAM (Business Activity Monitoring); pero a la vez los procesos misionales se han ido tornando más complejos, involucrando muchos actores internos y externos en el desarrollo de los mismos. Por lo tanto, se pueden utilizar dos estrategias para poder lograr un intercambio adecuado de la información manejada:
- Proveer servicios estandarizados consumibles por aplicaciones, a través del uso de la arquitectura orientada a servicios (SOA).
- Usar la metodología de modelamiento de procesos de negocio para entender y dirigir las actividades de los procesos de negocio0 en los que también puede existir intercambio de información entre aplicaciones.
La problemática principal para el departamento de TI de una empresa es lograr la comunicación de la información requerida entre las aplicaciones a través del uso de un lenguaje común. Para ello se identifica primero qué problema de integración es al que se tiene que enfrentar (propagación de datos, procesos multipaso, aplicaciones compuestas).Luego, hay que clasificar las aplicaciones actuales (en aplicaciones de procesos de lotes, transaccionales, cliente/servidor, web, tiempo real y paquetes de sofware). Finnalmente, teniendo toda la información previa recopilada, se puede determinar cuál puede ser la mejor estrategia de integracióm (EAI, A2A, B2B, BPM, SOA).
Patrón Integrador Consumidor Propuesto
Como aplicación de las innovaciones que presenta BPMN 2.0. Implementamos los conceptos de Call Activity, Escalation y Signal para la propuesta de un nuevo patrón, al que llamamos: Integrador Consumidor.
Problema:
El problema que soluciona la implementación del patrón es la necesidad de integración de información, concretamente la actualización de datos maestros, efectuada por varios procesos de negocio y que tienen una presentación y/o estructura diferente a la que es común para todos a través de una estructura centralizada.
Motivación: Poder consultar información de datos maestros (común entre los procesos de negocio), unificada desde un punto centralizado, que es consistente, confiable y única para todos los procesos de negocio, que la comparten.
Aplicación:
Caso 1 de Aplicación.
Actualización de los datos básicos de un paciente, en una EPS, que pueden ser
actualizados desde diferentes procesos de negocio como: Afiliaciones, Tesorería, IPS.
Caso 2 de Aplicación.
Actualización de información del cliente en VehiAlpes, desde procesos de negocio como:
Ventas, Servicio al cliente, Mercadeo.
Caso 3 de Aplicación.
Actualización de los datos básicos de un destinatario en una empresa de mensajería
desde diferentes procesos de negocio como: Distribución en Zona, Confirmaciones,
Servicio al cliente, Punto de Servicio, entre otros.
Estructura: La idea que proponemos mediante el patrón es la invocación de una señal al Integrador; al momento de generarse el evento de actualización de un dato maestro, desde cualquier proceso de negocio, éste a su vez, como respuesta, genera una cadena de señales hacia todos los procesos de negocio, sincronizando un tiempo de detención de actividades sobre el dato que se está actualizando. Una vez ha enviado todas las señales, escala a un llamado de actividad de actualización, dependiendo del dato maestro a actualizar, que contiene el código propio, definido por el proceso de negocio que gobierna al dato maestro. Y una vez finalizado la ejecución de la actividad que permite la actualización del dato. El Integrador, envía nuevamente una señal a todos los procesos, para reanudar las operaciones que utilizan el dato maestro. Finalmente los procesos reciben la señal y continúa la operación de negocio con normalidad.
Consecuencias: El uso de este modelo garantiza la aplicación de una solución a un problema común, que utiliza componentes de escalabilidad, de señales, llamados de actividades que permiten la reutilización de código y eventos informativos, de modo que lo hace flexible, modificable, escalable, proporcionando una alternativa de solución para la integración de información, en relación con la homogeneidad y gobernabilidad de Datos Maestros.
Problema:
El problema que soluciona la implementación del patrón es la necesidad de integración de información, concretamente la actualización de datos maestros, efectuada por varios procesos de negocio y que tienen una presentación y/o estructura diferente a la que es común para todos a través de una estructura centralizada.
Motivación: Poder consultar información de datos maestros (común entre los procesos de negocio), unificada desde un punto centralizado, que es consistente, confiable y única para todos los procesos de negocio, que la comparten.
Aplicación:
Caso 1 de Aplicación.
Actualización de los datos básicos de un paciente, en una EPS, que pueden ser
actualizados desde diferentes procesos de negocio como: Afiliaciones, Tesorería, IPS.
Caso 2 de Aplicación.
Actualización de información del cliente en VehiAlpes, desde procesos de negocio como:
Ventas, Servicio al cliente, Mercadeo.
Caso 3 de Aplicación.
Actualización de los datos básicos de un destinatario en una empresa de mensajería
desde diferentes procesos de negocio como: Distribución en Zona, Confirmaciones,
Servicio al cliente, Punto de Servicio, entre otros.
Estructura: La idea que proponemos mediante el patrón es la invocación de una señal al Integrador; al momento de generarse el evento de actualización de un dato maestro, desde cualquier proceso de negocio, éste a su vez, como respuesta, genera una cadena de señales hacia todos los procesos de negocio, sincronizando un tiempo de detención de actividades sobre el dato que se está actualizando. Una vez ha enviado todas las señales, escala a un llamado de actividad de actualización, dependiendo del dato maestro a actualizar, que contiene el código propio, definido por el proceso de negocio que gobierna al dato maestro. Y una vez finalizado la ejecución de la actividad que permite la actualización del dato. El Integrador, envía nuevamente una señal a todos los procesos, para reanudar las operaciones que utilizan el dato maestro. Finalmente los procesos reciben la señal y continúa la operación de negocio con normalidad.
Consecuencias: El uso de este modelo garantiza la aplicación de una solución a un problema común, que utiliza componentes de escalabilidad, de señales, llamados de actividades que permiten la reutilización de código y eventos informativos, de modo que lo hace flexible, modificable, escalable, proporcionando una alternativa de solución para la integración de información, en relación con la homogeneidad y gobernabilidad de Datos Maestros.
Ver Modelo en PDF
BPMN 2.0
Desarrollo de BPMN
Originalmente, BPMN fue desarrollado por Business Process Management Initiative (BPMI), un consorcio conformado por varias compañías desarrolladoras de software. Con una propuesta inicial para proveer una notación gráfica para descripciones de procesos expresada en BPML (Business Process Modeling Language), semejante a BPEL.
La primera versión de la especificación de BPMN fue desarrollada por Stephen A. White de IBM, publicada en 2004. En 2006, BPMN versión 1.0 fue oficialmente aceptada como un estándar OMG.
Innovaciones de BPMN 2.0
La versión 2.0 contiene las siguientes extensiones de tipos de diagramas existentes para procesos y modelos de colaboración:
√ Nuevos tipos de eventos: Eventos de múltiple paralelismo y escalamientos.
√ Paralelo basados en eventos.
√ Eventos subprocesos que son sólo externalizados cuando los eventos definidos, ocurren.
√ Opciones extendidas para el modelado de datos en procesos.
√ Actualizaciones de modelado de colaboración. Como ejemplo, el de participantes multi-instancia.
√ Símbolos para diferentes tipos de tareas.
√ Nuevas formas de modelado e invocación de actividades que son definidas en otro lugar.
√ Diferentes marcas de actividades multi-instancia.
√ Nuevo tipo de diagrama de coreografía.
√ Nuevo diagrama de conversación.
Considero que de los cambios más interesantes propuestos en la versión BPMN 2.0, está la introducción de los dos nuevos diagramas. Por esta razón menciono a continuación las ventajas del uso de las coreografías como reemplazo de los diagramas de colaboración:
* En una coreografía, la representación de intercambio de mensajes es independiente de los procesos asociados.
* La secuencia de mensajes intercambiados incluyen divisiones que dan mayor claridad. A diferencia de un diagrama de colaboración, que no visualiza explícitamente esta información.
* Una representación de coreografía, especialmente, para escenarios extensos, es más compacta y clara que un diagrama de colaboración con menos de un proceso público.
* Las coreografías pueden ser descompuestas con subprocesos de coreografía. Lo que genera una presentación compacta y comprensible.
* El manejo de colaboración dificulta la verificación de la compatibilidad de procesos, a diferencia de los diagramas de coreografía que pueden ser más fácilmente analizados, con respecto a la factibilidad del intercambio de mensajes.
Originalmente, BPMN fue desarrollado por Business Process Management Initiative (BPMI), un consorcio conformado por varias compañías desarrolladoras de software. Con una propuesta inicial para proveer una notación gráfica para descripciones de procesos expresada en BPML (Business Process Modeling Language), semejante a BPEL.
La primera versión de la especificación de BPMN fue desarrollada por Stephen A. White de IBM, publicada en 2004. En 2006, BPMN versión 1.0 fue oficialmente aceptada como un estándar OMG.
Innovaciones de BPMN 2.0
La versión 2.0 contiene las siguientes extensiones de tipos de diagramas existentes para procesos y modelos de colaboración:
√ Nuevos tipos de eventos: Eventos de múltiple paralelismo y escalamientos.
√ Paralelo basados en eventos.
√ Eventos subprocesos que son sólo externalizados cuando los eventos definidos, ocurren.
√ Opciones extendidas para el modelado de datos en procesos.
√ Actualizaciones de modelado de colaboración. Como ejemplo, el de participantes multi-instancia.
√ Símbolos para diferentes tipos de tareas.
√ Nuevas formas de modelado e invocación de actividades que son definidas en otro lugar.
√ Diferentes marcas de actividades multi-instancia.
√ Nuevo tipo de diagrama de coreografía.
√ Nuevo diagrama de conversación.
Considero que de los cambios más interesantes propuestos en la versión BPMN 2.0, está la introducción de los dos nuevos diagramas. Por esta razón menciono a continuación las ventajas del uso de las coreografías como reemplazo de los diagramas de colaboración:
* En una coreografía, la representación de intercambio de mensajes es independiente de los procesos asociados.
* La secuencia de mensajes intercambiados incluyen divisiones que dan mayor claridad. A diferencia de un diagrama de colaboración, que no visualiza explícitamente esta información.
* Una representación de coreografía, especialmente, para escenarios extensos, es más compacta y clara que un diagrama de colaboración con menos de un proceso público.
* Las coreografías pueden ser descompuestas con subprocesos de coreografía. Lo que genera una presentación compacta y comprensible.
* El manejo de colaboración dificulta la verificación de la compatibilidad de procesos, a diferencia de los diagramas de coreografía que pueden ser más fácilmente analizados, con respecto a la factibilidad del intercambio de mensajes.
lunes, 19 de septiembre de 2011
Diagrama de la Estructura Organizacional.
El siguiente, es el diagrama de la estructura organizacional de vehialpes, en el cual detallamos la situacion actual, mezclado con las opciones de mejora que ofrecemos al esquema actual.
Diagrama
Diagrama
domingo, 18 de septiembre de 2011
Entrega 1 Artículo
A continuación, proporcionamos el vínculo de descarga de la primera entrega del artículo, el cual estaremos desarrollando a lo largo del curso.
Entrega I Articulo
Entrega I Articulo
martes, 13 de septiembre de 2011
Version actualizada del Canvas.
Con el pasar del tiempo, hemos hecho modificaciones al canvas inicial, y ahora estamos trabajando con las ideas iniciales del mismo, transformandolas a BPMN.
Aqui publico entonces la version mas reciente de dicho canvas.
DESCARGAR EN PDF
DOCUMENTO EN GDOCS
Aqui publico entonces la version mas reciente de dicho canvas.
DESCARGAR EN PDF
DOCUMENTO EN GDOCS
lunes, 12 de septiembre de 2011
Este diagrama BPMN describe el proceso de recolección de información, el cual queremos optimizar con nuestra propuesta de cambio. Para ver el diagrama en su tamaño original, haga clic sobre él. Posteriormente, estaremos publicando el detalle de los subprocesos de Validar Información y Analizar Información.
lunes, 5 de septiembre de 2011
Patrón Top-Down para modelaje de procesos en BPMN
Este patrón pretende simplificar, a través de una serie de pasos, plasmar un proceso de negocio en la notación BPMN 2.0.
Los pasos son:
1. Definir el alcance del proceso: Se debe entender lo siguiente:
a. ¿Como empieza el proceso?.
b. ¿Que es lo que representa una instancia del proceso, quienes son los participantes del proceso?.
c. ¿Que significa el final del proceso?.
2. Definir el diagrama BPMN de nivel mas alto para el camino ideal: Normalmente los procesos siguen un flujo que va variando conforme las decisiones o los eventos que van ocurriendo, por lo que se piensa inicialmente en dibujar el curso de eventos ideal para el proceso. Se realiza mediante los siguientes pasos:
a. Adicionando los “Pools”: Los pools encierran las sucesiones de eventos y actividades que ocurren en un proceso. Cuando hay procesos externos de los que no se tiene conocimiento pleno pero que actuan de alguna forma en el proceso a modelar, se pueden dibujar en el diagrama como un pool solitario. Tambien se dibujan en pools solitarios los participantes del proceso no pertenecientes a la organización.
b. Adicionando los "lanes" a los “Pools”: Los lanes encierran las actividades y eventos cubiertos por un rol de negocio (el cual es asumido por una persona).
c. Adicionar el evento de inicio y de final del proceso: El evento de inicio puede describirse como la llegada de un mensaje (puede ser para descubrir una solicitud, la llegada de un documento) o la llegada de un evento de tiempo (como por ejemplo, cuando un proceso debe ejecutarse regularmente cada cierto tiempo). Si lo inicia un participante directamente, se define un evento de inicio básico.
d. Se identifican los pasos principales (o actividades globales) del proceso y se dibujan. Se aclara que estos pasos principales van a contener una serie de sub-pasos, por los se dibujan con la notación de las actividades de tipo subproceso.
e. Se conectan los pasos a través de flujos de secuencia (normalmente son flechas que indican el paso de una actividad a otra. Hay flujos en los que se toman decisiones para ir a una actividad un otra, o que se inician actividades en paralelo, o que esperan a que un conjunto de actividades finalice para avanzar a la siguiente. Para definir los dos ultimos flujos, se utilizan las compuertas lógicas (o gateways).
Paso 3. Se adicionan los caminos de excepción del nivel superior. Para esto, se pueden seguir estos pasos:
a. Identificar los estados de finalización no exitosa del proceso.
b. Ingresar eventos de finalización para cada estado final no exitoso del proceso.
c. Se insertan los gateways, que son compuertas para especificar condiciones que van a dirigir las actividades tanto en caso de éxito como en caso que el proceso tenga que finalizar de manera no exitosa.
Paso 4. Para cada actividad de subproceso definida, se tiene que detallar toda la secuencia de pasos que deben ocurrir para que se cumpla, y describir los pasos a los eventos de finalización no exitosa de la actividad de tipo subproceso.
Paso 5. Si se tienen Pools externos, se trazan los flujos de mensajes que van desde y hacia estos Pools por parte del proceso encerrado en un Pool.
Paso 6. Si se quiere describir flujo de datos, se pueden utilizar las figuras mensaje (tiene apariencia de carta), objeto de datos (para describir variables que cambian en el proceso, tiene apariencia de una hoja de papel) o un almacén de datos (para descubrir fuentes externas de datos que se usan de cierta forma en el proceso).
Los pasos son:
1. Definir el alcance del proceso: Se debe entender lo siguiente:
a. ¿Como empieza el proceso?.
b. ¿Que es lo que representa una instancia del proceso, quienes son los participantes del proceso?.
c. ¿Que significa el final del proceso?.
2. Definir el diagrama BPMN de nivel mas alto para el camino ideal: Normalmente los procesos siguen un flujo que va variando conforme las decisiones o los eventos que van ocurriendo, por lo que se piensa inicialmente en dibujar el curso de eventos ideal para el proceso. Se realiza mediante los siguientes pasos:
a. Adicionando los “Pools”: Los pools encierran las sucesiones de eventos y actividades que ocurren en un proceso. Cuando hay procesos externos de los que no se tiene conocimiento pleno pero que actuan de alguna forma en el proceso a modelar, se pueden dibujar en el diagrama como un pool solitario. Tambien se dibujan en pools solitarios los participantes del proceso no pertenecientes a la organización.
b. Adicionando los "lanes" a los “Pools”: Los lanes encierran las actividades y eventos cubiertos por un rol de negocio (el cual es asumido por una persona).
c. Adicionar el evento de inicio y de final del proceso: El evento de inicio puede describirse como la llegada de un mensaje (puede ser para descubrir una solicitud, la llegada de un documento) o la llegada de un evento de tiempo (como por ejemplo, cuando un proceso debe ejecutarse regularmente cada cierto tiempo). Si lo inicia un participante directamente, se define un evento de inicio básico.
d. Se identifican los pasos principales (o actividades globales) del proceso y se dibujan. Se aclara que estos pasos principales van a contener una serie de sub-pasos, por los se dibujan con la notación de las actividades de tipo subproceso.
e. Se conectan los pasos a través de flujos de secuencia (normalmente son flechas que indican el paso de una actividad a otra. Hay flujos en los que se toman decisiones para ir a una actividad un otra, o que se inician actividades en paralelo, o que esperan a que un conjunto de actividades finalice para avanzar a la siguiente. Para definir los dos ultimos flujos, se utilizan las compuertas lógicas (o gateways).
Paso 3. Se adicionan los caminos de excepción del nivel superior. Para esto, se pueden seguir estos pasos:
a. Identificar los estados de finalización no exitosa del proceso.
b. Ingresar eventos de finalización para cada estado final no exitoso del proceso.
c. Se insertan los gateways, que son compuertas para especificar condiciones que van a dirigir las actividades tanto en caso de éxito como en caso que el proceso tenga que finalizar de manera no exitosa.
Paso 4. Para cada actividad de subproceso definida, se tiene que detallar toda la secuencia de pasos que deben ocurrir para que se cumpla, y describir los pasos a los eventos de finalización no exitosa de la actividad de tipo subproceso.
Paso 5. Si se tienen Pools externos, se trazan los flujos de mensajes que van desde y hacia estos Pools por parte del proceso encerrado en un Pool.
Paso 6. Si se quiere describir flujo de datos, se pueden utilizar las figuras mensaje (tiene apariencia de carta), objeto de datos (para describir variables que cambian en el proceso, tiene apariencia de una hoja de papel) o un almacén de datos (para descubrir fuentes externas de datos que se usan de cierta forma en el proceso).
FASE DE ARQUITECTURA DE PROCESOS, DESARROLLO E IMPLEMENTACION.
FASE DE ARQUITECTURA DE PROCESOS
La fase de arquitectura de procesos es un prerrequisito para cualquier organización que desee sobrellevar actividades relacionadas con el manejo de procesos de manera exitosa de manera ágil y sostenible.
La arquitectura de procesos nos asegura que:
• Los procesos a rediseñar o desarrollar desde cero cumplen con los objetivos de la organización.
• Los procesos están alineados con la manera de hacer negocios y son capaces de proveer productos o servicios a los clientes.
• Los procesos están alienados con la arquitectura y aplicaciones TI.
• Los procesos están alineados con procesos relacionados.
• Toda información relevante y decisiones acerca de los procesos están en un mismo grupo.
• Las decisiones relevantes y los procesos de alto nivel están presentados en una manera fácilmente entendible.
La PAP se desarrolla en una serie de fases como son:
BPM scenario: la criticalidad e intensidad de esta fase será influenciada por el escenario BPM de la organización, como son:
• Administración de procesos “negocios como siempre”.
• El escenario “en la silla del conductor”.
• El escenario proyecto “piloto”.
• El escenario “por debajo del radar”.
La madurez de la organización en arquitectura: la madurez de la organización no solo está relacionada con el nivel de pensamiento de arquitectura y la implementación, sino también a la arquitectura del hacer y la disciplina de ser capaz de obedecer las disciplinas relacionadas.
Aislamiento: situaciones donde los arquitectos desarrollan una arquitectura perfecta y muy pocas personas están al tanto de ella ni saben usarla. Aquí los arquitectos deben encontrar más cohesión y compromiso del resto de la organización.
Barreras: situaciones donde los arquitectos requieren cierta cohesión con el resto de la organización pero no están muy adelantados con la arquitectura. La arquitectura va a ser muy predominante a nivel operacional pero no añade ningún valor estratégico.
Perder: la organización tiene conocimiento limitado de arquitectura y tiene integración parcial en la organización. Ocurre mucho en organizaciones donde se apagan muchos incendios por tanto no hay tiempo ni recursos para centrarse en otras opciones más estratégicas.
Permitir: la organización adopta una arquitectura como una opción permisiva clave. El problema (reto) está en que la arquitectura siga siendo una clave permisiva y no un problema.
El objetivo y el foco de la arquitectura. Antes de embarcarse en formular una arquitectura, es importante decidir el nivel del objetivo y el enfoque de la arquitectura.
La arquitectura de procesos no se logra con una serie de lineamientos preestablecidos sino con una serie de pasos:
Paso 1: obtener la estrategia e información del negocio.
Se debe obtener la siguiente información:
• Objetivos globales y principios generales además de una estrategia organizacional completada o actualizada según sea apropiado.
• Lineamientos y modelos de negocios relevantes.
• Lineamientos y modelos organizacionales relevantes.
Es importante entender lo fundamental del negocio para que la arquitectura de procesos sirva al negocio.
Adicionalmente, es necesario capturar información relevante, mayoritariamente de alto nivel como:
• Productos y servicios que están por debajo de la lógica y los principios.
• Clientes y los principios y la lógica que están por debajo.
• Política de precios y descuentos.
• Socios (incluyendo proveedores) y canales de distribución.
Obtener esta información puede ser un gran reto, más que todo el obtener la información de los principios y la lógica que hay por debajo de todo lo anterior, por que habitualmente estos principios y lógicas son considerados implícitamente.
Paso 2: obtener procesos de lineamientos y modelos.
Se debe determinar quién es el dueño del proceso, objetivo del mismo, la selección de un método de modelado y de una herramienta de administración, método de gobierno de dicho proceso, outsourcing del proceso modelos de referencia del proceso.
Adicionalmente, la arquitectura debe contener una representación grafica de alto nivel de los procesos. Este diagrama tiene varios propósitos, sin embargo esto solo funciona cuando una vista de alto nivel tiene información relevante de lo que pasa por debajo y es adoptada y usada por toda la organización.
Esto trae el beneficio de enganchar a los de administración en el modelado de los procesos.
Paso 3: obtener información relevante y modelos y principios de tecnología.
En este paso se deben obtener detalles concernientes a los aspectos relevantes de la información así como la tecnología que lo soporta.
El departamento de IT puede tener muchas herramientas y aplicaciones pero el reto está en centrarse en los principios y las opciones principales. Además es muy importante que el departamento do IT apoye los objetivos estrategias y el negocio.
Paso 4: consolidar y validar.
Toda la información es consolidada y validad para comprobar consistencia. Suele ser el paso más complicado.
Una manera de consolidar la información recolectada es el relaciona los distintos modelos de arquitectura unos con otros.
Paso 5: Comunicaciones.
Se debe socializar la arquitectura y sus beneficios con gente de peso dentro de la organización, tanto como sea posible.
Paso 6: aplicar la arquitectura.
Se debe buscar la manera de aplicar los conceptos de la arquitectura de procesos en la organización, pero para esto se deben tener mecanismos para manejar las posibles excepciones. Uno de los métodos propuestos para esto es la DYA (DYnamic Archtecture).
Paso 7: hacerlo mejor.
En este paso se puede refinar y expandir la arquitectura. Adicionalmente en este paso es importante el asegurarse que cada vez más gente esté usando la arquitectura, puesto que le beneficio real de la arquitectura de procesos se vuelve evidente con el paso del tiempo.
FASE DE DESARROLLO.
Normalmente un proyecto se desarrolla en una de dos maneras, con el ciclo SDLC o con el RAD. El modo BPM propone una serie de pasos y aproximación al problema distinto implementando una serie de pasos:
Paso 1: comunicaciones.
Durante la fase de desarrollo es importante comunicar el objetivo y la extensión de los procesos a automatizar a los stakeholders, además de dar respuesta a cada una de las preguntas que puedan surgir en un caso de automatización.
Paso 2: determinar los componentes BPM.
Aquí hay que tomar una decisión sobre cuáles son las herramientas requeridas.
Paso 3: decidir si reusar, comprar, hacer o “Outsource”.
Cada una de estas opciones tiene sus ventajas y desventajas, por tanto es necesario hacer un balance de cada una de estas, ver cuales están disponibles, cuales son viables, entre otros factores, para poder tomar una decisión.
Paso 4: actualizar las especificaciones técnicas y funcionales.
Paso 5: desarrollo de software.
Cualquier solución BPM tendrá las capas de presentación, procesos y de integración. Es crucial entender que cada una de estas capas necesita una aproximación distinta para el proceso de desarrollo y pruebas puesto que involucra distintos grupos de personas.
Paso 6: distribución de hardware
Hay que considerar una serie de problemas que pueden surgir al distribuir hardware como la compatibilidad, escalabilidad y el mantenimiento y soporte. Adicionalmente, hay que asegurarse que el hardware distribuido es exactamente igual al que se utilizo en el proceso de desarrollo.
Paso 7: pruebas.
Esta fase es crucial y debe ser adecuadamente planeada y en detalle y debe ser ubicada dentro del proyecto de manera adecuada (intentando no aplicar las pruebas cuando el proyecto este demasiado avanzado), además que se deben considerar una serie de problemas que pueden surgir durante la fase de pruebas.
FASE DE IMPLEMENTACION.
La mejor manera de asegurar una implementación sin problemas es el iniciar a considerar los problemas de la implementación al inicio del proyecto. De esa manera cuando se llegue a la fase de implementación, los esfuerzos estarán más enfocados en actualizar la información y en realizar las tareas y no en soluciones de último minutos para que la aplicación guste al usuario.
Para llevar a cabo una buena implementación, se requiere el desarrollo de los siguientes pasos:
Paso 1: comunicación.
Hay que comentarle a la gente el proyecto, recibir feedback, sugerencias entre otros. Lo ideal es considerar el feedback recibido en vez de descartarlo.
Paso 2: actualizar la estrategia de implementación.
Es importante revisar la estrategia de implementación por que el equipo del proyecto y la organización tendrán un mejor entendimiento de los cambios propuestos y la estrategia de implementación debe tomar en cuenta la situación actual, la cual puede haber cambiado sustancialmente desde los tiempos de implementación de la estrategia.
Paso 3: prepararse para la pruebas de aceptación de los usuarios.
En esta fase se requiere que usuarios reales prueben la solución, para probar integridad en un uso rutinario, así como el observar las expectativas y asunciones.
Paso 4: entrenamiento del personal.
El entrenamiento puede tomar la forma de cursos formales o entrenamiento in-situ. Obviamente el material usado para el entrenamiento debe ser consistente y el entrenamiento no debe ser realizado demasiado pronto, para prevenir la pérdida del conocimiento adquirido.
Paso 5: completar las pruebas y pilotos de negocios.
Es que donde las pruebas de aceptación de los usuarios son ejecutadas por el negocio. Se debe involucrar a todos los agentes que sean necesarios en estos escenarios, obtener feedback de cada uno de ellos, hay que estar preparados para realizar cambios, tener un mecanismo para medir y compartir los resultados entre los usuarios, entre otros factores.
Paso 6: actualizar los entregables.
Es importante el actualizar continuamente los entregables y asegurarse que los stakeholders los acepten.
Paso 7: involucrar a los administradores.
Paso 8: desarrollar roll-out, back-out y planes de contingencia.
Paso 9: desarrollar y ejecutar programas de marketing.
Paso 10: tutorar al personal.
Paso 11: roll-out changes.
Paso 12: monitorear y ajustar.
Paso 13: proveer feedback a los usuarios y stakeholders.
La fase de arquitectura de procesos es un prerrequisito para cualquier organización que desee sobrellevar actividades relacionadas con el manejo de procesos de manera exitosa de manera ágil y sostenible.
La arquitectura de procesos nos asegura que:
• Los procesos a rediseñar o desarrollar desde cero cumplen con los objetivos de la organización.
• Los procesos están alineados con la manera de hacer negocios y son capaces de proveer productos o servicios a los clientes.
• Los procesos están alienados con la arquitectura y aplicaciones TI.
• Los procesos están alineados con procesos relacionados.
• Toda información relevante y decisiones acerca de los procesos están en un mismo grupo.
• Las decisiones relevantes y los procesos de alto nivel están presentados en una manera fácilmente entendible.
La PAP se desarrolla en una serie de fases como son:
BPM scenario: la criticalidad e intensidad de esta fase será influenciada por el escenario BPM de la organización, como son:
• Administración de procesos “negocios como siempre”.
• El escenario “en la silla del conductor”.
• El escenario proyecto “piloto”.
• El escenario “por debajo del radar”.
La madurez de la organización en arquitectura: la madurez de la organización no solo está relacionada con el nivel de pensamiento de arquitectura y la implementación, sino también a la arquitectura del hacer y la disciplina de ser capaz de obedecer las disciplinas relacionadas.
Aislamiento: situaciones donde los arquitectos desarrollan una arquitectura perfecta y muy pocas personas están al tanto de ella ni saben usarla. Aquí los arquitectos deben encontrar más cohesión y compromiso del resto de la organización.
Barreras: situaciones donde los arquitectos requieren cierta cohesión con el resto de la organización pero no están muy adelantados con la arquitectura. La arquitectura va a ser muy predominante a nivel operacional pero no añade ningún valor estratégico.
Perder: la organización tiene conocimiento limitado de arquitectura y tiene integración parcial en la organización. Ocurre mucho en organizaciones donde se apagan muchos incendios por tanto no hay tiempo ni recursos para centrarse en otras opciones más estratégicas.
Permitir: la organización adopta una arquitectura como una opción permisiva clave. El problema (reto) está en que la arquitectura siga siendo una clave permisiva y no un problema.
El objetivo y el foco de la arquitectura. Antes de embarcarse en formular una arquitectura, es importante decidir el nivel del objetivo y el enfoque de la arquitectura.
La arquitectura de procesos no se logra con una serie de lineamientos preestablecidos sino con una serie de pasos:
Paso 1: obtener la estrategia e información del negocio.
Se debe obtener la siguiente información:
• Objetivos globales y principios generales además de una estrategia organizacional completada o actualizada según sea apropiado.
• Lineamientos y modelos de negocios relevantes.
• Lineamientos y modelos organizacionales relevantes.
Es importante entender lo fundamental del negocio para que la arquitectura de procesos sirva al negocio.
Adicionalmente, es necesario capturar información relevante, mayoritariamente de alto nivel como:
• Productos y servicios que están por debajo de la lógica y los principios.
• Clientes y los principios y la lógica que están por debajo.
• Política de precios y descuentos.
• Socios (incluyendo proveedores) y canales de distribución.
Obtener esta información puede ser un gran reto, más que todo el obtener la información de los principios y la lógica que hay por debajo de todo lo anterior, por que habitualmente estos principios y lógicas son considerados implícitamente.
Paso 2: obtener procesos de lineamientos y modelos.
Se debe determinar quién es el dueño del proceso, objetivo del mismo, la selección de un método de modelado y de una herramienta de administración, método de gobierno de dicho proceso, outsourcing del proceso modelos de referencia del proceso.
Adicionalmente, la arquitectura debe contener una representación grafica de alto nivel de los procesos. Este diagrama tiene varios propósitos, sin embargo esto solo funciona cuando una vista de alto nivel tiene información relevante de lo que pasa por debajo y es adoptada y usada por toda la organización.
Esto trae el beneficio de enganchar a los de administración en el modelado de los procesos.
Paso 3: obtener información relevante y modelos y principios de tecnología.
En este paso se deben obtener detalles concernientes a los aspectos relevantes de la información así como la tecnología que lo soporta.
El departamento de IT puede tener muchas herramientas y aplicaciones pero el reto está en centrarse en los principios y las opciones principales. Además es muy importante que el departamento do IT apoye los objetivos estrategias y el negocio.
Paso 4: consolidar y validar.
Toda la información es consolidada y validad para comprobar consistencia. Suele ser el paso más complicado.
Una manera de consolidar la información recolectada es el relaciona los distintos modelos de arquitectura unos con otros.
Paso 5: Comunicaciones.
Se debe socializar la arquitectura y sus beneficios con gente de peso dentro de la organización, tanto como sea posible.
Paso 6: aplicar la arquitectura.
Se debe buscar la manera de aplicar los conceptos de la arquitectura de procesos en la organización, pero para esto se deben tener mecanismos para manejar las posibles excepciones. Uno de los métodos propuestos para esto es la DYA (DYnamic Archtecture).
Paso 7: hacerlo mejor.
En este paso se puede refinar y expandir la arquitectura. Adicionalmente en este paso es importante el asegurarse que cada vez más gente esté usando la arquitectura, puesto que le beneficio real de la arquitectura de procesos se vuelve evidente con el paso del tiempo.
FASE DE DESARROLLO.
Normalmente un proyecto se desarrolla en una de dos maneras, con el ciclo SDLC o con el RAD. El modo BPM propone una serie de pasos y aproximación al problema distinto implementando una serie de pasos:
Paso 1: comunicaciones.
Durante la fase de desarrollo es importante comunicar el objetivo y la extensión de los procesos a automatizar a los stakeholders, además de dar respuesta a cada una de las preguntas que puedan surgir en un caso de automatización.
Paso 2: determinar los componentes BPM.
Aquí hay que tomar una decisión sobre cuáles son las herramientas requeridas.
Paso 3: decidir si reusar, comprar, hacer o “Outsource”.
Cada una de estas opciones tiene sus ventajas y desventajas, por tanto es necesario hacer un balance de cada una de estas, ver cuales están disponibles, cuales son viables, entre otros factores, para poder tomar una decisión.
Paso 4: actualizar las especificaciones técnicas y funcionales.
Paso 5: desarrollo de software.
Cualquier solución BPM tendrá las capas de presentación, procesos y de integración. Es crucial entender que cada una de estas capas necesita una aproximación distinta para el proceso de desarrollo y pruebas puesto que involucra distintos grupos de personas.
Paso 6: distribución de hardware
Hay que considerar una serie de problemas que pueden surgir al distribuir hardware como la compatibilidad, escalabilidad y el mantenimiento y soporte. Adicionalmente, hay que asegurarse que el hardware distribuido es exactamente igual al que se utilizo en el proceso de desarrollo.
Paso 7: pruebas.
Esta fase es crucial y debe ser adecuadamente planeada y en detalle y debe ser ubicada dentro del proyecto de manera adecuada (intentando no aplicar las pruebas cuando el proyecto este demasiado avanzado), además que se deben considerar una serie de problemas que pueden surgir durante la fase de pruebas.
FASE DE IMPLEMENTACION.
La mejor manera de asegurar una implementación sin problemas es el iniciar a considerar los problemas de la implementación al inicio del proyecto. De esa manera cuando se llegue a la fase de implementación, los esfuerzos estarán más enfocados en actualizar la información y en realizar las tareas y no en soluciones de último minutos para que la aplicación guste al usuario.
Para llevar a cabo una buena implementación, se requiere el desarrollo de los siguientes pasos:
Paso 1: comunicación.
Hay que comentarle a la gente el proyecto, recibir feedback, sugerencias entre otros. Lo ideal es considerar el feedback recibido en vez de descartarlo.
Paso 2: actualizar la estrategia de implementación.
Es importante revisar la estrategia de implementación por que el equipo del proyecto y la organización tendrán un mejor entendimiento de los cambios propuestos y la estrategia de implementación debe tomar en cuenta la situación actual, la cual puede haber cambiado sustancialmente desde los tiempos de implementación de la estrategia.
Paso 3: prepararse para la pruebas de aceptación de los usuarios.
En esta fase se requiere que usuarios reales prueben la solución, para probar integridad en un uso rutinario, así como el observar las expectativas y asunciones.
Paso 4: entrenamiento del personal.
El entrenamiento puede tomar la forma de cursos formales o entrenamiento in-situ. Obviamente el material usado para el entrenamiento debe ser consistente y el entrenamiento no debe ser realizado demasiado pronto, para prevenir la pérdida del conocimiento adquirido.
Paso 5: completar las pruebas y pilotos de negocios.
Es que donde las pruebas de aceptación de los usuarios son ejecutadas por el negocio. Se debe involucrar a todos los agentes que sean necesarios en estos escenarios, obtener feedback de cada uno de ellos, hay que estar preparados para realizar cambios, tener un mecanismo para medir y compartir los resultados entre los usuarios, entre otros factores.
Paso 6: actualizar los entregables.
Es importante el actualizar continuamente los entregables y asegurarse que los stakeholders los acepten.
Paso 7: involucrar a los administradores.
Paso 8: desarrollar roll-out, back-out y planes de contingencia.
Paso 9: desarrollar y ejecutar programas de marketing.
Paso 10: tutorar al personal.
Paso 11: roll-out changes.
Paso 12: monitorear y ajustar.
Paso 13: proveer feedback a los usuarios y stakeholders.
Administración de procesos de negocio
BPM no es una herramienta de tecnología, o una iniciativa para procesos de negocio. Es la administración que permite el logro de los objetivos de la organización a través de la mejora, gestión y control de los procesos esenciales de negocio. Es de gran importancia mejorar los procesos de negocio, antes de automatizarlos.
La administración del nivel operacional tiene como objetivo principal el logro y control de los procesos esenciales de negocio para mejorar los objetivos de la organización. Establecer la dirección y mejoramiento de procesos de negocio es un paso definitivo que debe ser abordado por la alta dirección.
Otro aspecto importante a tener en cuenta, antes de considerar la implementación de la tecnología, como herramienta para el mejoramiento de los procesos de negocio, es que, si bien la introducción de tecnología, puede ser de gran contribución, no siempre es requerida para que el mejoramiento de los procesos sea exitoso.
Es responsabilidad de la dirección ejecutiva asegurarse de que existe un vínculo claro entre los proyectos de mejora de procesos realizados por la empresa, y la estrategia de la organización y sus objetivos. Si no es posible evidenciar la forma en que el proyecto de mejora de los procesos, contribuye y aporta un valor significativo a los objetivos de la organización, el proyecto no debería llevarse a cabo.
Para efectuar un diagnóstico adecuado en relación con la efectividad de los procesos de negocio, es necesario evaluar cómo los componentes críticos de la organización, son sincronizados:
· Intención Estratégica
· Visión estratégica
· Ejecución
· Valores, cultura y comportamiento
· Las personas
Una vez evaluada la efectividad y viabilidad de implementar la tecnología al proyecto de mejoramiento de los procesos, se plantean alternativas como frameworks que permiten modelar los procesos a partir de las bases y las reglas de negocio que soportan la operación de la organización, alineándolas con BPM, de acuerdo con la estrategia general de negocio. A través de las distintas fases del framework:
· Estrategia de la organización
· Proceso de arquitectura
· Plataforma de ejecución
· Entendimiento
· Innovación
· Desarrollo
· Las personas
· Implementación
· Evidenciar el valor.
· Rendimiento sostenible
lunes, 29 de agosto de 2011
Modelo propuesto: Prototipo 1 - Canvas
Link: Canvas actual versión 2
Como problema a tratar hemos escogido la postventa en el manejo de repuestos originales, teniendo en cuenta que la participación en el mercado de la marca que importa vehiAlpes es del 30%, el 70% restante queda en los talleres particulares y el uso de repuestos no originales por parte de los propietarios.
Link: Prototipo Canvas
Proceso de diseño del Modelo de Negocio
Para diseñar un proceso de negocio, debemos tener en cuenta que el logro de los objetivos dependerá del proyecto y del establecimiento de la relación entre el alcance del proyecto y los principales objetivos. El Canvas de modelo de negocio es el lenguaje almacenado para el diseño de esfuerzos. Este ayuda a estructurar y presentar ideas preliminares y mejorar las comunicaciones, mediante la presentación gráfica de un lenguaje común de negocio. Para ello desarrolla el diseño mediante una planeación inicial que deberá cubrir las primeras fases del diseño de proyecto de un modelo de negocio: Movilizar, entender y diseñar.
El proceso de diseño del modelo de negocio, requiere del desarrollo de las fases:
El proceso de diseño del modelo de negocio, requiere del desarrollo de las fases:
- Movilizar: A través de la cual efectuamos la gestión de los intereses creados, legitimar el proyecto, constituir un equipo de trabajo multifuncional, con orientación de los tomadores de decisiones, de modo que se optimiza la planeación, estimando un tiempo razonable, para la educación, orientación y preparación para abrir la mente hacia procesos que implican un cambio. De modo que podamos trabajar en el concepto más difícil al que nos enfrentamos al momento de presentar un diseño y es la resistencia al cambio. Las actividades a realizar en esta fase son:
* Objetivos del marco de proyecto.
* Ideas de negocio preliminares para pruebas
* Plan
* Asamblea de aprendizaje
Factores Críticos de éxito:
* Personal calificado, con experiencia y conocimiento.
Peligros Clave:
* Sobreestimar el valor de las ideas iniciales.
Las actividades cruciales en esta primera fase incluyen el montaje del proyecto, con el acceso a las personas adecuadas y a la información correcta: Ideas frescas, redes de personal capacitado.
* Sobreestimar el valor de las ideas iniciales.
Las actividades cruciales en esta primera fase incluyen el montaje del proyecto, con el acceso a las personas adecuadas y a la información correcta: Ideas frescas, redes de personal capacitado.
- Entendimiento: En esta fase las actividades que se realizan son: Análisis del ambiente, estudio de los clientes potenciales, entrevistas con expertos, investigaciones, recopilación de ideas y opiniones.
- Diseño: Fase en la que se desarrolla la lluvia de ideas, generación de los Prototipos que satisfacen la evolución de las ideas propuestas, pruebas y selección del modelo que más se ajusta a las necesidades del negocio.
- Implementación: Comunicar e involucrar. Debe plantear la habilidad para adaptarse al nuevo modelo de negocio, aprovechando el desarrollo y logros de las etapas previas, como el entendimiento, en donde se ha adelantado la labor de involucrar a los participantes de los procesos de negocio y que ahora serán aliados estratégicos para la implementación del mismo.
- Administración: Evaluación permanente del modelo de negocio. Actualizar o replantear el modelo de negocio, alinear los modelos de negocio en toda la organización. Y administrar sinergias o conflictos entre los modelos. A través de gobiernos de modelos de negocio. Que podrán retroalimentarse y tomar decisiones oportunas que permitan la maduración y mejoras del proceso de negocio.
Para el caso de VehiAlpes, consideramos que la fase en la que debemos dedicar mayor esfuerzo, es en la de entendimiento, para poder involucrar a los socios de negocio, específicamente los talleres, para que estén dispuestos a aportar y participar activamente dentro del nuevo modelo de negocio propuesto, dados los beneficios económicos que este les propone.
Suscribirse a:
Entradas (Atom)