If five applications are using the same database, and these apps need to be released at different times, what type of architecture or configuration accommodates that scenario?
The main concern is: Any of the five applications are allowed to change the database, which can then break any of the four apps in production.
Werner Vogel, the CTO of Amazon, says that in services should be isolated, independent, and own their own data in a service oriented architecture.
Maybe an alternative approach would be to expose the shared portions of the applications as services that own their data. Let applications that require that information get it from one place.
This arrangement would give you a single place to apply the rules that pertain to that data. Change them in one place, and all clients see them at once.
One issue I’d have with several apps sharing the data would be the possibility of apps applying different business rules to the same data.
Maybe you can hide schema details with a combination of views and stored procedures. This would keep the common data layer in the database, where it’d be easier to maintain in a single spot for all apps. The downside is that you’d be tied to a single database with its stored proc language, but that’s not too severe. Most places don’t switch databases lightly. Middle tier code comes and goes, but data lives on.