Archive for March 5th, 2010

It’s Part of SQL Server 2008 R2?

Friday, March 5th, 2010

SQL Server 2008 R2 includes some impressive new features and functions. But, when you run setup they are nowhere to be found. Included in the list are the new StreamInsight, PowerPivot (sort of), and Master Data Services. Where are these features and why are they not included in the setup wizard?

Except for PowerPivot for SharePoint, the features are in their own distribution folders on the setup DVD. StreamInsight is in the StreamInsight folder and Master Data Services is in the MasterDataServices folder. PowerPivot for SharePoint is actually included in the setup wizard, but you need to know where to look. More on that later.

To answer the question as to why StreamInsight and Master Data Services are not part of the setup we need to look at the big picture as Microsoft defines it. Microsoft has decided to migrate all data management and analysis applications under a single umbrella and that umbrella is their flagship database, SQL Server 2008 R2. This is much like what they are doing with SharePoint by including PerformancePoint as a feature beginning with SharePoint 2010.

The thinking is that creating a comprehensive data management suite is simpler if the components are marketed as a single platform. Not only does this make sense logistically, it makes sense financially. Instead of socking companies with more fees as they continue to build their data management infrastructure, Microsoft has rolled many of their previous offerings into the SQL Server 2008 R2 platform. Companies now benefit financially by no longer being required to fork out thousands of dollars for each of the features that they want to implement. Rather than forking out thousands of dollars for each application, they can purchase the appropriate edition of SQL Server and find everything they need.

I mention this because StreamInsight, in particular, is not a SQL Server based product. StreamInsight sits outside of the SQL Server resource pool and performs Complex Event Processing on incoming data streams. Designed to handled massive volumes of data in memory, StreamInsight enables a company to create processes that scan the incoming data streams and discard or redirect the data based criteria written in a .NET compliant language and using LINQ.

StreamInsight can use SQL Server based data tables to hold static data used for comparison purposes. It can also pass selected data through and ouput adapter to SQL Server for storage. Because StreamInsight runs against memory based data, it can process the queries without the I/O overhead required by a traditional database server.

Master Data Services is another application included with SQL Server 2008 R2. Master Data Services does store data in SQL Server. However, the processing it does is not a pure database or data warehouse function. Master Data Services (MDS) enables and organization to gather multiple copies of significant master data together, merge and standardize the data, and then send it back out the original applications. Those applications then contain a consistent and accurate representation of the common data. A previous blog contains a more detailed discussion of what constitutes master data so I will not go into that here.

Finally, we have the new PowerPivot for SharePoint. PowerPivot for SharePoint is a new addition to SQL Server Analysis Services in SQL Server 2008 R2. Microsoft created the SharePoint add-in to enable users to create, share, and manipulate PowerPivot workbooks in concert with PowerPivot for Excel 2010. The only way to install PowerPivot for SharePoint is to perform a SQL Server Analysis Services installation with SharePoint integration. After selecting SharePoint integration, the wizard walks through the essential configuration tasks for PowerPivot. A standard Analysis Services installation does not include PowerPivot. For a more in depth discussion of PowerPivot for SharePoint and PowerPivot for Excel please see my previous blogs.

By combining all of these features into SQL Server 2008 R2, Microsoft is proving even more that they are committed to improving the way businesses handle data without requiring excessive investments. I am sure that there is even more to come and that the next release of SQL Server will continue this trend of managing data where ever it is so that companies can continue to gain ground in managing and analyzing business critical data.

SQL Server Reporting Services on Windows Server 2008 R2

Friday, March 5th, 2010

In the tradition of the entertainment awards season, I want to thank Microsoft for taking IIS out of the equation with SQL Server 2008 Reporting Services. That made installation and configuration of Reporting Services much simpler. For those who began working with Reporting Services 2008, this is the first version with a dedicated web server. The main advantage is simplified configuration without worries about the impact on IIS and the web applications that depend upon it.

SQL Server 2005 Reporting Services, however, does depend upon IIS to manage and share reports. This works very well with Windows Server 2003 and IIS 6.x. If you need to install the 2005 version of Reporting Services on Windows Server 2008 R2 you will need to pay special attention to the IIS installation. This version of Reporting Services is not fully compatible with IIS 7.5, which is provided with the operating system.

I recently needed to get Reporting Service 2005 installed on Windows Server 2008 R2 and quickly ran into my first issue. No matter how hard I tried, I could not get the Reporting Services to show up as a selection during setup. After doing some research, I found that the IIS 6 components of IIS 7.5 are required for Reporting Services. Most of the blogs and articles simply indicated that adding IIS 6.0 Management Compatibility would fix that. However, the problem still existed.

After reading many articles and literally days of following the recommendations, I finally stumbled upon an article located at http://support.microsoft.com/kb/938245 with all of the answers I needed. It seems that IIS 6.0 compatibility is not the only thing required.

The most common services and features are automatically included when you install the IIS 7.5 role on Windows Server 2008 and Windows Server 2008 R2. It turns out there are a few more features that Reporting Services 2005 requires. The first one we have already mentioned: IIS 6.0 Management Compatibility. When you select this feature, make sure that all of the sub-features are selected.

Moving up to the Common HTTP Features section, you will notice that not all of the sub-features are selected. The HTTP Redirection and WebDAV Publishing are not selected for installation. HTTP Redirection is required so make sure to install it. The WebDAV Publishing feature is not required by Reporting Services 2005.

In the Application Development section, select the ASP.NET option.

The Windows Authentication option is a required security feature. Check Windows Authentication under the Security section.

If a dialog appears to tell you that other features are required as you make these selections, click OK to install those features.

After installing the new role features is complete, go to the Services control panel and confirm that the World Wide Web Publishing Service is set to start automatically, and is running.

Now you can run the SQL Server 2005 setup and install Reporting Services. When installing Reporting Services, go ahead and select the configuration option for standalone or SharePoint integration. Setup will walk you through the configuration process and you are now ready to go.

Note that this is how to install SQL Server 2005 Reporting Services 64-bit version. If you need to install the 32-bit version on Windows Server 2008, take a look at the Microsoft Knowledge Base article at http://support.microsoft.com/kb/934162/ for details.

The Politics of it All

Friday, March 5th, 2010

In researching Master Data Management, I found an interesting article on the Information Management website dealing with the “Top 5 Mistakes in MDM Delivery”. The entire article contains wisdom everyone should heed when starting out to create a MDM solution:

  1. Do not overanalyze the requirements.
  2. Have the big picture in mind from the start.
  3. Determine the modeling approach to use.
  4. Use a holistic approach that includes both analytical and operational points of view.
  5. Do not underestimate the political dimension.

The last point caught my attention. Having been in the industry for more than 20 years, I have had a bit of experience with the political aspect of an implementation. Over time, I have learned that where two or more are gathered, politics is to be found. Maybe experienced is a better word for it.

I have been involved in simple accounting implementations with only one person and huge enterprise implementations where I had to work with many more people to get a system up and running. In every case, politics came into play. Sometimes it was subtle and other times not so much. I was always the outsider coming in to change everything. More like to ruin everything if you ask some of them.

After time, you come to expect the resistance and the accompanying politics. But, you always hope each project will be different. That this next one will be met with pure joy and elation and everything will go smooth as silk. This is rarely, if ever the case.

So why does politics come into play? Remember, the person coming in to change things is the outsider. No matter how much experience we may have in an industry, or with the client, we do not and cannot know everything.

These people own their systems and the data within them. They know everything about what they do and they typically do it well without our help. This is true even when the systems are manual, horribly outdated, or failing. In some of my implementations, the express goal of the new system was to break the ownership cycle and open the data up for use by management in making intelligent business decisions, really!

One of my clients was told on a regular basis that his business was profitable and doing very well. This was always backed up by hand written financials presented to the president and the board during the bi-annual board meetings. Again, really! I don’t need to tell you that the politics involved in this extreme form of data ownership was difficult.

So what do we do, when implementing a new system? Whether the new system is a new application, a data warehouse, or a master data management solution the approach needs to be well thought out and as gentle as possible.

Always take into account the emotional aspect of data ownership. The longer the person has owned the data the more emotionally attached they become. Anyone messing with the data is messing with them. This makes it very important to sit down with the owners and demonstrate to them that their data is as safe in the new system as in the old one.

In cases where people have been in the organization for years, changes in their routine are very stressful. Gently introducing the new procedures and routines is very important when working with some people. They need to be shown how much easier and more accurate their job will be with the new system.

Many times, the best approach is to show how the changes this person experiences, including loss of ownership, can benefit the organization as a whole. Work to change that focused ownership to a broader view of contributing to the success of the company. In a Master Data Management solution it may help to point out that relinquishing full ownership of the data means that the data they have will become more useful to them in the long run and that it will keep everything more current within all departments that track the same type of data.

Playing politics is difficult. Often times you simply have to step out of the line of fire and ask management or the internal project manager to help out.

The easiest implementation I did involved 23 employees changing an accounting and sales management system over to a completely different one. Some of the employees were very resistant to the change. However, the manager spearheading the project decided to do an initial conversion and work through the main issues. After determining that we had discovered the majority of the issues, she had me do one more

more conversion.  When that conversion was complete she printed final reports from the old system and simply turned it off and had it removed.  Remarkably, there were very few additional issues and everything went extremely well.

In case you are wondering about the implementation I mentioned earlier with the hand written financials, they are on the new system.  However, the financials are still being created by hand from reports even though they can be printed directly from the system.  Sometimes you just can’t get everyone on board and have to leave it completely to management to handle it.  Sometimes even they have trouble with the politics.

SQL Server 2008 R2 Master Data Services

Friday, March 5th, 2010

In the past few weeks, I have had the opportunity to look at Microsoft’s new Master Data Management offering. This being a new area for me, I was very interested in the concept and did a bit of research to try to understand the ins and outs of Master Data Management, or MDM.

My understanding of the purpose of Master Data Management is the creation of a central repository for the most important data. This repository and its stewards are then responsible for maintaining the data in a consistent and current state for use by the originating systems. Essentially, MDM is the process of creating a single version of the truth for vital data and making sure that all systems using that data share that single version.

What I found was that managing master data is a much more detailed and evolutionary process than I would have imagined. For starters, each organization must determine what they consider master data. For some organizations, customer or product data will play a major role in MDM. These may not be as important to include for other organizations. The basic criteria for master data are that the data must be relatively static in nature, common to multiple systems, and it should not include transactional data.

Customer data is one of the most common collections of data in many MDM solutions. However, managing this data outside of the originating application may not be as important to an organization that has a transient customer base, or where the data resides in a single system and location.

Product data is another common element in MDM systems. Most companies deal with a static collection of products or services and may need to track and manage that data for use within several systems. However, product data is of no use as a master data element if the organization is an auction house where the products will change rapidly based on what is available at any given point of time.

Sales data is one of the least common data collections included in master data. Most of the time this data is considered transactional in nature. This is true for most organizations that produce invoices and collect payment in a short timeframe. For organizations that carry long-term sales contracts, this data becomes a good candidate for master data. The overall state of the entities remains static with periodic changes to balances.

So how do you decide what to include in an MDM solution? Here are some basic questions to ask about each candidate data set for master data.

  1. Is the data spread across multiple systems and/or locations? If so, it is a sure bet that each data set holds some common data with their own unique twist on the how it is maintained and ultimately looks. Remember to look places outside the mainstream applications for additional sets of this data. That includes checking individual computers for special purpose databases, spreadsheets and lists used for marketing campaigns and other analysis.
  2. Does the data remain reasonably static? Reasonably static data is data that experiences little to know change over a pre-determined period of time. Again, customer data where the address, phone number, or name may occasionally change is a good candidate.
  3. Does the volume of data justify the effort? If you sell no more than 10 products or services, or have only three customers, don’t bother with that data. The overall benefit of maintaining it out of the originating system, or systems, is very low when compared to the effort involved.
  4. Most importantly, is the data significant to the operation? If the data is frequently referenced for reporting or other operations, it may benefit the company to create and maintain the data in a consistent format to push back into the originating systems.

This is blog only scratches the surface of what to include in a MDM solution. With all of this considered, it is most important to start small and grow from there. Select at least two related data sets to include at the beginning and grow your solution as you learn what does and does not work.

Better error messages (Part 1)

Friday, March 5th, 2010

There was a very interesting discussion on Slashdot the other day about writing good, memorable error messages.  The question was basically: how do you get the user’s attention so they will remember the error instead of blindly clicking OK to get past it?  Developers are tired of getting a call saying that an app isn’t working, but no more details.  Worse still, users complain without the specifics, somehow thinking that saying “it keeps crashing” will help.

What it seems to come down to is that users are fairly immune to error messages.  They often won’t actually see a message in front of them since they are conditioned to ignore them.  Basically, if you are interrupting your users they will be annoyed and simply dismiss the message so they can keep going.  It’s pretty common to hear “you need to click OK twice when you save – I don’t know why.”  As developers we want to scream “read the message!”  We wouldn’t show a message if it wasn’t important.

But is that really true?  Let’s think about that a bit.  If an exception occurs and we display a message box what do we hope to gain by it?  The user doesn’t really care about what happened.  Either you work around the error, or the user needs to stop everything while something resolves itself (e.g. network outage).

The worst thing to do is to ask a user for an error message when they call the help desk.  The error will already be gone at that point unless it keeps popping up.  Remember that the first instinctive action was to dismiss the dialog.  The user doesn’t want to call the help desk.  The user doesn’t have time to call the help desk!  The automatic response is to click OK and try again.  Telling a user to reproduce an error is also a sure way to cause upset!

The Slashdot discussion mentioned creative ideas like using colors/shapes/images.  Perhaps the user would be able to say “it was the blue circle error” or “it was the dancing penguins” easier than “it was error #0800BADC: File permission error.”  The consensus, however, was that such solutions didn’t really help.  To the extent that a user will even remember such a message, this doesn’t convey any specific information.  A red square might signify file access error, but without a path and specific error how does that help in troubleshooting?

The bottom line seems to be that error messages are a losing proposition.  You need to do everything in your power to prevent error conditions from blocking the user.  Obviously, simply avoiding errors isn’t possible (no matter what you might tell your clients!).  Instead, you may need to be creative about dealing with unexpected issues.

Continued in part 2…

Link: http://ask.slashdot.org/story/10/03/01/132219/How-Do-You-Get-Users-To-Read-Error-Messages