In my last post I talked about the Pros and Cons of patents (admittedly more about the Cons). Now I just received the following link: http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0003Y1&topic_id=1 . Microsoft surprisingly filed a patent application for a technology called micro charts (also known as Sparklines). From my understanding there is a lot of prior art that stands against such a patent. I hope the USPTO will acknowledge this.
Archive for the 'Palo Use Cases' Category
Today’s computer games deliver 3D video sequences in photorealistic quality. To do this in real-time, the hardware industry developed high-end graphical processing units, also called GPU. A GPU has unbelievable processing power. Instead of 2, 4 or 8 processor cores as known from the traditional Intel/AMD CPU the GPU uses an arrays of hundreds of parallel floating point processors to compute images in their internal graphics memory.
What value does this bring to finance people? The answer is simple: When doing analysis, planning, budgeting, forecasting, scenarios or reporting a lot of number crunching happens, especially if you are looking at aggregated and multidimensional OLAP data models as we usually do in Business Intelligence or Corporate Performance Management. Number crunching consumes enormous processing power. The number one complaint about BI and CPM software is slow query performance, as BI and OLAP Analyst Nigel Pendse points outs.
So our Palo researchers had a look at the GPU hardware architecture and discovered that GPUs are the perfect hardware accelerator for in-memory OLAP server like Palo. They expect a performance increase by a factor of 20 (not 20%) at least. This would be a performance breakthrough that has never been seen before in the BI industry. The reason why this works so well is the fact that Palo uses an in-memory technology. Since today’s GPUs have 4 GB of Graphic memory it is possible to load the entire cube directly in the GPU RAM. So there is no bottle neck like disk IO etc. that would decrease the GPU power.
And it gets even better: We just had the GPU Technology Conference in San Jose. There NVDIA announced the Fermi Architecture. This new GPU technology is due in 2010 and will again increase the processing power by the factor of 5 (against today’s Tesla technology).
And by the way: Did I tell you that you can combine GPUs? Here at Jedox we run TESLA hardware with 4 parallel GPUs and 16 GB RAM in one server and it still scales almost linear. So this makes 20 x 4 x 5 = 400. A query that took 40 seconds to calculate on a CPU will be done in 0,1 seconds with GPU. Theoretically of course. Results in practice will be seen on CeBIT 2010.
You’ve probably heard the shortest joke in the IT industry. It goes like this: “I’m almost done”.
When doing BI and Performance Management projects with our clients, we occasionally have the same problem. Projects take longer than we (or our client) anticipated and there is a variety of possible reasons: technical problems with the software or installation, data quality problems on the ETL side, or incomplete requirement specifications. Or different role perception: We see ourselves as coaches for the Palo-BI Suite and we expect the customer to do part of the work, especially at later phases of the project, while the customer expects to be handed over a 100% completed project.
20 years ago, to cope with this and similar types of issues, my brother Peter (former CEO and founder of MIS AG who unfortunately died in a car accident in 2004) came up with a surprisingly easy formula to calculate realistic project duration (both for internal software development projects as well as consulting projects with clients). Simply take the gut feeling of the developer or the consultant and multiply the number of days or weeks that he thinks are realistic with pi (3,1415). In other words, if somebody thinks 10 days are realistic, the project will most probably take 31,5 days.
20 years after Peter had told me about this rule, I finally had a look at the theory behind it. In my opinion it goes like this: If a person takes an educated guess about how long it will take, he will automatically just see the work to get 80% or 90% of the desired functionality done. He simply neglects the 10% to 20% percent that is needed to make the product or the project 100% perfect. But how long will it take to complete these 10%-20%? Very long as you can see in the following drawing which shows a typical curve based on the Pareto principle (80/20 rule). Doing between 80% to 90% of the work will only take you around a third of the total effort (MD gf stands for man days estimated using gut feeling)
So if you only look at 80% to 90% of the total functionality you will come to the conclusion that the project will only take you 33% of the time it actually really would if you look at the 100% result. That is where pi comes into play. Multiply the number of days a developer or a consultant estimates for the project by the magic 3,1415 and you most probably have a realistic amout of time it will take to really get done 100%. The following drawing explains this.
PS: At Jedox we decided to multiply the “gut feeling” estimate by 2. This is not pi but then we also have a clause in our general terms of contract where we ask for an additionaly 60% range that we can charge above our original estimate. And 2 x 160% roughly equals pi.
Excel excels at giving users a strong sense of security. How many times have you witnessed this scene played out in organisations: armed with a ‘dashboard report’ the likes of which the company has never seen, your controller struts into that board meeting, looking every inch the fiscal superstar. Excel is often seen as the magic formula for making a whole host of business decisions. But is Excel in the midst of its own mid-life crisis?
With the 30th anniversary of the first spreadsheet upon us, the original “killer app” and vehicle on which the PC first rode to fame doesn’t quite add up. The existence of “rogue” spreadsheets spreading through an organisation can turn logic on its head. The problem is tracing the errors in such a manual process. Is it down to Microsoft’s “interoperability”or just your colleague having a bad keystroke day?
Are spreadsheets responsible for the downturn? When spreadsheets, not people, become the decision makers then certainly, chaos can ensue. Consider the following: The European Spreadsheet Risk Interest Group analyses and quantifies the cost of spreadsheet errors worldwide. In the last six months alone, they have reported various situations, including:
A well-known medical and consumer imaging company had to amend its third-quarter loss by $9 million, announcing that the adjustment was needed because too many zeros were added to an employee’s accrued severance on a spreadsheet; the company’s CFO characterised the situation as “an internal control deficiency”
The many add-on tools that have appeared on the market to cushion Excel’s weakness when it comes to error protection and auditing is the strongest witness to the case. Excel is seen as ‚BI Tool No. 1′ but financial controllers must ensure that a company’s numbers aren’t spread across numerous desktops in isolation; and apply enduring standards, for example by connecting Excel, OpenOffice Calc and web-based online spreadsheets by one common, commercial-strength Open Source database.
Palo takes the risk out of Excel and delivers a single version of the truth: safety in numbers, down the Chinese walls.
Recent Comments