Llegamos a ustedes gracias a:



Columnas de opinión

La brecha del conocimiento SOA

Por: Dan Rosanova,consultor principal de Nova Enterprise Systems.

[30/12/2008] La estructura común de negocios que permite que las grandes corporaciones funcionen de manera eficiente puede, en el fondo, inhibir el desarrollo de una satisfactoria arquitectura orientada a servicios (SOA). La mayoría de empleados ajenos a las TI trabajan para un equipo, en un departamento, una división o alguna estructura jerárquica similar. Durante mucho tiempo, este patrón organizacional ha funcionado bien para las grandes corporaciones, los gobiernos y otros organismos. Obviamente, los integrantes de tales estructuras organizacionales ven el mundo a través del contexto de su posición en esta jerarquía. Pero esta estructura organizacional puede convertirse en un desafío para el análisis SOA cuando la solución TI hace necesario que representantes de todas las partes del negocio aporten información.

A lo largo de los años, el mundo del software ha madurado al punto en que tanto el análisis como el diseño son procesos refinados. Actualmente, la mayoría de personas relacionadas al mundo de TI está familiarizada con las principales técnicas usadas para recopilar requerimientos de negocios y para desarrollar arquitecturas de sistemas. El papel del "Experto en la Materia" (SME, por sus siglas en ingés) ya es un lugar común en los proyectos de desarrollo de software. Esto ha sido muy útil para construir líneas de sistemas de negocios (depósitos de software, si se quiere) que tradicionalmente servían a la unidad de negocios para la cual fueron creadas.
Focalizarse directamente en el conocimiento de un experto de negocios permite que el equipo de desarrollo produzca una solución muy próxima a lo que la unidad realmente necesita. Este proceso no tiene nada de sencillo, pero por lo menos es común y bien comprendido.
En este contexto, un singular desafío de la arquitectura SOA es su necesidad de agrupar a los SME de toda la empresa. La arquitectura SOA construye una base colectiva de conocimientos, la misma que representa la forma en que el negocio opera a un nivel que está por encima de las líneas de negocio individuales. Esto representa varios y muy diferentes problemas para el proceso de análisis SOA. Los representantes de cada línea de negocios tienen que involucrarse en el análisis de las necesidades del SOA y sus capacidades. Si cada negocio tiene su propio equipo TI, probablemente estos también deban participar. 
No se trata solo de tener más gente que provea información  o explique las necesidades de sus departamentos. Conforme crece este proceso de análisis, aumenta también la cantidad de puntos de vista. Los representantes de un departamento pueden tener un enfoque sesgado debido a su proximidad con su unidad de negocios, llegando a descuidar las opiniones y necesidades de otras unidades de negocio. En realidad, lo más natural es que se produzcan situaciones de este tipo, teniendo en cuenta sobre todo que cada una de estas personas se desempeña en áreas que conoce y, por lo tanto, puede tener dificultades para darse cuenta de que otras áreas funcionan de la misma manera. Muchas veces, los SME son líderes en sus departamentos y pueden padecer de una actitud del tipo todo debe girar a mi alrededor, donde mi alrededor es en realidad mi departamento.
Por lo general, esto no ocurre de manera intencional, pero ilustra una de las formas más comunes de prejuicios que se suele encontrar tanto en la arquitectura SOA como en las iniciativas de integración. Personalmente, me gustaría reunirme con un muchos representantes para alentarlos a ver la pantalla completa.
En mi línea de trabajo, a menudo tengo reuniones con representantes del área de finanzas, contabilidad y operaciones (post-venta), así como la de TI. Los miembros de estos equipos tienen una única perspectiva de un solo flujo de data a través de la empresa, pero cada uno ve solo una pieza. La representación de esta data varía en cada departamento, pero siempre subyacen los mismos conceptos: órdenes y data financiera asociada.
Por lo general, el área de finanzas se interesa particularmente por la manera en que se programan los ingresos y se calculan las ganancias. Por su parte, Contabilidad no se preocupa mayormente de estos detalles pero desea asegurarse de que los libros mayores reflejen minuciosamente las intenciones de Finanzas y se ajusten a los requerimientos de GAAP. Asimismo, los equipos de Operaciones tienden a concentrarse en el flujo de de las órdenes a través de los procesos de aprobación y entre los sistemas externos, y no pocas veces ignoran las repercusiones de estos aspectos en las áreas de Finanzas y Contabilidad.
Uno de los conflictos más recurrentes surge cuando Finanzas quiere registrar un ingreso que solo ha sido cobrado parcialmente; Contabilidad dice que eso violaría su GAAP y Operaciones agrega que no se puede dividir órdenes sin quebrar sus procesos. Discutir el asunto con todos los involucrados al mismo tiempo les permite comprender cómo el otro departamento interactúa con diferentes aspectos de la misma data. Cuando los líderes de cada línea de negocios se ven confrontados con las realidades de las otras líneas, a menudo se muestran menos reticentes a comprometerse. Al fin y al cabo, todos están en el mismo equipo.
Por definición, la arquitectura SOA consiste en reunir gente para construir sistemas que sean útiles a toda la empresa, lo cual nos lleva a otro tema: el efecto de las diferentes personalidades en la dinámica de grupo. Este aspecto se complica aún más gracias a las reuniones con representantes de diversas áreas, debido a que su participación solo obedece a la posibilidad de dar a conocer sus necesidades. Por eso, suele ocurrir que alguna persona del grupo (generalmente alguien muy persuasivo o respetado) gane demasiada influencia sobre las decisiones de diseño que resultan de tales reuniones.
Para contrarrestar este efecto, acostumbro combinar sesiones de grupos grandes y pequeños, así como seguimientos personalizados o individuales (o incluso reuniones previas, aunque es mejor ser cuidadoso con este tema). Esto ayuda a filtrar la avalancha de información y de puntos de vista diferentes que se desprende del proceso. En las empresas multinacionales, este efecto de dinámica de grupo es aun más pronunciado.
En el fondo, el tema central es un asunto que se presenta incluso en el análisis de software tradicional: la brecha de comunicación. Las respuestas a suministrar pueden variar mucho dependiendo de la manera en que se plantee el problema. Puede ser el resultado de las destrezas básicas de comunicación y el contexto en que se formula la pregunta (para mí, el contexto es parte de la comunicación, así que tal vez estoy siendo redundante). En el curso de una discusión sobre los detalles de un proceso existente, es frecuente que una pregunta abstracta dé lugar a una respuesta demasiado específica. Es decir que si la respuesta se centra demasiado en implementación, no facilita que el arquitecto de la empresa comprenda el panorama general del problema ni las variantes particulares de este caso de aplicación.
Por ejemplo, si el SME plantea "la necesidad de recibir órdenes en los formatos A, B y C de los socios X, Y y Z", es importante evitar distraerse demasiado con los detalles específicos de la coyuntura porque, de lo contrario, se corre el riesgo de alejarse de una comprensión abstracta y desconectada de las particularidades de la implementación. En resumen, el problema, sutil pero no por ello menos perjudicial, radica en que luego de abordar un tema de manera tan específica puede ser muy complicado retomar el enfoque abstracto. Sin embargo, tampoco es posible prescindir de lo específico. Aunque suene extraño, las dificultades pueden provenir del SME o del analista de negocios, e incluso del grupo en general. Algunas veces, simplemente no se pueden evitar estas situaciones. Lo único que nos queda es hacer nuestro mayor esfuerzo para tener presente estos problemas pero, al mismo tiempo, asegurarnos de que el servicio o el departamento realmente estén recibiendo órdenes. Pueden surgir diferencias de implementación ligadas a clientes puntuales, pero ahí ya nos encontramos en el eslabón más bajo del análisis de la cadena de procesos.
Yo solía usar una estrategia que consistía en formularle al SME la misma pregunta de tres maneras distintas, aunque -por lo general- no durante la misma reunión. Mayormente, el planteamiento seguía el siguiente patrón:
-¿Entonces, cuáles son los flujos de trabajo o cambios de estado que una orden puede seguir?"
- Hay situaciones en las que una orden puede seguir una ruta distinta de ?. (repetir las opciones que dio en la respuesta anterior)?
- "¿Qué hace usted si se presenta una excepción y una orden debe sufrir un cambio inusual?
Al usar partes de la información obtenida en la respuesta -replanteada de otra manera- realmente podemos hacer que los SME se proyecten más allá de la implementación inmediata o en curso. En lugar de restringirse a hablar solo de la capacidad real o actual, podrán revelar mucho más sobre los verdaderos requerimientos de fondo. Esto resulta mucho más importante cuando se discuten las capacidades de negocio que se necesitan para una arquitectura SOA.
Para lograr que esto se ponga en marcha sin inconvenientes, es mejor establecer una visión con suficiente anticipación: comuníquela claramente a los SME y a los otros participantes del análisis SOA. En un principio, la visión se resumirá a lo que una arquitectura SOA puede aportar a la empresa y la forma en que se deberá dar inicio al proceso.
Progresivamente, la visión evolucionará desde los planteamientos genéricos iniciales, hacia un enfoque específico de la empresa que está sujeta al análisis. Esta visión es a la vez una herramienta que nos permite trasladar los conceptos introductorios y abstractos de la arquitectura SOA a los SME (que cada vez están más empapados del SOA) de manera clara y no necesariamente técnica. Es posible empezar comunicando esta visión quizá solo al gerente principal de TI que se nos ha asignado o al que reportamos, pero la empresa terminará adoptándola rápidamente y dirigirá en su evolución. Es en este punto que el rompecabezas empieza a tomar forma.
CIO USA
Dan Rosanova es consultor principal de Nova Enterprise Systems, una consultora especializada en aplicaciones empresariales y soluciones Microsoft BizTalk Server. Tiene diez años de experiencia en soluciones empresariales de finanzas, telecomunicaciones, seguros e industrias médicas en plataformas Windows, Solaris y Linux.