BANKRUPTCY SONNET
Suddenly vacant space. So suddenly
the landlords haven’t vacuumed. So very
vacant the brokers are at a loss for
adjectives. Special and spacious, this place
represents a rare opportunity
to make your statement in a property
that towers over the Interstate. So
special you and your partners can claim your
respective pieces of executive
real estate, sleek and smart, catercorner
suites overlooking the soon-to-be heart
of whatever new business you now must
build to play a part and have a shot at
being there when the economy swells.
Saturday, April 25, 2009
Monday, April 20, 2009
FORRESTER blog repost Oracle’s Sun Acquisition Accelerates Push into Data Warehousing Appliances
Oracle’s Sun Acquisition Accelerates Push into Data Warehousing Appliances
By James Kobielus
Last fall, Oracle CEO Larry Ellison announced that his company was getting into the hardware business, but I think he misspoke. At that time, he was referring to the new HP Oracle Database Machine with Exadata Storage, a high-end data warehousing (DW) appliance that incorporated hardware from his partner, as well as intelligent storage software technology from that partner--and even had the partner’s name first in the product name. If that was the criterion for “getting into the hardware business”--i.e., running on someone else’s hardware--then every software vendor on earth is in the hardware business, by my reckoning.
But today’s Oracle announcement is the real deal. Oracle is acquiring longtime partner Sun Microsystems, putting the software powerhouse fully into the hardware business--and hitting the DW industry like an earthquake. I’ll let my Forrester colleagues blog on the other implications of this deal--for the open source, Java, middleware, SOA, and other markets that Sun is in--and give you a few quick thoughts on the deal’s implications for the DW market.
For starters, this deal will give Oracle the ability to engineer a completely integrated DW appliance composed of all Oracle components, including hardware and software. Now Oracle will be able to take on Teradata and IBM--both of which have long offered their own integrated solutions--more aggressively with high-performance DW offerings. Just as important, Oracle will be able to leverage Sun’s manufacturing scale economies to bring its all-Oracle DW appliances below the $25K-per-terabyte threshold needed for penetration into the midmarket.
Also, Oracle will now have another widely adopted transactional database, the open-source MySQL, that it can--and should--consider tweaking and packaging on an DW appliance. To the extent that Oracle gives customers a choice of DBMSs on a DW appliance platform, it can gain a differentiator that Teradata, IBM, Microsoft, Sybase, and Netezza lack (you have to go to a startup such as Dataupia for multi-DBMS choice on an appliance). Many information managers prefer to stick with their existing DBMSs when building a DW, and prefer to implement that DW on an appliance to take advantage of its out-of-box balanced configuration of CPU, memory, storage, and I/O.
Furthermore, Oracle is acquiring a hardware and operating system vendor that has long been one of the primary platforms on which its own DW/DBMSs, middleware, and tools have been deployed. This acquisition can only be welcome news for joint Oracle-Sun DW customers who have worried about Sun’s solvency for some time now and began to sweat serious bullets when IBM failed to emerge as a white knight. For many Sun customers, an Oracle-powered DW platform will now look like a safer bet than ever.
Of course, there are clear risks in this pending acquisition.
First, a combined Oracle/Sun sows uncertainty among the DW appliance vendors--such as Greenplum and ParAccel--who have partnered with Sun and now find themselves in earnest “co-opetition” with full-competitor (and then some) Oracle.
Second, Oracle’s other DW appliance hardware partners--including HP, IBM, and EMC/Dell--must be concerned that Oracle will now shift focus away from their respective appliance products in favor of those it builds with its own Sun hardware group.
And finally, Oracle’s acquisition of Sun--and possible future development of a MySQL DW appliance--may discourage customers from considering third-party DW appliances, such as from Kickfire--that build on MySQL. If that happens, and a market for non-Oracle-branded MySQL DW appliances never takes root, Oracle will be denying its MySQL customers the choice that Oracle Database customers already enjoy. Currently, Oracle Optimzed Warehouse customers can deploy that enterprise DBMS as a DW on their choice of Sun, HP, IBM, and EMC/Dell platforms.
Let’s hope that Oracle makes the most of its pending Sun acquisition. Ellison either misspoke last fall, or was speaking prophecy. Like most DW vendors, Oracle’s destiny is to grow ever more hardware-dependent for its long-term scalability, performance, and optimization story.
By James Kobielus
Last fall, Oracle CEO Larry Ellison announced that his company was getting into the hardware business, but I think he misspoke. At that time, he was referring to the new HP Oracle Database Machine with Exadata Storage, a high-end data warehousing (DW) appliance that incorporated hardware from his partner, as well as intelligent storage software technology from that partner--and even had the partner’s name first in the product name. If that was the criterion for “getting into the hardware business”--i.e., running on someone else’s hardware--then every software vendor on earth is in the hardware business, by my reckoning.
But today’s Oracle announcement is the real deal. Oracle is acquiring longtime partner Sun Microsystems, putting the software powerhouse fully into the hardware business--and hitting the DW industry like an earthquake. I’ll let my Forrester colleagues blog on the other implications of this deal--for the open source, Java, middleware, SOA, and other markets that Sun is in--and give you a few quick thoughts on the deal’s implications for the DW market.
For starters, this deal will give Oracle the ability to engineer a completely integrated DW appliance composed of all Oracle components, including hardware and software. Now Oracle will be able to take on Teradata and IBM--both of which have long offered their own integrated solutions--more aggressively with high-performance DW offerings. Just as important, Oracle will be able to leverage Sun’s manufacturing scale economies to bring its all-Oracle DW appliances below the $25K-per-terabyte threshold needed for penetration into the midmarket.
Also, Oracle will now have another widely adopted transactional database, the open-source MySQL, that it can--and should--consider tweaking and packaging on an DW appliance. To the extent that Oracle gives customers a choice of DBMSs on a DW appliance platform, it can gain a differentiator that Teradata, IBM, Microsoft, Sybase, and Netezza lack (you have to go to a startup such as Dataupia for multi-DBMS choice on an appliance). Many information managers prefer to stick with their existing DBMSs when building a DW, and prefer to implement that DW on an appliance to take advantage of its out-of-box balanced configuration of CPU, memory, storage, and I/O.
Furthermore, Oracle is acquiring a hardware and operating system vendor that has long been one of the primary platforms on which its own DW/DBMSs, middleware, and tools have been deployed. This acquisition can only be welcome news for joint Oracle-Sun DW customers who have worried about Sun’s solvency for some time now and began to sweat serious bullets when IBM failed to emerge as a white knight. For many Sun customers, an Oracle-powered DW platform will now look like a safer bet than ever.
Of course, there are clear risks in this pending acquisition.
First, a combined Oracle/Sun sows uncertainty among the DW appliance vendors--such as Greenplum and ParAccel--who have partnered with Sun and now find themselves in earnest “co-opetition” with full-competitor (and then some) Oracle.
Second, Oracle’s other DW appliance hardware partners--including HP, IBM, and EMC/Dell--must be concerned that Oracle will now shift focus away from their respective appliance products in favor of those it builds with its own Sun hardware group.
And finally, Oracle’s acquisition of Sun--and possible future development of a MySQL DW appliance--may discourage customers from considering third-party DW appliances, such as from Kickfire--that build on MySQL. If that happens, and a market for non-Oracle-branded MySQL DW appliances never takes root, Oracle will be denying its MySQL customers the choice that Oracle Database customers already enjoy. Currently, Oracle Optimzed Warehouse customers can deploy that enterprise DBMS as a DW on their choice of Sun, HP, IBM, and EMC/Dell platforms.
Let’s hope that Oracle makes the most of its pending Sun acquisition. Ellison either misspoke last fall, or was speaking prophecy. Like most DW vendors, Oracle’s destiny is to grow ever more hardware-dependent for its long-term scalability, performance, and optimization story.
Sunday, April 19, 2009
Sunday, April 12, 2009
poem Falling Sonnet
FALLING SONNET
I
Comedy is all
banana slippage.
Tragedy is trapped
in bodies that are
forever falling,
never quite finding
their footing. Walk a
mile in a clown’s shoes,
you’ll know what Bozo
goes through, but not so
Pozzo. Even an
unlucky bastard
can presume descent
from a long line of
long lines. Too narrow
a furrow to toe.
Sun a midday moon
raking truculence.
The Moon resumes its
tragic flatulence.
Comedy is a
coma. Tragedy
is a crack, a tout
le monde with trembling
hemispherics, a
slippery sole and
a hole daring to
keep us from footing.
II
Comedy is all banana slippage.
Tragedy is trapped in bodies that are
forever falling, never quite finding
their footing. Walk a mile in a clown’s shoes,
you’ll know what Bozo goes through, but not so
Pozzo. Even an unlucky bastard
can presume descent from a long line of
long lines. Too narrow a furrow to toe.
Sun a midday moon raking truculence.
The Moon resumes its tragic flatulence.
Comedy is a coma. Tragedy
is a crack, a tout le monde with trembling
hemispherics, a slippery sole and
a hole daring to keep us from footing.
III
Comedy is all banana slippage.
Tragedy is trapped in bodies that are
forever falling, never quite finding
their footing. Walk a mile in a clown’s shoes,
you’ll know what Bozo goes through, but not so
Pozzo. Even an unlucky bastard
can presume descent from a long line of
long lines. Too narrow a furrow to toe.
Sun a midday moon raking truculence.
The Moon resumes its tragic flatulence.
Comedy is a coma. Tragedy
is a crack, a tout le monde with trembling
hemispherics, a slippery sole and
a hole daring to keep us from footing.
IV
Comedy is all banana slippage. Tragedy is trapped in bodies that are forever falling, never quite finding their footing. Walk a mile in a clown’s shoes, you’ll know what Bozo goes through, but not so Pozzo. Even an unlucky bastard can presume descent from a long line of long lines. Too narrow a furrow to toe. Sun a midday moon raking truculence. The Moon resumes its tragic flatulence. Comedy is a coma. Tragedy is a crack, a tout le monde with trembling hemispherics, a slippery sole and a hole daring to keep us from footing.
I
Comedy is all
banana slippage.
Tragedy is trapped
in bodies that are
forever falling,
never quite finding
their footing. Walk a
mile in a clown’s shoes,
you’ll know what Bozo
goes through, but not so
Pozzo. Even an
unlucky bastard
can presume descent
from a long line of
long lines. Too narrow
a furrow to toe.
Sun a midday moon
raking truculence.
The Moon resumes its
tragic flatulence.
Comedy is a
coma. Tragedy
is a crack, a tout
le monde with trembling
hemispherics, a
slippery sole and
a hole daring to
keep us from footing.
II
Comedy is all banana slippage.
Tragedy is trapped in bodies that are
forever falling, never quite finding
their footing. Walk a mile in a clown’s shoes,
you’ll know what Bozo goes through, but not so
Pozzo. Even an unlucky bastard
can presume descent from a long line of
long lines. Too narrow a furrow to toe.
Sun a midday moon raking truculence.
The Moon resumes its tragic flatulence.
Comedy is a coma. Tragedy
is a crack, a tout le monde with trembling
hemispherics, a slippery sole and
a hole daring to keep us from footing.
III
Comedy is all banana slippage.
Tragedy is trapped in bodies that are
forever falling, never quite finding
their footing. Walk a mile in a clown’s shoes,
you’ll know what Bozo goes through, but not so
Pozzo. Even an unlucky bastard
can presume descent from a long line of
long lines. Too narrow a furrow to toe.
Sun a midday moon raking truculence.
The Moon resumes its tragic flatulence.
Comedy is a coma. Tragedy
is a crack, a tout le monde with trembling
hemispherics, a slippery sole and
a hole daring to keep us from footing.
IV
Comedy is all banana slippage. Tragedy is trapped in bodies that are forever falling, never quite finding their footing. Walk a mile in a clown’s shoes, you’ll know what Bozo goes through, but not so Pozzo. Even an unlucky bastard can presume descent from a long line of long lines. Too narrow a furrow to toe. Sun a midday moon raking truculence. The Moon resumes its tragic flatulence. Comedy is a coma. Tragedy is a crack, a tout le monde with trembling hemispherics, a slippery sole and a hole daring to keep us from footing.
Wednesday, April 08, 2009
FORRESTER blog repost Dislocation Intelligence in a Brutal Economy
Dislocation Intelligence in a Brutal Economy
By James Kobielus
It's painful to see the auto, newspaper, construction, financial services, and so many other formerly vibrant sectors of the world economy go down the proverbial tubes. One of the most nauseating realities is when millions of people lose their jobs, homes, and communities in a seeming blink.
I grew up in the perpetually recessionary Detroit area. I'm attuned to the regional dislocations that come from depending too much on an industry that has seen better days. Abandoned storefronts, dilapidated housing, vacant lots, tumbleweed-quiet city streets--all of it evidence of a growing ghost town, telltale signs of a marginal economy that depends on government programs, private charity, and low-wage service jobs. During my college years, I was a policy analyst with an urban coalition in downtown Detroit, and I could see that the slide was long-term and nigh irreversible.
Even in relatively well-off areas such as Washington DC, where I've spent close to a quarter-century, we’re not immune to serious economic dislocations. The National Capital Region, so reliant on federal spending, is likely to feel the brunt of whatever cuts Obama will almost certainly make to close this massive deficit. And even here you can’t escape dislocations in sectors that we all depend on, such as retailing, as evidenced by, for example, the ex-Circuit City big boxes that seem even bigger and boxier now that they’re totally empty.
In recent years, corporations have adopted location intelligence solutions to support their market-entry strategies, such as adding new stores and waging marketing campaigns. They also use these tools--essentially, geographic information systems coupled with predictive modeling--to optimize their footprint in existing markets. And to a lesser extent, they also use location intelligence to plan their exit strategy of closings and retrenchments. But when departures are hasty--such as any Chapter 11 proceeding--all we’re left with are vast tracts of vacant real estate, plus many formerly employed people who must find a way to survive amid ruins. Imagine how a General Motors or Chrysler bankruptcy will hit Detroit--it will be a liquidation to rival Hurricane Katrina in its devastation of a major city.
Dislocation intelligence is something that the leaders of the auto companies--and the Obama administration--should exercise when making the tough decisions to restructure this critical industry. People’s pain should be factored into decisions to close and relocate plants, so that, for example, whole cities--such as Flint, Toledo, and Janesville--can make a smooth exit from over-reliance on this one industry. As part of that effort, urban planners should consider the infrastructure that remains behind, so that, for example, whole regions of a city are not suddenly deprived of hospitals, grocery stores, and other basic amenities. Imagine you’re on welfare and have to somehow go 10 miles to buy a loaf of bread.
Mapping tools are just tools, not salvation. Detroit long ago passed a point of no return. The US auto industry will never recover the manufacturing jobs that attracted people from all over the world to southern Michigan, northern Ohio, and other regions.
But we as a country should try to smoothe over these economic dislocations so that they don’t completely wipe some places off the map.
By James Kobielus
It's painful to see the auto, newspaper, construction, financial services, and so many other formerly vibrant sectors of the world economy go down the proverbial tubes. One of the most nauseating realities is when millions of people lose their jobs, homes, and communities in a seeming blink.
I grew up in the perpetually recessionary Detroit area. I'm attuned to the regional dislocations that come from depending too much on an industry that has seen better days. Abandoned storefronts, dilapidated housing, vacant lots, tumbleweed-quiet city streets--all of it evidence of a growing ghost town, telltale signs of a marginal economy that depends on government programs, private charity, and low-wage service jobs. During my college years, I was a policy analyst with an urban coalition in downtown Detroit, and I could see that the slide was long-term and nigh irreversible.
Even in relatively well-off areas such as Washington DC, where I've spent close to a quarter-century, we’re not immune to serious economic dislocations. The National Capital Region, so reliant on federal spending, is likely to feel the brunt of whatever cuts Obama will almost certainly make to close this massive deficit. And even here you can’t escape dislocations in sectors that we all depend on, such as retailing, as evidenced by, for example, the ex-Circuit City big boxes that seem even bigger and boxier now that they’re totally empty.
In recent years, corporations have adopted location intelligence solutions to support their market-entry strategies, such as adding new stores and waging marketing campaigns. They also use these tools--essentially, geographic information systems coupled with predictive modeling--to optimize their footprint in existing markets. And to a lesser extent, they also use location intelligence to plan their exit strategy of closings and retrenchments. But when departures are hasty--such as any Chapter 11 proceeding--all we’re left with are vast tracts of vacant real estate, plus many formerly employed people who must find a way to survive amid ruins. Imagine how a General Motors or Chrysler bankruptcy will hit Detroit--it will be a liquidation to rival Hurricane Katrina in its devastation of a major city.
Dislocation intelligence is something that the leaders of the auto companies--and the Obama administration--should exercise when making the tough decisions to restructure this critical industry. People’s pain should be factored into decisions to close and relocate plants, so that, for example, whole cities--such as Flint, Toledo, and Janesville--can make a smooth exit from over-reliance on this one industry. As part of that effort, urban planners should consider the infrastructure that remains behind, so that, for example, whole regions of a city are not suddenly deprived of hospitals, grocery stores, and other basic amenities. Imagine you’re on welfare and have to somehow go 10 miles to buy a loaf of bread.
Mapping tools are just tools, not salvation. Detroit long ago passed a point of no return. The US auto industry will never recover the manufacturing jobs that attracted people from all over the world to southern Michigan, northern Ohio, and other regions.
But we as a country should try to smoothe over these economic dislocations so that they don’t completely wipe some places off the map.
Wednesday, April 01, 2009
FORRESTER blog repost Inmon’s vitriolic slap at “virtual data warehousing” does not withstand scrutiny
Inmon’s vitriolic slap at “virtual data warehousing” does not withstand scrutiny
By James Kobielus
In a recent article, Bill Inmon incinerates a strawman concept that he refers to as “virtual data warehousing (DW).” For those unfamiliar with Inmon, he is generally considered the founder of DW as a data management discipline, has been at it since the 70s, and has more published books and articles to his name than most mortals. So he clearly may be considered an authority on the topic of DW.
But methinks Mr. Inmon doth protest too much on this “virtual DW” bugaboo, however defined (we’ll get to that in a moment). Also, he attacks this concocted notion with such emotional vehemence that it’s clear he considers it a threat to the centralized EDW paradigm upon which he has built his career and reputation.
For starters, his definition of this concept is oddly vague and questionably narrow: “a virtual data warehouse occurs when a query runs around to a lot of databases and does a distributed query.” Essentially, Inmon defines “virtual DW” as the ability to a) farm out a query to be serviced in parallel by two or more distributed databases, b) aggregate and join results from those databases, and c) deliver a unified result set to the requester.
That’s an important query pattern, but not the only one that should be supported under (pick your quasi-synonym) data federation, data virtualization, or enterprise information integration (EII) architectures. Inmon’s definition excludes the many federated queries that may only hit on a single database, with no joins and results aggregation, and with the EII fabric handling the necessary on-demand transformation from that source’s schema to an abstract semantic model.
Per my data federation report from last fall, Forrester has a broader perspective on the topic than does Mr. Inmon. Data federation is any on-demand approach that queries information objects from one or more sources; applies various integration functions to the results; maps the results to a source-agnostic semantic-abstraction model; and delivers the results to requesters. Nothing in the scoping of data federation necessarily requires the multi-source aggregation and joining that Inmon puts at the heart of “virtual DW.”
Putting Inmon’s narrow scoping of “virtual DW” behind us for the moment, let’s consider his chief objections to this approach. First, it requires the “analyst to integrate data” (as if that’s something analysts are ill-suited for or regard as some inordinate burden). Second, it consumes resources, experiences suboptimal performance, and “shuffles a lot of data around the system that otherwise would not need to be moved” (as if centralized DWs don’t consume resources, experience performance bottlenecks, and move data). Third, it is “limited to the [historical] data found in the [source] databases.” Fourth, it suffers from “no reconcilability of data...[hence] no single version of the truth for the corporation.”
It’s a fairly straightforward matter to dispatch these objections:
First, data integration--through ETL, EII, and other approaches--is a core job function for DW professionals, not some alien function outside their core competency.
Second, data federation is often the optimal approach for low-latency BI (just check out the case studies in my data federation and really urgent analytics reports). Federated environments can be tuned to provide top-notch performance and minimize source-system impacts when “shuffling” data around in a decentralized fabric.
Third, the source databases in a federation environment often include DWs, which, per their core function, usually manage a considerable amount of historical data. Once again, see my data federation report with discussion of case studies for a) Federation of Local DWs via Centralized EII Infrastructure and b) Federation of Dispersed EDW and ODS Data Into Siloed BI Environments.
Fourth, data federation is not totally incompatible with data reconciliation. In fact, federation environments can be architected for single version of the truth, data governance, and master data management. However, it can indeed be tricky to manage data quality in federated environments (see Rob Karel’s coverage of MDM and DQ for a deep dive on that issue).
My basic objection to Inmon’s line of discussion is that he treats data federation as mutually exclusive from the enterprise DW (EDW), when in fact they are highly complementary approaches, not just in theory but in real-world deployments. Yes, data federation can be deployed as an alternative to traditional EDWs, providing direct interactive access to online transactional processing (OLTP) data stores. However, data federation can also coexist with, extend, virtualize, and enrich EDWs, as well as other data-persistence nodes such operational data stores (ODS) and online analytical processing (OLAP) data marts. The case studies in the cited reports bear that out.
Inmon’s arguments are worth consideration. The centralized EDW model he touts is useful for illuminating some traditional best practices. But by no means can it do justice to the stubbornly heterogeneous, distributed, mixed-latency BI and DW requirements of most enterprises.
By James Kobielus
In a recent article, Bill Inmon incinerates a strawman concept that he refers to as “virtual data warehousing (DW).” For those unfamiliar with Inmon, he is generally considered the founder of DW as a data management discipline, has been at it since the 70s, and has more published books and articles to his name than most mortals. So he clearly may be considered an authority on the topic of DW.
But methinks Mr. Inmon doth protest too much on this “virtual DW” bugaboo, however defined (we’ll get to that in a moment). Also, he attacks this concocted notion with such emotional vehemence that it’s clear he considers it a threat to the centralized EDW paradigm upon which he has built his career and reputation.
For starters, his definition of this concept is oddly vague and questionably narrow: “a virtual data warehouse occurs when a query runs around to a lot of databases and does a distributed query.” Essentially, Inmon defines “virtual DW” as the ability to a) farm out a query to be serviced in parallel by two or more distributed databases, b) aggregate and join results from those databases, and c) deliver a unified result set to the requester.
That’s an important query pattern, but not the only one that should be supported under (pick your quasi-synonym) data federation, data virtualization, or enterprise information integration (EII) architectures. Inmon’s definition excludes the many federated queries that may only hit on a single database, with no joins and results aggregation, and with the EII fabric handling the necessary on-demand transformation from that source’s schema to an abstract semantic model.
Per my data federation report from last fall, Forrester has a broader perspective on the topic than does Mr. Inmon. Data federation is any on-demand approach that queries information objects from one or more sources; applies various integration functions to the results; maps the results to a source-agnostic semantic-abstraction model; and delivers the results to requesters. Nothing in the scoping of data federation necessarily requires the multi-source aggregation and joining that Inmon puts at the heart of “virtual DW.”
Putting Inmon’s narrow scoping of “virtual DW” behind us for the moment, let’s consider his chief objections to this approach. First, it requires the “analyst to integrate data” (as if that’s something analysts are ill-suited for or regard as some inordinate burden). Second, it consumes resources, experiences suboptimal performance, and “shuffles a lot of data around the system that otherwise would not need to be moved” (as if centralized DWs don’t consume resources, experience performance bottlenecks, and move data). Third, it is “limited to the [historical] data found in the [source] databases.” Fourth, it suffers from “no reconcilability of data...[hence] no single version of the truth for the corporation.”
It’s a fairly straightforward matter to dispatch these objections:
First, data integration--through ETL, EII, and other approaches--is a core job function for DW professionals, not some alien function outside their core competency.
Second, data federation is often the optimal approach for low-latency BI (just check out the case studies in my data federation and really urgent analytics reports). Federated environments can be tuned to provide top-notch performance and minimize source-system impacts when “shuffling” data around in a decentralized fabric.
Third, the source databases in a federation environment often include DWs, which, per their core function, usually manage a considerable amount of historical data. Once again, see my data federation report with discussion of case studies for a) Federation of Local DWs via Centralized EII Infrastructure and b) Federation of Dispersed EDW and ODS Data Into Siloed BI Environments.
Fourth, data federation is not totally incompatible with data reconciliation. In fact, federation environments can be architected for single version of the truth, data governance, and master data management. However, it can indeed be tricky to manage data quality in federated environments (see Rob Karel’s coverage of MDM and DQ for a deep dive on that issue).
My basic objection to Inmon’s line of discussion is that he treats data federation as mutually exclusive from the enterprise DW (EDW), when in fact they are highly complementary approaches, not just in theory but in real-world deployments. Yes, data federation can be deployed as an alternative to traditional EDWs, providing direct interactive access to online transactional processing (OLTP) data stores. However, data federation can also coexist with, extend, virtualize, and enrich EDWs, as well as other data-persistence nodes such operational data stores (ODS) and online analytical processing (OLAP) data marts. The case studies in the cited reports bear that out.
Inmon’s arguments are worth consideration. The centralized EDW model he touts is useful for illuminating some traditional best practices. But by no means can it do justice to the stubbornly heterogeneous, distributed, mixed-latency BI and DW requirements of most enterprises.
Subscribe to:
Posts (Atom)
