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.
2 comments:
ERP as an integration database - I dunno.
My experience has been that I can read from the ERP's database, but to update it I need to go through their (poorly documented) API. Then over time, numerous applications written by numerous application teams are integrated to this API - which is great until it violently changes.
Based on my experience, I'd rather integrate with a message bus.
ERP as an integration databaseNo, that's not the scenario. The scenario is you have applications outside the ERP and you want to integrate them with the ERP and with each other.
Most of the time you want to integrate applications with the ERP, less with each other, because the ERP itself becomes the "enterprise bus" for better or worse. (As their architectures improve, this should be for the better.)
In this scenario, the components become fairly simple: an application, an application database, and the ERP. The interface between the application database and the ERP may be batch, real-time synchronous, or scheduled asynchronous.
In some cases applications outside the ERP share a database, and may actually use this as an Integration Database before, during, or after integrating that data with the ERP.
A diagram might help, but I don't have one here.
Post a Comment