Martin Fowler writes about the difference between an Application Database and an Integration Database. He continues by expressing his favor for a message-based integration rather than an Integration Database.
I dunno. The devil is in the details. Here are some thoughts...
For one thing, message-based solutions are often based on new technology, and often from a new vendor. Even if the quality is good, avoiding vendor lock-in is not easy, even with a "standard" like JMS.
Unless the developers have done message-based implementations already, new skills are needed. If the enterprise has an ERP like SAP R3, then there's another issue to deal with: is the messaging product the "enterprise bus" or is SAP the bus? The answer may not be ideal either way. Going outside of the ERP though can lead to duplicating functionality or at least "rules", and/or lead to too much effort at the boundary between messages and the ERP API.
(This gets better when the ERP implements messaging, but what about those "legacy" message buses?)
The lower the number of applications that need integrating, the more I favor using an Integration Database. Care is still needed if vendor lock-in is to be avoided, but most enterprises I suspect have their databases of choice, SQL Server, MySQL, whatever. The open source databases like MySQL and PostgreSQL are perfect for an Application Database or an Integration Database at very low total cost of ownership.
If one of the systems is an ERP, the more I favor an Integration Database, especially if the developers are familiar with the database technology and unfamiliar with a message-based solution. These databases tend to be an Application Database, although the they could be both: what we're really talking about is Application Data Model and Integration Data Model; both may be present in the same database.
I'd much rather get the best of both the data and message worlds, and more, by using a Tuple Space.
Databases are not hot right now, but they are certainly tried and true, and I bet the enterprise has a better license for them, and more developers who can handle them than it does for messaging. It may not be SOA, but you probably won't be SOL either.