¿Cómo empezar a hacer SOA?

SOA es un concepto que nació y ha ido evolucionando en las tecnologías de la información desde hace varios años, a partir de mediados de los 80’s para ser más exactos. Gartner por su parte reconoce y adopta SOA como una tendencia tecnológica a mediados de los 90’s.

Según tendencias, de los mayores referentes tecnológicos en el mundo, SOA tiene más de 10 años que maduró y ha sido adoptado por las empresas para llevar a cabo sus desarrollos de Sistemas. La realidad es que en México más del 60% de las empresas no han adoptado SOA y, es más, no entienden aún el beneficio tangible que esto puede traer a sus organizaciones, y eventualmente impactar de manera positiva en sus costos de desarrollo de Software.

Para empezar es importante hacer alusión a la evolución del desarrollo de sistemas, el cual ha ido madurando desde el “Desarrollo Estructurado”, pasando por el “Desarrollo Orientado a Objetos”, después y sin mucho éxito el “Desarrollo Orientado a Componentes”, para llegar ahora a lo que es el “Desarrollo Orientado a Servicios”, que cabe señalar son los inicios y la base de lo que hoy en día marca una clara evolución de las Tecnologías de la Información, el “Cloud Computing” en sus modalidades de SAAS e IAAS.

El desarrollo Orientado a Servicios o Arquitectura Orientada a Servicios no es más que una filosofía, es un marco de referencia sobre el cual se debe basar el desarrollo de un sistema para que se adopten de forma inmediata los beneficios que SOA trae consigo, entre los que encontramos:

• Reducción de esfuerzos para el desarrollo de una nueva aplicación.
• Estandarizar la forma en que se programa dentro de la empresa.
• Creación de una NUBE privada y/o pública de Servicios.
• Reutilización real de software desarrollado.
• Reducción en la curva de aprendizaje de los programadores.
• Reducción significativa del costo total de la propiedad (TCO) de los sistemas.

Para hacer un poco más “terrenal” el concepto, aquí comparto 6 puntos muy ágiles de implementar, y con los cuales podrás empezar a evolucionar hacia una “Arquitectura Orientada a Servicios”:

• • Dividir en dos perfiles al equipo de desarrollo:
    1. Arquitecto de Software: deberá jugar un rol de Auditor y facilitador.
    2. Es importante que cuando se implementan procedimientos y políticas de desarrollo, exista un tercero en discordia cuya responsabilidad sea la de validar que la Arquitectura se cumpla cabalmente y conforme se haya acordado dentro de la empresa.
    3. Es fundamental que el Arquitecto provea a la empresa de la infraestructura de Software adecuada y óptima para las necesidades de cada uno de los proyectos que se llevan a cabo. Es el responsable del “CÓMO” de todos y cada uno de los sistemas que se construyen.
    4. Programadores Jr. o Sr.: el programador únicamente tendrá la responsabilidad de entender las reglas de negocio y plasmarlas en código fuente. El programador no debe preocuparse por el “CÓMO” sino del “QUÉ”.
  • Crear una arquitectura institucional que esté dividida en capas, al menos 3: vista, negocio y persistencia.
  • Crear los catálogos o clasificación de servicios de negocio: es importante dividir el desarrollo (módulos) en las distintas áreas de negocio que la empresa conoce y maneja en su vocabulario cotidiano. Ejemplo: nómina, contabilidad, presupuestos, compras, inventarios, etc. Esta es la premisa básica para darle orden a nuestra nube de servicios. Se recomienda hacer uso de un patrón de diseño conocido como “FACADE”.
  • Cada que se desarrolle un nuevo CASO DE USO o proceso de negocio, debe clasificarse dentro de nuestro catálogo de servicios (creado en el punto anterior) y definirse sus parámetros de entrada y salida del proceso, así como sus tipos de datos de cada uno de los parámetros. Esto se conoce como definición de un CONTRATO de un servicio. Cada uno de los procesos que se desarrolla debe de diseñarse e implementarse pensando en que sea reutilizable, es decir, que sea dinámico y se auto configure dependiendo cada uno de los parámetros que recibe o dependiendo de quién lo está mandando a llamar. Entre más variantes de negocio se contemplen más reutilizable será nuestro servicio.
  • Es fundamental que todos y cada uno de los CASOS DE USO o servicios que se construyan no guarden estado (sean “Stateless”), existen varias reglas y buenas prácticas a seguir para que esto se logre. Esta buena práctica será fundamental cuando queramos convertir nuestras aplicaciones en una NUBE que a su vez pueda estar corriendo en ambientes distribuidos como entornos de alta disponibilidad.
  • Este último punto es de los más importantes, y debe permanecer latente a lo largo de todos y cada uno de los puntos que se vayan definiendo en una Arquitectura Orientada a Servicios. Se deben de establecer políticas y procedimientos de lo que “SE VALE” y lo que “NO SE VALE” dentro de cada una de las capas, los métodos, los objetos, los componentes, las variables, etc. Es importante definir un manual de políticas y control de calidad, con el cual el Arquitecto pueda realizar constantes Auditorías de calidad de código para asegurarse que la Arquitectura se está respetando.

¡No importa lo bien que se haya definido el proceso sino se controla su cumplimiento durante todo el ciclo de vida!