De toda la iniciativa Web 2.0 y Enterprise 2.0, así como de Enterprise Architecture, se desprenden dos grandes estrategias que deberían ponerse en marcha (si no se ha hecho ya) dentro de los departamentos de IT:

• Establecer el software como un servicio. Es decir, diseñar todas las funciones de las aplicaciones futuras como servicios, a la vez que se inicia el traslado de las aplicaciones actuales hacia el mismo concepto. Esto implica establecer una Enterprise Architecture que guíe tanto la incorporación de esas nuevas aplicaciones, como la migración de las antiguas y, tal y como indica el CISR (Center for Information Systems Research) del MIT, hacer pasar a la empresa por las cuatro fases necesarias: silos, standardized IT, standardized business processesy business modularity. De este modo, mediante la disponibilidad de las funciones de las distintas aplicaciones como servicios, es posible alcanzar la business modularity o, lo que es equivalente, posibilitar a la compañía llegar al nivel de madurez tecnológica necesario como para alinear las TI con la estrategia de negocio.
  
• Hacer desarrollos a medida, encaminados a cubrir dos aspectos fundamentales. El principal, es el de dar soporte a los procesos que forman parte del core-business y que claramente representan un factor diferencial para la empresa en el mercado. El segundo, utilizar el desarrollo a medida para hacer que las aplicaciones propietarias de terceras partes se transformen en servicios y se integren dentro del bus de servicios de la compañía.

En su forma más básica, podemos decir que SOA pretende alinear el software y los servicios de datos con los procesos de negocio para que, de este modo, servicios específicos puedan ser mezclados y reutilizados según convenga.

SOA es un término que en la actualidad se está utilizando masivamente y, como suele ocurrir cuando esto sucede, en muchos casos se utiliza de forma errónea e introduce confusión en el mercado. Esto se ve potenciado debido a que SOA es un término que describe dos cosas muy diferentes. Por un lado, las primeras dos palabras describen una metodología de desarrollo de software, mientras que la tercera, Architecture, hace alusión al modelo de los componentes software que posee una compañía, es decir, a una representación de todas las piezas software existentes que, de manera conjunta, forman el edificio empresarial. Así, SOA en realidad es una estrategia que pretende la construcción de todos los componentes software de la compañía utilizando una metodología de desarrollo orientada a servicios y un soporte tecnológico que lo haga posible.

En lo que se refiere a la metodología de desarrollo, podríamos decir que la idea de SOA es tan antigua como la programación en sí misma, dado que desde el comienzo de los tiempos del desarrollo de aplicaciones, se ha trabajado en diferentes formas de modularizar el código, inicialmente mediante el uso de includes, después mediante el uso de librerías, más tarde mediante el uso de objetos, para llegar a los componentes y finalizar con SOA y WebServices. Por tanto, el concepto no es nuevo, lo que es nuevo es el gran alcance que tiene, pues afecta a toda la arquitectura tecnológica de la compañía.

SOA promete muchas bondades y alguna de ellas las analizaremos más adelante. Sin embargo, SOA no es algo que pueda estar al alcance de todas las empresas. En primer lugar, SOA únicamente tiene sentido en caso de que el tamaño del departamento de TI sea considerable y esté formado, al menos, por más de un sistema primario. Es decir, SOA aporta su mayor beneficio dentro de sistemas complejos y heterogéneos, por eso, para pequeñas empresas es difícil que pueda aportar un valor directo. Dentro de las grandes corporaciones, con sistemas tecnológicos complejos y heterogéneos, SOA no va a proporcionar los mismos beneficios a cada una de ellas.

Como se comentaba más arriba, según el CISR (Center for Information Systems Research) del MIT, en los trabajos "IT Architecture as Strategy" y "IT-Driven Strategic Choices", las empresas han de pasar por cuatro fases bien distintas: silos, standardized IT, standardized business processes y business modularity. Sólo una vez que se ha pasado por todas ellas, SOA puede aportar todo su valor y, en la actualidad, la mayor parte de las empresas que formaban parte del estudio realizado, se encontraban en la primera o segunda de las fases. Por tanto, es muy importante analizar detenidamente las consecuencias de implantar una estrategia SOA.

Adicionalmente debemos tener en cuenta que, gracias a la palabra Architecture que forma parte de SOA, SOA es mucho más que construir software. Tomar la decisión sobre la implementación de SOA requiere tener un compromiso claro con una Enterprise Architecture bien definida, requiere la creación de una metodología de desarrollo centralizada y un equipo centralizado de arquitectos que marquen las directrices globales sobre las que se desarrollarán los servicios. Además, requiere la implicación a nivel de CEO y staff-ejecutivo, con el fin de que faciliten la incursión del equipo de TI en los procesos de core-business de la compañía. Entender el negocio y compartir la estrategia es la piedra angular de Enterprise Architecture y, por tanto, de SOA.

Otro aspecto muy importante es lo referente a Governance. Tal y como se ha indicado anteriormente, con el objetivo de reutilizar servicios a lo largo de la compañía, es necesario que exista una metodología de desarrollo centralizada, de forma que diferentes áreas del negocio no desarrollen el mismo servicio de diferentes maneras. Bajo este paraguas se incluyen procesos, herramientas y todo aquello que es necesario para poder desarrollar la estrategia tecnológica. Por tanto, debe haber un repositorio centralizado que, además, ha de estar bien documentado. De otro modo, SOA no va a proporcionar otra cosa diferente a más desorden, dado que servicios desarrollados de forma aislada, sin tener en cuenta una Enterprise Architecture centralizada, van a tener un bajo potencial de reutilización.

En Kynetia, ayudamos a nuestros clientes en la creación de sus Service-Oriented Architecture (SOA), que lógicamente forma parte del subconjunto de iniciativas necesarias para establecer la Enterprise Architecture.

Ventajas de SOA

Tal y como se definía al principio, SOA está compuesto por dos aspectos bien diferentes: metodología de desarrollo y arquitectura. Por tanto, los beneficios se pueden apreciar en ambos campos.

SOA como metodología de desarrollo

• Reutilización. El objetivo es conseguir agrupar en servicios funciones de negocio que puedan ser utilizadas cuando sea necesario por la aplicación que la requiera. De este modo, estaremos ahorrando mucho tiempo y dinero en desarrollar de diferentes maneras la misma cosa.
• Incremento de productividad. Si se ha realizado la componentización adecuada de las funciones de negocio, los tiempos de desarrollo de nuevos proyectos caerán drásticamente, dado que muchas de las funciones que antes había que desarrollar ahora se pueden reutilizar y, mientras antes era necesario recodificar la función, ahora simplemente se establece un enlace con el servicio que la proporciona.
• Más agilidad. Incluso aunque un servicio no fuese reutilizado por otras aplicaciones, SOA permite aislar funciones completas. De este modo su modificación sería mucho más sencilla (al estar aisladas y conocer perfectamente las entradas y salidas) y, por tanto, el mantenimiento es mucho más ágil.

Arquitectura de servicios como estrategia

• Mejor alineamiento con el negocio. Al componentizar el software en funciones de negocio, éste puede ser mucho más flexible, pues cambiar los procesos es mucho más fácil si las funciones están aisladas. Es más, en unos años, el staff de negocio de la compañía podría ser capaz de tener control sobre los diferentes servicios (funciones) disponibles y mezclarlas y machearlas de diferentes maneras para dar lugar a diferentes procesos de negocio. Aunque algunos vendedores de productos SOA prometen esto en la actualidad, la realidad demuestra que de momento estamos lejos de poder alcanzar esta meta.