La (des)integración entre aplicaciones

Escribo este post en la previa a un parcial. Por suerte, hoy me ha tocado algo simple para cualquier programador: Unos 5 patrones de diseño, y algunas cosas de encriptación y algunos conceptos básicos de OO. Lo que nos mata de esta materia es el trabajo de campo que hay que armar (una suerte de tesina) por lo que al menos los parciales no son tan pesados (repito, para los que ya son programadores).

Es muy común que en nuestras empresas se tenga más de un sistema en pleno desarrollo, e inevitablemente alguien una vez va a pedirnos que compartan datos. Y empezamos con la primera etapa de integración de aplicaciones. Parece inocente, inofensiva, un poco de trabajo para pasar datos de una tabla a otra en bases de datos diferentes. Es como primero lo vé el project leader. Se propone una solución simple, a veces con unos scripts de sql, unos triggers y listo.

Todo marcha bien después de resolver varias inconsistencias como claves que no coinciden, datos que están de un lado y no del otro, y esa clase de cosas que no previmos antes porque simplemente nos tomamos todo a la ligera.

Pasan unas semanas, o incluso unos días, ya vemos que necesitamos más que compartir datos. Por ejemplo, una base de datos requiere que cuando se ejecute cierta lógica de negocio, se impacte inmediatamente en ambos sistemas, y no se puede esperar a ningún proceso ni nada. Aquí la mayoría toma una de estas dos decisiones:

* Encapsular todo en stored procedure y que la base dueña sea X.
* Lo resuelven con triggers

Pero lo menos común es que nos pidan sólo una vez esto. Nos pedirán todo tipo de cosas. Pronto habremos inundado nuestra base de datos de un maremagnum incontrolable de instrucciones de tsql cada vez más confusas. Triggers que pisan el compartamiento de otros, resultados indeseables, clientes insatisfechos, y lo peor, horas largas después de oficina para tratar de resolver el problema. Nótese como puse que lo peor es quedarse y no que el cliente esté insatisfecho. Seamos sinceros, el cliente nunca estará satisfecho si estamos trabajando así, no hay vuelta que darle.

Entonces llega la reunión, con trompetas y banderines. Se nos acerca en su caballo real una persona de alto rango que va a participar con los líderes de ambos sistemas y sus programadores principales. Hay que resolver el problema. Nuestras aplicaciones no se integran.

Pero el primer error que todos cometen es absurdamente nefasto:

* No se miran casos de éxito.

Sin querer decir que la estrategia de implementación que utilizan es excelente, podemos igualmente ver a los productos de Office integrándose entre si e integrándose con sharepoint e internet explorer. Podemos ver aplicaciones extensibles por plugins y sistemas empresariales robustos modularizados en varios pequeños sistemas que han hecho un relativo buen trabajo (o al menos les ha funcionado, sin decir que eso es un éxito).

Y si realmente queremos integración podemos ver a Google con todas sus aplicaciones cada vez mas complejas, podemos ver como Facebook y Twitter, entre otros, permiten a cualquiera integrarse con ellos.

Tenemos de donde sacar ideas. Pero no, lo primero que hacemos es pensar que nuestro problema es único y que debemos resolverlo con nuestra inteligencia. Porque nosotros somos los cerebros del presente y no hay nadie más capacitado para planear el siguiente paso.

Y lamentablemente en la Argentina, así como en muchísimos países donde el IT ha tenido un gran auge, el personal está poco calificado y terminamos encontrándonos con ideas bizarras, no probadas y que no están lo suficientemente pensadas. Pronto entramos en el ciclo vicioso que yo llamo Anti patrón de desintegración de aplicaciones. Ok, acabo de inventar ese nombre, pero nos sirve.

Entonces en vez de iniciar con la integración de nuestros sistemas, los estamos desintegrando. Pronto habremos aumentado la complejidad en el mantenimiento, y con ello, los costos y tiempos. ¿Acaso es el precio a pagar para que nuestras aplicaciones trabajan juntas? No, sería un concepto erróneo pensar que la integración no es una inversión para obtener una ganancia futura, tanto en tiempo como dinero.

¿Cómo lograr la integración entonces?

Cada problema responde a uno o varios patrones. No son difundidos como los patrones de arquitectura, de diseño o de programación. Debemos plantearnos con qué contamos, cuales son todos los problemas, y qué se necesita. Y todo es mejor pensarlo como si todavía no tuviéramos las aplicaciones construídas. Entonces si somos capaces de ello, vendremos con una idea bastante buena.

Lo que puede pasar luego es que, por pensar que los sistemas no han sido creados, nuestra idea no puede aplicarse sin realizar una gran cantidad de breaking changes. Bueno, entonces podríamos plantearnos tres alternativas:

* Realizamos los breaking changes de manera inrcremental. A romper todo señores!
* Modificamos nuestra estrategia original para que pueda adecuarse a la situación actual. Es mejor partir de una idea buena e irla "adulterando" que partir directamente de una mala idea. De esa forma nos acercaremos más a lo que "hubiera sido" ideal.
* Si podemos, planteamos un plan de integración desacoplada, creando e implementando componentes separados de nuestras aplicaciones que se encarguen de la lógica de integración. Concepto que puede ser peligroso, pero al menos no nos inunda la base de datos de triggers.

Es un tema que dá mucho para hablar. Pero no quiero hacer un post gigantesco debido a que las posibilidades son infinitas en cuanto a integración. Y acá podría sonar a que me estoy contradiciendo ya que dije que los escenarios no son únicos. En realidad los factores lo son pero los patrones a aplicar generalmente ya existen.

Todos nos enfrentamos tarde o temprano a la integración de aplicaciones. Al menos con este post quizás alguno pueda pensarlo mejor antes de mandarse a realizarla.