June 27, 2012 at 8:06 am
HI All,
We are in the process of implementing a new Reporting (business intelligence system). It could be anything from BO, Proclarity, cognos etc. Our operational systems is currently sitting in Sql Server. and the database will remain SQL server even in the new reporting tool.
We are not sure yet weather the new reporting tool will require a datawarehouse or not. but moving forward, my manager want us (team) to be ready for anything..
he tasked me to find out why he should send us on SSIS and SSAS training ?
But he want this information not in technical language. becuase he will put forward the proposal infront of the board who are deciding on the reporting tool. It will great to have some examples which really prove that needs of going for these courses.
a big thanks in advance.
Regards.
June 27, 2012 at 8:48 am
1. SSIS/SSAS/SSRS are all part of SQL server
2. If your going to get a new server, and the SQL licences and hardware cost say £100k, on top of that you want to get BO in at an additional £100K, you spend £200k. If you kept everything in SQL server and didnt go for BO your company saves £100k which they can then use to send you on the courses which are around £1k each.
3. Do things like BO provide you with the means to do the actual ETL (I dont know I have only ever used SQL BI tools for BI), if not then your going to need to know SSIS to be able to take data from serverA to serverB at a minimum
Could probably think of more given some time.
June 27, 2012 at 2:14 pm
SSIS training will prepare you for building a data warehouse, so far as the ETL goes. Regardless of what end user tool is in place, the data has to be prepped for its use. It is bad practice to report directly off your production systems, so at a minimum you will want to have a server hosting the data that is consumed by the reporting tools, cubes, etc. I would strongly vote for denormalization, but, heh heh, I am biased.
This is not the only thing SSIS is good for as it can automate and optimize mass data moves of whatever kind your organization may need.
SSAS will house your cubes. Training in this area will help you to design, deploy and maintain your cubes. Again, this is independent from the BI tool.
We are a SQL shop and use SSIS, SSAS and SSRS, and then also have 2 user tools, Targit and Tableau.
So far as I know, many BI tools offer ETL functionality. I learned SSIS and SSAS without training but have been in the SQL arena for a very long time. I would recommend training in any tool that is going to be part of a large important project.
June 28, 2012 at 3:28 am
hi thanks a lot for your comments.
Another question if you got time to reply.
What are Cubes ? Why do we need Cubes ? What are the advantages of Cubes ? I need to know these in no techinical language to put to my manager. So that they have better understanding of the situation.
tHANKS
June 28, 2012 at 3:34 am
July 2, 2012 at 12:05 am
sohailaziz1
Cubes are awesome tools, you may look at them as a 1000 reports in one single object, end-users will be able to manipulate their data in different ways beyond their wildest dream and really fast. You can google-youtube for any cubes' video.
It will be a great opportunity to take data modeling training, just one or two members for the team, with data modeling the team will have the knowledge to create a sound database structure for BO, BI, data warehousing, etc; and define the way to go with normalize or denormilize models.
Whatever solution is chosen, it should not report directly from the business application.
Cheers,
Hope this helps,
Rock from VbCity
July 5, 2012 at 3:08 pm
I generally explain a cube as a spreadsheet Gone Rubik's, as it provides slice n dice not found on a regular spreadsheet. cubes are 3d, they contain dimensions, while a spreadsheet is rows and columns only. think of what else you could get out of a spreadsheet if only you could have that next dimension ...
Much a user can gain from a spreadsheet or report, but those, to me, are starting points, giving the basics of the data. what about when a user wants to run a hunch?
"Gee, why is Region X off on sales so much this quarter on this report?" might require someone to go write a new report or generate a new spreadsheet, etc etc., but if there is a well-designed cube out there, this kind of ad hoc query may already be baked right in.
Perhaps your user can filter by region X and see their inventory levels or maybe a major competitor moved to town and several products aren't moving because of price pressure. Maybe you can see the pricing changed at end of year and the trend has been coming but those static reports just didn't make it obvious ...
I consider a cube to be a hunch-running tool, where to go for info that a static report will just never be able to provide.
Best part, once it's designed and automated, the users never have to bug you!!! It's self-serve reporting.
July 6, 2012 at 5:12 am
I never understand why people want to buy these expensive products when they already have SQL Server, SSIS, SSAS and SSRS running which can do the job.
Maybe they think that because it has a product name that it will set itself up, create its own cubes and write and publish its own reports without much staff involvement 😀
July 6, 2012 at 5:34 am
I'll come at theis from a more 'plain language' point of view.
SSAS is great for producing highly flexible information for reasonably technical users. Financial Analysts for example. These guys will be numerate and understand how different characteristics of the data should interact. The cubes it offers are highly flexible and allow them to examine anything by anything but, on the downside, your HR director is just going to look at it blankly. If your organisation has business analysts amongst it's ranks then you really want to know SSAS because it's what you're going to use to allow them to do their jobs without having to spend hours typing data into excel first. If you don't have analysts (and many companies don't) then it's probably never going to get used.
SSRS produces a rigidly pre-defined set of data for less techy users. It's about producing the monthly progress reports for the board, or last months headline sales figures. The positive is that you can design reports that are very easy for the un-initiated to understand but the downside is that you will have to define them yourself so they're inflexible. They're what you'll use to build a standard suite of reports.
SSIS is an odd one for me and I've always felt it's not really a BIDS tool. BIDS is about providing information to users but SSIS is more about managing the data and the database. The benefits of SSIS knowledge might be harder to sell because it won't directly provide a better experience to the user. Instead it will make you more productive. ALOT more productive. It's the tool you're going to use to set up your maintenance plans. It's the tool you're going to use to ship data from A to B and shape it into a form that's easy to report on and analyse. It's a hugely useful tool but a difficult one to explain to the user because they'll never see the benefit.
July 6, 2012 at 9:07 am
I've used both Business Objects' ETL tool (Data Integrator/Data Services) and SSIS, and there are strengths and weaknesses in both. The following are my opinions; it's been a year since I last worked with SSIS (total of 18 months "in the trenches") and two years since I last danced with BODI (four years together), so YMMV (and my memories may be questionable!):
- The BODS development tool is much nicer to work with than SSIS/BIDS, especially such things as letting you do incremental development much more easily.
- Both tools have areas where it's easier to do a certain task than the other (examples: BODS: Multiple data sources and performance; SSIS: Scripting). I'll make the point again: Setting up data sources in BODI/BODS is easy, and can be a challenge in SSIS. I REALLY LIKED the scripting capabilites in SSIS, which made some very difficult tasks in BODI to be easier to deal with in SSIS (I'm not saying that scripting is drop-dead simple, but there were times when I thanked the Gods Of Redmond that those capabilities were there).
- I had a much steeper learning curve with SSIS than BODI/BODS. I've been a geek for 35+ years, so I've been able to learn a large number of languages and technologies: I'm no dummy. I pulled my hair out a lot more with SSIS than BusObj. Again, YMMV, but I liked the BusObj development tool a lot more than SSIS/BIDS.
- Maintenance and portability: Wow, BusObj has SSIS beat all over the place. Porting BODI jobs from dev to test to prod is stupid easy, while SSIS had all kinds of wonky gotchas in my way. I was surprised to find out the hoops I had to jump through to make a package to be portable among my systems. Monitoring jobs and capturing job results (success/failure, what went wrong) is better in BusObj than SSIS.
If it was someone else's money being spent, I'd rather work in BODS, but it's hard to beat the price of MS' BI suite.
I'm only addressing the ETL side of the coin, but you'll also want to consider the report generation tools and the cost of creating reports (IT resources for SSRS vs. BusObj universe creation and WEBI development, which can be done my end-users very easily). This isn't an easy process or decision!
July 6, 2012 at 9:30 am
A few remarks.
SQLS 2012 with VS2012 provide much better flexibility for moving SSIS packages between different environments. Generally, VS2012 BI tools are greatly improved over VS2008.
I have lately seen movement from SSRS to cubes with PowerPivot. We are maintaing a rather voluminous data mart and create user-specific cubes on a short notice. They -- mostly business analysts -- come in the morning and download their data into their Excel sheet. While this is going on -- usually 12-15 minutes --, they get a cup of coffee and go through their e-mails, so we no longer hear complains we heard two years ago when they had to wait for their report render for a particular set of parameters. They have their data in a pivot table and they slice and dice it any way they wish, fast.
When choosing BI tools, one should consider the entire five-step process:
- you gather data (say by SSIS)
- you cleanse data
- you consolidate data
- you present data (SSAS, PowerPivot, ...)
- you keep the data as "the only, undisputed truth"
Note that gathering and presenting of the data are only two steps out of five. When choosing your tools, you should consider what their use will mean to the entire process.
July 6, 2012 at 10:22 am
Thank you alll for your valuable input.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply