Aun cuando estamos en un blog de desarrollo, por lo que los temas deben ser técnicos en su mayoría, la tendencia actual es la de estrechar la brecha existente entre los departamentos de tecnología de las organizaciones y los especialistas del negocio.
Esta brecha ha sido mantenida, y en muchos casos incrementada, por una incorrecta comprensión de la relación entre tecnología y negocio y el cómo esta relación puede ayudar y facilitar la obtención de los objetivos empresariales.
Para nadie es un secreto que mientras mejor funcionen las aplicaciones en una organización y mientras mejor y más rápido estas respondan a los intereses del negocio, pues más ganancias y mayor visibilidad tendrá la organización.
Si partimos entonces de lo anterior debemos asumir que los arquitectos y desarrolladores deben tener una mejor comprensión del negocio de sus empresas y tratar por todos los medios que las arquitecturas estén preparadas para responder a los cambios y exigencias del negocio que siempre busca adaptarse a las necesidades circundantes, esto se puede reafirmar a través de este blog [1] donde se deja bien claro que un negocio necesita de una persona técnica con conocimiento pleno del mismo para poder tomar decisiones técnicas oportunas y efectivas.
Por lo general esto no se ha cumplido y eso ha motivado que la situación de muchas empresas sea que tienen múltiples sistemas desarrollados en múltiples plataformas, lenguajes, tecnologías, y que cuando se integran entre sí, esta integración se presenta punto a punto de la siguiente manera.
Fig. 1. Esquema de integración punto a punto que refleja el estado de muchas empresas en la actualidad.
En este sentido y en el área de las tecnologías hay varios paradigmas que han dejado bien claro la certeza de todo lo anterior, me refiero a: SOA y BPM.
Para aquellos que no lo sepan SOA se refiere a “Service Oriented Architecture” y BPM se refiere a “Bussiness Process Management”. En español “Arquitectura Orientada a Servicios” y “Gestion de Procesos de Negocio” respectivamente.
SOA, es un tema de arquitectura que se ha constituido en un paradigma para el diseño de las arquitecturas de las empresas y sistemas. Básicamente busca exponer los recursos del negocio como servicios, independientemente de la aplicación o BD donde residan, que puedan ser consumidos desde la misma empresa y por clientes y socios externos. Debemos entender por recursos del negocio los datos, información y funcionalidades de las aplicaciones que se corresponden con actividades del negocio, y debemos entender por servicio la forma de relación entre un proveedor del recurso y el consumidor de dicho recurso. Esta forma de relación se establece por lo general a través de un contrato entre ambas partes asegurado por acuerdos de nivel de servicio que determina la calidad de los servicios brindados.
Una idea de lo que propone SOA se puede obtener de la siguiente imagen:
Fig. 2. Esquema que muestra la propuesta general detrás de SOA. Crear capas de servicios que sean consumidos por procesos de negocio y expuestos a través de interfaces.
Estas interfaces pueden ser nuevos sistemas compuestos, que se nutren de funcionalidades y datos de sistemas legados ya existentes. También pueden ser interfaces como portlets desplegados en portales empresariales.
BPM por su parte, se encarga de organizar los procesos de negocio de tal manera que respondan a los objetivos y estrategia de negocio de una forma más efectiva y ágil. Se apoya en técnicas de modelado, diseño, implementación, ejecución y pruebas que aplicados a partir de herramientas informáticas agiliza el desarrollo de aplicaciones y acerca este desarrollo al personal no técnico. Al modelar los procesos de negocio se permite que tanto el personal técnico como el no técnico tengan claridad sobre el funcionamiento de estos procesos y si se puede diseñar y simular su funcionamiento entonces se pueden optimizar. Si además estos procesos se pueden modificar de forma fácil y rápida, pues se responde más prontamente a los cambios del negocio y si todo esto se puede llevar al nivel de aplicaciones pues entonces tenemos aplicaciones más cercanas al funcionamiento real del negocio.
Fig. 3. Esquema general detrás de BPM. Diseñar procesos de negocio basados en la estrategia de negocio que consuman información de los sistemas subyacentes y que respondan a los intereses de los stakeholders.
La relación entre SOA y BPM comienza a hacerse clara cuando entendemos que los procesos de negocio se descomponen en actividades y si consideramos estas actividades como recursos del negocio y por lo tanto servicios podemos llegar a la clara conclusión de que SOA permite exponer los recursos del negocio como servicios y estos servicios son consumidos por los procesos de negocio en su implementación dentro de las aplicaciones. Esta relación apoya la idea inicial de reducir la brecha entre tecnología y negocio al lograr que el personal del negocio comprenda mejor el funcionamiento de las aplicaciones y que el personal técnico domine mejor el funcionamiento del negocio.
Una idea general de esta solución se puede apreciar en la siguiente imagen:
Fig. 4. Esquema general de una arquitectura de integración basada en SOA y BPM.
Las funcionalidades relacionadas con BPM están en la parte más alta de la arquitectura SOA nutriéndose de las funcionalidades y datos que esta provee. Por su parte SOA se encarga del acceso a datos y de las soluciones de integración e interoperabilidad entre sistemas proveyendo un acceso limpio desde las soluciones BPM.
Un poco más a detalle podemos decir que las aplicaciones legadas serán accedidas desde servicios de datos o desde soluciones de integración y sus datos y funcionalidades serán consumidas por soluciones basadas en BPM, tal y como se muestra en la siguiente imagen.
Fig. 5. Esquema interno de una solución BPM que utiliza funcionalidades y datos provistos por una solución SOA que brinda acceso mediante servicios a sistemas legados.
Ahora bien, si buscan en internet verán mucho revuelo desde el 2000 hacia acá con estos 2 paradigmas y esto se debe a que al globalizarse el comercio, profundizarse el uso de internet y al haber una explosión de nuevas tecnologías, aplicaciones y formas de realizar negocios las empresas se han enfrentado a un conjunto de problemas relacionados con la integración e interoperabilidad de sus sistemas y con la interacción con sistemas externos.
Luego de esta introducción un poco tardía, debe quedar claro que el objetivo de este blog es ir mostrando ideas, estrategias y soluciones para los problemas de integración e interoperabilidad que se presentan en el día a día de cualquier arquitecto de software.
Ya se han posteado varias entradas relacionadas fundamentalmente con SOA y quisiera hacer una serie relacionada con BPM con la ayuda de la herramienta Bonita BPMS.
[1] http://www.javiergarzas.com/2013/04/tu-negocio-no-va-a-funcionar.htm
Esta brecha ha sido mantenida, y en muchos casos incrementada, por una incorrecta comprensión de la relación entre tecnología y negocio y el cómo esta relación puede ayudar y facilitar la obtención de los objetivos empresariales.
Para nadie es un secreto que mientras mejor funcionen las aplicaciones en una organización y mientras mejor y más rápido estas respondan a los intereses del negocio, pues más ganancias y mayor visibilidad tendrá la organización.
Si partimos entonces de lo anterior debemos asumir que los arquitectos y desarrolladores deben tener una mejor comprensión del negocio de sus empresas y tratar por todos los medios que las arquitecturas estén preparadas para responder a los cambios y exigencias del negocio que siempre busca adaptarse a las necesidades circundantes, esto se puede reafirmar a través de este blog [1] donde se deja bien claro que un negocio necesita de una persona técnica con conocimiento pleno del mismo para poder tomar decisiones técnicas oportunas y efectivas.
Por lo general esto no se ha cumplido y eso ha motivado que la situación de muchas empresas sea que tienen múltiples sistemas desarrollados en múltiples plataformas, lenguajes, tecnologías, y que cuando se integran entre sí, esta integración se presenta punto a punto de la siguiente manera.
Fig. 1. Esquema de integración punto a punto que refleja el estado de muchas empresas en la actualidad.
En este sentido y en el área de las tecnologías hay varios paradigmas que han dejado bien claro la certeza de todo lo anterior, me refiero a: SOA y BPM.
Para aquellos que no lo sepan SOA se refiere a “Service Oriented Architecture” y BPM se refiere a “Bussiness Process Management”. En español “Arquitectura Orientada a Servicios” y “Gestion de Procesos de Negocio” respectivamente.
SOA, es un tema de arquitectura que se ha constituido en un paradigma para el diseño de las arquitecturas de las empresas y sistemas. Básicamente busca exponer los recursos del negocio como servicios, independientemente de la aplicación o BD donde residan, que puedan ser consumidos desde la misma empresa y por clientes y socios externos. Debemos entender por recursos del negocio los datos, información y funcionalidades de las aplicaciones que se corresponden con actividades del negocio, y debemos entender por servicio la forma de relación entre un proveedor del recurso y el consumidor de dicho recurso. Esta forma de relación se establece por lo general a través de un contrato entre ambas partes asegurado por acuerdos de nivel de servicio que determina la calidad de los servicios brindados.
Una idea de lo que propone SOA se puede obtener de la siguiente imagen:
Fig. 2. Esquema que muestra la propuesta general detrás de SOA. Crear capas de servicios que sean consumidos por procesos de negocio y expuestos a través de interfaces.
Estas interfaces pueden ser nuevos sistemas compuestos, que se nutren de funcionalidades y datos de sistemas legados ya existentes. También pueden ser interfaces como portlets desplegados en portales empresariales.
BPM por su parte, se encarga de organizar los procesos de negocio de tal manera que respondan a los objetivos y estrategia de negocio de una forma más efectiva y ágil. Se apoya en técnicas de modelado, diseño, implementación, ejecución y pruebas que aplicados a partir de herramientas informáticas agiliza el desarrollo de aplicaciones y acerca este desarrollo al personal no técnico. Al modelar los procesos de negocio se permite que tanto el personal técnico como el no técnico tengan claridad sobre el funcionamiento de estos procesos y si se puede diseñar y simular su funcionamiento entonces se pueden optimizar. Si además estos procesos se pueden modificar de forma fácil y rápida, pues se responde más prontamente a los cambios del negocio y si todo esto se puede llevar al nivel de aplicaciones pues entonces tenemos aplicaciones más cercanas al funcionamiento real del negocio.
Fig. 3. Esquema general detrás de BPM. Diseñar procesos de negocio basados en la estrategia de negocio que consuman información de los sistemas subyacentes y que respondan a los intereses de los stakeholders.
La relación entre SOA y BPM comienza a hacerse clara cuando entendemos que los procesos de negocio se descomponen en actividades y si consideramos estas actividades como recursos del negocio y por lo tanto servicios podemos llegar a la clara conclusión de que SOA permite exponer los recursos del negocio como servicios y estos servicios son consumidos por los procesos de negocio en su implementación dentro de las aplicaciones. Esta relación apoya la idea inicial de reducir la brecha entre tecnología y negocio al lograr que el personal del negocio comprenda mejor el funcionamiento de las aplicaciones y que el personal técnico domine mejor el funcionamiento del negocio.
Una idea general de esta solución se puede apreciar en la siguiente imagen:
Fig. 4. Esquema general de una arquitectura de integración basada en SOA y BPM.
Las funcionalidades relacionadas con BPM están en la parte más alta de la arquitectura SOA nutriéndose de las funcionalidades y datos que esta provee. Por su parte SOA se encarga del acceso a datos y de las soluciones de integración e interoperabilidad entre sistemas proveyendo un acceso limpio desde las soluciones BPM.
Un poco más a detalle podemos decir que las aplicaciones legadas serán accedidas desde servicios de datos o desde soluciones de integración y sus datos y funcionalidades serán consumidas por soluciones basadas en BPM, tal y como se muestra en la siguiente imagen.
Fig. 5. Esquema interno de una solución BPM que utiliza funcionalidades y datos provistos por una solución SOA que brinda acceso mediante servicios a sistemas legados.
Ahora bien, si buscan en internet verán mucho revuelo desde el 2000 hacia acá con estos 2 paradigmas y esto se debe a que al globalizarse el comercio, profundizarse el uso de internet y al haber una explosión de nuevas tecnologías, aplicaciones y formas de realizar negocios las empresas se han enfrentado a un conjunto de problemas relacionados con la integración e interoperabilidad de sus sistemas y con la interacción con sistemas externos.
Luego de esta introducción un poco tardía, debe quedar claro que el objetivo de este blog es ir mostrando ideas, estrategias y soluciones para los problemas de integración e interoperabilidad que se presentan en el día a día de cualquier arquitecto de software.
Ya se han posteado varias entradas relacionadas fundamentalmente con SOA y quisiera hacer una serie relacionada con BPM con la ayuda de la herramienta Bonita BPMS.
[1] http://www.javiergarzas.com/2013/04/tu-negocio-no-va-a-funcionar.htm
Entradas
Introducción a SOA y BPM. Recapitulando.