Última parte del árticulo…

Me han convencido, quiero tener SOA ¿cómo?

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?. Desde el punto de vista tecnológico, 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 de programación, 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. Las empresas como IBM, Microsoft, Oracle, Software AG, disponen de sus suites empresariales que dan soporte tecnológico a este tipo de arquitectura. A menudo se confunde el objetivo con la forma de llevarlo a cabo, el fin con los medios.

Por otra parte, uno de los mitos más extendidos es que SOA se puede comprar. Que viene en una caja que pueda vender cualquiera de las empresas de software. También, que la orientación a servicios es una forma de hacer las cosas que aparece de manera natural con el uso de determinadas herramientas. Por desgracia, esto no es así. En realidad no hay ninguna tecnología, producto o framework que sea SOA. Se puede tener una orientación a servicios con tecnologías ya disponibles anteriormente y por contra, se puede disponer de las últimas tecnologías y no construir servicios, sino aplicaciones silo (que no se comunican entre sí), de la manera que podemos entender como “tradicional”. De hecho, SOA es neutral desde el punto de visto de la tecnología y el vendedor. En ultima instancia, es una forma de computación distribuida por lo que cualquier tecnología donde se pueda ejecutar programas de manera remota  y donde se pueda indicar el contrato del servicio (parámetros de entrada/salida) sería posible implementar una arquitectura orientada a servicios.

En cuanto a la metodología, 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. Cambiar la percepción de un organización  con aplicaciones silo, verticales, que se pensaron en su momento para dar soluciones a un área o departamento dentro de la organización, no a toda la organización, y que no “hablan” entre sí. La orientación de SOA es proporcionar servicios que sea útiles a toda la organización, soluciones de negocio.En cuanto al ámbito de la adopción de SOA, 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,  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.

Evitemos caer en errores ya conocidos
La entrada en el mundo SOA suele ser en principio una experiencia poco gratificante en el sentido de que no suele estar claro qué es SOA, cuánto me cuesta, como lo llevo cabo, etc. etc. En ocasiones no existe una definición clara de los conceptos que se manejan y de la metodología necesaria para ponerla en práctica. Si a ello se añade la dificultad habitual de poner en práctica cualquier gran iniciativa de T.I. es bastante probable que no se alcance el éxito esperado (al menos en principio). La consultora Gartner lista 12 errores o malas prácticas al adoptar SOA. Son errores conocidos en los que no podemos caer.  Entre estos errores, los más importantes son los siguientes:

  1. Excesivo número de servicios.
    Se puede caer en el error de pensar que todos los componentes software deben ser considerados como servicios útiles para el negocio. Como solución, hay que diseñar los servicios con el objetivo puesto en que sirvan para la lógica de negocio, no en las particularidades técnicas.
  2. Dejar SOA únicamente a los técnicos
    Como he comentado anteriormente SOA no es una tecnologia. Sin embargo, en la práctica, la implicación del área de negocio suele brillar por su ausencia y se considera SOA como un proyecto de T.I. Para evitar esto, se propone que en los equipos halla analistas de ambos “mundos”.
  3. No reutilización
    Uno de los principios de SOA es la reutilización de los servicios ya construidos. Sin embargo, en demasiados casos esto no se logra. El motivo puede ser tan simple como que no sepa que el servicio que necesitamos ya está construido, es decir, no tenemos una relación de los servicios disponibles. Para evitar esto, se necesita un repositorio o directorio de servicios que nos permita encontrar rápidamente el servicio que se adapta a nuestras necesidades
  4. Empezar demasiado grande
    Se puede caer en adoptar SOA “de golpe”, contemplándolo como un proyecto de larga duración donde se quiere pasar de la nada al todo. Dadas las dificultades que plantea la adopción de SOA a nivel de cambio cultural pero también técnico y de infraestructura, se recomienda empezar por un proyecto pequeño aunque con la vista puesta en el largo plazo (aplicando aquello de “piensa grande y actúa pequeño)
  5. Subestimar los riesgos técnicos
    Aunque SOA no es una tecnología, obviamente se necesita de esta última para llevar a cabo la implantación de la misma. Normalmente se implementa con la “familia” tecnológica de web services. Evidentemente esta implementación de SOA no es fácil de llevar a la práctica,  exigiendo perfiles técnicos y recursos para llevarlos a caso que constituyen un riesgo.

En definitiva, si hay que tener en cuenta los principios de SOA y vigilar de cerca su aplicación, más cerca todavía hay que vigilar que no se caiga en errores o malas prácticas (máxima cuando están documentadas y otros han caído antes en ellas).
Conclusión
En definitiva, si queremos comenzar a transitar en el “largo camino hacia SOA” tenemos que tener muy en cuenta lo siguiente:SOA no es un tecnología, es una forma de diseñar las aplicaciones de negocioLa adopción de SOA produce el beneficio de reducción de los costes, time to market y mejora la flexibilidad de la organizaciónAdoptar SOA no es fácil y tiene un fuerte riesgo técnico pero también organizativo (es necesario un fuerte cambio cultural).No debemos cegarnos con las soluciones técnicas (suites de productos comerciales) ni querer adoptar SOA de golpe y de forma masiva. Frente a esto es preferible incluso empezar con un pequeño piloto con productos “open source”, poniendo el énfasis en el diseño (orientación a servicios).

Primera parte

Segunda parte

Comparte esta entrada…

Share