Comprender el Valor de las Arquitecturas de referencia
No hay nada más que a los arquitectos les guste hacer que discutir sobre definiciones. Si alguna vez te encuentras con tiempo libre en una sala de arquitectos, intenta pedir una definición de «Servicio» o «arquitectura» y mira qué tipo de lucha creativa puedes comenzar. Dicho esto, las definiciones son de hecho muy importantes para que podamos tener un lenguaje común para comunicar la intención y el beneficio de las mismas cosas en las que estamos tratando de convencer a las empresas para que inviertan. Desde esa perspectiva, en la última década han surgido una serie de conceptos que se han convertido en lo más importante para los arquitectos empresariales autodenominados: marcos de arquitectura y arquitecturas de referencia. En Zapflash anteriores, discutimos los marcos de arquitectura, lo que deja el tema de las arquitecturas de referencia sin tocar por ZapThink. Dado que no podemos dejar un buen argumento atrás, vamos a usar este ZapFlash para explorar de qué se tratan las arquitecturas de referencia y qué valor tienen para agregar a la historia de la Arquitectura Orientada a Servicios (SOA).
¿Qué es una Arquitectura de referencia?
Una definición comúnmente aceptada para arquitectura de referencia es que proporciona una metodología y / o un conjunto de prácticas y plantillas que se basan en la generalización de un conjunto de soluciones exitosas para una categoría particular de soluciones. Las arquitecturas de referencia proporcionan orientación sobre cómo aplicar patrones y/o prácticas específicos para resolver clases particulares de problemas. De esta manera, sirve de «referencia» para las arquitecturas específicas que las empresas implementarán para resolver sus propios problemas. Nunca se pretende que una arquitectura de referencia se implemente tal cual, sino que se utilice como punto de comparación o como punto de partida para los esfuerzos arquitectónicos de las empresas individuales.
Otros refinan la definición de arquitectura de referencia como una descripción de cómo construir una clase de artefactos. Estos artefactos se pueden incorporar de muchas formas, incluidos patrones de diseño, metodologías, estándares, metadatos y documentos de todo tipo. En resumen, si necesita orientación sobre cómo desarrollar una arquitectura específica basada en las mejores prácticas o conjuntos autorizados de artefactos potenciales, debe buscar una arquitectura de referencia que cubra el alcance de la arquitectura que desea construir.
Uno de los ejemplos más populares de arquitecturas de referencia en TI es la arquitectura Java Platform Enterprise Edition (Java EE), que proporciona una arquitectura de referencia en capas y plantillas que abordan una variedad de problemas tecnológicos y empresariales que han guiado muchos sistemas empresariales basados en Java.
Arquitecturas de referencia vs. Frameworks de arquitectura
Si bien las definiciones anteriores pueden parecer bastante cortadas y secas, hay mucho en común entre los conceptos de arquitecturas de referencia y frameworks de arquitectura. Para algunos, aquí es donde las cosas se ponen arriesgadas y las definiciones se vuelven borrosas. Los marcos de arquitectura, como el Marco Zachman, el Marco de Arquitectura de Grupo Abierto (TOGAF) y el Marco de Arquitectura del Departamento de Defensa (DoDAF) proporcionan enfoques para describir e identificar los insumos necesarios para una arquitectura en particular, así como los medios para describir esa arquitectura. Si una arquitectura en particular es un libro de cocina que proporciona orientación sobre cómo resolver un conjunto particular de problemas con un enfoque particular, un marco de arquitectura es un libro sobre cómo escribir libros de cocina. Por lo tanto, los marcos de arquitectura brindan a los arquitectos empresariales las herramientas que necesitan para describir y recopilar requisitos de manera adecuada, sin exigir ningún tipo de arquitectura específico. Más específicamente, los marcos de arquitectura describen una taxonomía de ejemplo de los tipos de «vistas» arquitectónicas que un arquitecto podría considerar desarrollar, y por qué, y proporciona pautas para tomar la decisión de desarrollar vistas particulares.
Esto difiere del concepto anterior de una arquitectura de referencia en que una arquitectura de referencia va un paso más allá al acelerar el proceso para un tipo de arquitectura en particular, ayudando a identificar qué enfoques arquitectónicos satisfarán requisitos particulares y averiguar qué conjunto de artefactos arquitectónicos mínimamente aceptables se necesitan para cumplir con los requisitos de «mejores prácticas» para una arquitectura en particular. Para continuar nuestra analogía con los libros de cocina, si un marco de arquitectura es un libro sobre cómo escribir libros de cocina, entonces una arquitectura de referencia es un libro que proporciona orientación y mejores prácticas sobre cómo escribir libros de cocina centrados en la pérdida de peso, por ejemplo. Esto significaría que la arquitectura particular que desarrolla para su organización sería un libro de cocina específico que proporciona recetas para bajar de peso dirigidas a su organización. De hecho, si te confunde con las definiciones, reemplazar el término «arquitectura » por» libro de cocina » es útil: marcos de libros de cocina, libros de cocina de referencia y su libro de cocina en particular.
Además, la mayoría de las arquitecturas de referencia enfatizan la parte de «plantilla» de la definición de una arquitectura de referencia. Tanto los marcos como los RAS proporcionan las mejores prácticas, y aunque podría argumentarse que los RAS proporcionan más metodología que un marco, los RAS todavía no se caracterizan realmente por su componente metodológico. Sin embargo, la mayoría se pueden caracterizar por su componente de plantilla. Desde esta perspectiva, los patrones son instancias de plantillas en este contexto. De hecho, varias arquitecturas de referencia para el mismo dominio son permitidas y bastante útiles. Las arquitecturas de referencia pueden ser complementarias proporcionando orientación para una sola arquitectura, como SOA, desde múltiples puntos de vista.
El valor de una Arquitectura de referencia SOA
En muchos sentidos, los proyectos SOA necesitan desesperadamente arquitecturas de referencia bien pensadas. ZapThink ve un alto grado de variabilidad en los proyectos SOA. Algunos prosperan y tienen éxito, mientras que otros fracasan y fracasan. Muchas veces, la razón del fracaso puede atribuirse a malas prácticas arquitectónicas, compras prematuras de infraestructura y gobernanza y gestión inadecuadas. Otras veces el fracaso es principalmente organizativo. Sin embargo, lo que es común en la mayoría de los éxitos son prácticas arquitectónicas bien documentadas y/o comunicadas y un método sistemático para aprender de los propios errores y tener un bajo costo de fracaso.
Además, encontramos que muchos arquitectos pasan una cantidad significativa de su tiempo investigando, investigando, (re)definiendo, contemplando y discutiendo decisiones arquitectónicas. En muchos casos, estos arquitectos están reinventando la rueda, ya que sus pares en otras empresas, o incluso en la misma empresa, ya han dedicado ese tiempo y esfuerzo a definir sus propias prácticas arquitectónicas. Este esfuerzo adicional no solo es ineficiente, sino que también impide que la empresa aprenda de sus propias experiencias y aplique ese conocimiento para aumentar la eficacia.
Desde esta perspectiva, las arquitecturas de referencia SOA pueden proporcionar ayuda a aquellos que luchan con sus esfuerzos SOA o están pensando en lanzar uno nuevo. Las arquitecturas de referencia SOA permiten a las organizaciones aprender de los éxitos y fracasos de otros arquitectos y heredar las mejores prácticas probadas. Las arquitecturas de referencia pueden proporcionar información arquitectónica faltante que se puede proporcionar de antemano a los miembros del equipo del proyecto para permitir prácticas recomendadas de arquitectura coherentes. De esta manera, la arquitectura de referencia SOA proporciona una base de activos que los esfuerzos de SOA pueden aprovechar a lo largo del ciclo de vida del proyecto.
De hecho, para obtener los beneficios de SOA prometidos de reutilización, reducción de redundancia, reducción de costos de integración y mayor visibilidad y gobernanza, las empresas deben aplicar sus esfuerzos de SOA de manera consistente. Esto significa más que comprar y establecer la infraestructura de algún proveedor como un estándar corporativo o adherirse a la última pila de estándares WS -*. Las arquitecturas de referencia SOA pueden servir de base para esfuerzos SOA dispares en toda la organización, incluso si utilizan diferentes herramientas y tecnologías. Las buenas arquitecturas de referencia SOA proporcionan las mejores prácticas y enfoques SOA de una manera independiente de los proveedores, la tecnología y los estándares. Por lo tanto, no vayas a buscar uno de tu proveedor favorito. De hecho, si obtuvo su arquitectura de referencia SOA de ese proveedor, es posible que desee considerar abandonarla en lugar de algo más neutral para el proveedor.
En particular, OASIS ofrece una Arquitectura de Referencia SOA (RA) que «modela los elementos arquitectónicos abstractos para un SOA independientemente de las tecnologías, protocolos y productos que se utilizan para implementar un SOA. Algunas secciones de la RA usarán elementos abstractos comunes derivados de varios estándares.»Su enfoque utiliza el concepto de «patrones» para identificar diferentes métodos y enfoques para implementar diferentes partes de la imagen arquitectónica. Si bien la Arquitectura de Referencia SOA de OASIS ciertamente no es la única válida en el bloque, sin duda es un buen punto de partida para aquellos que buscan una arquitectura de referencia SOA neutral para los proveedores en la que basar sus propios esfuerzos arquitectónicos.
The ZapThink Take
Enterprise architects necesita toda la ayuda que pueda obtener para asegurarse de ofrecer a su organización arquitecturas fiables, ágiles, resilientes y neutrales para los proveedores que cumplan con los requisitos en constante cambio de la empresa. Si bien es cierto que el arte y la práctica de la arquitectura empresarial continúan madurando, las empresas deben buscar tomar prestadas todas las mejores prácticas que puedan y aprender de otros que ya han seguido el camino de EA y SOA. Si planea aprender SOA, o cualquier forma de EA, a medida que avanza, o peor aún, de un proveedor, entonces corre el riesgo de todo el éxito de sus esfuerzos SOA. Más bien, aproveche (de forma gratuita) las arquitecturas de referencia SOA para que pueda avanzar a un ritmo más rápido y con un menor riesgo. Bernardo de Chartres lo expresó mejor en el dicho bien conocido: «somos como enanos sobre los hombros de gigantes, para que podamos ver más que ellos, y las cosas a mayor distancia, no en virtud de una agudeza visual por nuestra parte, o cualquier distinción física, sino porque somos llevados en alto y elevados por su tamaño gigante.»Ponte sobre los hombros de otros gigantes de la arquitectura empresarial y deja que aumenten tu visión y éxito.