Fuente: http://ibiscom.net/index.

php/es/ibpm/56-bpm-y-soa-dos-tecnologias-
complementarias

BPM y SOA Dos tecnologas complementarias

Este texto est basado en el artculo: Issues and Best Practices for the BPM and SOA
Journey, enix consulting limited, Derek Miers ,2006 Traduccion de Javier
Beltran

En los ltimos aos, tanto BPM - Business Process Management y SOA Service Oriented
Arquitecture, se han promocionado como dos enfoques que ayudarn a las organizaciones a
mejorar su rendimiento. Ambos enfoques ofrecen una metodologa evolutiva para la
transformacin de la arquitectura empresarial y para el desarrollo de TI, todo bajo una visin
holstica. Aunque los dos tienen objetivos ligeramente diferentes, tienen mucho en comn y se
complementan muy bien.
BPM es una metodologa de mejoramiento continuo del rendimiento de los
procesos. Es sobre todo una disciplina de gestin basada en la mejora iterativa de
los procesos de negocio. Es una tecnologa que impulsa el trabajo en la
organizacin soportado en el monitoreo, la optimizacin y la trazabilidad de los
procesos de negocio.

SOA es un enfoque para el desarrollo de sistemas que ofrece aplicaciones a

travs de la composicin y la orquestacin de componentes discretos,
independientes, o "servicios". La Filosofa de diseo de SOA es orientada a
procesos, focalizada en el negocio, conducida por principios arquitectnicos y
orientada a soportar los cambios del entorno.

BPM est enfocado en el mejoramiento continuo del rendimiento del negocio y SOA, por
otra parte, es fundamentalmente un enfoque de integracin de TI.
Este documento presenta una serie de conceptos y elementos que ayudan a delinear un plan
integral para implementar BPM-SOA en una organizacin al tiempo que aborda una serie de
tcnicas y enfoques que ayudan a superar los retos asociados con el despliegue de BPM-SOA.

Por qu el inters en BPM-SOA?

En un clima de negocios en rpida evolucin, las presiones sobre las empresas para adaptarse son
inmensas y provienen fundamentalmente de nuevos acuerdos comerciales que se deben
satisfacer con clientes, socios y proveedores, del cumplimiento de nuevas regulaciones legales y
del advenimiento de nuevas tecnologas
Los clientes se han convertido en participantes activos de los procesos de negocio de las
organizaciones, ellos esperan tener una experiencia multi-canal, coordinada en todos los puntos de
contacto con la organizacin. Pero los procesos por lo general estn fracturados a travs de las
diferentes funciones y canales (ventas, soporte tcnico, contabilidad, call center, sala de correo,
los socios, Internet, puntos de atencin personalizada, etc), creando todo tipo de oportunidades
para la perdida de foco en los objetivos o para la perdida de comunicacin en la implementacin
de la solucin que se debe dar a los clientes. Ms especficamente, la existencia de diferentes
procesos para apoyar los diferentes canales, conducen inevitablemente a una conducta no
coordinada e incoherente que provoca la prdida de clientes.
Los sistemas de informacin de hoy son a menudo altamente estructurados, con puntos de
integracin fijos que los hacen frgiles y difciles de cambiar, su infraestructura tecnolgica esta
frecuentemente llena de parches producto de los esfuerzos de desarrollo requeridos para satisfacer
nuevas necesidades y est plagado de dbiles y delicadas interconexiones. Al mismo tiempo, los
procesos de negocio que estos sistemas soportan tienen un enfoque interno, orientado hacia el
control y embebidos en rgidos sistemas legacy y aplicaciones empresariales.
BPM y SOA, aplicadas en conjunto proporcionan la infraestructura ideal para resolver estos
problemas en las organizaciones, como se muestra a continuacin:
Segn un reciente estudio de McKinsey, el xito de las iniciativas de SOA en las empresas puede
proporcionar beneficios significativos, incluyendo la reduccin de los costos de integracin en un
60-70% en el mediano plazo y aumentando dramticamente la capacidad de adaptacin. Por
ejemplo, un banco minorista redujo su tiempo de comercializacin en un 30% y sus costos
de desarrollo y de mantenimiento en un 10-20%.

Figura 1 - Resumen de los resultados de encuesta realizada por AMR sobre los beneficios
de SOA (El gasto promedio en SOA fue de U$ 667 mil dlares)

La combinacin de las dos tcnicas es esencial para asegurar la eficacia en la organizacin. Por
ejemplo, a pesar de un fuerte nfasis en los procesos de negocio, la encuesta de AMR (Figura 1)
encontr que aproximadamente un tercio de las organizaciones que estn llevando a cabo
iniciativas para implementar SOA, no podan volver a reconfigurar los procesos de negocio
acorde con sus necesidades. Esto obedeci en gran parte porque no se haba desplegado un entorno
BPM para proporcionar la capa de orquestacin.
Las ventajas especficas de las iniciativas de BPM estn bien documentadas. En una reciente
revisin de estudios de casos con BPM, el mejoramiento del rendimiento del negocio fue el
resultado que ms se destac (reduccin de costos y menor tiempo de ciclo), seguido del
mejoramiento en el servicio al cliente. Tambin se encontr que algunas empresas haban utilizado
BPM para integrar sus canales y proporcionar de esta manera una experiencia a sus clientes ms
consistente, otras haban llevado los procesos de la organizacin a una capa independiente por
encima del nivel de sus sistemas legacy con el fin de proporcionar una plataforma con mayor
agilidad y otros haban utilizado el enfoque de redistribuir el trabajo para el cliente (self-service
portal).
Los nmeros que acompaan estos casos de estudio son impresionantes. Por ejemplo, una
divisin de Allianz, el grupo asegurador mundial, logr un incremento del 80% en
eficiencia, reduciendo el tiempo promedio para procesar una demanda de semanas a das.
La DVLA, entidad que maneja las Licencias para los Vehculos en el Reino Unido,
aument la productividad en el manejo de casos en ms del 50%, lo que le permiti a la
DVLA reasignar personal a otras reas.
El holands KPN operador de telecomunicaciones redujo el tiempo promedio de
procesamiento de pedidos en un 90 por ciento y el ahorro de costos entre 150.000 y
200.000 libras por mes. Adems, estiman que la solucin permiti una reduccin del
95% en los errores, un 80% en la automatizacin de rdenes y un 50% en mejora de la
productividad.

Desde una perspectiva empresarial las tecnologas BPM-SOA proporcionan una serie de
beneficios, entre los que se cuentan:
Reducen el tiempo de salida al mercado y mejoran la capacidad de la empresa para
responder rpida y eficientemente a los cambios empresariales.

Proporcionan el mecanismo para explotar las nuevas oportunidades del mercado y para
transformar la velocidad de respuesta en una ventaja competitiva. Hacen que parezca fcil
golpear la competencia.

Permiten a una empresa grande copiar una innovacin en el mercado y rpidamente

aprovechar sus recursos y el alcance para hacer frente a la amenaza competitiva de los
jugadores ms hbiles.

Reducen los costos de TI significativamente, mientras que las aplicaciones pasan del
paradigma disee - compile ejecute propio del desarrollo de software tradicional, a uno
basado ms en ensamblar, configurar, monitorear (comn en los despliegues de BPM-
SOA).
 Promueven un rendimiento predecible y consistente a travs de las re-utilizacin de las
capacidades estandarizados, basados en procesos de negocio (servicios empresariales)
y ofrecen una mejor visibilidad y trazabilidad sobre la situacin del trabajo o de las
actividades en la empresa.

Los cambios realizados en los procesos no tienen por qu afectar los servicios subyacentes
y las aplicaciones de lnea de negocio con los que interactan (y viceversa). Este aspecto
aumenta significativamente la agilidad de los procesos de aislar el impacto del cambio.

La necesidad de coordinar los procesos de negocio y mejorar la productividad no termina

en el firewall de la organizacin. BPM (y SOA) ofrece la oportunidad de coreografiar los
participantes de los procesos a travs de la cadena de valor, ya sean clientes, socios o
proveedores.

Un nuevo estado de pensamiento

Ambos BPM y SOA puede ser considerado como un estado de pensamiento - una forma de pensar
acerca de cmo los negocios y los activos de TI trabajan juntos; de cmo el modelo de negocio
y de gobierno deben ser diseados y una manera de implementar la tecnologa y las aplicaciones
para soportar este diseo. Sin embargo, se trata de dos diferentes formas de pensar: BPM es
fundamentalmente un enfoque de arriba hacia abajo, mientras que SOA es usualmente un enfoque
de abajo hacia arriba. El desafo consiste en juntar estas dos perspectivas, identificando los puntos
en comn y resolviendo las diferencias.
Comn a los dos enfoques es el concepto de bajo acoplamiento. En BPM, se refleja en el
acoplamiento dbil que existe entre los diferentes procesos mientras que en SOA se refleja
en la independencia entre s de los diferentes servicios.

La respuesta a una necesidad de negocio, se compone de un conjunto de componentes

dbilmente acoplados, en lugar de totalmente integrados en tiempo de diseo como ocurre
con las aplicaciones tradicionales. Adems, s este enfoque se aborda correctamente, el
costo de desarrollo y mantenimiento de TI se reduce considerablemente.

Los dos fomentan la reutilizacin como mecanismo para aumentar la agilidad y la

flexibilidad empresarial. Si se disean adecuadamente, los sistemas de negocio se puede
adaptar de acuerdo con las necesidades cambiantes del entorno en lugar de estar limitado
por aplicaciones frgiles y altamente integradas que restringen la agilidad.

Si bien ambos enfoques prometen un futuro atractivo y puede llevarse a cabo de forma
independiente, La bsqueda del valor mximo de cualquiera de estas tcnicas incluye aprovechar
los mtodos del otro. Los servicios a menudo requieren de la orquestacin en el contexto ms
amplio de un proceso de negocio y los procesos de negocio pueden incorporar una serie servicios
de negocio que trabajan cooperativamente.
Llevar a cabo una iniciativa BPM sin el empleo de principios basados en SOA es cuestionable.
Eso puede significar que se estn ignorando las mejores prcticas, o no hay una integracin
significativa, (que, a su vez, probablemente pone de relieve un enfoque errneo a la gestin y al
control de los procesos de negocio). Por supuesto, es posible emplear los principios de SOA sin
utilizar BPM, ya que muchos proyectos de software requieren integracin y no tienen necesidad
de la gestin por procesos.
Muchas iniciativas SOA comienzan de abajo hacia arriba, encapsulando la funcionalidad de
aplicaciones existentes, mediante Servicios Web y tecnologa middleware para conectar estos
componentes con el objetivo final de convertir ese plato de espaguetis frgil en una serie de bloques
de construccin modular, de la que es posible, entonces, componer nuevas aplicaciones y servicios.
Por otro lado, el negocio necesita una eficaz metodologa de diseo de software de arriba-
abajo, que aline las necesidades del negocio y, al mismo tiempo, aproveche discretos e
independientes componentes o servicios como mecanismos para soportar estas necesidades.
Aqu vale la pena sealar que los beneficios de BPM-SOA se extienden mucho ms all de la
organizacin de TI, que normalmente representa entre el 2% y el 10% de la base de costos de una
empresa. Disear servicios orientados al negocio, permite la optimizacin de las operaciones a
travs de la organizacin lo que constituye el otro 90% a 98% de la base de costos. En el mbito
empresarial, BPM-SOA se convierte en una arquitectura global, que abarca todos los sistemas de
TI, mediante los cuales se soportan las capacidades de negocio que la organizacin quiere entregar.
A su vez, este nfasis en servicios orientados al negocio permite extender los lmites en la
organizacin y hacer un mejor uso de la innovacin en toda la cadena de valor.
Un ejemplo de las mejoras obtenidas con el uso de estas tecnologas es Optus uno de los ms
grandes proveedores de servicios de telecomunicaciones de Australia, quien utiliza una solucin
de BPM para soportar sus obligaciones legales en torno a la portabilidad local de los nmeros. El
sistema soporta la gestin que deben hacer diferentes unidades de negocio al interior de Optus,
contratistas externos independientes y otros proveedores (competidores). Como resultado de ello,
Optus ha reducido el tiempo de "activacin" de nmeros locales en un 30% y espera, una vez est
completamente optimizado el proceso, obtener una mejora del 60% en el rendimiento del mismo.
Pero esto no es slo un beneficio para los clientes, pues el aumento de la eficiencia del proceso en
un 10% se traduce en reduccin de costos en millones de dlares.
Otro ejemplo es Dell que ha reducido los costos inherentes a la logstica de entrega, mediante
la integracin de los servicios de sus proveedores y sus propios procesos. Si un proveedor no est
llevando a cabo el acuerdo de nivel de servicio, Dell es capaz de cambiar a otro proveedor
inmediatamente. Como resultado, aumento su poder de negociacin, reduciendo an ms los
costos para el consumidor.

BPM-SOA Modelado - Un problema de dialecto.

 Los trminos "proceso", "componente", "Servicio" aunque son ampliamente utilizadas, suelen
interpretarse sutilmente diferente por los distintos grupos en una organizacin. De hecho, tenemos
que pensar que un proceso puede estar compuesto por un conjunto de servicios discretos y
viceversa que un servicio de negocio podra ser implementado como un conjunto de procesos.
Proceso = Servicio = Capacidad

Sin embargo, el termino proceso significa diferentes cosas para diferentes personas. La
interpretacin de un director esta por lo general bastante en desacuerdo de la que se usa en las
trincheras del desarrollo de software. Cuando se piensa en "proceso" en un nivel alto,
normalmente se asocia con un objetivo. Por ejemplo, el proceso de servicio al cliente esta
para garantizar que la empresa tenga clientes felices. Una nocin de proceso de alto nivel,
implica la identificacin de las "capacidades" que son necesarios para satisfacer el objetivo. De
esas capacidades de alto nivel, uno puede disear una estructura organizativa adecuada para
entregar ese propsito. Pero el problema viene cuando se dice la palabra "proceso" en una
organizacin funcional, aqu en vez de pensar en trminos de las capacidades necesarias para
cumplir con el propsito, la gente tiende a mirar a la jerarqua funcional existente, mirando a
travs de los diferentes departamentos que conforman ese feudo, hasta identificar listas de
actividades. Los diferentes caminos a travs de las actividades (procedimientos normalizados de
trabajo) se conocen como "procesos". Pero esto no es la misma nocin de proceso que comenz
con el proceso como fin u objetivo.

Figura 2 - "El proceso como propsito" no es lo mismo que los "Procedimientos de

Operacin Estndar"

De hecho, el termino proceso es mejor interpretado como un espectro con los "procedimientos"
en un extremo, y las "prcticas" en el otro. Los procedimientos por lo general se imponen y buscan
lograr normalizacin y control, mientras que las prcticas tienden a evolucionar y se utilizan como
una gua. Cuando uno mira de cerca un proceso (como objetivo), se encuentra una mezcla
de procedimientos y prcticas, que con el tiempo, cuando las prcticas son mejor "entendidas",
usualmente son llevadas a nuevos procedimientos.
Para comprender la rica realidad de los procesos de una empresa, necesitamos mejores maneras de
pensar acerca de los procedimientos y prcticas. El problema es que cuando un diagrama de flujo
es la nica representacin de los procesos, siempre parece que se ve bien y es muy difcil detectar
errores o partes del proceso que podran beneficiarse de la reconstruccin, pues los diagramas de
flujo tienen una visin muy procedimental del proceso, centrndose en el orden de las actividades
sin tener en cuenta, o al menos tratar de representar, las prcticas de negocio flexibles. Por otra
parte, con diagramas de flujo, como el nico concepto de modelado, la tentacin es modelar todo
hasta el ms mnimo nivel de detalle (precisamente el punto en que las empresas se atascan en la
parlisis del anlisis).
Si los trozos de procesos se pueden representar como discretas capacidades de negocio, los
servicios se pueden utilizar para componer procesos de negocio de alto nivel (como proceso
objetivo). Uno podra pensar en las capacidades de negocio como los bloques de Lego que se puede
utilizar para crear un proceso de negocio de alto nivel.

Modelando procesos como servicios.

Dado que BPM es una forma de pensar en la estructura de un negocio con un visin de arriba-
abajo, es fundamental contar con un proceso de modelado que refleje esta realidad. En
consecuencia, el reto es partir de procesos como propsitos de negocio y realizar actividades de
descomposicin hasta llegar a un nivel de granularidad adecuado para el negocio.
En este sentido una organizacin de electrodomsticos, modelo cada uno de sus procesos como
una coleccin de Capacidades de Negocio. Una capacidad de negocio puede contener otras
capacidades de negocio y puede ser implementada por un nmero de procesos normalizados. Un
proceso normalizado, a su vez, est conformado por un conjunto de objetos reusables mediante los
cuales se cambia el estado de entidades de negocio.
 Figura 3 - Procesos de negocio de alto nivel se componen de varios niveles de capacidades
de negocio y servicios.

Por su parte, el proyecto Financial Management Enterprise Architecture (AMFE) de la

Administracin de Servicios Generales (GSA) de los Estados Unidos, utiliza un enfoque diferente
(ver Figura 4), basado en una extensin del estndar EDOC para proporcionar mltiples niveles
de componentes de negocio. De esta manera, una serie de capacidades de negocios o disciplinas,
que en realidad son las funciones de negocio, cumplen las necesidades de los procesos de negocio
de ms alto nivel (Proceso como Propsito). A su vez, un cierto nmero de servicios de negocios
soportan una capacidad de negocio de la organizacin y cada servicios de negocio se compone
de un conjunto de componentes de "nivel de trabajo" dentro del proceso.
 Figura 4 - Procesos de negocio de alto nivel se componen de varios niveles de
capacidades de negocio y servicios.

Por ejemplo, el proceso de Finanzas est compuesto por un conjunto de disciplinas (facturacin,
pago, Auditora, Gestin de Tesorera, Presupuesto, etc.). Estas capacidades de nivel de disciplina
de negocios fueron reutilizados en otros procesos. Por ejemplo, el proceso de adquisiciones se
compone de las siguientes capacidades: Contratos, transferencia, entrega, pedidos,
facturacin, contabilidad (entre otras).
Otro enfoque se describe en un artculo de McKinsey de 2003 (Ver figura 5). Los autores discuten
el concepto de Dominios de negocio, que son ms o menos sinnimo de las capacidades de
negocio discutido anteriormente. Un dominio tiene un contexto de negocio comn y se utiliza para
controlar la manera cmo el trabajo de desarrollo e infraestructura se rige y es financiado. Los
servicios se utilizan como la interfaz de cada dominio. Uno podra pensar en estos dominios como
portafolios de servicios alineados con las necesidades de una comunidad. Tener el negocio
dentro de estos dominios asegura que los lmites no son dependientes de la tecnologa.

Figura 5 Dominios de negocio

Aprovechar las aplicaciones actuales

Dado que la mayora de los sistemas actuales han sido desarrollados sin tener en
cuenta lineamientos de SOA o BPM y que estos sistemas tienen mezclado los procesos manuales
y los automatizados, donde las personas hacen parte del trabajo y los sistemas otras partes, es
decir, la gente es parte del sistema.
 De hecho, en algunas empresas, los procesos de negocio se ven a menudo en trminos de los
sistemas que fueron diseados originalmente para apoyarlos. Estos sistemas ya no hacen parte
del "Cmo", sino que se han convertido en el "Qu" y son ms importantes que el proceso. Por
lo tanto reemplazar estos sistemas no es tan simple como apagar sus partes y sustituirlos por una
nueva funcionalidad. Las aplicaciones legacy incorporan funcionalidad que esta disgregada en
a travs del sistema haciendo difcil que en un momento determinado se pueda cambiar una funcin
especfica o un proceso determinado.
En consecuencia, existe un gran problema para las empresas que estn buscando transformar las
aplicaciones existentes en aplicaciones modernas. Por ejemplo, en General Motors, el programa
de reemplazo de aplicaciones legacy requiri esfuerzos a travs de varios frentes de trabajo que
evaluaban cada sistema y lo clasificaban contra un amplio espectro de necesidades. En algunos
casos se tuvo la necesidad de "volver a aprender" lo que la aplicacin realmente haca y en otros
se ajust el sistema para que su funcionalidad pudiera ser re-usada. Adicionalmente, en muchos
de los procesos de negocio se necesit "re-ingeniera", mientras que algunas aplicaciones fueron
"reemplazadas" y otros fueron "retiradas".
En la mayora de situaciones, es una cuestin de acondicionar la funcionalidad existente y
garantizar que se pueda aprovechar en aplicaciones BPM. Cada elemento de la funcionalidad de
la aplicacin debe ser empaquetada como un servicio independiente, de manera que puedan
ser invocados cuando sea necesario dentro de un proceso de negocio determinado. A su vez,
estos procesos pueden ser expuestos como servicios para ser reutilizados por otros procesos,
permitiendo la definicin recursiva de nuevos procesos.
De esta manera, la moderna Suite BPM y sus correspondientes componentes middleware SOA,
permite encapsular funcionalidad nueva y existente en componentes reutilizables que se integran
en los procesos de negocio, segn sea necesario. La diferencia fundamental entre el viejo estilo
de workflow y el enfoque de integracin es que, en lugar de integrarse con cada aplicacin en los
puntos donde sea necesario, el motor de BPM llama un "componente" o servicio Web que
"envuelve" la aplicacin legacy.
Es un requisito clave para la capa SOA el ser capaz de envolver la funcionalidad de las
aplicaciones empresariales existentes (tales como ERP, CRM o SCM), para luego entregar esta
funcionalidad a las nuevas aplicaciones sin necesidad de extensiones personalizadas de la
aplicacin subyacente. De hecho, hay fuertes indicios de que los proveedores de las principales
aplicaciones, como SAP y Oracle (que en la actualidad incluye PeopleSoft, Siebel y JD Edwards),
estn ocupados reconstruyendo sus entornos de aplicaciones monolticas para hacerlos ms
accesibles a la personalizacin en el nivel de proceso. La funcionalidad entregada por la aplicacin
se est descomponiendo para que sea ms susceptible a la personalizacin.
En general, este enfoque de la integracin de servicios y procesos de negocio permite a la empresa
ampliar y reutilizar sus inversiones existentes en TI, aprovechando la funcionalidad construida al
tiempo que permite el desarrollo de nuevas aplicaciones, orientadas a procesos, que se ajustan
mejor a las necesidades cambiantes de los usuarios. El resultado es una estructura ms gil, un
entorno tecnolgico ms productivo que los desarrolladores pueden utilizar para crear
nuevas aplicaciones o capacidades de negocio, de manera ms rpida y a menor costo. Tal vez lo
ms importante, al final, es que los sistemas manejan un vocabulario que el negocio entiende
mejor.

Mejores Prcticas
Las siguientes son aspectos importantes a tener en cuenta dentro de un proyecto de
implementacin de BPM SOA:

Es solamente experimentando los beneficios de BPM-SOA como la organizacin va a

respaldar y a comprometerse con el programa y va a ayudar a impulsar el cambio. Ms
an, como resultado de ver y experimentar el cambio iterativo, los requerimientos del
negocio van a empezar a cambiar ms rpidamente y despus de varias iteraciones, cuando
los procesos y los servicios evolucionen para adaptarse mejor a las necesidades del
negocio se van a ver los beneficios que van a entregar retornos masivos de la inversin.

Asegur un grupo directivo de alto nivel, formado con el patrocinio del nivel ejecutivo.
De lo contrario, la iniciativa probablemente ser condenada al fracaso. Es importante
asegurar que las batallas se libren en los niveles adecuados, teniendo en cuenta la estrategia
y los objetivos generales de la empresa. La clave es asegurar que existe un acuerdo en torno
a cmo las funciones y responsabilidades se dividen. Decidir quin es responsable de qu,
y luego asegurar que existe consistencia en todos los miembros del equipo directivo.

Desarrolle y establezca polticas eficaces de funcionamiento, que deben ser comunicadas

y su cumplimiento medido. Trabaje con el Grupo Directivo, acuerde el alcance del proyecto
inicial y desarrolle una hoja de ruta sobre el camino a seguir, destacando cmo (y cundo)
otras partes del negocio sern involucrados. Iter sobre la hoja de ruta despus de cada
ciclo del proyecto. Establezca beneficios a corto plazo (proyectos tcticos para construir
el xito), mientras crea un coherente y flexible entorno de TI que puede soportar los
cambiantes requerimientos de negocios.

Es importante empezar con proyectos pequeos y poder demostrar casos de xito, para
entonces aprovechar ese xito y construir ms. Como regla general, cuanto mayor es el
alcance, ms difcil es controlar el proyecto inicial, pero ms grande es la oportunidad para
la innovacin. Elegir el punto correcto para iniciar y formar un equipo de trabajo eficaz es
un factor crtico de xito.

En lugar de tratar de hervir el ocano, en primer lugar, asegrese de llevar a cabo un

proyecto tctico para que la empresa pueda saborear el xito. Asegurar un alcance afinado
y limitado es un factor crtico de xito. Para el proyecto inicial, al menos, evite la tentacin
de gastar el tiempo llenando un depsito de herramientas o servicios. Aunque este tipo de
 esfuerzo puede aadir valor a un Centro de Excelencia de BPM cuando se est enfrentando
con problemas en toda la organizacin, es una distraccin durante el experimento tctico.

Asegur que las expectativas de los usuarios de negocios se establecen adecuadamente

desde el principio. Tenga en cuenta que BPM-SOA implica una metodologa
fundamentalmente diferente a los tradicionales ciclos de vida de desarrollo de proyectos
pues est centrada en iteracin y adaptacin. Asegrese de que la poblacin de usuarios
comprende las implicaciones de este cambio (debe haber una intencin de despliegue de la
primera iteracin a las pocas semanas del lanzamiento del proyecto inicial). Esto es
esencial para detener el crecimiento del alcance y reducir el riesgo de fracaso del proyecto.

No sobrevalore la "madurez" de la organizacin. La transformacin a una organizacin

orientada a procesos y servicios requiere un cambio en la mentalidad predominante tanto
de los negocios como en TI.

Llev a cabo un ejercicio para caracterizar las capacidades de alto nivel de la empresa.
Estas capacidades son las conductas que la empresa debe presentar con el fin de cumplir
con los "requisitos para relacionarse con el exterior" con los clientes, reguladores,
accionistas, socios, proveedores, etc. El objetivo es identificar todas las influencias de
importancia estratgica en la empresa de tal manera que mecanismos adecuados puede
ser instalados y monitoreados.

Cuando modele las capacidades de negocio, piense en las partes que la constituyen y
asegrese de comprender cmo encajan en el todo. Con el fin de limitar la dependencia
entre la capacidad y los procesos que hacen uso de ella, exprese la interfaz como un
contrato de servicio y diseo el contrato de tal manera que no sea especfico para un tipo
de solicitud. El contrato debera estar definido en el nivel declarativo, en lugar ser definido
programticamente, pues si es hard code los beneficios de acoplamiento se perdern.

En lugar de descomponer la funcionalidad deseada en trozos (que luego son codificados

y altamente integrados), la mejor prctica es ensamblar un conjunto de servicios
independientes en procesos, donde cada uno de estos servicios provee parte de la
funcionalidad deseada.

Cuando se trata de desarrollar efectivas arquitecturas de procesos, cntrese en la

construccin de familias de componentes (servicios) que puedan ser instanciados y
reutilizados cuando sea necesario. Desarrolle servicios de granularidad alta como recuperar
perfil del cliente, actualizar la direccin, calcular credit scoring o actualizar inventario.

Comience con un plan, no con uno completo para toda la organizacin, pero con uno que
permite al equipo construir experiencia y conocimiento, haga un piloto e itere. Afine el
alcance inicial del proyecto, defina el cronograma previsto y despus profundice en los
detalles. Comience con unos pocos servicios y est preparado para aadir ms servicios,
 pero slo dentro del contexto del plan (el proceso de negocio que constituye el objetivo
inicial). Mantenga la meta siempre a la vista.

Tenga en cuenta que la intencin es desarrollar el marco general de arquitectura para la

empresa. Inevitablemente, el cambio organizacional es necesario, por lo tanto ste debe
ser cuidadosamente administrado y sincronizado con la implementacin de la tecnologa.

Entienda que la arquitectura de SOA es slo parcialmente responsable de los potenciales

beneficios, que se derivan del diseo de servicios. La granularidad es muy importante ya
que un mal diseo de servicios puede matar cualquier proyecto. Un servicio exitoso es
aquel que se vuelve a utilizar con frecuencia y que casi nunca cambia. Inicie diseando
desde la perspectiva de los clientes, teniendo en cuenta sus necesidades de confiabilidad,
rendimiento, tiempo de entrega, servicio de soporte y procesamiento de transaccional.

Conclusin

Mientras BPM y las estrategias basadas en SOA pueden llevarse a cabo de forma independiente el
uno del otro, hacen mucho ms sentido cuando se integran entre s. Cuando se despliega BPM
utilizando tcnicas de SOA, los servicios son utilizados como bloques de construccin que pueden
ser orquestados a travs de los BPMS para apoyar las necesidades de los procesos de negocio ms
complejos. Adems de crear nuevos servicios, un principio bsico de SOA sta en la capacidad
de envolver componentes funcionales de las aplicaciones existentes y a continuacin,
exponer estos componentes como servicios que pueden ser llamados por diferentes procesos de
negocio. Estos servicios reutilizables tambin pueden ser ensamblados para formar nuevos
servicios compuestos y nuevas aplicaciones.

Creer que BPM es un subconjunto de SOA es un error. Esa forma de pensar fortalece que la
agilidad del negocio sigue siendo dependiente de TI y en lugar de eliminar la barrera entre la TI
y el negocio, la refuerza. BPM busca realizar mejoras en el rendimiento del negocio, sin considerar
los beneficios de pensar en SOA. Mientras que SOA aspira a apuntalar la agilidad del negocio,
este es fundamentalmente un enfoque de integracin de TI. En todo caso, la relacin de BPM-
SOA es al revs. SOA es un enfoque de mejores prcticas de diseo para el desarrollo y despliegue
de una iniciativa BPM.
Para tener xito en el largo plazo, BPM y SOA necesita convertirse en una forma de pensar a nivel
empresarial. Que tomar tiempo y no puede precipitarse. El Grupo Directivo debe asegurarse de
que la iniciativa tenga los recursos adecuados, con la correcta infraestructura de desarrollo y los
mecanismos de entrega. Por supuesto, una visin efectiva visin de arquitectura ayudar
reflejada tanto en una hoja de ruta de negocios en evolucin y un conjunto de servicios de apoyo
tecnolgico. Junto a esta visin, una disciplina de gestin es esencial para asegurar que la iniciativa
se mueve continuamente hacia la meta de mejorar el rendimiento del negocio.