Secciones

SOA - Parte I - ¿Que es SOA?

Aprovechando que estoy preparando la certificación como arquitecto Bea Weblogic en plataforma SOA, crearé una serie de entradas sobre el tema.

SOA (Service Oriented Arquitecture) en un paradigma para la realización y el mantenimiento de los procesos de negocios enfocados a sistemas distribuidos.
Está basado en 3 principios básicos: servicios, interoperatividad y bajo acoplamiento.

  • El servicio es una funcionalidad de negocio self-contained.
  • Un ESB (Enterprise Service Bus) es la pieza de infraestructura que proporciona un alto grado de interoperatibidad entre los sistemas distribuidos. Proporciona una forma sencilla de distribuir procesos de negocio que usan diferente plataforma y tecnología.
  • Bajo acoplamiento (lose coupling) es un concepto que implica reducir las dependencias entre las diferentes piezas del sistema. Como los procesos de negocio están distribuidos entre diferentes backends, es importante minimizar los efectos provocados por cambios y fallos.

El principio de lo simple

Aunque la mayoría de entradas que haya en este blog estarán relacionadas con temas informáticos, me gustaría comenzar mi blog con un principio que intento aplicar a la hora de tomar decisiones , el principio de la navaja de Occam.

La navaja de Occam (navaja de Ockham o principio de economía o de parsimonia) hace referencia a un tipo de razonamiento basado en una premisa muy simple: en igualdad de condiciones la solución más sencilla es probablemente la correcta.

El postulado es Entia non sunt multiplicanda praeter necessitatem, o «No ha de presumirse la existencia de más cosas que las absolutamente necesarias».

El rol de los Arquitectos de Software

De la misma manera que ocurre con la Arquitectura de Software, existen múltiples definiciones sobre el rol de los arquitectos. Podríamos incluso citar una definición por autor. Esto parece ser causa de que, en general, se ubica a los arquitectos en el contexto de una organización en particular, con las propias necesidades y requerimientos de esa organización.

La realidad parece indicar que es poco probable que se pueda dar una definición de arquitecto, transversal a cualquier organización, y definir un estereotipo de arquitecto que especifique cuáles son sus responsabilidades y habilidades necesarias dentro de un proyecto. Lo que sí es posible es definir prototipos de arquitectos “a muy grandes rasgos” y aplicar cada uno de estos arquetipos, en una situación en particular, dependiendo del contexto de la empresa, del proyecto y del equipo de trabajo.

Tipos de arquitectos de software

Para definir qué es un arquitecto de software, debemos tener en cuenta un contexto y un escenario en particular. Dicho de otra forma, depende de la organización, de su negocio, de sus objetivos, de la influencia del área de sistemas, de la importancia de el/los proyecto/s y del tamaño de los mismos. Teniendo en cuenta este contexto, podemos proponer una serie de categorizaciones:

Arquitecto técnico

Se trata de profesionales con amplios conocimientos técnicos, conocedor del negocio de los proyectos y que, probablemente, esté asignado a uno o varios proyectos al mismo tiempo. Algunas de sus responsabilidades suelen ser: definir los lineamientos de diseño, su arquitectura y demás cuestiones técnicas de los proyectos.

Arquitecto funcional

Tienden a ocupar el rol de team leader y, a su vez, de líder técnico. Manejan el project y planifican junto al PM las iteraciones. Suele representar un canal de comunicación fluida entre el PM y los equipos de desarrollo. Validan diseños; guían a los desarrolladores, para que cumplan con las expectativas de calidad tomando métricas, organizando y promoviendo la documentación y las buenas prácticas; aseguran que el proyecto no se desvíe de la arquitectura previamente definida.

Arquitecto Corporativo

Unifica los dos casos mencionados anteriormente; pero con algunos agregados. Este modelo, tomado sobre la base que propone Bredemeyer Consultingexternal link, es al que apunta Epidata Consulting para sus arquitectos de software.

Probablemente, en la literatura referida al tema se logre recopilar una mayor cantidad de perfiles o roles de arquitectos. Esta mayor variedad, en general, apunta a grandes organizaciones, donde cada función está claramente dividida y, sobre todo, limitada, transformando al arquitecto en un ente con responsabilidades restringidas.