Una KB grande vs Varias KB mas chicas. Manejando fuerzas opuestas

A medida que pasa el tiempo es normal que las empresas automaticen cada vez mas sus procesos, desarrollando  (o integrando) aplicaciones en cada vez mas secciones de las mismas.

Con este crecimiento, aparecen fuerzas opuestas en la forma de modelar la realidad.

Por un lado, se quieren tener base de conocimientos lo mas chicas posibles, para poder entender y tener un desarrollo mas rapido y ágil. Esto implica que se van a tener varias KB para cada uno de los sistemas necesarios.

La otra opción es tener una KB que tenga todos los sistema de la empresa, siempre que sea posible. Esto hace que se tengan KB grandes, lo cual es buenísimo para el manejo del modelo de datos, el mantenimiento de las instalaciones, etc.

Comparación de ventajas y desventajas

	VENTAJAS	DESVENTAJAS
Muchas KB chicas	Fácil de entender cada KB Desarrollo Agil Diferentes versiones de GeneXus en cada KB Fácil de instalar cada KB Migraciones mas fáciles No se mantiene la integridad referencial en forma automática Programación rápida	Difícil de enteder el modelo global Interfaces entre sistemas mas complejos Proceso de instalación para cada KB (mucho trabajo) Si hay objetos compartidos entre KB (por ejemplo transacciones) es difícil mantener sincronizados entre las KB Dificil mantener propiedades sincronizadas
Una KB grande	Modelo de datos unificado Integridad referencial Interfaces entre sistemas muy fáciles Fácil instalar	Build all lento Difícil de probar Difícil de migraciones Difícil de entender la relación entre los objetos de la KB. Programación mas lenta

Parte de estas ventajas y desventajas pueden mitigarse utilizando módulos, dividiendo una KB grande en módulos mas pequeños. Aun faltan algunos ajustes para que esto sea práctico, pero son pasos en la dirección correcta. Por ejemplo, seria bueno poder ver una KB "filtrada" por un modulo, de forma de solo ver los objetos de dicho modulo y los objetos públicos de los demás módulos y nada mas. Esto ayudaría a los desarrolladores a entender una KB grande. 

Un caso que no se puede resolver correctamente usando módulos, es cuando se necesita una versión nueva de GeneXus para una parte del sistema. Por ejemplo, tengo una KB corporativa en GeneXus Evolution 2 y necesito desarrollar un sistema para dispositivos móviles que pueda funcionar sin conexión, por lo que tengo que usar GeneXus Evolution 3. 

Las opciones que tengo, son hacer una migración de toda la KB de Ev2 a Ev3 (lo cual es todo un proyecto en si mismo  y puede llevar recursos que en el momento no se tienen) o desarrollar el sistema en una KB separada en Evolution 3, e integrarla a la KB grande, cuando se realice la migración definitiva. 

Me viene dando vueltas en la cabeza este problema de mantener varias KB en diferentes versiones de GeneXus, pero que comparten un mismo modelo de datos. Tengo algunas ideas (no demasiado maduras) para poder resolver este problema, las cuales son bastante difíciles de implementar. 

Me parece importante conocer y manejar las fuerzas opuestas de muchas KB vs KB centralizada, pues muchas veces el éxito de mantenimiento de sistemas, dependen de como se organicen las bases de conocimiento de las instalaciones.