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).

En anteriores entradas de este blog se han introducido conceptos que ayudan a plantear la adopción de una arquitectura SOA (SOA ¿por dónde empezar? y SOA ¿cómo lo implemento?). Sin embargo, en ocasiones, ayuda aclarar más saber lo que no se debe hacer para evitar caer en errores en los que otros han caído antes. Una búsqueda en la red de conceptos como “SOA mistakes” o “SOA antipatterns” arroja un lista casi interminable de resultados,  SOA AntiPatterns: How Not to Do Service-Oriented Architecture, SOA Anti-Principles por poner unos ejemplos.

Sin embargo, la referencia en primer lugar debe ser de Gartner, que por otra parte estableció “oficialmente” el término SOA. En este documento de 2007 (pdf) de la propia Gartner se listan 12 errores o malas prácticas al adoptar SOA. Los errores que cita son los siguientes:

  1. Excesivo número de servicios
    Se puede caer en el error de pensar que todos los componentes software e incluso objetos (programados por ejemplo en Java o c#) deben exponerse como servicios útiles para el negocio. Se constata que el número de servicios útiles de negocio son de lejos mucho menor número que los componentes.
    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. Olvidarse de los datos
    No tener cuenta que al final los servicios tratan con datos de negocio y que por lo tanto en su diseño debe contemplarse como se relacionan las necesidades de negocio con el modelo de datos puede dar como resultado una aplicación con un pobre rendimiento y que puede poner en peligro la integridad de los propios datos. Se propone por lo tanto que el diseño del servicio y del modelo de datos esté coordinado.
    Personalmente, no estoy muy de acuerdo con esta afirmación. Creo que uno de los problemas que se producen en el diseño de servicios es que se tiene demasiado en consideración el modelo de datos sobre el que se está trabajando. En ocasiones, se llega incluso a que el servicio sea un calco del modelo de datos en el que se tiene operaciones tipo CRUD que no tienen valor para el negocio.
  3. Dejar SOA únicamente a los técnicos
    SOA no es una tecnología es un forma de diseñar aplicaciones que promete acabar con la división tradicional entre el área de negocio y el área de T.I. estableciendo una colaboración natural entre ellos. 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”.
  4. No reutilización
    Uno de los principios de SOA es la reutilización de los servicios ya construidos. Sin embargo, se plantean casos en que el equipo de desarrollo no se fía de desarrollos de otros equipos o simplemente cree que el software que el desarrolla es mejor que el del resto, por lo que en la práctica no se reutilizan los servicios. Por supuesto, también existen razones técnicas que dificultan o reducen esta reutilización, por ejemplo:
    – No existe un repositorio donde se puedan buscar si ya existen los servicios que se necesitan
    – Las características de seguridad o rendimiento de los servicios existentes no cumplen nuestros requisitos
    – En el diseño de los servicios se tuvo en cuenta únicamente las necesidades del proyecto y no las futuras de la organización.
    Para evitar esto, hay que cambiar la mentalidad y aplicar el principio de si algo ya está desarrollado, hay que intentar usarlo antes de hacer un desarrollo propio.
  5. 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).
  6. Empezar en el lugar adecuado
    En ocasiones no se sabe donde empezar a implantar un diseño orientado a servicios. Esto es una cuestión compleja que debe ser contemplado por la metodología en una fase de “descubrimiento de servicios”. Sin embargo, para ser prácticos, Gartner plantea la obvia solución de dar respuesta a los clientes que lo necesitan en primer lugar, por ejemplo si se pide para dar servicio a un frontal, entonces se debería crear un servicio que aporte los datos que necesita este frontal. Si se necesita para dar soporte a un proceso de negocio, entonces proporcionar un servicio en este contexto.
    En mi opinión, esto tiene el riesgo de ser excesivamente “reduccionistas” y no tener una visión global y a largo plazo de las necesidades de la organización.
  7. Asumir que todo el mundo piensa igual que tú
    Cada perfil (incluso cada persona) dentro de la organización tendrá su propia idea de lo que significa SOA y tendrá unas expectativas al respecto diferentes. Esto puede dificultar en gran medida la adopción de SOA por lo que se recomienda tener esto en cuenta desde el primer momento y establecer los cauces de comunicación necesarios para tener una visión única de los objetivos y de las expectativas.
  8. Dictadura vs Anarquía
    Tradicionalmente, con aplicaciones departamentales en “silos”, los grupos o áreas de T.I. han tenido gran independencia unos de otros  con un algo grado de libertad de actuación. Si embargo con la adopción de SOA y la caída de esos silos, es necesario una gran colaboración entre todas las partes. Para ello se puede caer en la situación opuesta y establecer un sistema “dictatorial” en el que un grupo o persona toma todas las decisiones y el resto está obligado a seguirle.
    Evidentemente, ninguna de las dos escenarios es recomendable por lo que se recomienda establecer un comité de coordinación en el que estén representados todas las partes. Lo difícil será mantener el control sin coartar la iniciativa del resto.
  9. Subestimar los riesgos técnicos
    Aunque SOA no es una tecnología, se asume que se implementa con la “familia” tecnológica de web services (WSDL, SOAP, WS-Security, etc.). También que esta tecnología necesita de una infraestructura de gestión y ejecución como el servidor de aplicaciones, ESB, UDDI, etc. Teniendo en cuenta esto, 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.
  10. Permitir que proliferen los servicios no compartidos
    Se entiende por servicios no compartidos aquellos que sólo los usa un cliente. Una buena implementación de SOA minimiza el número de servicios necesario gracias a que se reutilizan por varios clientes. Si esto no ocurre así probablemente se deba a que se están llevando a cabo málas prácticas como la duplicación de servicios, servicios de un grano demasiado fino o que realmente se han implementado un gran número de servicios que en realidad son necesarios.
    Para evitar esto hay que implantar un proceso formal de definición y validación de servicios y disponer de un registro en tiempo de diseño, en el que se pueda buscar si ya existe el servicio que necesitamos o si es necesario implementarlo.
  11. Excesiva centralizacion
    Se viene a reconocer que en una organización grande se tienen diferentes perspectivas y no todos los servicios se consideran de la misma manera. Por ejemplo, algunos servicios sólo tienen sentido en el conteto  de una aplicacion (se denominan “servicios privados”). Por otra parte, se estima que un número relativamente pequeño de los servicios tienen sentido para toda la organización.
    Para paliar este problema puede necesitarse la división de la organización en varios dominios SOA (uno para cada unidad de negocio). Por supuestos estos dominios están “federados” para los servicios se puedan reutilizar entre diferentes dominios.

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).

¿qué otra mala práctica añadirías a esta lista?

Comparte este artículo…