Implementar SOA sin buenas prácticas conduce al fracaso

“Los proyectos implementados hasta la fecha demuestran que una SOA [arquitectura orientada a servicios] requiere mayor inversión en el gobierno del diseño de servicios y mejores prácticas en la integración de aplicaciones, que van más allá de los niveles actuales en la mayoría de las empresas”, comenta Paolo Malinverno, vicepresidente de investigación de la consultora.
“En un principio, el riesgo de fracasar es mínimo pero en la medida que se desarrolle el proyecto SOA, la curva de riesgo aumenta. Por ello, una organización no debe contemplar nunca una SOA sin establecer una serie de procesos gubernamentales en cuanto a la definición de servicios, su implementación y su mantenimiento”.
El entusiasmo generado por las SOAs y los beneficios que pueden generar con la llegada de la Web 2.0 hace que muchas compañías hayan emprendido proyectos SOA por la vía rápida, sin analizar previamente si existen o no las condiciones internas básicas para asegurar su éxito, que pasan por un gobierno robusto, disciplina en el desarrollo de servicios y los recursos humanos adecuados.
Así, Gartner estima que, si sigue la tendencia actual, en el 2010 menos de un 25 por ciento de empresas grandes tendrán las competencias técnicas y organizativas necesarias para sustentar una SOA que cubra toda su actividad empresarial.
“Tampoco debemos quitar importancia de los riesgos técnicos”, avisa Massimo Pezzini, vicepresidente y analista de la consultora. “Las herramientas que posibilitan una SOA hoy en día son tan fáciles de usar que esconden la complejidad técnica de implementar una plataforma SOA fiable. En realidad, desarrollar una infraestructura SOA pan-empresarial de alto rendimiento, escalable, segura y manejable presupone cierto dominio técnico que pocas organizaciones han sabido desarrollar”.
“Para evitar caer en los errores más comunes cometidos en la implementación técnica de una SOA, recomendamos que las organizaciones diseñan sus infraestruturas técnicas en base a sus necesidades funcionales y no funcionales reales (por ejemplo, rendimiento, disponibilidad y seguridad), y no en base a modelos teóricos. Seleccionar un producto para la infraestructura SOA probado y documentado es también crítico”.
Otra cuestión técnica clave es que las compañías monten la arquitectura SOA de forma que resulte fácil de monitorizar y reportar información para depurar bugs. “Finalmente, resulta vital dedicar tiempo al testeo y al menos un 25 por ciento del total del esfuerzo invertido en un proyecto SOA debe dedicarse a esta actividad”, concluye Pezzini.

Paralelamente, desde un punto de vista organizativo, no se puede asumir que un régimen de gobierno corporativo único valga para todos. “Demasiado gobierno o demasiado poco matará un proyecto SOA, así que una compañía tiene que calibrar el nivel justo”, comenta Malinverno. De esta forma, una entidad debe asegurar que su régimen de gobierno no peca de demasiada sofisticación ni que es desproporcionado respecto al tamaño, la organización y la cultura de la empresa.
De acuerdo con Gartner, las áreas donde más errores comenten los departamentos informáticos y los responsables de aplicaciones a la hora de encomendar un proyecto SOA son:
Materia técnica

  • Subestimar la complejidad técnica de una SOA a gran escala;
  • Una selección inadecuada de los componentes de la infraestructura de la aplicación;
  • Una validación insuficiente de la infraestructura que posibilita la SOA (por ejemplo, no realizar una prueba de concepto o pruebas de estrés);
  • Malas prácticas en cuanto a la seguridad, la gestión y el manejo de problemas que surjan en torno a la infraestructura, los servicios y las aplicaciones cliente de la SOA;
  • No calibrar adecuadamente la granulación de los servicios;
  • Una documentación no actualizada o insuficiente.

Materia organizativa

  • No contemplar cambios o mejoras en el gobierno corporativo;
  • Tratar la organización de un proyecto SOA como cualquier otro proyecto para el desarrollo de aplicaciones;
  • No anticipar un aumento en las incidencias de atención al cliente una vez que la SOA madure;
  • No instalar un centro para fomentar competencias de integración o un centro de excelencia en torno a la SOA;
  • Externalizar los arquitectos del sistema (o no contratarles).