Llegamos a ustedes gracias a:



Columnas de opinión

Dos arquitecturas, un camino

Por: Dan Rosanova, consultor principal de Nova Enterprise Systems

[31/01/2009] Por lo general, los presupuestos de TI siguen un proceso bastante estricto y predeterminado a lo largo del año fiscal. Los gerentes conocen a la perfección la encarnizada competencia que se desata por los intereses encontrados de las TI. La arquitectura orientada al servicio (SOA, por sus siglas en inglés), con su promesa de hacer posible la reutilización y la interoperatividad a través de la empresa, suele ser un candidato de fuerza para obtener financiamiento. Sobre todo ahora que ya se conocen casos de éxito y que los ejecutivos están cada vez más al tanto de sus beneficios.  De hecho, la mera  propaganda quedó atrás, ahora estamos en el mundo real.

Aunque esto parece muy positivo, lo cierto es que la arquitectura es importante en todos los aspectos del software, y ni siquiera el mejor SOA estaría a salvo de una falla mayor si no fuera por las arquitecturas subyacentes a la implementación de los servicios específicos. Curiosamente, lo mismo ocurre al revés. El riesgo es que el esfuerzo y los recursos invertidos en la disciplina arquitectural sean en vano o, peor aún, deriven en un fracaso, si el otro elemento no está a la altura.
Yo vivo en Chicago, una ciudad que cuenta con una fantástica arquitectura, tanto en sus edificios como en su infraestructura. Ambos son indispensables para una ciudad exitosa donde la gente vive y hace negocios. La ciudad es un éxito porque, quienes la planificaron, diseñaron y construyeron excelentes servicios al interior de los edificios (agua, electricidad, telecomunicaciones y transporte), y porque quienes planificaron los edificios (los arquitectos) diseñaron y construyeron excelentes estructuras. Invertir exclusivamente en uno de estos aspectos, hubiera sido un fracaso. Hasta el edificio más fantástico carecería de sentido en medio de una ciudad que careciera de los servicios que, a largo plazo, hacen posible el éxito a nivel ambiental.
La misma figura se cumple en el ecosistema de la empresa. Invertir solo en arquitectura al nivel de la empresa con SOA (la ciudad) solo resulta útil si la arquitectura de los componentes individuales y los servicios (edificios) también han sido apropiadamente diseñados y construidos. Del mismo modo, invertir únicamente en aplicaciones de arquitectura puede llevar a desperdiciar oportunidades en el contexto del SOA y, muy probablemente, a duplicar esfuerzos.
Algo por el estilo me ocurrió cuando trabajaba para una gran compañía. El equipo había hecho un excelente trabajo en arquitectura de aplicación. Gran parte de sus energías se había concentrado en el diseño orientado a dominio y al desarrollo de Agile. Al interior de los propios silos de aplicación, se habían diseñado modelos elegantes y efectivos para cumplir los objetivos de negocios a través de una programación rápida y expresiva. Desafortunadamente, la inversión no fue utilizada con la misma eficiencia para garantizar interacción fuera de la aplicación: debido a una combinación de tecnología heredada y del inexorable cumplimiento de los plazos, el resultado fue demasiada duplicación.
La solidez de los modelos de dominio que tan minuciosamente habían montado se veía amenazada por el hecho de no ser los únicos conductos a través de los cuales la data se originaba y se preservaba. La situación llegó a tal punto que el piso empezó a moverse debajo de las aplicaciones.
Sin embargo, esta organización estaba apta para remontar la cuesta. Como ya mencioné, habían implementado muy buenas prácticas de arquitectura de aplicación. La única tarea pendiente era extender esas prácticas a la empresa, al nivel del SOA.
Yo he sido arquitecto de aplicaciones. Sin temor a equivocarme puedo afirmar que, respecto al SOA y a los grupos de arquitectura de aplicaciones, existe una mentalidad de "nosotros vs. ellos". Esto puede deberse, en parte, a la percepción de proximidad entre tecnología y grupos de negocios. Es indispensable que el SOA esté cerca del negocio, más aún en una arquitectura de aplicación tradicional, donde tanto analistas como arquitectos escudriñan detalladamente los detalles que provienen de los expertos de dominio. Los arquitectos del SOA tienen que estar mucho más cercanos y someterse a los designios del negocio en un nivel más elevado y menos personal.
El negocio (en oposición a un departamento, a una línea de negocios) puede ser difícil de conceptualizar. Y la cosa se complica más debido a la tendencia de muchos desarrolladores de ver esta ola de requerimientos no funcionales, que por lo general es de carácter crucial para el éxito del SOA, como algo insignificante.
Muchos desarrolladores están acostumbrados a estar tan próximos del problema (y de la solución) que terminan pensando al respecto en el contexto del código. Así, cuando se topan con un requerimiento inmediato del tipo "leer e importar este archivo, ciertos desarrolladores y gerentes de proyecto no son capaces de apreciar todo lo que ello implica. Nos encontramos entonces ante la violación de una frontera entre sistemas. La situación se vuelve aun más obvia cuando la fuente del mencionado archivo es un partido B2B. En última instancia, se trata de un asunto que cae en la jurisdicción del SOA, pero ese es tema de otro artículo.
Lamentablemente, en la actualidad, muchas empresas están jugando a la chapada en ambas áreas de la arquitectura, y no cuentan con el equilibrio necesario ni con la suficiente habilidad de negociación. A continuación, algunas estrategias simples para superar estos desafíos: 
-Respetar los límites del sistema. Va en serio. Incluso si el otro sistema es una aplicación interna o si ha sido diseñado por el mismo grupo de desarrolladores. El ratio de cambio puede ser diferente entre ambos sistemas. Uno cruza una frontera de sistema cuando nuestra aplicación está escrita contra un esquema de esa fuente externa (incluso los archivos flat tienen esquemas); hemos incorporado en nuestra aplicación una dependencia de esta fuente externa. Las fronteras de sistema son un asunto serio, y solo un control adecuado asegura que sean respetadas.
-Establecer una visión común. Los representantes de ambas arquitecturas (el SOA y las aplicaciones) deben reunirse de forma regular para abordar los planes de funcionalidad previstos para cada una. Ninguna de las partes debe adelantarse demasiado en el desarrollo de soluciones a corto plazo para necesidades inmediatas. La comunicación frecuente también posibilitará reducir la cantidad de duplicación, pues cada equipo podrá coordinar sus esfuerzos de desarrollo. A las reuniones asistirán líderes técnicos, de preferencia arquitectos y analistas de negocio de cada equipo. Una hoja de ruta a escala corporativa puede resultar útil, pero mejor no se entusiasme demasiado.
-Reutilice los principios para cada disciplina. De hecho, son complementarios. Incorpore patrones de diseño tanto al nivel de aplicaciones como del SOA. Estos son el lenguaje común de cada disciplina y representan el camino más corto hacia conceptos que facilitan la comunicación entre profesionales de software. Muchos patrones del SOA han sido construidos sobre la base de patrones tradicionales de arquitectura, de manera que, a este nivel, la comunicación puede permitir que ambos lados comprendan las metas y los conocimientos del otro.
Volviendo a la analogía de Chicago, es como si aplicáramos las mismas pautas para planificar sistemas de desagüe tanto al interior de los edificios como entre estos. Si bien su implementación específica es muy diferente, comparten muchos aspectos en común.
Con un poco de orientación y comunicación, cualquier empresa puede -y debe-encontrar el balance apropiado entre arquitecturas en los niveles SOA y de aplicaciones. Solo habiendo logrado este equilibrio será posible alcanzar éxitos reales en SOA. Tenemos así el reverso de la medalla de la compañía que mencioné líneas arriba, en la cual una impecable planificación de necesidades del negocio, flujos de data y requerimientos de servicio puede desplomarse completamente a causa de una pobre arquitectura en la implementación del propio SOA. A lo mejor, parte de la confusión que reina en torno al SOA se debe a que, en realidad, se trata de una entidad de capa doble: el nivel abstracto de arquitectura del negocio y el nivel concreto de arquitectura de servicio.
Dan Rosanova es consultor principal de Nova Enterprise Systems, una consultora que se especializa en aplicaciones corporativas y soluciones Microsoft BizTalk Server. Tiene una experiencia de diez años entregando soluciones corporativas para finanzas, seguros, telecomunicaciones e industrias médicas en plataformas Windows, Solaris y Linux.
CIO USA