Análisis de Impacto ampliado o manejo del API de mi aplicación.

Hace unos años, las aplicaciones Genexus podian representarse con el siguiente esquema simple:

El origen de los datos, era una base de datos y se tenia salida en forma de pantallas, reportes, archivos de texto, mails, etc.

Cuando teníamos un cambio en la aplicación, nos alcanzaba con analizar que era lo que cambiaba en las tablas de la base de datos y debíamos comprobar que las salidas fueran las esperadas. 

También era conveniente comparar las navegaciones de los objetos internos, para ver que los cambios fueran los esperados y con eso,  nos resultaba facil el manejo de los cambios de version de nuestras aplicaciones. 

Las aplicaciones actuales, son bastante más complejas, y pueden representarse en forma simplificada como:

Cual es la diferencia? 

Seguimos teniendo la base de datos y las mismas salidas, pero se agregaron otras fuentes de datos (generalmente web services)  y a su vez nuesta aplicacion paso a ser fuente de datos de otras aplicaciones.

Que consecuencias tiene esto? 

El analisis de impacto anterior que solo abarca la base de datos, se torna insuficiente para analizar cual sera el impacto de la nueva version. 

Debo agregar un analisis de cuales son los servicios externos que cambiaron y cuales de los servicios que mi aplicacion publica cambiaron, para poder avisarle a quienes los consumen. 

Un buen ejemplo de esto son las aplicaciones generadas por GeneXus para Smart Devices, que pueden tener una base de datos local (cuando son offline) y tambien recuperan y guardan datos de servicios REST. Cuando haga una nueva version, tengo que saber si los servicios cambiaron para saber si debo o no instalar una nueva version en los dispositivos moviles. 

Otro ejemplo, es cuando una aplicacion WEB, publica web services SOAP para que sean consumido por los demas. 

Cual seria un analisis de impacto "ampliado"?

Asi como en IAR de hoy, compara la estructura de la base de datos actual y la futura y muestra las diferencias, en analisis de impacto de las API, deberia guardarse una foto de la interfaz actual de los servicios consumidos y compararlo con la interfaz del web service futuro. En el caso del los Web services SOAP, puedo almacenar los WSDL. En el caso REST, es un poco mas complejo. 

Creo que con la incorporación de los módulos y la definición de cuales son los objetos públicos y privados, vamos en el camino correcto, para lograr tener un GeneXus API Manager, que permita administrar la interfaz de mi aplicación.