Introducción

Habíamos entrado en un nuevo siglo y la orientación a objetos gozaba de plena salud. La vieja escuela de pensar que la programación consistía en llevar a cabo actividades de composición algorítmica había quedado muy atrás. La masa de desarrolladores había parecido aceptar plenamente que el diseño y construcción de productos digitales partía de la creación de abstracciones de datos.

No solo había quedado constatado que esta nueva forma de aproximarse al desarrollo de soluciones resultaba mucho más estable y duradera sino que además parecía haber encajado bien con la forma de pensar de la comunidad. Había un claro confort ante la nueva idea de que crear productos era, sobre todo y ante todo, establecer un diálogo colaborativo entre diferentes categorías de objetos contractualmente diseñados para encajar como un guante en los contextos arquitectónicos donde su uso había sido previsto.

Además, el nuevo paradigma fomentaba la creación de distintas variantes de cada tipo de objetos para mostrar diferentes comportamientos sistémicos en ejecución por medio de un simple esfuerzo de remplazo sustitutivo. No se podía pedir más. Los objetos se mostraban como las entidades autónomas por antonomasia capaces de encapsular comportamientos específicos a la misma vez que ofrecían oportunidades abiertas de composición continua para contribuir al espacio del problema. Cada sistema era ahora una solución adaptativa y extensible por el mero hecho de estar construida sobre la base de una arquitectura orientada a objetos.

Objetivos

Y lo cierto es que eso fue verdad. Nunca nadie pidió más. Sin embargo, en el ámbito de la academia, había reservas acerca de si realmente, la verdadera esencia de la orientación a objetos había sido entendida desde su base fundacional. Al hablar de objetos, se estaba poniendo especial estrés en que las abstracciones de datos, además de ser eminentemente realidades estables y duraderas en el espacio de cada problema, deberían ser entidades con un potencial de reusabilidad idealmente universal.

La incomodidad de la academia venía de la idea de que los programadores parecían aplicar los conceptos de la orientación a objetos tan sólo en el marco de cada proyecto. Al arrancar cada nuevo desarrollo, se hacía borrón y cuenta nueva, y el conjunto de objetos con el que había que trabajar, se creaba nuevamente desde cero. Parecía no haberse entendido, que la reutilización que prometía la orientación a objetos, sólo tendría sentido si creábamos abstracciones cuyo espacio de reusabilidad se extendiera más allá del ámbito de cada proyecto particular. Era preciso dejar de pensar en hacer contribuciones al proyecto para empezar a hacer contribuciones al dominio al que dicho proyecto pertenecía. Pero, ¿estarían las organizaciones dispuestas a asumir los costes de construir artefactos en pro de la construcción de ese dominio, aún cuando no fueran a facturar directamente por ese esfuerzo de abstracción?

Reutilización. La reutilización se dibujaría como el principal eje de preocupación de la orientación a componentes. El desarrollo de activos debería dejar de realizarse en el marco de cada proyecto para empezar a contribuir al dominio al que dicho proyecto pertenecía.

Si lográbamos llegar hasta el punto de madurez en el que las contribuciones se hicieran en el ámbito de dominios de actividad para elaborar, de forma iterativa e incremental, catálogos de artefactos arquitectónicos bien formados, estaríamos ante una verdadera idea de reutilización. Los artefactos de cada dominio podrían ser aplicados transversalmente dentro de todos los proyectos presentes y futuros vinculados al marco de dichos dominios.

Con esto, no solamente habíamos precisado la idea general de reutilización, sino que ahora seríamos capaces, incluso, de establecer métricas acerca de cuán reutilizables son los activos arquitectónicos en si mismos. Al conocer la extensión de cada dominio a la que contribuye un artefacto, sería posible calcular el número de oportunidades que dicho artefacto tiene de ser usado en el marco de su dominio de aplicación.

Catálogos, dominios y métricas. Parecía un buen momento para separarse del manido concepto de objeto y abrazar una terminología más apropiada. Se hablaría de componentes, como aquéllas entidades de mayor granularidad, capaces de ofrecer diferentes servicios de valor en el marco de la arquitectura. Todo esfuerzo de desarrollo no se abordaría sin disponer de un nutrido catálogo de componentes bien organizado y, una vez más, la actividad de diseño crecería en nivel de abstracción al entender que la actividad de construcción de soluciones sería un ejercicio compositivo.

De esta forma, cada organización se reintepretaría como una auténtica factoría de software con una inteligencia especializada de dominio y un esquema de proceso compositivo bien definido. Lo primero, se materializaría en el conjunto de componentes de catálogo que pasaría a ser el verdadero activo de valor de la factoría. A lo segundo, se le daría forma en base a herramientas de construcción generativa capaces de desplegar código fuente de la línea base de la arquitectura.

Principios

La actividad de investigación en la academia seguía en plena ebullición centrada en el debate de que un adecuado entendimiento acerca de la reutilización no había sido alcanzado dentro de la comunidad. La orientación a objetos, al menos desde un punto de vista teórico, había fracasado en parte porque era precisamente esta cualidad la preocupación principal que tuvo en pretensión desde sus orígenes.

Como explicaremos un poco más adelante, dentro de la orientación a componentes, surgieron diferentes escuelas. Pero en relación a la caracterización del paradigma, esta nueva estrategia de diseño y construcción de software puede describirse, por agregación, en los siguientes principios fundacionales de diseño.

• Principio de Contribución. Como venimos explicando a lo largo de todo este artículo, el principio de contribución establece que el conjunto de activos que se desarrollen en orientación a componentes no debe ser nunca diseñado y construido para dar respuesta a una necesidad local confinada al marco de un determinado proyecto. Muy al contrario, cada esfuerzo de desarrollo que emerge en el espacio de un proyecto debe ser estratégicamente extendido en alcance y abstracción para permitir su contribución a dominio. La estructura arquitectónica del catálogo, debe ofrecer un locus para ubicar la contribución dentro del dominio y también definir un contexto de composición con el resto de componentes en la vecindad que regule la forma que debe tomar dicha contribución.

• Principio de Reutilización. De manera recíproca, el principio de reutilización dentro de la orientación a componentes, prescribe que toda solución que se idee para hacer frente a una necesidad surgida en el marco de determinado proyecto local debe ser resuelta siempre en términos de una composición entre los artefactos presentes en el catálogo de dominio. Sólo si no existe una solución en estos términos puede elaborarse una respuesta local que, en cualquier caso, y en virtud del principio anterior, debe ser contribuido en tiempo y forma al catálogo de dominio.

• Principio de Composición. En alineamiento con los dos principios anteriores, el principio de composición defiende que cualquier ejercicio de diseño y construcción de nuevas soluciones en el marco del paradigma de la orientación a componentes se articula a través de un proceso sistemático iterativo e incremental. Primero se escoge, del catálogo de dominio, el conjunto de componentes que van a formar parte de la solución para hacer frente al problema surgido en el seno del proyecto local. Después, a través de una actividad compositiva entre los componentes implicados se elabora una solución a dicho problema. Finalmente, si esa solución compositiva se entiende de reutilización potencial dentro del dominio, se encapsula la misma como un nuevo artefacto para ser contribuido al catálogo de componentes.

• Principio de Adaptación. En estrecha relación con el principio de reutilización anterior, el principio de adaptación establece que en el marco de la orientación a componentes, todo activo arquitectónico debe ser diseñado de manera que su contrato compositivo presente el nivel adecuado de plasticidad contractual. Esto se prescribe de cara a fomentar en los componentes un mayor grado de flexibilidad en los procesos de conexión compositiva permitiendo así que éstos entren a participar en un mayor número de contextos arquitectónicos de uso diferentes de aquellos para los que fueron originalmente diseñados. Como explicaremos más adelante, este fue uno de los principales puntos de discordia que dieron lugar a diferentes escuelas o corrientes de pensamiento en el seno de este paradigma.

• Principio de Extensión. En continuidad con lo que se defendía dentro de la orientación a objetos, el principio de extensión en el marco de la orientación a componentes estresa la importancia de crear arquitecturas capaces de mostrar comportamientos extensibles de manera no invasiva. Es decir, las arquitecturas de componentes deben ser capaces de ser extendidas sobre la base del código en curso sin la necesidad de que estas sean reestructuradas. Aunque esta idea coincide, en términos generales, con el principio abierto cerrado de la orientación a objetos, lo cierto es que las diferentes escuelas de orientación a componentes propondrían caminos de solución divergentes, e igualmente interesantes, para ofrecer comportamientos extensibles en este sentido.

• Principio de Contextualización. El principio de contextualización establece que, dentro del paradigma de orientación a componentes, cualquier artefacto en uso debe mostrar un comportamiento potencialmente influenciado por el contexto arquitectónico en el cual se despliega su ejecución. Contrariamente a las ideas de la orientación objetos que promueven una respuesta agnóstica e independiente del contexto, en la orientación a componentes, los artefactos son capaces de tomar conciencia ambiental del entorno de ejecución y mostrar una respuesta adaptada al mismo. Como veremos más adelante, las diferentes escuelas mostrarían distintos niveles de respuesta a este principio.

• Principio de Descubrimiento. Finalmente, el principio de descubrimiento establece que cuando los componentes se despliegan en tiempo de ejecución dentro de un determinado contexto de uso deben ser capaces de explorar la vecindad arquitectónica para descubrir otros componentes con los que articular un enlace compositivo. Tras ello, el conjunto así articulado empieza a operar para mostrar un comportamiento sistémico global adecuado. El principio de descubrimiento se encuentra en estrecha relación con el principio de contextualización anterior ya que cuando un componente es extraído de un determinado contexto y sumergido en otro contexto diferente, los enlaces compositivos que articula con la nueva vecindad son diferentes y se observan comportamientos globales también distintos.

Mecanismos

El debate teórico dentro de la orientación a componentes parecía haber dejado claro que se requería el uso de un nuevo tipo de artefacto arquitectónico. Algo que nos separase de la orientación a objetos lo suficiente como para entender que las pretensiones y directrices de esta nueva estrategia de desarrollo de software eran divergentes con respecto a aquéllas presentes en el paradigma anterior.

Pensado a diez mil pies de altura, lo más razonable era imaginar que los componentes serían artefactos encapsulados, de alto nivel de granularidad, orientados a servicios y con altas capacidades de reutilización y enlace compositivo en el marco de arquitecturas expresadas a un mayor nivel de abstracción. Sin embargo, ahora estábamos caminando sin ruedines. No existía ningún lenguaje de programación que hubiera consolidado los mecanismos de soporte esenciales a este nuevo paradigma. Cualquier construcción conceptual debería hacerse sobre la base de algún lenguaje preexistente.

Y es que precisamente en la granularidad, se encontró la principal fuente de controversia dentro de la comunidad académica. Mientras que algunos autores abogaban por el hecho de que una mayor reutilización productiva sólo se conseguiría a través de la creación de artefactos mas volumétricos en responsabilidad, otros, no sin poca razón, argumentaban que, muy al contrario, la reutilización maximal debería buscarse en la creación de artefactos aún más pequeños que los objetos. Los componentes, en este sentido, deberían ser concebidos como activos que, convenientemente contribuidos al cuerpo de un objeto, aportaran rasgos parciales de comportamiento. La versatilidad de estos rasgos para ser contribuidos a cualquier activo en el marco de una arquitectura les conferiría un carácter de universalidad en su nivel de reutilización.

Y esta fue, tal y como comentábamos con anterioridad, la base de una importante discrepancia que nunca dio en resolverse del todo dentro del paradigma de programación orientada a componentes. El concepto de componente no tenía un claro soporte sintáctico ni semántico en el marco de ninguna tecnología ni lenguaje de programación. Al menos no un soporte comúnmente aceptado. Por ende, la duda era, ¿a qué nos estábamos refiriendo cuando pensábamos en componentes? ¿a qué se parecía un componente? ¿cual era su estructura anatómica y sus partes constituyentes? A este respecto, surgieron tres vias diferentes de respuesta.

• Modelos Compositivos. En los modelos compositivos, los componentes deberían ser entendidos como espacios de colaboración bien diseñados donde una colección de objetos articulaban una colaboración específica que, de alguna forma, operaba como respuesta canónica a un problema de aparición recurrente. En especial, el uso de técnicas de abstracción paramétrica, genericidad y encapsulación materializaría el concepto de componente. La aplicación de la inversión de control, inyección explicita de dependencias y contexto de ejecución permitiría concebir los procesos de diseño y desarrollo como actividades basadas en enlazado de activos por delegación. La potencia adaptativa de este tipo de arquitecturas seguía basándose en el uso de sustitución compositiva. Sin embargo, la inversión de control conferiría, a este respecto, un mayor grado de flexibilidad, control y sistematización.

• Modelos Adaptativos. En los modelos de componentes basados en adaptación, los componentes podían ser imaginados asimismo como activos arquitectónicos convencionales, típicamente objetos si así se quiere pensar. Sin embargo, un nuevo tipo de artefacto complementario, conocido por el nombre de extensión adaptativa, permitiría aplicar transformaciones, en tiempo de ejecución, sobre el cuerpo de los activos de la arquitectura. De esta manera, se conseguiría alterar el comportamiento, estructura y capacidad de los activos en la arquitectura y, por extensión, afectar al comportamiento sistémico global. En este tipo de modelos, el foco de atención en tiempo de diseño dejaba de estar centrado en la construcción de activos con un modelado perfecto para ponerse en la definición de extensiones adaptativas capaces de articular transformaciones relevantes en momentos adecuados. Si los activos de una solución ya no iban a ser elementos inmutables durante el tiempo de vida del sistema, sino más bien, realidades plásticas y maleables, ya no era necesario tenerlos preparados para toda colaboración desde el inicio. En su lugar, cada artefacto iría sufriendo transformaciones pertinentes bajo demanda de las condiciones de cambio ambiental por medio de la aplicación estratégica de extensiones adaptativas.

• Modelos Generativos. Por su parte, los modelos generativos desarrollados dentro del marco la orientación a componentes, conceptualizarían los componentes a un nivel de descripción mucho más bajo que los dos modelos anteriores. En este tipo de modelos, los componentes debían ser pensados como fragmentos de código fuente que, por aplicación de técnicas de composición generativa articuladas bien a nivel léxico o sintáctico, conseguían elaborar estructuras de código fuente que darían lugar a comportamientos altamente flexibles y adaptativos. Los procesos de construcción compositiva basarían su comportamiento en el uso de modelos de metadatos y reglas de composición que legitimaran solo aquellas construcciones de código bien formadas de acuerdo un esquema gramatical. Si bien este modelo es, sin lugar a dudas, el más flexible de los tres, su aplicación es la más atrevida por cuanto opera a un nivel de abstracción muy bajo. Pese a ello, no son pocas las soluciones que hoy en día operan con este tipo de aproximaciones.

Arquitecturas

El relato teórico de la orientación a componentes y su extensión metodológica recogida en el campo de lo que dio en llamarse ingeniería basada en componentes, pronto encontró partidarios en diversos espacios de realización práctica dentro de las corporaciones. En efecto, este nuevo modelo de desarrollo venía a resolver algunos de los problemas que, de manera recurrente, algunas organizaciones centradas en la construcción de software, venían experimentando con cotidianidad.

En particular, se pueden distinguir tres tipos de problemas de corte metodológico y tecnológico, claramente resueltos por aplicación de las técnicas de la ingeniería de componentes. Cada uno de ellos se daba en organizaciones con una orientación de la actividad de negocio diferente dentro del perímetro de la construcción de software. Asi que tiene sentido considerarlas como tres áreas de preocupación independientes que dieron lugar a sendos modelos de arquitectura.

• Familias de Productos. En algunas empresas de desarrollo de software a gran escala centradas en cliente final se había popularizado un modelo de diseño de productos basado en familias. Este tipo de corporaciones ya no se limitaban a construir y comercializar productos aislados sino que, por el contrario, vendían un paquete de soluciones dependientes e interrelacionadas que, de alguna manera, venían a dar respuesta a las necesidades típicas de cierto perímetro de operación. Las suites de Adobe o Microsoft son dos claros exponentes de esta idea. En el marco de estas organizaciones de desarrollo, disponer de un catálogo de componentes bien formado que pudiera ser reutilizado transversalmente dentro de ese espacio de soluciones y más aún, reestructurar los procesos de desarrollo de software internos para alinearlos con las ideas de la orientación a componentes y aumentar las cotas de desarrollo productivo parecía una opción excepcional. Sobre esta base, equipos especializados se encargarían de nutrir de manera sistemática el catálogo de componentes y, bajo este prisma, sería fácil medir el grado de reutilización de los componentes dentro de dicho catálogo.

• Líneas de Productos. Por otro lado, las empresas dedicadas al desarrollo de productos específicos para cliente final, encontrarían en la base teórica del paradigma de la orientación a componentes, una conceptualización interesante para sistematizar sus procesos de construcción de software y reducir notablemente los costes y tiempos de entrega. Por la vía de la especialización, este tipo de empresas, ahora era capaz de crear productos de manera ágil en base al uso de catálogos de componentes, procesos compositivos prediseñados y herramientas generativas que pudieran elaborar una solución rápida fácilmente adaptable y configurable en función del conjunto de características específicas que el cliente había demandado. Esta idea constituía la esencia de la Software Factory que estaba detrás de este paradigma de desarrollo. Los activos, los procesos y la organización empresarial se diseñarían para crear un tipo de corporación centrada en hacer bien una sola cosa y entregarla rápido. La velocidad de entrega era el factor diferencial con la competencia.

• Arquitecturas Dirigidas por Modelos Finalmente, muchas organizaciones hacían frente al problema de crear variantes diferentes de un mismo producto para que pudiera operar sobre plataformas tecnológicas diferentes. Tal es el caso de la construcción de aplicaciones digitales que, en los primeros años del desarrollo móvil, suponía una imputación en costes importante dado que se tenían que mantener streams de desarrollo independientes para cada plataforma. Aún hoy en día esto sigue siendo un problema, si bien La familia de plataformas de despliegue tecnológico se ha reducido considerablemente. No obstante, la orientación a componentes vino a dar una respuesta también en este perímetro a través de las arquitecturas dirigidas por modelos. El diseño de los productos digitales debería establecerse en base a la definición de modelos formales que, por aplicación de técnicas de transformación sistemática y dirigida, permitirían que un mismo diseño de producto pudiera traducirse en código convenientemente generado para compilar y ejecutar en las diferentes plataformas tecnológicas de mercado.

Cada uno de los tres escenarios que acabamos de describir, corresponden a modelos arquitectónicos diferentes. Lamentablemente la descripción en detalle de cada uno de estos modelos y su relación con los modelos de mecanismos descritos con anterioridad está fuera del alcance de este artículo. Bien valdría la pena dedicar series específicas para tratar en profundidad cada uno de estos aspectos.

Patrones

Las segmentación en escuelas que acabamos de describir en la sección anterior conduciría a una fragmentación importante en las líneas de trabajo teóricas del paradigma de orientación a componentes. Ahora, cada corriente de pensamiento defendía un modelo de artefacto diferente y legitimaba el uso de una familia de mecanismos de soporte específicos.

En componentes, un patrón de diseño debía proporcionar una solución probada para dar respuesta a un problema de aparición recurrente dentro de las arquitecturas de este paradigma. Sin embargo, ni el conjunto de problemas que emergían, ni sobre todo el de los posibles modelos de soluciones aplicables eran los mismos para cada escuela. Cada escuela tenía sus problemas comunes y sus soluciones de aplicación potencial. Cada escuela disponía de su propio catálogo de patrones de diseño.

• Patrones Compositivos. En los modelos compositivos, las arquitecturas estaban basadas en el uso de componentes que seguían aplicando los mecanismos clásicos de la orientación a objetos. Se buscaba encapsular colaboraciones entre entidades para formar componentes y diseñar arquitecturas en base a delegación, herencia, polimorfismo, ligadura dinámica y genericidad. De esta manera, el conjunto de problemas que surgían en torno a este tipo de actividades sería esencialmente la misma que en la orientación a objetos y los patrones de diseño de dicho paradigma serían aquí plenamente aplicables.

• Patrones Adaptativos. En las arquitecturas basadas en el uso de modelos adaptativos, por el contrario, el espacio de posibles problemas no era exactamente el mismo. El mero hecho de permitir que cada componente pudiera ser dinámicamente contribuido con nuevos rasgos de comportamiento parcial reducía la complejidad estructural y volumétrica de las arquitecturas descargando notablemente la carga cognitiva en los procesos de diseño. Por su parte, dentro del espacio de la solución, ahora los componentes eran entidades plásticas que podían evolucionar morfológicamente bajo demanda para adaptarse dinámicamente a las condiciones de cambio ambiental. Y a su vez, la formulación en la que se expresarían los patrones estaría basada en el uso de una nueva familia de técnicas contributivas.

• Patrones Generativos. Finalmente, en las arquitecturas basadas en modelos generativos, los componentes tomaban la forma de fragmentos de código que podrían ser compuestos por medio de técnicas compositivas de bajo nivel. Dentro de este marco, el espacio de problemas recurrentes tenía más que ver con cómo hacer frente a aspectos relativos a la generación dinámica de código bien formado que con preocupaciones de índole arquitectónica. Si la composición se resolvía a nivel léxico el espacio de patrones de diseño describiría cómo era posible enfrentar el anclaje de unos fragmentos de código frente a otros para que dieran logar a componentes reutilizables. Si por el contrario, la composición se resolvía a nivel sintáctico, los patrones se formularían en términos de transformaciones sobre el árbol gramatical.

Aunque de un primer vistazo pueda parecer que los modelos de composición que hemos citado hasta ahora no han tenido una aplicación real dentro de la comunidad de desarrollo lo cierto es que no es para nada así. En el ámbito de las arquitecturas compositivas, la aparición masiva de marcos de trabajo que aplicarían técnicas y patrones de inversión de control fue una realidad que gozó de una gran acogida casi desde sus inicios. Por su parte, las arquitecturas adaptativas se posicionaron con más fuerza dentro de lenguajes más ligeros como Python, Ruby o JavaScript que en las comunidades de los lenguajes más sólidos al uso como Java o C#. Es de destacar, en este sentido, el notable auge que experimentó la programación orientada a aspectos en cierto momento. Finalmente, las arquitecturas generativas fueron las soluciones de nicho de aplicación idónea para el desarrollo de inteligencia dentro de los IDEs de desarrollo. Al fin y al cabo, dentro de este marco, era preceptivo entender que el modelo de componente estaba basado en el uso de fragmentos parciales de código fuente.

Técnicas

El relato fragmentado anterior también debe extenderse al explicar las diferentes familias de técnicas que se aplicarían dentro del paradigma de la orientación a componentes. Para modelos de componentes basados en composición, adaptación, o generación es razonable pensar que las técnicas de aplicación serían considerablemente distintas. En este sentido, cabe hacer una reflexión sobre la naturaleza divergente de cada uno de los modelos de componentes que venimos describiendo a largo de este artículo.

• Técnicas Compositivas. Para el caso de las arquitecturas basadas en el uso de modelos compositivos, los artefactos son componentes computados que resuelven sus dependencias inicialmente durante las fases primeras de configuración o, dinámicamente, bajo la demanda de los distintos artefactos que son solicitados durante la ejecución. El único margen de maniobra para la adaptación, dentro de este contexto, es el de aplicar técnicas de sustitución compositiva que articulen un entramado de colaboraciones diferente.

• Técnicas Adaptativas. En el caso de las arquitecturas construidas sobre modelos adaptativos, los componentes son artefactos sujetos a la transformación dinámica de su estructura y comportamiento por medio de la aplicación de extensiones adaptativas. Esta aplicación suele estar asociada a mostrar una respuesta adaptada a condiciones ambientales de cambio durante la ejecución. Las técnicas contributivas que se aplican por parte de las extensiones son de muy diversa índole. Podemos hablar de técnicas adaptativas cuando nuevas características se añaden al cuerpo de un componente, extensivas cuando la adición es por alteración de la cadena de herencia, de intercesión cuando se trata de inyección de lógica adicional que se aplica en algún momento dentro de la ejecución de algún artefacto o de contextualización cuando se altera el marco semántico sobre el que se evalúan las expresiones de código.

• Técnicas Generativas. Finalmente, las arquitecturas basadas en modelos generativos, hacen uso de diferentes familias de técnicas para resolver los problemas de composición. En el caso de operar a nivel léxico, es frecuente resolver la composición en base a motores de plantillas que combinan paramétricamente fragmentos de código expresados con metadatos y marcas de anclaje. Por el contrario, si se opera a nivel sintáctico, lo habitual es definir transformadores que se aplican de forma iterativa y discrecional sobre la base de un árbol gramatical. Incluso a veces es posible hablar de operación a nivel semántico caso que se alcanza mediante la aplicación de decoradores sobre código fuente que permiten articular tal suerte de transformaciones sin necesidad de recurrir al plano sintáctico.

Conclusiones

Entraba el año 2000 y casi sin darnos cuenta habíamos realizado una transición de un cambio de paradigma. La comunidad de desarrolladores, con un fuerte foco de atención en la orientación objetos por aquellas fechas, empezó abrazar determinadas prácticas y principios de diseño y construcción de software que en realidad se estaban moviendo hace una nueva línea de trabajo paradigmática.

Se estaba produciendo la transición desde los objetos hasta los componentes. El hecho es que lo más atractivo de este movimiento es que dicha transformación se estaba produciendo sin disrupción cultural y tampoco con la introducción de nuevos modelos de desarrollo basados en el uso de nuevas tecnologías, lenguajes ni sintaxis. Los cambios se fueron produciendo con naturalidad y de una forma muy orgánica.

Lo atractivo de este cambio, es que se ponía de relevancia que la evolución en los procesos de diseño y construcción de software transitando hacia nuevos paradigmas de desarrollo no necesitaba palancas tecnológicas de transformación. Un paradigma de desarrollo es, sobre todo y ante todo, un nuevo espacio de reflexión que invita a pensar en una nueva forma de orientar las actividades de construcción de software.

No pasaría lo mismo años después, cuando emergiera la necesidad de mover toda la lógica empresarial desde lo local hacia la nube. En ese momento, se requerirían nuevos modelos de infraestructura dar soporte a tro forma de ejecución. Pero también, se demandaría revisitar la manera en la que las arquitecturas de diseño y construcción de productos digitales deberían evolucionar para encajar dentro de este nuevo marco de operación. Había nacido la orientación a servicios. Pero eso ya es otra historia.