Let's say you have a Master Database and a few External/Internal applications that use WebServices to interface data.

What would be your preferred architecture to interface data from and to those applications? Would you put some sort of Enterprise Service Bus in between? Like BizTalk? Or something cheaper?

We don't want to block applications while they are interfacing, but we do want to use return codes from the interfaces to determine if we need to take some actions in the originating application or not.

  • When you say "interface data" from one application to another what do you mean? Are you just interested in synchronizing the state of one system's data across all the other systems? Jun 3, 2012 at 16:18
  • When users add/update/delete data in one application, there has to be taken 'some' action in one or more of the other applications. For example, delete the same record, or check the 'deleted' flag.
    – Erwin
    Jun 4, 2012 at 6:15

1 Answer 1


When I have done this sort of thing before - database shared across applications, I find it best to have a single "engine" management service that handles the database - and all apps interface with that. This allows for single place for database code changes - new tables etc - and also managing access, turning on/off application access, security, downtime and maintenance tasks (including database moves/upgrades etc).

It is often worth the extra initial effort - and many appls can use the same code/sprocs etc without any need to know the database at all (abstracted away).

This does have some risks of course - it is a single point of failure across the platform (but so is the database itself if it is shared) and it has to be secured and signed to protect against illegal calls from suspect code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.