lunes, 22 de diciembre de 2014

Feliz Navidad y Exitos en 2015 !


Ya hace un año que felicitábamos las fiestas desde Chakray Consulting, recién nacidos en el mes de Noviembre de 2013 ... como pasa el tiempo. En aquel entonces, con el lema "Tiempo para Crecer"

Finalizando 2014 y muy cercano ya 2015, queremos enviar a todos nuestros clientes, colaboradores y amigos una felicitación desde el optimismo que nos llena el ya ser un referente en el mercado para Soluciones de "Midleware" basadas en la Suite WSO2. 

Feliz Navidad y entrada genial al 2015, que este, sea un año de éxitos. Nosotros, comenzaremos como acabamos, con una apuesta por hacer bien las cosas, con la tecnología adecuada , como soporte al negocio de nuestros clientes.

Un abrazo a todos
Chakray Consulting

lunes, 14 de abril de 2014

Integracion de Sistemas a traves de Servicios. Arquitectura Chakray


Documento realizado por el Equipo de Chakray que muestra varios casos de Uso de la Arquitectura de Referencia(SOA + BPM)  con la que abordamos consultorias y desarrollos mediante uso de ESB (ESB WSO2) + Bonita BPM .

Un Enterprise Service Bus (ESB) es un software destinado a la integración de aplicaciones. Su cometido es facilitar el ofrecimiento y la demanda de servicios, gracias a la creación y la gestión de distintos flujos de datos, de manera totalmente transparente . En la configuración del ESB se detalla la lógica que orquestara la arquitectura mediante BPM , que básicamente se activa a partir de eventos automatizados o que son lanzados por las propias aplicaciones. La configuración puede interpretarse como una capa de abstracción.
Las características más destacadas de un ESB son las siguientes:
  • Es una plataforma de integración basada en estándares de comunicación abiertos: Actualmente el ESB se ha convertido en la forma de integrar la multitud de aplicaciones utilizadas a nivel corporativo, y se puede considerar la siguiente generación de herramientas EAI disponibles en el mercado. 
  • Combina los paradigmas SOA y EDA: El ESB combina la potencia de la arquitectura orientada a servicios con la versatilidad de la arquitectura dirigida por eventos. 
  • Está basado en la naturaleza síncrona de los servicios y asíncrona de los eventos: El ESB provee una capa de abstracción que facilita la asincronía de la que carecen las aplicaciones o servicios. 
  • Contiene herramientas para configurar el flujo de los mensajes, de forma que es posible transformar (mediante tecnologías estandarizadas de transformación de formatos como XSLT o XPath), duplicar, filtrar, y añadir seguridad y control de acceso (p. ej., con Spring Security) a todas las transacciones. 

sábado, 22 de febrero de 2014

Tiempo Real no es sinónimo de “rapidez“


Últimamente, se esta escribiendo mucho sobre Tiempo Real, TR en Big Data, en Social Media,en IoE (Internet de todas las cosas), en IoT( de las cosas), en IIOT (Internet Industrial de las cosas) etc etc .Se hace referencia a una serie de  sistemas como de Tiempo Real cuando solo se quiere decir que el sistema es  o debe ser rápido (o con la menor latencia posible) ...

“Tiempo Real” no es sinónimo de rapidez

Un sistema de tiempo real es aquel en el que para que las operaciones estén correctas no depende tan solo que la lógica e implementación de los programas  fue correcta, sino también en el tiempo en el que dicha operación entregó su resultado. Si las restricciones de tiempo no son respetadas el sistema se dice que ha fallado.”  Donald Gillies.

En los Sistemas TR no es la latencia de la respuesta lo que nos determina o condiciona (esta latencia a veces esta en el orden de los segundos), el enfoque en tiempo real de la latencia es el asegurarse que la latencia del sistema es la suficiente, para resolver el problema al cual el sistema está dedicado (cumpliendo obviamente la funcionalidad requerida).


Un Sistema TR :Tiempo, principal restricción a tener en cuenta y Real, que trabaja sobre un Sistema Real (siempre que sea Predecible [Determinista para los puristas])

Un buen ejemplo es el de un robot que necesita tomar una pieza de una banda sinfín. Si el Robot llega tarde, la pieza ya no estará donde debía recogerla. Por lo tanto, el trabajo se llevó acabo incorrectamente, aunque el robot haya llegado al lugar adecuado. Si el robot llega antes que la pieza llegue, la pieza aun no estará ahí y el robot puede bloquear su paso. El robot puede necesitar un rango de mili segundos para realizar la operación o de segundos.

Los Sistemas de adquisición que alimentan a plataformas BigData no son predecibles. No son Sistemas TR . Son Sistemas que buscan  Mínima Latencia“ (máximo Throughput)


Algunas características de los sistemas informáticos que se suelen utilizar y que los hacen inadecuados para el tiempo real por hacerlos no predecibles son:
    • Memoria caché y pipe-line: Una misma instrucción de código máquina puede ejecutarse en más o menos tiempo según la historia del programa.
    • Interrupciones no controladas: El tratamiento de las interrupciones puede introducir una sobrecarga excesiva, que puedan impedir que un programa finalice en el tiempo adecuado.
    • Memoria virtual: La paginación de memoria en disco introduce retardos en los procesos que pueden retrasar en exceso su activación
    • Protocolos de comunicación no deterministas: Colisiones, reenvíos, etc. En el caso de un sistema distribuido los tiempos consumidos en el paso de información debe estar acotado.
Es por ello que los Sistemas TR necesiten de Sistemas Operativos, Protocolos de Comunicación y Lenguajes de Programación diferentes a los Sistemas Informáticos en otras disciplinas. 

Una clasificación de Sistemas en TR atendiendo a la criticidad en función del fallo en el tiempo de latencia de un proceso:
    • TR Duro (Hard Real Time Systems): El tener un fallo en el tiempo de latencia de un proceso del sistema lleva como consecuencia un error en el sistema
    • TR Suave: (Soft Real Time Systems): El tener un fallo en un proceso del sistema no conlleva un fallo en el sistema siempre y cuando este fallo esté dentro de ciertos límites establecidos
    • TR misión crítica El  funcionamiento incorrecto del sistema puede llevar a la pérdida de vidas o catástrofes similares 

sábado, 8 de febrero de 2014

Integración en la Empresa Industrial (I)


La Gestión Integral de una Empresa Industrial con aplicaciones diferentes que cubren , tanto la supervisión y control de planta, como la gestión comercial y el negocio en general , donde cada departamento adquiere Software con distintas características tecnológicas (metadatos, lenguajes de programación, interfaces de usuario , etc..) es uno de los mayores retos a los que creo se enfrenta en los próximos tiempos el mundo de los Sistemas de Información .

El mayor reto nace del 'Gap' existente entre los sistemas de información que supervisan los Entornos Empresariales y los Sistemas de Información que supervisan los Entornos en Planta. 
'Gap' debido a la necesidad de ambos de Gestionar de manera eficiente en base, el Empresarial a la Inteligencia de Negocio y, y el de Planta a la Inteligencia Operacional, la información necesaria para la toma de decisiones en sus ámbitos inmediatos.

El Entorno Empresarial quiere
  •  Conocer el Estado de cada una de las órdenes de fabricación.
  • Conocer los Recursos utilizados para ejecutar las órdenes: Personal y Equipos
  • Conocer el Tiempo empleado por cada recurso.
  • Conocer las Cantidades de Materiales consumidos y producidos.
  • Conocer los Lotes de Materiales consumidos y producidos. Trazabilidad.
  • Conocer los Parámetros del Control de Calidad, Puntos Críticos. QM/QI.

Para definir sus Sistemas de Información de Negocio y los KPIs del BI

El Entorno en Planta Quiere
  •  Conocer el Estado de cada uno de los Equipos.
  • Conocer los Tiempos y Causas de Parada de equipos, líneas, etc.
  • Conocer los Tiempos, Materiales y Personal de intervenciones de mantenimiento.
  • Conocer las Condiciones de Operación de los procesos críticos.
  • Conocer los estudios de Capacidad y Gráficos de Control predictivos, SPC.

Para definir sus Sistemas de Información de Operacion y los KPIs del OI


Una visión jerárquica del conglomerado de aplicaciones de apoyo a la supervisión de la planta da idea de la complejidad que la información correcta este disponible en el momento correcto y en lugar correcto en cada uno de los pasos involucrados en los procesos de fabricación y distribución dentro de la cadena de suministro.


Obviamente, la solución pasa por la integración de ambos entornos. En la actualidad nos encontraremos con tres Situaciones:

Sistemas Manuales

Se utilizan albaranes/partes/… para enviar órdenes a la planta y para recibir los datos de producción (Enlace de Integracion debil y muy acoplado). Finalmente, los datos de producción se 'pican' al ERP.

Si se usa para intercambiar poca información no suele ser caro. Pero, tienen varios inconvenientes:
  • El Mantenimiento es muy costoso
  • Cada vez que se modifica o actualiza cualquiera de ambos entornos, es necesario modificar el enlace de integración.
  • No es desplegable a otros casos o plantas

Sistemas Propietarios . Ejemplo MICROSOFT AXAPTA, SAP, ORACLE, etc

Solucionan Gran parte del Problema pero, aparte de presentar Soluciones monolíticas y difícilmente Interoperables con tras plataformas:

  • Sigue existiendo una gran barrera, de tal forma que desde el Entorno Empresarial sólo se puede ver y analizar los datos una que vez que estos han sido transferidos desde Entorno de Planta.
  • No es posible acceder a datos detallados del Entorno de Planta para consultar excepciones, tomar una decisión, conocer el estado real de un determinado lote, etc., y menos aún en tiempo real.
  • No existe transparencia. Los parámetros, variables, recursos, servicios, etc. tienen distintos nombres y probablemente no significan lo mismo en ambos sistemas. No es posible disponer de Dashboards.

Sistemas Interoperables Basados en Standares Internacionales:

La capacidad de las aplicaciones a nivel de producción y los sistemas de negocio, ambos basados en estándares, para compartir información e intercambiar servicios y cooperar en los procesos utilizando la información y los servicios.

Este sera el caso de análisis de mi siguiente post :)

viernes, 17 de enero de 2014

La Arquitectura Empresarial


Según Gartner, "Arquitectura Empresarial es el proceso de trasladar una visión y estrategia de negocio en un cambio efectivo, comunicando las capacidades actuales y repensando los principios y los modelos que describen el estado futuro de la empresa y facilitan su evolución".
AE es una práctica estratégica, que permite conectar las relaciones entre las iniciativas de negocio y la tecnología que la apalanca,  permite evaluar las fortalezas y debilidades, y trazar estrategias de transformación, desde la Arquitectura actual hacia un modelo Arquitectónico que represente una visión futura.

La AE nos permite observar como las estrategias y metas, componentes y Procesos de Negocio y Tecnologías están relacionadas y mostrar la interdependencia entre ellas. 
"Los proyectos de tecnología deben existir exclusivamente como parte de las estrategias de negocio de la empresa."
EA permite enfocar los problemas de una forma integrada y coherente, al mismo tiempo que ofrece un medio para alcanzar un entendimiento y conceptualización entre todos los involucrados en las decisiones de la empresa.

Una muy buena practica al implementar una AE es usar un modelo de referencia para lo cual TOGAF (The Open Group Architecture Framework) es una excelente alternativa, es un marco de trabajo de Arquitectura Empresarial que proporciona un enfoque para el diseño, planificación, implementación y gobierno de una arquitectura empresarial de información.

TOGAF se basa en cuatro dimensiones:
1.    Arquitectura de Negocios (o de Procesos de Negocio), la cual define la estrategia de negocios, la gobernabilidad, la estructura y los procesos clave de la organización.
2.    Arquitectura de Aplicaciones, la cual provee un plano (blueprint, en inglés) para cada uno de los sistemas de aplicación que se requiere implantar, las interacciones entre estos sistemas y sus relaciones con los procesos de negocio centrales de la organización.
3.    Arquitectura de Datos, la cual describe la estructura de los datos físicos y lógicos de la organización , y los recursos de gestión de estos datos
4.    Arquitectura Tecnológica, la cual describe la estructura de hardware, software y redes requerida para dar soporte a la implantación de las aplicaciones principales, de misión crítica, de la organización