Pilot projects - The importance of being earnest

There has been an interesting discussion recently in regards to what technology is needed to provide market risk managers with sensitivity data. The data will have to be stored at deal level, which amounts to 23 million rows/day. System will need to store 10 days worth of sensitivity data. Users will want to be able to aggregate chosen data to specific level in a reporting hierarchy within seconds.
It is interesting for me to watch the appraoch that has been taken to find the definite chosen solution for this. The higher entity in the project has provided a vision, that is, to use a particular vendor product, which provides out-of-the-box solution to perform aggregation on the fly. The approach is “straightforward”. Load all data to memory, and away we go.The complexity is as follows:

  • the software has never been used for such a large scale implementation
  • 10 days worth of data amounts to 230 million rows of data, and this translates to a total of 750GB of data/region. There are 3 main regions to deal with, and this adds up to the need to persist 2.2TB of data in memory, which in turn will result in millions of dollars of hardware cost/year, plus the software cost.

All throughout the pilot, various issues have been identified

  • During the pilot, only a subset of the data has been tested, due to constraint in sourcing the required hardware to support a full test
  • The business is expected to simplify the reporting hierarchies to cope with hardware constraint
  • There is no flexibility on providing FX rates conversion once data is loaded to memory
  • There must be enough buffer in hardware resource to accommodate for business growth, i.e. there must be enough memory to load all data, otherwise system will fail
  • and the list of unknown continues

Now it is decision time. Someone will need to look at the result of the pilot and make a go/no go decision with the choice of technology.

I sit on the outside of this project, and it interests me to see how decisions are made, and on what basis. Is the pilot genuinely used to pick the best solution which is the best fit for this particular business requirement, or is it used to justify that the initial hunch to pick a particular software vendor as a solution -  is correct. Somehow I suspect that the latter is true in most cases. It is hard to back off a particular route once that route is taken, and the goal post would suddenly switch from “finding the best solution to a problem”, to “how to make a particular solution work for a particular problem”. Two different things.

How does this relate to my oracle blog?

Well, as an Oracle consultant, I believe that an oracle solution without the bells and whistles would work just fine. With the correct data model design, we can end up with a FACT table which is lean enough to allow it to be used for aggregation on the fly. For current day’s data that is used more often, data would end up being cached in memory, and aggregation on the fly should “fly”. And for other day’s data that is used occassionally, does it matter so much if it takes a few seconds longer to aggregate? This surely would save the client a few million dollars annually. And some of the saved dollars can be spent on on a good business intelligence solution to improve user experience.

But again, what do I know..

 

 

 

 

 

No comments yet.

Leave a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>