.
Vender la Gestión de Procesos de Negocio (BPM) no es nada fácil. Es mucho más fácil vender una Arquitectura Orientada a los Servicios (SOA).
Es también posible vender a la dirigencia un enfoque basado en la Arquitectura de Empresa. Pero no con BPM.
Esos son hechos. Lo interesante es entender las razones de un escenario tan lejano de la lógica.
En las conversaciones que tenemos con los comerciales de mi empresa y los otros consultores senior, hemos podido ventilar ciertos elementos que complementan mi trabajo (tanto científico como pragmático) en el área durante los últimos 5 años y 10 meses.
La SOA es un aproximación técnica. Por lo tanto, los técnicos estarán dispuestos a acogerla. No es necesario entenderla claramente; los argumentos esgrimidos por los vendedores más importantes en los últimos años, sumado a la supremacía del discurso de la conectividad universal como objetivo último de toda arquitectura ágil y bien realizada, no dejan espacio para dudas.
Desafortunadamente, nadie hace las preguntas que nadie ha hecho. Y todos tan contentos, y nadie hace el ridículo.
.
Para qué la conectividad universal? para poder reutilizar de manera también universal (tanto para componentes locales como distantes, en forma transparente e independiente del protocolo) los componentes. De hecho, no los componentes como tales, sino las funcionalidades expuestas por el componente.
De manera tácita, la serpiente se muerde la cola: el argumento principal de los vendedores es la posibilidad de crear aplicaciones compuestas.
Veamos el gráfico de nuestra graciosamente engurgitada BEA:
BEA - Aplicaciones Compuestas
Las aplicaciones compuestas se realizan sobre la base de una plataforma evolutiva realizada con componentes desacoplados y deslocalizados. Esto quiere decir que las funcionalidades se basan en simples contratos funcionales, y los proveedores que satisfacen tales contratos se encuentran en cualquier lugar del espacio (locales, distantes, y hasta super-distantes).
Entonces, se necesitan componentes que se puedan conectar de forma universal. Esto garantiza su reutilización.
Premisas:
La tecnología T permite de obtener A y B. Lo que usted desea es sobre todo A. B permite de obtener A.
Análisis de Causalidad:
Usted necesita C (axioma), B garantiza C, B permite crear A, entonces A poseerá también la cualidad C. QED.
Esta pequeña demostración de la serpiente hambrienta nos deja pendiente solamente el aspecto que hemos denominado C. Lo acabo de emplear en los párrafos anteriores, pero es un vocablo tan repetido y tan buscado en la ingeniería de software, que olvidamos que está allí: la reutilización.
Procedo entonces a formular la pregunta que incomoda desde hace más de 4 años a todos mis colegas y competidores que laboran en los dominios de la arquitectura, concepción y programación: cuál es la tasa de reutilización obtenida? (seguido de: y cuál es la tasa de evolución en los últimos 5 años?).
Este punto ya lo he mencionado en el pasado, y la respuesta sigue siendo invariablemente una de estas dos: “indeterminada” (con cara de verguenza por la falta de franqueza), ó “menos de 1%“.
¿¿¿¿¿Para qué insistir e invertir tanto con una aproximación arquitectónica si el argumento de base no ha sido demostrado??????
(Esto es similar a la actual crisis bancaria: la aproximación se volvió una finalidad en sí misma, una meta-paradoja)
Si con humildad volvemos a los años 1993-1995, cuando se sentaron las bases metodológicas de la práctica de las tecnologías orientadas a objeto, veremos que el aspecto más crítico de la reutilización es la creación de un referencial. Un referencial es un inventario controlado (managed) que permite establecer un control de calidad sobre la evolución de la arquitectura de un sistema o aplicación.
Con humildad debemos también reconocer que la creación de un referencial nunca fué fácil. ¿Por qué debería serlo en una SOA? ¿qué ha cambiado? acaso tenemos nuevas técnicas o metodologías? tal vez, pero no son populares ó por lo menos no son prácticas.
Es decir, la reutilización es una solución y un problema en sí misma. Estamos tan enseguecidos en su búsqueda, que pocos se preocupan de los aspectos difíciles y los retos que esto significa. El (entonces) famoso “ingeniero de reutilización” que vendían tantas propuestas metodológicas a principios de los años 90 no es práctico y ha desaparecido en la bruma (desde 1995, para ser precisos). Los arquitectos han tomado una parte de ese rol, pero la reutilización se volvió un término inconveniente y ha sido escondida adecuadamente.
Yo recuerdo el “ingeniero de reutilización” porque me parecía magnífico evitar el despilfarre, pero me resultaba difícil materializarlo, y nunca lo ví en ningún proyecto. Quedó retenido en mi memoria porque le tomé cariño, como a cualquier otra curiosidad ó idea en apariencia genial pero realmente bastante lunanca: más exótica que útil.
Si entendemos esto, luego es fácil entender por que los servicios web crecen en forma horizontal en las organizaciones, pero el crecimento vertical (la evolución en la forma de servicios con versiones explícitas) no es fácil de lograr (¿Cuando fué la última vez que chequeó un proyecto con servicios web versionados?). Como causa y como consecuencia de esta aproximación, la forma de describir los componentes y sus funcionalidades mantiene el formato empleado hace 15 años (el de la API). Muchos autores hablan de la urbanización… eso esta muy bien, pero como no poseemos notaciones para explicar las funcionalidades de un componente, mucho menos para expresar aquella de decenas/cientos/miles de funcionalidades expuestas pour un número creciente de componentes. Los bloques funcionales a nivel macro, los paquetes UML a nivel medio y las interfaces UML a nivel micro son la práctica corriente.
En realidad, estamos limitados porque no hemos querido/podido evolucionar en este sentido. Por eso las aproximaciones de tipo Scrum/XP son tan eficaces: no perdamos el tiempo generando una documentación que no podemos generar.
La Arquitectura de Empresa es un enfoque de negocio: según la teoría, se deben entender los procesos de la empresa, con el objeto de entender cómo se crea valor en interno, pero también cómo se debe/puede interactuar con los actores del entorno de la empresa (proveedores, compradores, competencia, reguladores). En el mundo real, un esfuerzo de documentación de los procesos se justifica si se desea calcular el riesgo operacional dentro de una aproximación de compliance; en algunas ocasiones también para construír procesos ejecutables mediante aplicaciones compuestas.
No me extenderé más en esta parte de mi discusión. Lo cierto es que a muchos managers le encantan los dibujos hechos con herramientas tales que ARIS, Mega, System Architect. En realidad, dada la complejidad de tales modelos, la consecuencia es una no-adopción (cariño) por parte de las personas encargadas de mantener los modelos. In veritas, la mayoría termina re-adoptando Visio y lo emplean en forma tan ad hoc como la propia organización. Una vez finalizados, se imprimen y se guardan en una gaveta, hasta la próxima auditoría de compliance.
Muchos dirigentes creen que con haber contratado la creación de tales modelos, ellos ya pueden lavarse las manos. Concuerdo con ellos que esto es la due diligence, pero esto no equivale a una appropriate diligence. Como siempre, prefiero ser provocador.
¿Qué falta en el mundo de la arquitectura orientada a servicios para poder garantizar la reutilización? habilitar la governancia de tales funcionalidades.
¿Qué falta en la arquitectura de empresa para que los modelos no sean solamente elementos pasivos y olvidados? establecer una governancia de los modelos.
Qué es la governancia? Eso lo puede responder wikipedia. Para nosotros los profanos, una definición orientada a procesos podría ser:
- el conjunto de procesos y procedimientos que permite de establecer ciclos de vida claros para los elementos governados,
- complementado por la ejecución de tales procesos y procedimientos.
- implica a los actores que participan en el ciclo de vida de los elementos, y a los clientes de los servicios generados
Una governancia para nuestras dos queridas arquitecturas (orientada a servicios y de empresa) genera una dinámica, hace que los elementos normalmente destinados a “guardar polvo” se conviertan en factores de la estrategia empresarial, tanto en el IT como a nivel del negocio.
El BPM involucra los aspectos de governancia, racionaliza/determina el expectro de la SOA y hace el puente entre la Arquitectura de Empresa a nivel de negocio y a nivel de servicios provistos por la Infraestructura Tecnológica. Es por esto que no es lógico que miremos los extremos opuestos y olvidemos el lazo que los une, y que puede evitar tantos dolores de cabeza.
Lo gracioso es que se genera el famos efecto de miopía de mercado. Cuando finalmente tenemos el conocimiento y la tecnología para realizar una gestión de los procesos de negocio (BPM), ya nadie busca la solución. En consecuencia, nadie cree en la proposición y es difícil venderla.
El nuevo reto de los próximos 10 años nos está esperando hace rato. Estamos atrasados, señoras y señores.
Valora mi trabajo
Si me conoce mi trabajo porque has trabajado conmigo, o conoces mi trabajo, puedes valorlo en Webspotters.com
No Comments Yet