Shared Database vs. Messaging Architecture

Question

I was down the pub with a friend of mine yesterday and we started discussing the architecture in use at the company he works at. The conversation basically surrounded the pr

Answer 1

Here is one con of a shared database-architecture, which is enough to avoid it:

Tight coupling - If one application requires changes to the master database tables - the other applications will need re-testing and possibly changing to accommodate those changes.

Shared database architectures end up avoiding serious changes to the schema. The master database and associated applications tend to stagnate, resulting in a company that can't offer innovative new products.

This MSDN article, one of many, explains how loosely coupled services can help with the scenario above. Loosely coupled systems can innovate and change without the rest of the company having to change at the same time - leading to a company that can respond well to customer demands.