Archives of the TeradataForum

Message Posted: Thu, 21 Sep 2000 @ 13:59:42 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

Sorry, I have been away and have not got the original question but can I add my bit?

We are currently going through our first installation of Business Objects using Teradata as our Data Warehouse for a Merchandise MIS and then rolling out to other areas. We have had Teradata in house for about eight years but have never had a satisfactory tool that did not require extensive user skill in SQL. The general goal is for Business Objects to provide that tool so that users can perform fairly complex queries without needing to know SQL. We hope it will become our corporate tool of choice for Management Information from Teradata

We chose it after a lengthy (12 month) selection process that reduced the original 20 plus packages down to six. For these we asked the company involved to answer a 112 point requirements list and give a more thorough demonstration. The final selection came down to MicroStrategy and Business Objects, both were invited to develop a prototype solution to demonstrate the viability of the product. We also visited reference sites for both. MicroStrategy did not fail as such, it just didn't quite fit the requirements (as we understood them!) as well as Business Objects at the time.

I also agree that this goes outside the scope of this forum and I would happily answer any questions directly. I will however summarise my thoughts on selecting a tool and what we have learnt since:

I agree, it is not a simple process! What you think you know and understand is very different to what you will learn after you start trying to implement. Try and do as thorough feasibility and proof of concept as time and money allows. Whatever tool you choose you will find areas that the others may do better, even if your requirements analysis and proof of concept lead you to believe otherwise.

The reverse of this is also true. There is no perfect package What you actually put into a requirements specification is coloured by what you know or don't know about OLAP tools. Similarly it is very difficult to provide specifications for Metadata/Universes and Reports early on as what you actually specify will be greatly affected by what you learn the package can and cannot do - you only start learning this when you try an build something.

You may have a fantastic Teradata RDBMS - be prepared to radically redesign some of it for OLAP performance.

What you think you want and what you actually need are very different. What you think you need and what you actually deliver will be very different. Be ready to accept that what you first build will be thrown away, be it in development or after implementation. Above all START SMALL AND SIMPLE!!!

The killer question: Do I think we chose the correct product?....

....Yes, but it has been a very painful process. We have found the development of the system to be far more troublesome with Teradata than we could ever have anticipated. I do not believe however that it would have been much better with anything else. There simply aren't as many good options as say for Oracle, SQL Server etc. Teradata does some things far better than other VLDBMS but it does because it does things differently. This can cause problems for developers trying to fit some form of tool over the top.

Hope this helps a bit, sorry if it's a bit of a waffle ot too much sucking eggs, feel free to contact me for further discussion.

Dave

	<Prev	Next>		<<First	<Prev	Next>	Last>>