Multiple applications against single database architecture

Question

We are currently creating a new strategy for our inhouse applications. We currently have about 10-15 applications that goes against the same database directly. This is obviously not very good and we want to evaluate our options. As far as I can see we have to choices:

• Duplicate the database and using replication etc for having them in sync
• Create a new application between the database and the 10-15 applications on top.
• Other?

I would very much like to hear your opionions on this. I belive that the second option is the way to go, that also gives us an effective layer to implement caching. But how would you expose this layer for all the applications? Will webservices/rest be the way to go, or are there other, better ways to do this?

Answer 1

I think the buzzword answer to this is "Service Orientated Architecture" - which is indeed option 2.

It's a large-scale undertaking, with many exciting dead ends to explore - but basically, instead of thinking about databases and tables, think about the services which those 15 applications need. Some may be shared, some may be specific to one application. Find a way of exposing those services to the applications - but remember that a web service call can be significantly slower than the equivalent direct database call, so don't take "service oriented architecture" to mean that you have to introduce web services everywhere - it's more of a mindset than a product specification.

Replication and synchronisation - in my experience - create very brittle systems, with failure modes that hurt the brain to even think about.

Other - well, you don't actually say what the specific problem is that you're trying to solve. If its performance - the cheapest way of soving performance issues is throwing hardware at the problem. If it's managability - an SOA can help with that - but it often also introduces additional infrastructure into the mix which also needs to be maintained. Make sure you are really clear about what's driving your architecture choices, because there's no single "best" solution - it's all about trade offs.