Enfoque de desarrollo. Para llevar esto a la empresa existen tres caminos:

1. De arriba hacia abajo: procesos de negocio primero, reglas de negocio, etc. y luego la automatización, es decir, empezamos con BPM y luego SOA.

2. De abajo hacia arriba: primero se construye un catálogo de servicios a nivel empresarial y luego los procesos de negocio, es decir, primero SOA y luego BPM.

3. También existen algunos modelos de madurez aplicados al BPM(5) pero cuyo valor deberá ser probado en el futuro.

¿Cuál debe ir primero? Indudablemente la respuesta dependerá de si la persona a la que se le pregunta es del negocio o de TI. Los primeros argumentarán su derecho de recobrar el control de los procesos de negocio “secuestrados” por los ERPs, los CRMs y cualquier otra solución de software de tres letras. Los segundos dirán que ellos tienen la cultura y las herramientas necesarias para desarrollar tan complejo proyecto. Lo cierto del caso es que aunque BPM sin SOA es posible la implementación de BPM descansa sobre la arquitectura tecnológica subyacente y si esta es SOA se obtiene la tan ansiada agilidad. Por otro lado, es importante reconocer que BPM le da una “cara de negocio” a SOA y por lo general es el punto de entrada a la oficina del CEO.

Claramente ambos enfoques tienen sus deficiencias. En el primero existe la posibilidad de que al modelar procesos estos puedan no tener una representación tecnológica que permita la ejecución tal y como está modelada. Por otro lado, empezando de abajo hacia arriba estaríamos ignorando el contexto de negocio en el que los servicios se desenvuelven con lo que ciertamente obtendríamos un catálogo de servicios reutilizables desde el punto de vista tecnológico pero sin valor alguno para el negocio. Sin embargo, desde mi perspectiva el primer enfoque tiene menos problemas que el segundo.

En primera instancia al empezar a partir del modelo del proceso nos garantizamos que los servicios desarrollados estén alineados con la estrategia de la organización incluso antes de que sean implementados, de esta forma logramos que estos servicios tengan un impacto inmediato en la ejecución de los procesos de la organización, es decir, los colaboradores verán cómo las aplicaciones de software que usan diariamente son mejores debido a la inversión que el departamento de TI hace, y mucho más rápidamente a como se hace hoy en día me atrevería a agregar. Por otro lado, es importante dejar claro que este es un esfuerzo conjunto entre el negocio y TI y por ende la interacción de roles de ambas partes en el desarrollo de proyectos de este tipo es fundamental. Dicha interacción se realiza principalmente a nivel arquitectónico entre el analista de procesos de negocio y el arquitecto de TI armonizando los elementos arquitectónicos en juego y en procura de la mejor solución para el negocio.

Desafíos. En la adopción de BPM/ SOA encontramos desafíos importantes, algunos de los cuales señalo a continuación:

• Debido a que este tipo de proyectos redefine la arquitectura total del negocio es imprescindible hacer una buena administración del cambio organizacional, un rol cuya importancia crece cada día. Por esta misma razón es indispensable que este tipo de proyectos cuente con el apoyo de la gerencia pues de lo contrario peligra en convertirse en una “guerra de silos” sin beneficio para nadie.

• Es importante desarrollar una metodología holística que tome en cuenta tanto el modelado de los procesos de negocio (incluyendo cosas como reglas, métricas, desempeño esperado, etc.) y el desarrollo de todos los elementos de TI involucrados (requerimientos funcionales y no funcionales). ¿Cuál es el grado de contribución de las metodologías de desarrollo de software (cascada, RUP o cualquier sabor de agile) en el logro de este objetivo(6)? Independientemente de cual sea la metodología es importante tener en mente que esta nos debe facilitar obtener tanto un ROI esperado así como la alineación de los procesos con la estrategia organizacional.

• El desarrollo de aplicaciones compuestas implica un cambio de paradigma con respecto al desarrollo de aplicaciones tradicionales end-toend. Esto podría requerir algún entrenamiento técnico de su equipo de desarrollo (portlets, WSRP) así como una concientización en la importancia de los separation of concerns que trae consigo el acoplamiento débil.

• Particularmente en empresas grandes el gobierno de la arquitectura de servicios y las aplicaciones compuestas puede volverse bastante complejo. Es indispensable definir el ciclo de vida de los servicios atado a la evolución de los procesos de negocio.

• El rol de los arquitectos empresariales es esencialmente importante y es por esto que es indispensable contar con personas apropiadamente capacitadas. Este arquitecto es el responsable de traducir las necesidades del negocio (expresadas en los modelos de proceso, tiempos de respuesta definidos en los Acuerdos de Nivel de Servicio, requerimientos de seguridad y confiabilidad, etc.) en un diseño tecnológico de diversas vistas (datos, componentes, servicios, seguridad, infraestructura) para producir una solución tecnológicamente coherente. Además, por su interacción con el negocio debe tener habilidades “suaves” tales como comunicación, negociación, liderazgo, entre otras.

El futuro cercano: BPM + SOA + EA. Desafortunadamente el término “arquitectura empresarial” (EA por sus siglas en inglés) ha sido satanizado en las empresas debido al cuestionado valor que hasta el momento han entregado los esfuerzos arquitectónicos. Estas iniciativas son muchas veces vistas como “torres de marfil” aisladas de la realidad de la empresa. Incluso es frecuente que se dejen de lado cada vez que se debe “apagar el siguiente incendio”. Lo paradójico es que uno de los objetivos de la arquitectura es precisamente evitarlos…

Otra dificultad que se presenta con el término es la diversidad de usos que se le da. A ciencia cierta no hay una definición clara y acordada de lo que una “Arquitectura Empresarial” significa. En Enterprise Architecture as Strategy(7) la definición que se da es la siguiente: “La Arquitectura Empresarial es la lógica organizacional para los procesos de negocio y la infraestructura de TI que refleja los requerimientos de integración y estandarización del modelo operativo de la empresa”. Me gusta esta definición porque pone a TI y a los procesos de negocio como componentes de la ecuación, al mismo nivel, y también porque hace una clara referencia a la estrategia elegida por la empresa de la mano del modelo operativo seleccionado, acorde con la tesis de los autores. En general podemos decir que la EA tiene la difícil tarea de traducir a términos operativos la estrategia organizacional, pasar del sueño a la realidad.

Independientemente de estas dos situaciones lo cierto del caso es que sin un gobierno de todos los elementos que hemos visto es difícil, por no decir imposible, alcanzar los objetivos planteados. Si BPM y SOA ocurren dentro del marco de una Arquitectura Empresarial, como componentes esenciales, tienen una mayor oportunidad de tener el impacto que de ellas se espera. La EA les da ese significado dentro de la estrategia del negocio tanto en el corto plazo como en la evolución a futuro. Hoy en día las empresas tienen que ser realmente diseñadas para poder adaptarse rápidamente (agilidad) sobre todo en una realidad en donde la competencia puede venir del cualquier parte del mundo. Algunos ejemplos de empresas que pasaron por esto son Dell y IKEA.

Como dijimos en el apartado anterior el rol central de esta arquitectura es el arquitecto empresarial. Un arquitecto empresarial es esa rara fusión de elementos tales como conocimiento de la estrategia organizacional, procesos de negocio y dominio de la tecnología en una sola persona. Diann Daniel(8) lo define de la siguiente forma: “… El arquitecto debe mapear, definir y estandarizar la tecnología, los datos y los procesos de negocio. Esto significa que debe tener tanto una visión micro como macro. Él debe entender la estrategia del negocio y traducirla en una solución arquitectónica (visión macro) pero también debe ser capaz de trabajar con proyectos individuales dentro de la visión micro. El arquitecto empresarial transforma el lenguaje técnico a soluciones de negocio y conoce la tecnología necesaria para hacer posible la estrategia de la organización”.

En relación con el tema de este artículo el arquitecto empresarial juega en ambos lados: sabe cómo traducir la estrategia en procesos de negocio y luego diseña soluciones tecnológicas para esos procesos. Es por esto que frecuentemente se le reconoce como puente entre el negocio y TI cerrando la brecha entre ambos, o por lo menos acortándola, base del pensamiento de Nicholas Carr que indiqué al inicio. Si su organización ya tiene una EA sería conveniente revisar la visión que tiene de los procesos de negocio. Si no la tiene empiece por investigar y formar arquitectos empresariales a través de una ruta de desarrollo profesional bien definida, atada al esfuerzo de desarrollo de BPM/SOA.

Una de estas rutas podría ser la identificación de arquitectos de TI con experiencia y complementar su conocimiento con métodos, herramientas, etc. de modelado de negocio tales como Value Stream Mapping de Lean Six Sigma, las habilidades “suaves” mencionadas, etc.

Conclusión: Aunque este pudiera parecer un esfuerzo complejo realmente vale la pena desarrollarlo. El beneficio para la empresa es demasiado grande para dejarlo pasar. Por otro lado, es importante darse cuenta de que BPM no solo trae consigo una visión holística del negocio sino que posibilita o incluso potencia el desarrollo de otros esfuerzos tales como Lean Six Sigma, Costeo ABC, entre otros.

En la próxima entrega hablaré sobre la sinergia existente entre BPM y Lean Six Sigma, cómo uno potencia al otro y la injerencia de TI en esto.

(5) http://cio.idg.com.au/index.php?id=1225422957

(6) http://www.ibm.com/developerworks/webservices/library/ ws-agile1/

(7)http://www.amazon.com/Enterprise-Architecture-Strategy- Foundation-Execution/dp/1591398398/ref=pd_bbs_sr_1/002- 0412087-8284069?ie=UTF8&s=books&qid=1185235473&sr =8-1

(8) http://www.cio.com/article/101401/The_Rising_Importance_ of_the_Enterprise_Architect