IBI-072-The Data Warehouse Blues - A History
There are good reasons why the data warehousing industry has such a bad reputation...
Hello and Welcome.
I am Esther.
I am Peters A I Assistant to create voice overs.
I will simply read Peters blog posts, so that you have a choice of reading the blog post, or listening to my voice.
Hello and welcome Gentlemen.
As I have recently announced on my channel.
I will be doing some opinion pieces and response videos.
In this blog post I wanted to talk about an excellent blog post my friend Bill Inmon recently released.
I want to use it as a starting point to talk about the current issues in the world of data warehousing.
Firstly, I highly recommend you read Bill’s blog post.
You can read it on the button below.
Now.
For those of you who chose not to read Bills post?
Please allow me to quote the most important pieces.
Quote.
“Just this week I had a conversation that I wish I would not have had. A gentleman started talking about the failure that data warehouse was and that no one wanted to build one. He said that talk about data warehouse was forbidden and that a mention of data warehousing in IT circles was a case for being ridiculed.
How did this happen, because none of that is true.
Here’s how it happened in many places. The marketing organization found that it needed enterprise data in order to see what was going on in the corporation. The corporation had a bunch of applications but no enterprise data. The marketing organization discovered data warehouse and thought that was a good idea.
The I T department was called in but had no expertise so a consulting firm or a vendor was brought in to build the data warehouse. The consulting firm or the vendor knew some buzz words but had no real understanding of what a data warehouse was. But I T had done work with the consulting firm or vendor before. I T felt that the consultant just had to know what he/she was doing.
The consulting firm built something for the client, but it wasn’t a data warehouse. When the project failed, data warehouse got the blame. The I T department could say – we tried data warehousing but it doesn’t work.
The truth is that the organization never built a data warehouse. Inevitably the missing ingredient was the integration of the application data into an enterprise format. Integration of application data requires hard work, thinking and managing tedium – all the things vendors and consulting firms hate. So the consulting firms just decided to ignore the need for integration and build something that remotely resembled a data warehouse.
And a data warehouse without integration – integrity of data – is not a data warehouse. I don’t know what it is but I know it is not a data warehouse.
Integration of data is the essence of data warehousing.
Yet data warehousing gets to be blamed when consultants and vendors ignore it.
The problem is that consultants don’t know what a data warehouse is and I T management is not sophisticated enough to know the difference.”
End quote.
For those of you who do not know.
We have been having this discussion since the early nineties.
Indeed one of the key predecessors of the I B M Information Warehouse was under development in the late nineteen eighties in Toronto. It was called the Query Business Information System. Also known as Q B I S.
In the early nineties it was very expensive to get data out of large operational systems and in to D B 2 which is what I B M was pushing in the early nineties.
The E T L systems were written in cobol and the storage for the working files was on tapes.
So when it came to data integration as Bill is talking about it was expensive.
This expense made the data warehouse harder to get budgets for because the return on investment was considered so risky.
The proposal to the business was that if business users could answer their own questions then you would make more profit in the company.
But since business users could not ask questions for themselves there was no track record that the data warehouse would generate the return on investment that was proposed.
Meanwhile, automating existing business processes to reduce the cost of those processes gave a very well understood return on investment.
So in the early nineties it was all but impossible to sell data warehousing.
I failed in sale after sale.
Teradata got some of the sales I tried to make.
I R I Express got other sales I tried to make.
Most of these sales and projects that I lost to other vendors also went very poorly and did not return their promised return on investment.
In the nineteen ninety two until nineteen ninety six period I lost so many deals it was heart breaking.
I finally had my break through in nineteen ninety seven.
I sold more than ten million U S dollars worth of deals in nineteen ninety seven.
Unfortunately one of them was cancelled due to internal issues in the customer.
Another one went poorly because I was excluded from the project as part of the politics of Hitachi Data Systems.
In nineteen ninety eight I sold the Telstra telco Corporate Data Warehouse project.
Another project that went poorly because of the politics of Price Waterhouse Coopers.
By the time I got to Ardent in early nineteen ninety nine I had a new idea for making sales forming in my mind.
That new idea was this.
By early nineteen ninety nine in Australia the I T landscape was awash with failed data warehousing projects.
So I hit on the idea that I would stop wasting my time trying to sell new projects to new customers who were doing data warehousing for the first time.
I hit on the idea that I would only engage in serious sales cycles with large companies who had the following profile.
One.
They had tried twice to implement a data warehouse.
Two.
They had spent more than two years trying to implement a data warehouse.
Three.
They had spent at least one million Australian dollars failing to implement their data warehouse.
You may not believe this but when I looked hard I found more than twenty companies in Australia that fit that profile.
I went and talked to all of them in my new position as the Professional Services Manager of the largest data warehouse development team in Australia at Ardent.
This included the team from the company that sold Bills Software in Australia.
The sales pitch was kept simple.
I told our prospects the following things.
One.
We are the best people in the country at data warehousing.
Two.
If you hire my team I will personally guarantee your return on your investment as long as you take my advice.
In the cases where I could not personally guarantee the return on investment I told the client that I could not guarantee the return on investment.
In those cases I told the client my personal level of confidence in our likelihood of getting the return on investment.
My prospects were shocked to have a salesman give an honest appraisal of the likely return on investment given his experience.
Three.
I told my prospects that we were easily the most expensive people in the country on an hourly basis and just as easily the cheapest people in the country when measured based on return on investment.
I went into these meetings so confident that we had a very compelling sales pitch.
Guess what?
We won a lot of those deals.
In nineteen ninety nine I did one hundred and thirty percent of my quota.
We also kicked I B M and the tool they were selling called E T I out of Telstra which was our telco and out of Qantas which was our airline. Those were the only two sites I B M had for the E T I tool they were selling.
At the same time Informatica was only able to sell two licenses and the two licenses they sold were to my prior two employers, Hitachi and Price Waterhouse Coopers.
Those two companies bought those two licenses because they did not want me around their customers.
So, effectively, by the time Informix bought Ardent, in Australia Data Stage was the dominant E T L software with fifty installed accounts.
And I was one of the great sales team that helped make Data Stage so successful in Australia.
So it would be reasonable for you to wonder.
One.
Why were there so many failing projects in Australia and around the world?
Two.
Why were we successful so often?
Firstly, let us deal with why so many data warehouse projects failed back in those years.
This is useful because they are failing for the same reasons now.
In most companies when you try and do something you have never done before in the I T world you give that job to your own internal I T department on the basis that they will find out how to do the job themselves and not have to send money to expensive consultants.
These internal I T people then read some books or today read some blog posts and watch some videos and then launch into the project with about five percent of the knowledge required to do it.
These data warehouses built by internal I T people almost always fail for the very reason they have no idea what they are doing.
So the next step is to hire one individual consultant who has some relevant experience who can implement the data warehouse and train the internal I T people how to support it.
That is the role I played when I started my first company in nineteen ninety four.
This sort of project still fails about eighty percent of the time because that one external consultant usually lies about his experience and since the internal I T people do not know how to spot those lies they hire the man and the project fails.
After all that?
Then the company might just hire external consultants that know what they are doing and have a track record to prove it. But they won’t hire such consultants up front because they can’t justify the expense over and above the first two methods.
Pretty much the first two methods have to fail before a large company will hire expensive consultants to do the job properly.
That is how it was in Australia.
That is how it is in most of the western world.
It is certainly how it is in most of the English speaking world.
If the internal I T people say they can build a data warehouse?
Then the business can not hire external consultants until after the internal I T people fail.
Usually they have to fail twice before the business will win the argument with the Chief Financial Officer to spend the big money to hire the best people.
All during this process the vendors of hardware and software get paid regardless of the success or failure of the project.
They push the business to buy the cheapest implementation methods so more money is left in the budget to buy their products.
The vendors have a financial motive to lie and to present shot cuts that will get their products sold.
I remember in the mid nineteen nineties companies started selling the ninety day data warehouse.
At that time this was completely ridiculous but a lot of companies bought it.
Indeed, my first E T L software was actually called the Instant Data Warehouse because it was so much faster than prior efforts.
But Instant it was not. That’s marketing. You have to do it.
The key problem in the nineties is the same key problem companies face today.
What is the likely return on investment for this thing called a Data Warehouse?
What is the probability we will get that return on investment?
Because the probability of getting the return on investment is variable and then the actual return on investment is variable.
And because the landscape is littered with failed projects.
It is more than reasonable for the Chief Financial Officers of these companies to take the position they will release only a small budget for a pilot project and that the pilot project has to prove the return on investment before the whole budget for the project is released.
It is also more than reasonable that the Chief Financial Officer will insist that the project be done as economically as possible with the view that if the return on investment is achieved then the project budget can be later increased for version two point oh.
The only problem is that if you build your data warehouse on the cheap they are very expensive to redo or extend to do properly.
So all this has led to the recipe that early iterations of data warehouses either fail entirely and do not even make it to production.
Or what is delivered to production in the one point oh version is so bad that it dies a death of non use and everyone talks about how data warehousing does not work.
Meanwhile.
For those of us who have done data warehousing properly?
Our customers make lots of new profit in a sustainable fashion avoiding the mistake of cost cutting for near term profit that harms long term growth.
Over the years people like Bill, Ralph, myself and many others wrote papers on the issues that cause failure in data warehousing projects.
Eventually I decided to turn that around and I did a series of blog posts about how to guarantee success of data warehousing projects.
In my own opinion, one of the great shames of our industry segment is that I was woke cancelled in two thousand and ten just as Sean Kelly and I were making a lot of headway in lowering the cost of data warehousing and increasing the reliability of the return on investment.
In this video shot in two thousand and ten you can see Sean Kelly and Brian Ganley talking about our two thousand and nine delivery of our new version of our telco data warehouse.
We were able to deliver the whole data warehouse for under four hundred thousand pounds in services start to finish.
We charged one hundred thousand euros for our data models.
We charged three hundred thousand pounds for our consulting services.
We even gave car phone warehouse what we called a variable capped price offer.
Our original proposal was for five hundred thousand pounds as a fixed price.
However we said that we would charge a daily rate and if we came in under the budget they kept the money.
We said that if we came in over the budget we would eat any over run.
In the end we came in one hundred and fifty thousand pounds under our original budget.
They were so pleased with this that they kept me on to do related work that was planned to go to another vendor.
One hundred thousand pounds of our revenue from that project came from work that we did not bid on.
We gave them my E T L software for free because they were an informatica account and had to go live on Informatica.
The project from day one arrival to in production was eight months.
I arrived early September two thousand and eight and we went live on the easter weekend two thousand and nine.
We mapped the billing system, their customer relationship management system and their network management system.
We took ALL the fields from ALL these three systems and put them into the dimensional data warehouse on a Netezza machine.
All the E T L was done in S Q L on the Netezza machine.
Informatica was pretty much just a scheduler of S Q L statements in the end.
At that time, two thousand and nine, delivering such a comprehensive data warehouse for under three hundred thousand pounds in services was unheard of.
This was exactly why we were hired to deliver the Sky Talk data warehouse right afterwards.
Having delivered both the car phone warehouse and sky talk data warehouse in consecutive years in partnership with Netezza we were talking to all the big telcos in Europe in two thousand and ten.
Then I was woke cancelled in late two thousand and ten.
Our industry did itself the dis-service of ignoring the massive improvements Sean Kelly and I had been able to make.
Our industry segment then continued to have projects that crashed and burned and failed to deliver the promised return on investment.
And as Bill notes this is now reflected in the common perception that data warehousing does not work.
And as Bill notes much of what has been done is not data warehousing but data warehousing got the blame in the end.
As I mentioned above.
People wrote a lot of articles about why these projects fail.
Ten years ago I decided to write a suite of blog posts to talk about how to make these projects successful.
You can listen to these blog posts on the videos below.
Sadly, the young men in our industry segment chose not to listen to these blog posts and they kept delivering projects that failed.
Now they have to live with that reputation for business failure for the rest of their lives.
Today I can go out on to the internet and ask so called data warehousing experts the following question.
How much would you charge to build a complete data warehouse for a telephone company with 4 million subscribers?
The answer I would get is this.
Well it depends.
I would have to closely analyse all the data that you want to put into the data warehouse and then give you an estimate.
But if I run over the estimate you will have to pay me extra.
And you can be pretty sure that the starting point is around six hundred thousand dollars and that the time frame is around one year.
My answer will be.
I will charge you one hundred thousand euros as a fixed price.
For that price I can guarantee that you will get a very large return on your investment.
I guarantee that the project will be done in less than six months.
I guarantee that fee will get you into production with two months of production support.
Then if you want to buy your ongoing production support from me after two months that will be extra.
Which of those two offers sounds like the man making it knows what he is doing?
I was making fixed price data warehousing offers as early as nineteen ninety six.
How could I make fixed price offers for a style of project that so commonly fails?
Because I had my own E T L software.
That’s how.
And after I went to work for Sean Kelly in two thousand and one we had our own data models called the Sybase Industry Warehouse Studio data models.
If you talk to so called Data Experts today about how they do projects?
They still start with a blank piece of paper for the data model.
Having a suite of data models to start with is still not standard today and we had it as a standard in Sybase twenty five years ago.
This is one more reason why our industry segment is a joke.
If I wanted to, I could go through a very long list of failed projects where the company selecting the vendor to implement the data warehouse made such poor decisions it was just crazy.
Please allow me to give you just three examples.
The best example I have of a major global company buying a data warehouse deal they should never have bought was Vodafone in Ghana in two thousand and eleven.
In two thousand and eleven Vodafone was one of the world’s leading mobile phone companies.
Vodafone Ghana spent two million dollars over a year with a vendor on a data warehousing project that was a complete failure.
When the vendor was removed and I went over their project deliverables there was not a single thing that they had produced that was worth keeping.
Not one document of any value was created out of that one million dollars spent.
The chief information officer gave me a copy of the tender response and asked me to please review it and tell me if there were any obvious signs that the vendor did not know what they were doing.
Right in front of him I opened the tender document to the project plan page and looked at it.
Vodafone Ghana had four billing systems because of the history of the acquisitions of the company.
Vodafone Ghana also bought the Telecom Ghana land line government telco.
In the project plan the task for E T L development was eight weeks.
I told him that eight weeks in the project plan for the development of E T L for four telco billing systems demonstrates that the vendor had no clue what they were doing.
I told him that even if I did that work, with my software, the fastest possible time it could be completed in was six months and the most likely possible time it would be completed in was eight months.
I told him that without needing to see the billing systems because I know what is inside telco billing systems.
I told him that anyone who had any experience in telco data warehousing would know that the most likely time period for the writing of the E T L was eight months, not eight weeks.
I told him that if his company had sent me the tender to review prior to purchase?
Then I would have told his company not to buy from this tender for free.
This was because I would rather do the 2 minutes work for free than to have another failed data warehousing project giving me and my segment a bad name.
In fact, I have often publicly said the following.
If any company who is considering buying a data warehouse development project would like me to review their final selection and to provide them my opinion of their selection?
Then I would be happy to do that for free to do my bit to stop the snake oil salesmen selling bad deals.
However, large companies will not even take me up on that free offer.
I can’t do any more than make the free offer of reviewing data warehousing proposals and telling customers if they should not buy the offer because it indicates lack of ability on behalf of the consultants making the proposal.
Here is a second one that is all too common.
The worst data warehouse purchase decision I have ever seen in my life was Telecom New Zealand buying a Teradata machine back in nineteen ninety two.
Telecom New Zealand used A S four hundreds for their billing system because they were so small as a telco.
The managing director of I B M New Zealand was on the board of Telecom New Zealand.
Teradata had made an offer to Telecom New Zealand.
This offer was unknown to me at the time.
I came into my I B M office in Sydney one morning in early nineteen ninety two.
There was an email from the secretary of the I B M New Zealand Managing Director in my in box.
She told me that the Managing Director wanted to see me in his office later that day.
My ticket from Sydney to Wellington could be picked up at the airport.
She had also faxed over copies of the technical specifications they could get for the Teradata machine being proposed.
So I went to the airport in a Taxi.
I picked up my ticket and I flew from Sydney to Wellington.
Such short notice trips were not that uncommon for me across my career.
I read the documentation provided on the way over.
I was in the Managing Directors office by 6 o’clock that night.
He asked me if the proposal would work.
I said no. It can’t work.
I explained the reason was the Teradata interface cards were designed to connect to I B M main frame computers.
They were not designed to connect to A S four hundreds.
I explained that the technical documentation provided by Teradata meant that to transfer one days worth of call data would take thirty six hours.
I explained that they had done their best to hide the slow transfer speeds of A S four hundreds deep down in their technical specifications.
But since I knew that connecting to A S four hundreds was a problem I knew to look for that information.
I told him it did not matter how large the Teradata machine was because the number of interface cards was limited.
He got his own people to verify what I was saying and they were shocked that they missed it.
I was only a second year Systems Engineer at that time so the Managing Director was pretty impressed.
The next day he went to the board meeting where the purchase decision would be made.
As a board member he said he had important information pertinent to the purchase decision and he would like to present it.
He asked his fellow board members if they were willing to listen to this information.
The board voted no.
They did not want to hear the opinion of the Managing Director of I B M New Zealand about a five million U S dollar purchase.
Please remember this was a government owned institution and this was tax payer money being spent.
At that time Telecom New Zealand was not a private company.
The money for the Teradata machine would be paid for with tax payer money and call costs to New Zealanders via a monopoly.
The refusal of the board to listen to the advice of the Managing Director of I B M New Zealand also had political implications for the government.
The Teradata machine was duly delivered and did not work.
Teradata convinced Telecom New Zealand that they needed to upgrade the machine and double it’s size to get it to work.
Telecom New Zealand bought that upgrade too.
Finally, a year later, Telecom New Zealand asked I B M for a proposal to replace the Teradata machine and project with a small I B M Main frame running D B 2.
I went over and worked on the proposal in mid nineteen ninety three.
When the proposal was presented Telecom New Zealand said they would buy the proposal if I B M bought back the Teradata machine at cost so that they could off load the failed machine.
The reason they wanted to do this was to avoid any political fallout if the failed purchase decision ever came out.
They wanted the purchase decision of the Teradata machine to be swept under the rug so to speak.
Of course, the I B M Managing Director reminded Telecom New Zealand that they had refused to even listen to him a year earlier.
He said he would not buy the Teradata Machine for even one dollar let alone ten million dollars.
In the end the purchase decision and the waste of ten million dollars came out and it was quite the political scandal.
A couple of years later the Teradata salesman for that deal was in Sydney.
I invited him to lunch just to meet him and say hello.
I asked him if he knew the machine he was selling to Telecom New Zealand would never work.
He said that of course he did.
I asked him why he sold a five million U S dollar machine when he knew it would not work.
He laughed and simply said.
Quote.
Peter, I got my commission.
End quote.
This is the attitude of most salesmen in most technology companies.
As long as they get their commission what happens on the deal is none of their concern.
In late nineteen ninety three the fifth largest bank in Australia called Saint George Bank was considering buying a Teradata Machine.
I got the Managing Director of I B M New Zealand to ask the Chief Information Officer of Telecom New Zealand if he would please take a call from the Chief Information Officer of Saint George Bank.
I wanted the Chief Information Officer of Telecom New Zealand to please tell the Chief Information Officer of Saint George Bank what had happened on that project.
The Chief Information Officer of Telecom New Zealand said no.
He would not take the call.
He said that the official position of Telecom New Zealand is that they would not provide any information about such a badly failed project to anyone for any reason.
The Saint George Bank duly purchased the Teradata machine only to go through the very expensive upgrades to try and get it to work.
Three years later, in nineteen ninety six, I did a call on the manager responsible for the Teradata project at Saint George Bank.
He was unhappy with how the project had gone.
I reminded him that I was the I B M employee who tried to sell them our D B 2 solution and they chose Teradata over my proposal.
He actually said to me and I quote.
But your proposal did not store the detailed banking transactions so we could not buy it.
I replied.
That is not true.
We had all the detailed banking transactions in our prototype and everyone in the evaluation team knows that.
He looked stunned.
He said he had been told our proposal did not support detailed transactions and that we only had summary data in our prototype.
I reminded him I wrote the code and I put the detailed transactions into the data warehouse myself.
All three million rows of them at the time.
I told him that who ever told him that the I B M proposal did not contain the detailed transactions lied to him.
He thanked me for telling him this.
He later emailed me and told me that he had spoken to people who were on the evaluation team and they all confirmed what I had said.
He told me that he had gone back and dug up the Teradata presentation for the sales pitch and on that presentation it said that the I B M proposal did not contain the detailed level transactions.
I told him this was situation normal for Teradata.
So he invited me back out for a second meeting to discuss whether I could help the bank migrate to a better solution.
At that time I was independent and I introduced an old friend of mine who now worked at Sun to this manager and said that Sun and Oracle would be a good fit.
A little while later I started working at Hitachi where we were selling Sequent hardware and I went back and said that now I represent Hitachi we would also be interested in presenting Sequent versus Sun with Oracle still being the database.
Both Sun and Sequent gave Saint George Bank rough estimates of the costs to migrate the now Teradata data warehouse to their hardware.
In the end Saint George Bank took the position of it’s better the devil you know than the devil you don’t know.
But here was another clear case where a vendor lied on a proposal presentation and yet the company still bought the product they were selling.
When you are willing to buy from a salesman you know is lying to you then you can hardly complain when the project goes poorly.
I will add this comment here.
The official policy of I B M was that no I B M employee was ever to disparage any competitor.
As part of our training we were taught that if we ever criticised a competitor in any way, shape, or form, we would lose our job.
There would be no discussion.
If we were found guilty by an internal H R investigation that we had criticised a competitor we would be fired.
During this sales process to Saint George Bank I took the evaluation team to my customer the Mutual Life Company.
The Mutual Life Company had evaluated Teradata two years prior when making the decision to buy the system I was working on.
They decided against Teradata.
The reason was that they were offered a proposal of a Teradata machine that was being sold as new and at new pricing.
The Mutual Life Company gave us the serial number of the Teradata machine.
The machine had previously been installed in the data center of an I B M customer.
In I B M we routinely took photographs of the serial numbers of competitive machines in our customers data centers.
This was because it was so common for them to be removed and then sold as new to unsuspecting buyers.
When we were given the serial number of the proposed Teradata machine we found it listed as having been installed at one of our customers.
We gave copies of those photographs to the Mutual Life Company.
This all had to go through our I B M legal department to make sure no rules were broken.
The Mutual Life Company had the Teradata salesman come in and he was asked to please explain these photographs.
The salesman pretended that he did not know the history of the machine thereby compounding the lie.
The Mutual Life Company had a standing policy that it did not buy products or services from any company where the salesman could be proven to have lied during the sales process.
My customer had gotten permission from his legal department to explain all this to the people from Saint George Bank evaluating the purchase of the Teradata machine.
I did not say any of this as it was nothing to do with me or I B M.
Unfortunately, one of those evaluators from Saint George Bank made the false allegation to the I B M salesman for the bank that I had made those comments.
I then had to defend myself in an internal inquiry from I B M Human Resources from these false allegations.
This is the sort of thing that was going on more than thirty years ago.
It has only gotten worse.
The snake oil salesmen have been getting away with lying because the customers they lie to are not willing to tell other prospects of the snake oil salesmen that the snake oil salesman is lying.
Where men are honest men of honour and integrity and they warn their peers that they are considering buying something from a snake oil salesmen?
Even the people they are trying to help will cause problems for the honest men of honour and integrity by lying about them.
For my entire life in marketing in the computing industry people have provided more support for the snake oil salesmen, the liars and the grifters, than they have for the honest men of honour and integrity like me.
The state of our industry reflects this more than thirty years of support for the snake oil salesmen.
The single most important action men in our industry segment could take to improve the reputation of the men in it is to support the honest men of honour and integrity in our industry segment like Bill Inmon and myself.
The second most important action men in our industry segment could take to improve the reputation of the men in it is to name and shame the snake oil salesmen in our industry segment.
I am quite happy to do that because my income stream is no longer able to be affected by lies told by liars.
I have been getting lied about in public since two thousand and ten so my income earning ability was destroyed back then.
I have since been able to create a small income stream that is not able to be destroyed by liars lying about me.
It would be nice if other men hired me to increase that income stream since I am now sixty two years old and in debt because I am an honest man of honour and integrity.
Sadly, I don’t think men in my industry segment will ever support the few honest men of honour and integrity there are in our industry.
I sincerely hope I am wrong on that point.
But I don’t think so.
In any case.
Moving forward.
While I have been woke cancelled I have not been idle.
I have invented the future of data warehousing.
We now have E T L development times in excess of twelve thousand fields mapped from source to target in one two hundred and twenty hour work month.
We now have the ability to have one suite of E T L for multiple customers of the same large operational system in the cloud.
This has brought down the costs of data warehouse development more than eighty percent over what it was when we did car phone warehouse in two thousand and nine.
We even have a mechanism for having just one suite of E T L without any customer data cohabiting with any other customer data in the one physical table.
Of course if the customers will allow their data to co habit in the same table and to implement security in views then the cost of that implementation is lower because there is only one set of tables for N customers.
If the customers insist on no cohabitation of data inside the same table then you need N sets of tables and indexes for the N customers which takes time and costs money to manage.
Even so having N sets of tables for N customers is far cheaper than having N copies of the E T L system to maintain.
Now that I am sixty two and I have the lovely opportunity to simply work from my nice apartment in Fiji?
I am hopeful that those men who are smart enough to understand what I am talking about will pick up on these new ideas and adopt them for their businesses.
Maybe they will and maybe they won’t.
In the end?
If the next generation of the smartest data warehouse architects do not pick up on these ideas I have put out into the public for data warehousing done properly?
Our industry segment will have the same bad reputation in twenty fifty as it has now.
I think that would be a shame given that the projects I and many others implemented delivered so much value to our customers.
Today it is really up to those smart young men coming through to decide for themselves if they will take my advice and adopt my ideas to make their data warehousing companies more successful.
We will see what they do.
And with that?
I hope you found this blog post interesting and informative.
Thank you very much for your time and attention.
I really appreciate that.
Best Regards.
Esther.
Peters A I Assistant.