| |
Las arquitecturas orientadas a servicios (SOA) suponen una excelente oportunidad para terminar con la desconexión entre las TI y el negocio, un problema que lleva años arrastrándose debido a los modelos de software estándar que hasta ahora han copado el mercado. Estos modelos suponen que, por cada nueva oportunidad de negocio, se ha de desarrollar nuevo código o implementar un paquete de software específico para cubrir las necesidades de esa oportunidad. Los fabricantes de aplicaciones se han dedicado a desarrollar módulos de aplicaciones para satisfacer a todos los nichos de mercado imaginables.
Este tipo de estrategias generan mucha complejidad, ya que conectar cada nuevo desarrollo es difícil. Las organizaciones han venido empleando conexiones punto a punto para tratar de vincular los datos, lo que ha generado una maraña de códigos de integración que en TIBCO nos gusta comparar con un plato de spaghetti; este caos es incapaz de maximizar los beneficios de cada ronda sucesiva de esfuerzo en el área de TI. La industria de middleware surgió como respuesta a esta situación, diseñada para llenar los huecos entre las distintas aplicaciones empresariales, pero a menudo a terminado añadiendo una capa más de complejidad a la integración entre aplicaciones y reforzando aún más la desconexión entre TI y negocio.
|
Esta falta de conexión ocasiona no pocos
problemas a las compañías: se incrementan los
costes y riesgos de la integración de la tecnología;
se dificulta el acceso a la información adecuada en
el momento adecuado; se aumenta el tiempo y esfuerzo que requiere
modificar los sistemas; y finalmente, el gasto en TI se dispara
y se vuelve fijo. Todo ello hace pensar a las empresas que
no están obteniendo beneficios incrementales de cada
ronda sucesiva de inversión en TI.
La clave que hace que los actuales proyectos
SOA tengan el potencial para acabar con esta problemática
es que están creándose en línea con los
cambios en los requerimientos del negocio. La comunidad TI
ha reaccionado ante el hecho de que la arquitectura no es
una serie de códigos creados para resolver problemas
tecnológicos específicos, aisladamente del problema
de negocio. Por el contrario, SOA supone toda una disciplina
de diseño, desarrollo y despliegue y, aplicado a los
procesos de una organización, proporciona ventajas
significativas frente a los enfoques tradicionales.
|
|
SOA permite ofrecer las funcionalidades de TI de
una organización como servicios que a su vez pueden reutilizarse
para otros proyectos futuros. Usuarios que ya utilizan enfoques
SOA en sus arquitecturas de información afirman haber obtenido
importantes ventajas, como una flexibilidad mucho mayor y significativos
aumentos de productividad, ya que los desarrolladores no sólo
se libran del trabajo de escribir código de bajo nivel, sino
que además, y como consecuencia de esto, tienen más
tiempo para centrarse en lo que verdaderamente es más importante
para el negocio. Los clientes también indican que las mejoras
de productividad no llegan de forma inmediata con una SOA, sino
de forma incremental a medida que se van implementando sucesivos
proyectos orientados a servicios.
SOA, pues, se muestra como una oportunidad para conectar TI y negocio, pero para que esto verdaderamente ocurra, la arquitectura debe estar creada y desplegada en línea con los requerimientos de los procesos de negocio. Es por ello que el software BPM tiene un enorme valor cuando se aplica dentro de un despliegue SOA, gracias a su capacidad para proporcionar un lenguaje común para que las TI y el negocio se comuniquen.
Añadiendo una capa de BPM a sus arquitecturas SOA, los clientes pueden reducir el tiempo de salida al mercado de productos y servicios y minimizar los costes de desarrollo, al utilizar una única suite de gestión de procesos de negocio. Consecuentemente, los clientes son capaces de transformar sus aplicaciones monolíticas CRM, ERP y heredadas en servicios reutilizables, que pueden ser combinados, organizados y orquestados para soportar procesos de negocio complejos.
No obstante, hay que señalar que la aplicación del BPM a SOA implica también una serie de retos. El primero es que es necesario que los procesos tengan un alto grado de madurez, precisamente por la desconexión que ha existido durante mucho tiempo. Parece que las herramientas que los arquitectos de TI y los usuarios de negocio han adoptado para hacer sus trabajos son incompatibles. Por ello, se requiere un nuevo entorno para crear y modificar reglas de negocio, procesos y estructuras de gestión, que esté a su vez vinculado con todo el entramado técnico de los sistemas y con el entorno de modelado de procesos.
Por último, me gustaría remarcar que este realineamiento también implica retos organizacionales. Más allá de los desarrollos técnicos, está emergiendo un nuevo rol en las organizaciones que se encargará de tender un puente entre TI y negocio, garantizando a un nivel básico que ambas partes están hablando el mismo idioma.
Una SOA no puede ser desplegada sin más; el departamento de TI no puede empezar a convertir en servicios cada activo tecnológico de la compañía; necesita centrarse en áreas que den soporte a la estrategia de negocio. Y definir estas áreas es tarea de esta nuevo rol que podemos denominar analista de procesos o arquitecto de negocio.
Crear servicios definidos como parte de los procesos de negocio, y desplegarlos en contextos de negocio, requiere de un profesional que comprenda tanto la parte técnica como los objetivos de negocio y los indicadores clave de rendimiento. Por ello, facultar a un arquitecto de negocio para que ejerza este papel puede ser una de las decisiones más importantes que una organización pueda tomar.
|
|
