Cómo iniciar un proyecto SOA?

Logré convencer a los interesados de mi compañía de que la mejor forma de obtener los objetivos estratégicos es a tráves de una Arquitectura Orientada a Servicios.
Cómo inicio?

Tal como comentaba en mi articulo anterior uno de los mayores problemas al hablar de SOA es que se cree que esto es un proyecto o cambio solo del área de tecnología de la empresa; si partimos de esta manera sera un fracaso total ya que simplemente volveremos a tener aplicaciones que responden a problemáticas técnicas pero no necesariamente a problemas del negocio.

Entender que es un proyecto que impactará toda la Empresa

Hasta que la Gerencia no entienda que iniciar este modelo de desarrollo es algo que requiere de una sinergia entre las diferentes áreas de la empresa para poder lograr la creación de servicios que se ajusten a sus necesidades no es recomendable iniciar el proyecto.

Tener esta premisa clara ayudará mas adelante cuando la gerencia vea que necesite crear nuevos roles (de los cuales hablaré en detalle en otro articulo), ajustar metodologías para la creación de nuevos procesos de negocio, mayor carga en auditorías, mayor carga en el área de calidad, gobernanza, etc.

De igual manera es muy importante resaltar que todo proyecto SOA, en su etapa de inicio, tiene un 30% más de carga que otros proyectos con metodologías tradicionales, esto porque primero necesita crear una base de servicios agnósticos para poder crecer exponencialmente más adelante.

Plan de Adopción

Ya sea que se iniciará un proyecto nuevo o que se migrará uno existente se necesita planificar la transición a nivel tecnológico, arquitectónico y organizacional.

Un plan de transición SOA incluye:

  • Definir la visión de la organización desde el punto de vista de negocio
  • Análisis de impacto
  • Arquitectura de transición y cada uno de sus hitos relacionados
  • Estimación del alcance del inventario de permisos
  • Adiestramiento de nuevos actores y sus respectivos roles

Una vez se tienen definidos cada uno de los puntos anteriores podemos tener una idea de qué tan grande será el proyecto en el que se esta involucrando la empresa.

Para iniciar un trayecto siempre necesitamos un mapa, esto nos dirá donde estamos y hacia dónde queremos llegar. Es importante hacer una valoración inicial para medir el nivel de madurez que tiene la empresa sobre una Arquitectura Orientada a Servicios.

El Open Group Service Integration Maturity Model (OSIMM) especifica como medir este nivel de madurez a través de siete dimensiones y siete niveles de madurez:

Dimensiones

  • Business
  • Organization & Governance
  • Method
  • Application
  • Architecture
  • Information
  • Infrastructure & Management

Niveles de Madurez

  • Silo
  • Integrated
  • Componentized
  • Service
  • Composite Services
  • Virtualized Services
  • Dynamically Re-Configurable Services

Estimar el inventario de servicios puede ser una tarea tortuosa dependiendo el tamaño del sistema que se planifica diseñar o migrar. En esto entra la tarea y reto de no caer en una metodología de desarrollo en cascada pero a la vez no ser tan puritano en cuanto a metodología de desarrollo ágil para poder estimar correctamente el tamaño del inventario de servicios. Inicialmente contando con los Servicios de Entidad y Utilidadque se planifican construir se puede tener una idea de que tan grande será el inventario.

Otro de los puntos mas importantes en toda transición SOA es que tanto el equipo técnico como el área de negocios estén capacitados en cada uno de los roles que estarán asumiendo. Esto no quiere decir que un usuario de negocio necesite aprender a programar, dista bastante de esto la necesidad.

Existen empresas dedicadas al adiestramiento, vendor-neutral, del área de negocio para mostrarles cual es su rol dentro de esta transición hacia SOA. Es recomendable que tanto el área técnica como la de negocios tomen estos adiestramientos, esto garantizará que ambos hablen el mismo idioma más adelante.

Todo proyecto SOA debería tener contemplado cada uno de los siguientes roles, es importante resaltar que una persona puede llevar mas de un rol a la vez ( Dedicaré todo un articulo para detallar cada uno de estos roles la próxima semana ):

  • Analista de Servicios SOA
  • Arquitecto de Servicios SOA
  • Desarrollador de Servicios SOA
  • Custodio de Servicios SOA
  • Custodio de Esquemas SOA
  • Custodio de Políticas SOA
  • Custodio de Repositorio de Servicios SOA
  • Arquitecto Empresarial SOA
  • Custodio de Estándares de Diseño Empresarial SOA ( y a la vez autor )
  • Técnico Especialista en Comunicación Técnica SOA
  • Especialista Aseguramiento de Calidad SOA
  • Especialista en Seguridad SOA
  • Especialista en Gobernanza SOA
Desde el punto de vista técnico: tener todos estos roles me garantiza una correcta implementación SOA?

Si cada uno de ellos cumple cabalmente con su rol es altamente probable que obtenga una implementación exitosa. De entre todas las responsabilidades y asignaciones que poseen cada uno de los roles anteriormente citados existen 6 documentos vitales que se necesitan para iniciar la fase de construcción de los servicios:

  • Arquitectura de los Servicios
  • Arquitectura de las Composiciones
  • Arquitectura del Inventario
  • Arquitectura Empresarial
  • Línea base de Desarrollo de Servicios
  • Línea base de Aseguramiento de la Calidad de los Servicios
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.