There Are No Pure Data Problems

Computerworld - While I agree with Ken Karacsony's assessment that "Too Much ETL Signals Poor Data Management," I have a very different opinion on what's at the heart of the issue and what kind of solution it deserves, at least on the online transactional processing (OLTP) side of things.
Where Karacsony sees just poor data management, I see poor engineering practices in general.
There is no such thing as a pure data problem, because in any business application, data always exists within the context of the business process. Whenever data is taken out of that context (for example, when it's stored in relational database management system tables), it loses a significant portion of its semantic significance. Take a typical database for a financial services company. While it may be sufficient for very simple cases to have just one flavor of address in the database, business process complexity is likely to require numerous variations of the address structure: current client residence address, property address, client correspondence address, shipping address, billing address, third-party address and so on. All these address records may have identical physical structures, but semantically they are very different. If someone does a home-appraisal search with the current client residence address instead of the property address, for example, he will get a wrong result. And, of course, giving the shipping department the billing address is probably a bad idea.
One way to ensure that data is not taken out of the business context is to build cohesive systems around a logical unit of the business and expose these systems to each other only through semantically rich messages.
One advantage that the messaging integration style has over the shared-database integration style is that it transmits not only the shared data but also the shared business-context semantics. Because it services many different owners at the same time, a shared database by its nature will rapidly lose its initial design crispiness due to an inability to keep up with modification requests. This in turn will lead to data overloading, redundancy, inconsistency and, in the end, poor data quality at the application level. (I would recommend using shared data integration within a single business unit but going to message-based integration for interdepartmental and enterprise development.)
Except for the area of ad hoc reporting, users don't deal with databases; they deal with business applications. I would argue that too much ad hoc reporting signals problems with the business process design, application workflow design and/or user-interface design. Too many OLTP applications are poorly designed and thus have