Archives

Si existe una característica que distingue al mundo informático es el uso de siglas. Dos extremadamente comunes dentro del mundo IT (Information Technology) son BPM (Business Process Management) y BPEL (Business Process Execution Language). Ambos enfoques enfatizan la necesidad de contar con un modelo que describa las reglas del negocio del sistema y cómo la información y el control cambia de manos a medida que se procesa una determinada funcionalidad del sistema.

En lo que resta del artículo se profundizará sobre sus diferencias, los objetivos que persigue cada uno, y cómo pueden combinarse para lograr un sistema IT exitoso.

BPEL y BPM: Similitudes y Diferencias

Si bien ambos enfoques comparten el hecho de concentrarse en procesos de negocios, es importante a destacar sus diferencias. BPM es una metodología, un esquema que propone distintas actividades y herramientas para organizar, administrar y monitorear los procesos de negocio. Incluye descripción de actividades humanas, de gestión, y también, toda la parte relativa a la funcionalidad en sí del proyecto. En cambio, BPEL, es un lenguaje para describir cómo se conectarán e interactuarán los distintos servicios del sistema. Luego, se puede pensar a BPEL como una de las herramientas dentro de BPM. Adicionalmente, como se plantea en la referencia [1], al enfocarse BPEL en la composición de servicios, no provee funcionalidad para actividades de análisis y monitoreo.

En la referencia [2] se profundizan y se brindan más detalles respecto de distintas características que distinguen a un enfoque del otro. Al ser BPEL un lenguaje mucho más técnico, se requieren más conocimientos específicos de tecnología. En cambio, en BPM son más necesarios conocimientos de gestión.

La segunda distinción es respecto a herramientas gráficas. Mientras que BPEL no tiene asociada ninguna notación en particular, BPM puede ser modelado a través del lenguaje gráfico BPMN (Business Process Modeling Notation). Otra diferencia radica en el peso que tenga la interacción de servicios. En una interacción compleja de servicios es cuando se exhiben con más naturalidad las ventajas de emplear BPEL. En cambio, cuando hay mayor interacción humana en el proceso o en la toma de decisiones, un esquema BPM se adapta mejor. En cuanto al trabajo en equipo, BPM tiene mayor facilidad para incluirlo en sus outputs.

Sin embargo, también existen puntos de encuentro. Ambos esquemas promueven el desarrollo de procesos reusables, minimizando el acoplamiento y maximizando la interacción Finalmente, ambos manejan formatos XML, por lo que requieren ser traducidos a un lenguaje ejecutable para ser procesados.

Combinando BPEL y BPM

En la referencia [3] se describe un escenario donde ambos enfoques son utilizados de manera cooperativa, logrando así aumentar el potencial de cada uno. El contexto es dentro del ambiente Oracle, donde se combinaron Oracle BPEM and BPM en un proyecto para la describir la composición de servicios.

En primera instancia, se utilizó BPM para modelar los procesos de negocio, entendidos por todos los involucrados en el proyecto, los cuales tenían amplio conocimiento de los mismos: ejecutivos, gerentes, managers, expertos del dominio, analistas y desarrolladores. Luego, a través de un diagrama de flujo de actividad, se dio a conocer de manera intuitiva cuál era el problema a atacar y cómo el proceso resolvería el problema.

Se utilizó BPEL para denotar la composición de los servicios IT involucrados. Para exponer los procesos BPEL se recurrió al service bus (componente que permite comunicar componentes en una arquitectura orientada a servicios). Esto permitía invocar desde BPM funcionalidad especificada en BPEL. Alternativamente, de no contar con un service bus, se podría invocar al proceso BPEL directamente desde la herramienta Oracle BPM a través del catálogo oficial de servicios Oracle.

Conclusiones

Tanto BPEL como BPM se enfocan en modelar reglas y procesos de negocio. BPEL puede ser considerado un subconjunto de BPM, ya que este último ofrece toda una metodología más general. En algunas ocasiones pueden combinarse, e incluir llamadas a procesos BPEL dentro de la descripción de alguna actividad en BPM, como se mencionó en el ejemplo de Oracle. Esta misma colaboración es repetible en otras herramientas y tecnologías, no siendo algo que exclusivo de Oracle. Conociendo sus diferencias, y los objetivos de cada una, se logrará maximizar el potencial de emplear ambos enfoques en IT.

Referencias:
[1] http://www.experts123.com/q/whats-the-difference-between-bpm-and-bpel.html?utm_expid=13366266-1
[2] http://oraclesoabpm.blogspot.com.ar/2011/03/bpel-vs-bpm.html
[3] https://forums.oracle.com/thread/994735

Una arquitectura SOA es una estructura compleja que provee comunicación y facilita la interacción de los distintos servicios y componentes que componen un sistema. Una vez que la arquitectura de comunicación está definida, por ejemplo a través de un service bus, el paso siguiente es definir qué servicios hay que implementar.

Puede existir en este punto una lucha de intereses. Algunos sectores querrán priorizar servicios técnicos, como manejo de contención de recursos o seguridad y permisos, contemplando autenticación y autorización. Sin embargo, según la referencia [1] es crítico comenzar identificando los servicios de negocio. Es decir, identificar y establecer los requerimientos y los servicios que los implementan. Para tal fin se proponen tres etapas: identificar los servicios, relevar sus requerimientos, y finalmente, documentarlos.

Etapa 1: Identificar los servicios de negocio

En este punto es importante detectar servicios que cumplan las siguientes características: que tengan poca interacción con otros y que sean relevantes, de manera de poder observar con mayor claridad el retorno de inversión en los mismos.

Existen dos grandes aproximaciones a la identificación de servicios: un enfoque TOP-DOWN y un enfoque BOTTOM UP. En el primero se recomienda empezar por casos de uso de negocio de alto nivel o flujos de procesos de negocio que ya existan en la organización. Los mismos funcionarán como punto de partida para lograr descomponer funcionalidad de alto nivel en subsistemas. Ayuda a este proceso de descomposición empezar con casos de uso que no generen mucha controversia entre los involucrados, de manera de no perder el foco del proceso. En pocas palabras, se busca definir a cada proceso como un servicio, tratando de observar los riesgos y debilidades en cada paso. Luego, cada servicio se va a su vez descomponiendo en servicios de menor complejidad.

En un esquema BOTTOM UP se parte desde las aplicaciones, tratando de identificar las áreas o sistemas que están inmediatamente a su cargo. Funciona casi como un proceso de ingeniería reversa, yendo del código propiamente dicho de las aplicaciones, hasta obtener casos de uso de alto nivel.

Respecto a cuál de las estrategias es mejor, es un viejo debate dentro de la comunidad. La realidad es que ambos funcionan bajo determinadas restricciones, por lo que es importante conocer ambas y reconocer cual se adapta mejor al contexto actual.

Etapa 2: Capturar requerimientos de negocio

En la referencia [1] se describe un esquema para determinar los requerimientos de negocio relativos a servicios, dentro de una arquitectura SOA. El esquema funciona como un checklist que debe ser revisado para que no se escape ningún requerimiento. El primer ítem en el checklist es accesibilidad: ¿cómo el usuario encuentra y accede al servicio?

Luego sigue funcionalidad: ¿que está aportando este servicio para ser un proceso crítico del sistema? ¿Qué problema está resolviendo? El tercer punto es interacción: definir cómo y cuándo se comunica el servicio con otros, y cómo será accedido. El cuarto punto es información: ¿qué datos de entrada y salida necesita el servicio? Finalmente, el quinto lugar se concentra en el proceso: ¿cómo se relacionan las acciones y los eventos del servicio?

Un punto interesante a tener en cuenta dentro del mundo SOA es que no siempre se conocen por anticipado todos los potenciales usuarios del servicio. En este caso, los stakeholders deberán describir lo que ellos esperan del servicio. El output de esta etapa se validará con los usuarios finales que se conozcan. Intentarlo con todos es inviable.

Etapa 3: Documentación

Los requerimientos de negocio relevados deben ser documentados cuidadosamente. Esto tiene un importante aspecto en la trazabilidad de los mismos, y tener siempre claro en todo momento qué servicio se está correspondiendo con qué requerimiento. Existen muchas opciones y herramientas para formalizar la especificación de requerimientos. La más conocida es a través de casos de uso. Los casos de uso encajan también perfectamente con una propuesta SOA, por lo que los mismos constituyen una opción solida a la hora de dejar documentado los requerimientos de los procesos de negocio.

Referencias:

[1] http://www.ibm.com/developerworks/library/ar-soareq2/index.html

BPM es una metodología que propone actividades y herramientas para modelar, describir, y ejecutar los procesos de negocio de una organización o empresa. Antes de empezar o iniciarse bajo la visión BPM, es interesante analizar y ver ejemplos y casos de éxito de la metodología.

En la referencia [1] se recolectan muchos de estos casos de éxito, en donde empresas y desarrolladores cuentan en primera persona su experiencia utilizando BPM. En este artículo nos concentraremos en dos ejemplos seleccionados de dicha lista. En ambos, BPM permitió clarificar procesos claves, y fue crucial para detectar puntos débiles en el proceso de reglas de negocio.

Caso 1: Sistema de Aeropuertos en Portugal

En la referencia [2] se encuentra desarrollado este ejemplo por completo. Se trata de la empresa Ana Aeroportos, de Portugal, encargada del manejo de varios aeropuertos de ese país. En particular, es responsable del toda la infraestructura que permite a los pasajeros conectarse y recorrer el mundo.

Se utilizó BPM para modelar el proceso denominado “Change Orders”, cuyo objetivo principal responder con eficiencia ante cambios de reglas de negocio. Es un proceso complejo, ya que cambios relativos a aspectos tecnológicos deben ser considerados, autorizados e implementados sin impactar de manera negativa en el funcionamiento general previo al cambio. Se apuntó a resolver los siguientes puntos a través de técnicas BPM:

- ¿Se puede estructurar el proceso de otra manera para hacerlo más simple y eficaz?
- ¿Cómo implementar la nueva estructura?

Una manera de atacar este problema es entrevistando a todos los involucrados, y conseguir un panorama general del flujo de control del proceso; sin embargo, este es un proceso costoso. Para reducir su alcance se utilizaron actividades de minería de información: buscando logs de datos de la ejecución del sistema se encontraron muchos aspectos a mejorar. El análisis de dicha información permitió encontrar fallas estructurales que funcionaban como cuellos de botella en el procesamiento de la información. Una manera de detectarlos es buscar actividades o procesos que se repitan una y otra vez.

Luego, el proceso de entrevistas se redujo sólo a porciones reducidas del comportamiento general, facilitando la tarea. Como era de esperarse, atacando los cuellos de botella se logró mejorar la performance del proceso. Claro que todo pudo lograrse empleando BPM para modelar el proceso de negocio, e identificar a través del mismo situaciones de superación.

Caso 2: Multi-CHEM

Multi-Chem es una empresa dedicada al mundo químico. En la referencia [3] se detalla por completo cómo el área de sistemas aplicó técnicas BPM para mejorar sus procesos operacionales. Se describirán aquí los principales puntos.

Fernando Coronado, gerente de aplicaciones de software, estaba a cargo de la adquisición de software para la empresa, su integración y de los desarrollos propios. A medida que la empresa iba creciendo detectó serios problemas en el manejo y autorización de documentos claves: para solucionarlo, empezó a trabajar con el área de Recursos Humanos, la cual manejaba formularios como licencias, permisos de viajes, nuevo personal, etc. El problema es que no estaba claro dónde estaba un documento en un momento dado, y quién lo había autorizado.

El grupo de IT tuvo la responsabilidad de encontrar una solución más efectiva. Por un lado se sabía que se necesitaba un producto que manejara todos los documentos de manera electrónica pero que fuera más preciso que el correo electrónico, y donde estuviera el manejo de todo el flujo de control y del proceso. Otro requerimiento importante fue la escalabilidad. Tenía que ser un producto que se adaptara rápidamente al crecimiento esperado de la empresa.

A través de un modelado BPM del proceso, se lograron identificar puntos cruciales: el nuevo sistema tenía que reflejar los procedimientos que se seguían manualmente, controlar dichos procesos, tener identificado en todo momento la ubicación y estado de todo documento, y finalmente permitir el monitoreo y auditaría en cada paso.

Con estos puntos se desarrolló finalmente un producto web, respondiendo a las necesidades buscadas. Emplear BPM permitió por un lado tener un conocimiento claro y general de todas las áreas y procesos involucrados en el manejo de documentos claves. También dio la posibilidad de detectar de optimizar el tiempo de recorrido de dichos documentos. Finalmente, ayudó a clarificar el proceso de captura de requerimientos para el desarrollo del nuevo producto web, incluyendo la capacidad de monitoreo y auditoría.

Referencias:

[1] http://www.bptrends.com/resources_publications.cfm?publicationtypeID=DFFB84D1-1031-D522-339E8B42679D513F
[2] http://www.bptrends.com/deliver_file.cfm?fileType=publication&fileName=BPTrends%20Article%20Process%20Mining%20%2D%20Ana%20Aeroportos%20de%20Portugal%2DAlberto%20Manuel%20%20V01%2DFinal%2Epdf
[3] http://www.bptrends.com/publicationfiles/02-01-11-CS-Multi-Chem-Relies%20on%20BPM-Coronado-final.pdf

Cuando Internet empezó a crecer exponencialmente, con cada vez más presencia de recursos, conexiones, páginas y sitios, la demanda de un análisis automático enfocado en la web se hizo evidente y necesaria. Para llevar esta tarea a cabo hubo que sortear una dificultad no trivial: todo el andamiaje de páginas y buscadores nació y se implementó desde una perspectiva humana, sin considerar la intervención automática de programas, servicios, o demás agentes de software. En otras palabras, los humanos podían leer páginas y navegar por la red sin problemas, pero para un programa poder procesar la información contenida en una página era una tarea que muchas veces sobrepasaba su capacidad. El principal problema era que la información no tenía estructura ni uniformidad en su presentación.

Como solución a este conflicto nace el concepto de web semántica. Este concepto, introducido por Tim Berners-Lee, propuso agregarle “significado” a la información en la web. Esto implicó dotarla de estructura y estándares, de manera que su procesamiento automático fuera viable. En la actualidad estos estándares se definen y ejecutan desde el World Wide Web Consortium (www.w3c.es).

Podemos decir que actualmente se vive una situación parecida en el mundo de las arquitecturas orientadas a servicios (SOA). De esta forma nace el concepto de servicios semánticos (semantic services) o directamente SOA Semántica, con el objetivo de introducir significado a la descripción de servicios para lograr un mejor procesamiento automático.

SOA semántica

En la referencia [1] se detallan los aspectos más relevantes a la hora de incorporar una estructura que facilite la detección y sincronización de servicios, obteniendo así una SOA semántica.

Por un lado, debe estar disponible el descubrimiento de servicios. Dentro de la web semántica, un agente de software debe poder encontrar un servicio y a partir de la descripción del mismo poder determinar su propósito y objetivo.

Luego, debe reconocer cómo invocar dicho servicio y conocer y entender su interfaz pública. Esto incluye deducir qué parámetros de entrada son requeridos por el servicio, y a su vez, cómo se devolverán los resultados. Estos conceptos, como es natural en SOA, deben escalar no sólo a la invocación de un único servicio, sino a la combinación de varios para lograr un resultado en común.

Finalmente, se debe contar con la capacidad de monitorear la ejecución de un servicio. En especial este aspecto es útil en aquellos procesos que requieren mucho tiempo de procesamiento y es necesario conocer su status actual en un momento dado.

Como vemos, los beneficios de la SOA semántica son importantes: se fomenta la capacidad automática de descubrir, invocar, combinar y monitorear servicios. Como ejemplo trivial, podría construirse fácilmente un servicio que se encargue de organizar las vacaciones familiares de manera automática, desde reservas de vuelo, hospedaje, y auto de alquiler.

Herramientas y propuestas

Falta todavía maduración y tiempo para que la SOA semántica sea una realidad. Sin embargo, existen algunas propuestas destacables. Algunas aproximaciones trasladaron el concepto de especificaciones RDF (Resource Description Framework) de la web semántica a servicios. Por ejemplo, el sitio http://musicbrainz.org provee una API con servicios semánticos basada en estas especificaciones.

Por otro lado, el lenguaje basado en markup de DARPA, conocido como DAML, es un intento más ambicioso y poderoso. Esta especificación está conectada con una ontología de servicios web denominada DAML-S, la cual provee una estructura de significado en común. La ventaja de DMAL es que provee al desarrollador de un mayor poder expresivo para describir la funcionalidad y objetivos de cada servicio.

Finalmente, el framework Services Modeling (WSMF) propone diversas facilidades para enriquecer la descripción de los servicios dentro de una arquitectura SOA.

No hay que perder de vista los avances dentro de la SOA semántica. Para tal fin se recomienda visitar periódicamente dos sitios. El primero, www.w3.org/2001/sw, aglutina todas las especificaciones formales respecto a servicios semánticos. El segundo, en www.daml.org, contiene una descripción de ontologías, herramientas y demás recursos de utilidad para introducir significado en la utilización de servicios.

Referencias

[1] http://soa.sys-con.com/node/39631

La noción de arquitecturas de software involucra describir y especificar la interacción de componentes con un alto nivel de abstracción,  mostrando la interacción entre los mismos y el flujo de comunicación. El gran impacto que tuvo el concepto de arquitecturas de software se debe a la inclusión de aspectos no funcionales como escalabilidad, disponibilidad, seguridad y performance.

Estos aspectos tienen su relevancia al momento de implementar y ejecutar una solución basada en herramientas BPM, filosofía que permite especificar cada uno de los pasos involucrados en un proceso de negocio: su identificación, modelado, desarrollo, puesta en ejecución y administración. De esta manera, existen conceptos de la arquitectura de software que pueden extrapolarse a la hora de llevar adelante una gestión de procesos según BPM. En [1] se enfocan estos conceptos desde tres puntos de vista: Puesta en producción  o deployment, estilos arquitectónicos y estimaciones de hardware.

Deployment

Desde el punto de vista de deployment, es importante pensar en la configuración que tendrá la arquitectura BPM al momento de gestionar los procesos de negocio de la organización. Una correcta configuración explorará 4 ángulos diferentes: el ambiente de desarrollo, que incluye la configuración, test, y corrección de bugs que surjan de la aplicación de herramientas BPM; el ambiente de testing que, como la etapa tradicional del desarrollo de software, estará enfocado en corroborar que se cumplan los diferentes criterios de aceptación, el ambiente de “staging”, que en esencia funciona como un entorno virtual seguro para correr productos en producción (muchas veces es opcional según la escala del proyecto) y el ambiente de producción, donde se aplicarán los distintos procesos.

Estilos Arquitectónicos

La aplicación de un estilo arquitectónico dependerá del set de herramientas BPM seleccionadas. Un estilo “stand alone” o de una única capa provee una única estructura para almacenar todos los componentes BPM (motor BPM, manager de aplicaciones, bases de datos) en una única máquina o servidor. La principal ventaja de este enfoque es la simpleza y el menor “overead” en las gestiones de administración, aunque puestas en producción complejas requerirán otro tipo de enfoque.

Un estilo de dos capas permite ubicar el motor de BPM y el manager de aplicaciones en distintos servidores, lo cual permite una mayor concurrencia y mejor performance.

Un estilo con tres capas permite tener servicios dedicados para cada componente BPM de manera individual. Obviamente, el mantenimiento y supervisión se vuelven más complejos, pero aumenta la magnitud de proyectos que puede abarcar.

Finalmente en un estilo multi-capas (con 4 o más), los componentes BPM se ubican en capas separadas, con servidores dedicados. Este estilo requiere especial cuidado en cuestiones de balance de carga y sincronización entre las distintas capas, aspecto generalmente subestimado.

Estimaciones de hardware

Desde el punto de vista de estimaciones de hardware, se deben considerar aspectos propios de BPM. Este punto generalmente es pasado por alto, y constituye uno de los errores más comunes para la implementación de una solución BPM. Las principales cuestiones inherentes a BPM que influyen para la estimación son: el número de procesos por año/mes/día/semana, la cantidad de actividades en cada proceso, cantidad de usuarios involucrados, integración con servicios externos, experiencia de la organización en soluciones BPM, y la infraestructura actual de IT de la organización.

Un caso concreto

En la referencia [2] se ilustra un caso típico de una arquitectura BPM por capas, combinando el management BPM con orientación a servicios al estilo SOA.

La capa principal es la de aplicación de servicios, que representan el corazón del sistema. Esto muestra la unión entre BPM y SOA, como es detallado en [3].

Usando BPM, SOA se concentra en servicios de procesos para desarrollar flujos de negocio complejos. BPM agrega poder adicional para la composición de servicios y permite modificar un flujo de comunicación de manera dinámica. Finalmente, BPM da la posibilidad de controlar procesos y unidades de ejecución a largo plazo, ideal para el contexto de aplicaciones bajo transacciones.

La capa inmediata es la capa de flujo de comunicación. Existen diversas tecnologías que pueden ayudar en este aspecto. Por ejemplo, un motor de orquestación como BizTalk se adapta perfectamente para sistemas automatizados. El objetivo de esta capa es modelar la interacción entre servicios.

La capa de presentación es el clásico “Front End”, donde se exhiben los puntos de entrada a los servicios ofrecidos. Esta capa tiene su complejidad, incluyendo conceptos como seguridad, autenticación, internacionalización, y personalización de características y estructura.

Finalmente, una capa de integración permite combinar el sistema con sistemas externos.

Cómo encarar una arquitectura BPM

En la referencia [4] se describen algunos pasos previos a tener en cuenta al momento de encarar una arquitectura BPM.  Un buen diseño BPM arquitectónico incluye examinar el proyecto desde el paso 0: es decir, tener un panorama amplio y completo del alcance del sistema. Esto incluye tener un conocimiento profundo del comportamiento del sistema y saber discernir entre el diseño detallado y el diseño a alto nivel. Sin tener en claro estos aspectos, el desarrollo arquitectónico sufrirá de serios riesgos para completar su éxito.

También en [4] se describen otros consejos útiles. Por ejemplo, un arquitecto BPM debe enfocarse en la perspectiva local de la empresa, y no considerar la visión global de todas las empresas socias involucradas. Este último aspecto sólo tiene que tenerse en cuenta para contemplar que los servicios satisfacen la integración con los socios. Otro consejo parte del viejo refrán de “no reinventar la rueda”: es raro tener que construir una arquitectura desde cero. Se debe tratar siempre de utilizar funcionalidades ya incluidas en muchos frameworks como seguridad, logging, manejo de conexiones y más.

Referencias

[1] http://blog.andrewrivers.co.uk/2009/04/description-of-bpm-architecture.html

[2] http://www.bptrends.com/publicationfiles/05-06-WP-BPM-SOA-Behara.pdf

[3] http://oreilly.com/catalog/essentialpm/chapter/ch02.pdf

El auge de los servicios en la nube hace que muchas empresas promocionen dichos productos de diferentes maneras, haciendo foco especialmente en la funcionalidad y en ciertas medidas de seguridad que cada vendor pueda tener implementada. Sin embargo, un escenario cada vez más común es que el potencial consumidor de servicios en la nube, bombardeado por la publicidad de estos servicios, no tenga en claro qué criterios de seguridad son los recomendados al momento de contratarlo.

En este contexto, la Cloud Security Alliance desarrolló un proyecto denominado Cloud Control Matrix (CCM), que tiene dos objetivos primarios que pasamos a explicar.  Por un lado, se trata brindar a los proveedores de servicios de Cloud Computing una guía con los principales requerimientos de seguridad; por otro lado, se busca brindar a los consumidores de servicios de Cloud los lineamientos necesarios para que puedan evaluar en su conjunto los riesgos de seguridad de los proveedores.

Aquellos interesados en el CCM pueden descargar el documento desde el siguiente enlace: https://cloudsecurityalliance.org/research/ccm.

El Cloud Control Matrix establece un marco de trabajo basado en controles, los cuales están alineados con los 13 dominios principales propuestos por la Cloud Security Alliance. Estos dominios son:

1. Marco de trabajo de la Arquitectura de Cloud Computing
2. Gobierno y gestión de riesgos en empresas
3. Aspectos legales y eDiscovery
4. Cumplimiento normativo y de auditorías
5. Gestión del Ciclo de vida de la Información
6. Portabilidad e interoperabilidad
7. Seguridad tradicional, continuidad del negocio y recuperación de desastres
8. Operaciones del centro de datos
9. Respuesta a incidentes, notificación y remediación
10. Seguridad de las Aplicaciones
11. Cifrado y gestión de claves
12. Gestión de Accesos e identidades
13. Virtualización

Todos los controles incluidos en CCM están detallados y bien explicados en el documento de manera tal de facilitar su comprensión. En la Figura 1 puede verse la Cloud Control Matrix, una planilla de cálculo donde cada una de las filas está asociada a un control de seguridad. Tal como se mencionaba, cada control posee una descripción detallada que permite contextualizar y comprender cada control.

Relación con otros estándares

Un punto importante que merece la pena remarcarse es que todos los principios y controles de seguridad contemplados en el Cloud Control Matrix, están basados y alineados con otros conocidos estándares de la industria, siendo los más destacados ISO/IEC 27001/27003, ISACA COBIT, PCI-DSS y NIST SP800-146. De hecho, en la planilla podrán encontrar como los controles planteados pueden mapearse con uno o varios de los controles de seguridad de estos estándares.

De esta forma nos aseguramos que el control de estos requerimientos de seguridad no son decisiones arbitrarias, sino que por el contrario son consistentes con estándares de las industrias que posiblemente cumplamos en otros ámbitos en las organizaciones.

Las arquitecturas basadas en servicios (SOA) representan uno de los más grandes avances en IT de las últimas dos décadas. Su enfoque basado en la reutilización de servicios, y la idea de construir servicios complejos interconectando servicios simples y pequeños ha sido de gran ayuda para el desarrollo de software de calidad. Asimismo, el concepto de “cloud computing” (CC) o “software en la nube” viene incrementando su popularidad y aceptación dentro de la comunidad IT.

Cloud computing se basa fuertemente en Internet, donde tanto recursos, software e información están puestos a disposición de otras computadoras y artefactos. Tanto SOA como CC poseen puntos en común, como ser la arquitectura de comunicación descentralizada, pero es importante notar que tienen enfoques y objetivos distintos. Teniendo esto en cuenta, ambas tecnologías pueden combinarse, aportando atractivos beneficios para cualquier empresa IT.

Puntos en común

Ambas tecnologías radican su potencial en brindar una estructura que permite delegar y particionar la funcionalidad del sistema, descomponiéndola en partes con menor complejidad. Esto no es otra cosa que la composición de servicios, lo cual permite que los usuarios los utilicen sin importar la  implementación o cuestiones no funcionales (como la escalabilidad). De la misma forma, ambas proponen desacoplar la interacción entre servicios, promoviendo así la reutilización.

En la referencia [1], expertos en IT destacan estos puntos de encuentro entre SOA y CC: Rob Helm, parte de la corporación Microsoft, afirma que estas tecnologías  potencian el desarrollo de componentes reusables y generan las mejores estrategias para correr componentes de gran escala en entornos distribuidos. Por su parte, Sanjiva Weerawarana, de la empresa WSO2 (http://wso2.com) destaca cierta similitud arquitectónica para proveer servicios y funcionalidad.

Diferencias principales

Es importante tener en cuenta las diferencias entre SOA y CC, tanto para su aplicación individual en una empresa, como su utilización en conjunto. En la referencia [2] se explicitan dos de las diferencias más importantes:

-          CC tiene un enfoque más vertical, al estar enfocado en estructuras de tipo “layer”. En cambio, en SOA cada servicio tiene a su cargo una funcionalidad de negocio. Todos juntos forman una aplicación o solución de negocio, siguiendo un enfoque más horizontal.

-          CC puede verse como una plataforma arquitectónica de ejecución. En cambio, SOA provee una solución arquitectónica para la interacción de servicios, contemplando también el diseño del sistema.

Combinando SOA y Cloud Computing

En la referencia [3] se brinda una interesante analogía que describe con precisión la manera de combinar SOA y CC. Imaginemos una biblioteca llena de material. Los libros representan los servicios que los usuarios pueden acceder una vez que la biblioteca los consigue y los hace disponibles, mientras que el edificio y la infraestructura de la biblioteca representan la noción de CC, donde los usuarios ingresan su búsqueda (servicios). Continuando con la analogía, los libros pueden combinarse para formar una saga (composición de servicios), y un mismo libro puede ser útil a varios usuarios a lo largo del tiempo (reutilización de servicios).

Requerimientos previos

Para proveer servicios dentro de CC existen una serie de condiciones previas, muchas de las cuales son simples extensiones a las condiciones para encarar una arquitectura SOA. Según la referencia [3] las mismas incluyen:

-          Virtualización del ambiente de IT para que puede ejecutarse en el lugar más conveniente en términos de costo y espacio.

-          Reusabilidad y  Disponibilidad: debe existir la logística adecuada dentro de la organización para asegurarse que los servicios estén disponibles para ser usados por muchos usuarios al mismo tiempo.

-          Manejo y Sincronización de los servicios: esto implica extender la gestión de los servicios de SOA al nivel CC, donde los mismos pueden no estar bajo control directo.

-          Seguridad y controles en los accesos: se deben reforzar las políticas de seguridad dentro de un entorno de CC.

Referencias

[1] http://www.infoworld.com/d/cloud-computing/cloud-soa-connection-724

[2]http://blogs.vmware.com/vcloud/2010/04/soa-and-cloud-computing-are-they-the-same.html

[3]http://www-01.ibm.com/software/solutions/soa/newsletter/nov09/article_soaandcloud.html

Aunque no lo creas, Agile depende de vos. La vorágine de la vida diaria y la velocidad con la que recibimos todo tipo de información no nos permiten reservarnos un espacio para reflexionar sobre el potencial que nos trae esta palabra y cómo llevarla a la práctica. Es decir: ¿por qué, cómo, y cuándo llevar Agile a nuestro entorno de trabajo?

No hay una única receta para responder a esta pregunta disparadora, pero existen señales que nos invitan a poner el foco en un factor clave: el cambio.

Vivimos cotidianamente con y del cambio, tanto en nuestros marcos personales como profesionales. El sistema corporativo suele ser desafiante frente a los distintos factores que entran en juego, algo que suele traducirse en resistencia al cambio. Se puede auspiciar una propuesta de cambio, desarrollando y comunicando (al equipo, al jefe, a un cliente) los siguientes valores a través de la presentación de la idea:

• Individuos e interacciones sobre procesos y herramientas.
• Software funcionando sobre documentación extensiva.
• Colaboración con el cliente sobre negociación contractual.
• Respuesta ante el cambio sobre seguir un plan.

Estos valores forman parte de una base que permiten preparar el terreno para explicaciones más exhaustivas sobre metodologías, procesos y artefactos ágiles (aquí entran en escena palabras como SCRUM, daily meetings, sprints, taskboard). A continuación proponemos tips y consejos para lograr estos objetivos con mayor agilidad.

Mantener presente los valores ya mencionados. Junto con el soporte de referencias bibliográficas, coaches, etcétera, podremos emprender un camino sin seguir ciegamente pasos ortodoxos para evangelizar la denominación ‘agile’;

Ser conscientes que debemos y podemos adaptarnos a la mentalidad de la personas y demostrar los éxitos con resultados concretos;

No desmotivarse al fallar, aprender rápido, capitalízalo y volver a intentarlo.

Para ello, desde GlobalLogic fomentamos día a día una serie de “valores complementarios”, que completan la base de los anteriores. Gracias a estos concretamos y alcanzamos metas en común entre nuestros equipos y los equipos del cliente.

1. Integridad: tratamos a las personas con respeto. Creemos en hacer siempre lo que decimos que vamos a hacer y cuando decimos que vamos a hacerlo;
2. Apertura: maximizamos la transparencia para crear un ambiente en el que cada individuo se anime a contribuir, donde cada pensamiento es valorado y considerado en las tomas de decisiones;
3. Innovación: creemos en aprender e innovar siempre, alentando y recompensando a aquellos que desafían la sabiduría convencional, tomando riesgos y compartiéndolos;
4. Trabajo en equipo: los buenos equipos pueden ser más fuertes que la suma de sus partes, cuidándose activamente y confiando uno de otros.

Los valores son quienes acompañan a transitar el cambio, el resto es cuestión de técnicas y herramientas que pueden ser aplicadas gradualmente. La reflexión tanto individual como grupal resultará una de las fuentes principales de aprendizaje en un nuevo marco que permitirá disfrutar aún más del trabajo realizado.

Referencias:
Manifiesto para el Desarrollo Agil de Software
GlobalLogic’s Core Values (https://www.globallogic.com/career-values.html)