Una vez que una organización se decide a adoptar SOA, quizás la primera pregunta que todo el mundo se hace es ¿por dónde empiezo?.

Para responder a esta pregunta hay que tener en cuenta que en realidad SOA no versa sobre una tecnología sino sobre una forma de hacer las cosas. Por lo tanto, estrictamente hablando, no hay una infraestructura tecnológica o productos concretos, lenguajes, etc. que haya que implantar obligatoriamente para adoptar SOA. Evidentemente, sí que hay una serie de estándares y de productos enfocados para lograr este objetivo. Por ejemplo, disponer de un Enterprise Service Bus, de un Registro de servicios, de un motor de procesos de negocio y de un lenguaje (más bien una plataforma) como puede ser Java (conocida como Java Enterprise Edition), que pueden ser la base tecnológica sobre la que construir una arquitectura orientada a servicios.

A menudo se confunde el objetivo con la forma de llevarlo a cabo, el fin con los medios. Como he dicho anteriormente, SOA es una forma hacer las cosas, un paradigma de diseño en el que se construyen las piezas de software (pequeños programas, rutinas o procedimientos) con una orientación a servicios (con un contrato que define sus parámetros de entrada/salida, sin estado, interoperables, que se puedan componer para formar otros servicios, etc. etc.).

La forma más adecuada para abordar la adopción de SOA en la empresa debe ser determinada como resultado de una planificación y estudio de sus características, de un modo pragmático, teniendo en cuenta su impacto en la organización y sobre todo el cambio cultural que debe realizarse. En muchas ocasiones, lo más díficil es lograr precisamente este cambio cultural. Cambiar la percepción de un organización en TI con aplicaciones silo, verticales, que no interoperan entre sí, a una orientación a servicios.

Los expertos recomiendan en este sentido, “piensa a lo grande y actua pequeño“. Es decir, teniendo la foto final en la cabeza no lanzarse a implantar el cambio en todos los niveles a la vez: metodología, infraestructura, middleware, registro de servicios para el gobierno, nuevos proyectos con enfoque a servicios, etc. En ocasiones esto resulta un bocado demasiado grande para que la organización lo digiera. Es recomendable marcarse objetivos a corto plazo, modestos, pero realizables. Todos ellos encaminados hacia la estrategia global de la adopción de SOA.

El manifiesto SOA, aborda esta cuestión en su tercer punto, que dice (traducción libre):

El alcance de la adopción de SOA puede ser variado. Mantén tus iniciativas bajo control y dentro de los límites que dicta el sentido común.

Thomas Erl, uno de sus autores, recomienda ser modesto en esta adopción para evitar riesgos y no lanzarse hacia la consecución de la foto final sino realizar aproximaciones iterativas. Para ello puede ser necesario ir evolucionando desde las aplicaciones SILO con sus “islas de servicios” hacia “continentes de servicios”, esto es, ir ampliando paulatinamente el ámbito de los servicios desde el departamento, el área TI y por último toda la organización (adopcion por fases).

A la hora de pensar por donde empiezo en la adopción de SOA, siempre es recomendable evitar los errores y las malas prácticas por los que otros han pasado antes: lo que no debo hacer.

Entradas relacionadas:

El papel fundamental del registro de servicios en SOA

Procesos de negocio con SOA

¿Cómo identificar los servicios de negocio en SOA?

Comparte este artículo…

Anuncios