The Franciscan Report

Enterprise applications usually use some type of framework to support their underlying applications. Framework can vary from a simple reusable components such as a Math library to a more complex solution such as a mechanims to handle Messaging, Security, etc. Some of the more complex framework requires access to external data storages such as database or a queue, etc.

There are two options on how applications code deploy with this framework's external resouces. One solution is to share the framework's resources amongts all applications, thus data specific to those applications will be stored in the same storages/tables.

The other solution is to store data specific to the application into its own database domain, thus creating a physical boundaries between different applications.

There are pros and cons of both approaches which I will discuss as follows;

The benefits of using the same physical storage for all data are:
- Easy to implement
- Development/Support teams will only have to look at one place to find the data.
- Easy to maintain from the sense where update to data schema will only need to be applied in limited places.

The disadvantages of such solution are:
- Data from different applications are tighly located in the same place.
- No way to protect the integrity of the data of other applications, since different team could potentially affect other team/application data.
- Depends on certain situation/application behavior, there could be performance impact since all applications will be using the same data storage.

The benefit of using segregated data storage:
- No need to worry about affecting other application data, when doing updates/modification to the tables
- If security is a concern, using database to enforce sensitive data between applications is easier to implement.
- No data violation could happen, in a case where some record could have the same values but different meanings, but if the data are stored in the same table, there could be some constraint violations.

The disadvantages of this approach:
- More work for support team, when they have to maintain all applications, thus tools need to be created to leverage this problem.
- Upgrade of data schema need to be applied to more places, but depends on how you implement the schema changes this could work for the benefit of the applications that couldn't afford to have the update yet.