The "DBMS2" Dialog Continues....
The back-and-forth debate continues... Curt Monash has posted a reply to my post regarding his article, "Time for a New View of Data Management".
[I wish he had posted this as a comment to my entry, but every blog needs content, I guess.]
It's worth repeating that I basically agree with his premise in the article, but I just don't think it's anything new or different enough to warrant calling it out as a new approach to data management (e.g., "the DBMS2 proposal").
Let's boil it down:
Point #1
Curt makes some hyperbolic statements that I take issue with, not because the points aren't directionally correct, but because the language he uses is inflammatory and as stated, are incorrect. Examples include, "...the pure relational model is collapsing under its own weight...", and "Centralized, pre-DBMS2 master data management will never succeed."
I also think Curt errs when he proposes "Drastic limitations on relational schema complexity. Relational schemas shouldn't go far beyond two simple models: master-detail for transactions, and hypercubes/star schemas for analytics." That sounds like a major headache in the making, requiring extensive data model reengineering within existing systems to address a problem that is neither urgent nor particularly costly. It's a difficult problem, not an intractible one. Yes, schema complexity is... well... complex. Duh indeed.
Perhaps the problem is Curt's insistence on dramatizing the situation with words like "drastic". As I said in my post, "All I need in the customer master is a pointer to show where the data lies. That's more logical, it works well within the existing SOA roadmaps I've seen, and it is, in fact, the way it is being done today." In his blog post, Curt acknowledges this, saying "He seems to think I favor a master enterprise schema of some sort, rather than SOA-based just-enough coupling."
If Curt had entitled his article "SOA should be extended to the data layer", I certainly would not have had these issues. But hey, Computerworld is an online magazine, and like all magazines, they need to sell copies. Or gain eyeballs or page views or clickthroughs, as the case may be.
Point #2
I pointed out that it is often performance requirements that dictate the architecture of a customer master. (I'm only concerned with the data management arguments as applied to CDI, naturally.) Curt replies that clearly we "shouldn't throw out DBMS that work for them and replace them with ones that don't work", and professes confusion over my concern.
But in his original article, Curt suggested that DBMS2 requires "Task-appropriate data managers. Just use whatever is cheapest and simplest for each set of applications." Unfortunately, as I point out, cheap and simple are not the only criteria. Sometime, a monolithic, mainframe-based database with a highly complex schema is the only way to get the required performance.
Point #3
Curt complains, "He seems to think I'm arguing in favor of decommissioning large central databases that work, and replacing them with federated horses-for-courses databases managed by different DBMS." Perhaps I got that impression from what he wrote:
My point was simply that the tools to accomplish complete and robust SOA at the data layer are not there yet. XML, even in its proliferation of purpose-specific dialects, simply does not yet provide the capability to map and tag and describe the same level of complexity that is reflected in database schemas.
Curt clarifies his position with this comment, "Rather, I'm suggesting that the reflex towards further consolidation should be viewed skeptically. New application systems should be hosted on the DBMS that are right for them, because the cost of federation will usually be less the cost of using a seriously wrong DBMS." No disagreement, but nothing earthshaking there, either. I have yet to go through an RFI or RFP process, or an architectural build session with a major bank, brokerage or insurance company where every possible option for storing, reconciling and distributing the data was not discussed and evaluated. This is simply good IT management.
So there you are. Tempest in a teapot, perhaps. If I had to summarize the meaningful takeaways from Curt's article and his blog post, it would be this:
[I wish he had posted this as a comment to my entry, but every blog needs content, I guess.]
It's worth repeating that I basically agree with his premise in the article, but I just don't think it's anything new or different enough to warrant calling it out as a new approach to data management (e.g., "the DBMS2 proposal").
Let's boil it down:
Point #1
Curt makes some hyperbolic statements that I take issue with, not because the points aren't directionally correct, but because the language he uses is inflammatory and as stated, are incorrect. Examples include, "...the pure relational model is collapsing under its own weight...", and "Centralized, pre-DBMS2 master data management will never succeed."
I also think Curt errs when he proposes "Drastic limitations on relational schema complexity. Relational schemas shouldn't go far beyond two simple models: master-detail for transactions, and hypercubes/star schemas for analytics." That sounds like a major headache in the making, requiring extensive data model reengineering within existing systems to address a problem that is neither urgent nor particularly costly. It's a difficult problem, not an intractible one. Yes, schema complexity is... well... complex. Duh indeed.
Perhaps the problem is Curt's insistence on dramatizing the situation with words like "drastic". As I said in my post, "All I need in the customer master is a pointer to show where the data lies. That's more logical, it works well within the existing SOA roadmaps I've seen, and it is, in fact, the way it is being done today." In his blog post, Curt acknowledges this, saying "He seems to think I favor a master enterprise schema of some sort, rather than SOA-based just-enough coupling."
If Curt had entitled his article "SOA should be extended to the data layer", I certainly would not have had these issues. But hey, Computerworld is an online magazine, and like all magazines, they need to sell copies. Or gain eyeballs or page views or clickthroughs, as the case may be.
Point #2
I pointed out that it is often performance requirements that dictate the architecture of a customer master. (I'm only concerned with the data management arguments as applied to CDI, naturally.) Curt replies that clearly we "shouldn't throw out DBMS that work for them and replace them with ones that don't work", and professes confusion over my concern.
But in his original article, Curt suggested that DBMS2 requires "Task-appropriate data managers. Just use whatever is cheapest and simplest for each set of applications." Unfortunately, as I point out, cheap and simple are not the only criteria. Sometime, a monolithic, mainframe-based database with a highly complex schema is the only way to get the required performance.
Point #3
Curt complains, "He seems to think I'm arguing in favor of decommissioning large central databases that work, and replacing them with federated horses-for-courses databases managed by different DBMS." Perhaps I got that impression from what he wrote:
"We must replace it [the relational model] with a radically different view of data management, which I'm calling DBMS2..."But actually, I think Curt was reacting to my comment about the current lack of pressure to decommission existing massive DB deployments. Which, if the pure relational model was "collapsing under its own weight" would certainly necessitate "drastic" measures, but it isn't, and it doesn't.
My point was simply that the tools to accomplish complete and robust SOA at the data layer are not there yet. XML, even in its proliferation of purpose-specific dialects, simply does not yet provide the capability to map and tag and describe the same level of complexity that is reflected in database schemas.
Curt clarifies his position with this comment, "Rather, I'm suggesting that the reflex towards further consolidation should be viewed skeptically. New application systems should be hosted on the DBMS that are right for them, because the cost of federation will usually be less the cost of using a seriously wrong DBMS." No disagreement, but nothing earthshaking there, either. I have yet to go through an RFI or RFP process, or an architectural build session with a major bank, brokerage or insurance company where every possible option for storing, reconciling and distributing the data was not discussed and evaluated. This is simply good IT management.
So there you are. Tempest in a teapot, perhaps. If I had to summarize the meaningful takeaways from Curt's article and his blog post, it would be this:
- SOA concepts in IT infrastructure and design need to be extended to the data layer.
- The modularity of the component approach can help with the problem of schema complexity.
- Emerging capabilities in new technologies (new DBMS and OLAP tools) and enhancements to existing ones (XML and Web Services) are bringing the possibility of a true data-level SOA closer to reality.
0 Comments:
Post a Comment
<< Home