It didn't take long for the first collision to occur. AG didn't really care about 50% of the columns in the AA data model. Worse, nobody on AG fully understood how AA was using that data. As a result AG inserted rows that were, from AA's standpoint, invalid. It took only a few days before somebody noticed the problem. Since AA owned the database, they quickly changed permissions on the database, effectively shutting down AG. AG fixed their errors, but within a month new problems were popping up and AA was again threatening a shutdown. It was an unacceptable response to a foreseeable problem that we really should have acommodated at the architecture level.

Our mistake was in allowing two completely different, unrelated applications to directly update a shared database. A much better approach would have been to ask AA to implement a set of services for accessing and updating their database. This approach ensures that the business logic required for updating the database is managed by and handled in a single location. In this way AA takes responsibility for the integrity of their database while AG gets the data it needs.

Lesson Learned: Sharing database instances is fine, so long as the sharing applications are cozily related in both problem domain and management structure. If not, then some layer of insulation is required - like common services for accessing and updating the data.

I guess another approach would be to allow each application to manage their own copy of the database, using a publish/subscribe mechanism for notifying interested applications of changes applied to the local copy of the database. An advantage to this approach is that the data model can be scoped to meet each application's individual requirements. I need to think about when one approach might make more sense than the other.

3:41:02 PM