While catching up on blog posts I came across a post by Patrick Husting from last month. The post titled “Better looking charts in Excel 2007/2010” provides a before and after example of a chart in Excel. The simple example is meant to show the importance of adding a little style to your reports.

I think this is an often overlooked aspect of a complete BI initiative. Too often the focus is only on the technical aspects and does not ultimately address user adoption. While there are several things that can contribute to low user adoption having ugly and unintuitive reports doesn’t help.

With this in mind, I would argue that taking the time and effort to design a comprehensive style guide is well worth the investment. If done properly it should help a project realize ROI. So, when you’re planning your next project consider budgeting time for style planning.

Anyhow, check out Patrick’s blog and let me know what you think.

Just a heads up for those who didn’t notice: yesterday Microsoft released the official release date for the next version of SQL Server. It will be generally available May 2010 and should appear on the May pricelist.

I have been looking forward to some of the improvements in the upcoming release and am particularly excited about Master Data Services. Here is a quick overview of the key features:

• Master Data Services
• PowerPivot
• Application & Multi-Server Management
• Improved Hyper-V Support – Live migration between hosts
• StreamInsight
• New Data Center Edition – Increased capacity (256 logical processors, max OS RAM, etc.)
• New Parellel Data Warehouse Edition

If you’d like to give the last CTP a try you can download it here.

I would have thought that this would be fairly common knowledge but I am often asked for a quick example of how to strip off the time element of a SQL datetime type. So, here is an example followed by an explanation of how and why it works:

SELECT DATEADD(d,DATEDIFF(d,0,GETDATE()),0)

Technically, this doesn’t strip the time but instead sets it to midnight of current date. So, what is this snippet doing? To start we need to know a little bit about how datetime is stored in SQL Server. The datetime type is an 8 byte type. Essentially, it is stored as two distinct 4 byte integers. The first 4 byte integer represents the number of days since the base date for SQL Server. The base date for the datetime type is 01/01/1900. The second 4 byte integer that represents the milliseconds since midnight.

With that in mind, the following snippet should return this base date:

SELECT CAST(0 as datetime)

Now, back to dissecting the original snippet, I am using the built-in DATEDIFF function to return an integer. The integer is the number of days that have elapsed since the base date of 01/01/1900. With the knowledge of how a datetime is stored you might be tempted to just CAST directly from the datetime to an int. However, depending on the time of day, it might cause the int to round up. So, it is better to just rely on the DATEDIFF.

Finally, to convert this integer back to a datetime type I am using the DATEADD function. Once again, we are using the base date and adding the integer to it to give us today’s date with a midnight time component. Pretty simple, right?

A new version of the core SyntaxHighlighter that wp-simplesyntaxhighlighter wraps has been released. As a result, I have released a new version of the WordPress plug-in that reflects this latest revision.

You can find a quick list of the changes here.

This is a continuation on my previous rants on borrowing traditional software development concepts for a BI project. As the title suggests, the topic today is source control.

No matter what you want to call it, a cornerstone of any good software project should be source control. This is pretty fundamental for software projects but it hasn’t been a priority for many in BI. I am not entirely sure why this is. Is it just an oversight? Are BI project managers oblivious to the existence of good source control tools? I’m not sure what the answer is but I am sure that BI teams should be using it.

The benefits of source control should be well known. So, I am not going to rehash them here. However, I would like to go over a few things to keep in mind:

Full Coverage

Source control can be applied to most parts of a BI project. Source control concepts can apply to data models, cube structures, ETL, and even the documentation for the project. Pretty much anything that changes over time can benefit. So, try to think beyond just source code.

Version Labels

Having the ability to identify something makes it infinitely easier to discus it. This same concept applies to components of a project. It doesn’t really matter whether it is some sort of name or just a revision number. The benefit is that it allows you to have a common term to refer to a snapshot of a project.

I strongly suggest that the labeling is universal and span all of the projects components. In other words, version 2.1 could universally refer to a snapshot of the ETL as it does to the data model. And, when you start introducing formal issue tracking and end-user team portals it becomes even more important (more on these topics at a later date).

Ultimately what I am getting here is that checking in revisions isn’t enough. Develop a consistent labeling system for releases. And, use the commenting features of your source control system to identify changes; all changes!

On Cost

There are many source control systems out there. And, many of these are free. So, cost should not be an excuse. Additionally, many of the design tools on the market today have some flavor integrated into the development environment. Don’t make excuses, find something that works for your team and use it!

I am finally getting around to installing Windows 7 on my laptop. Before I wipe everything I wanted to have an idea of what I currently have installed. So, I put together a little PowerShell script:

Get-WMIObject Win32_product | sort-object vendor | format-table name, version, vendor, caption -autosize | out-file installed.txt -width 250

It is a pretty simple example. It uses the Win32_product WMI class to get a list of installed application. I then sort by vendor, format as a table, and output to a text file. As I said, pretty simple.

The 2009 SharePoint conference wrapped up earlier today. Unfortunately, I was unable to attend. However, I did try to keep up by watching all of the tweets and blog posts that were being generated by the attendees. Here is a quick list of some of the more interesting SharePoint 2010 news:

• SharePoint 2010 beta should be available in November (sign-up here)
• Project Gemini gets a product name: PowerPivot
• SharePoint 2010 will run locally for developers under Vista and Windows 7 x64
• No more 32-bit, 64bit only
• IE6 will no longer be supported
• New PowerShell CmdLets for managing SharePoint
• New Document Center template optimized to supports hundreds of thousands of documents
• Windows SharePoint Services rebranded as Microsoft SharePoint Foundation
• Enterprise Metadata – includes tagging and ratings
• Integrated support for Silverlight
• Groove reworked as SharePoint Workspace
• Improved Mobile Web experience
• Sandbox isolation for custom code
• Business Data Catalog becomes Business Connectivity Services – no longer read-only
• Improved APIs – including list access through REST, LINQ, ATOM, and JSON

You can watch some of the highlights of the conference here.

Previously, I had discussed treating Business Intelligence projects in a similar manner to software development. Continuing on this subject another often overlooked item in BI projects is release management.

So, what do I mean by release management? Release management is a large and ever evolving topic in software development and often speaks to the entirety of an IT organization as opposed to a single project. However, for the purpose of this post I am really only interested in one thing: protecting the live production environment.

I have had numerous clients who seem to believe it is alright to develop directly against a live production environment. Yet, more often than not, if you walk down the hall in these same organizations you’ll see that their custom development teams follow strict guidelines for deploying new code to production. Why is this?

Often times these organizations look at BI as being non-critical. If a new release results in unexpected downtime it is viewed to be not as important as the uptime of a transactional business system. And, in an immature BI environment this is probably true. However, if an organization wants to realize the ROI needed to justify continuation of a BI program they are going to want to reach maturity.

Holding back on a sound release management plan or treating a BI project like a second-class citizen is only going to work to slow this maturity. It will hurt the overall perception of the program and will result in poor user adoption. If a user cannot count on a system to be fully tested and available why would they trust it? Ultimately, I think you will find it is far cheaper to start these processes as early as possible.

Fortunately, it is pretty easy to get going. Start with the environments. Have a formal development, testing, and production environment. This doesn’t need to be difficult or costly. The development and test environments do not need to be as robust as production. They just need to be able to isolate the changes from production. In most cases you’ll be able to use a subset of the overall data for development and testing purposes.

Next, establish some guidelines for promoting changes to the individual environments. If you’re using one of the agile methodologies for BI development it most likely already has an established process for this that you can follow. Overall, the governance behind this process can evolve and expand with the BI program.

Finally, the results should be a release process that allows developers to continue enhancements of the system, testers to verify the quality of the changes, and the end users rely on the availability and accuracy of production. I firmly believe that this is an essential part of any successful BI project. Can you proceed without it? Yes, but you’re going to pay for it in the long run.

There are many ways that a BI project can fail. And, many do just that. In my experience one of the top reasons is poor project management. Opinions as to why seem to fall into two camps. One side believes that BI is not inherently an IT project but is instead a business project and treating it like an IT project leads to failure. The other side opines that years of project management principles have been refined for software development and BI should learn from this.

Personally, I feel that both sides have their merits. I fully understand that there are some important differences with a BI project. And, there is no doubt that it must be driven by the business. Yet, I lean towards treating BI projects in a similar manner to software development project. In the future I hope to go into detail on how BI projects are different and hopefully will be able to provide advice on how to effectively manage these differences. In the meantime, what does it mean to treat a BI project like software and what exactly should be borrowed from the software development world?

Be Agile

To start with, the scope of a data warehouse and the ultimate business rules and requirements that it will encompass are vast. I contend that it is not possible to distill all of the business knowledge that is needed into a scope document; BI projects that try are bound to fail (at the very least they are susceptible to huge cost overruns and user adoption issues). With that thought in mind, a BI project does not lend itself to a traditional waterfall model.

Instead, a BI project should be agile and an iterative approach should be taken. There are several flavors of agile development methodologies and they are typically not geared towards a non-software project. So, lets look at some of the things that they do have in common: iterative development, a focus on team collaboration, and, perhaps most important, the ability to be adaptive to project change.

An Iterative Approach

It seems that many BI projects focus only on the big picture. The project can be on the small side and tasked with expanding a single subject area in an already existing warehouse. Or, it can be a huge build of an enterprise-wide data warehouse. Regardless, the focus often is on the pristine and perfect end product. I would argue that this is an enormous mistake.

There are a few reasons why I believe that this is a mistake. But, let me focus on the one. This style of development lacks transparency and creates a black box. It is difficult for the business to see the value in what is being developed. Instead, what they see is a lot of man hours being spent and they can quickly lose confidence in the project. This can be the death nail for a project and may very well hurt future BI efforts as well.

Alternatively, most BI projects can be broken into small components that take a short duration to complete. Each of these components can be prioritized and assigned to team members for a given iteration. Each successive iteration expands on the previous. So, after a single iteration you may not have a complete deliverable product but you do have something to show.

Take this example: you have a proposed large many-sourced product dimension that needs to be conformed. The work required to accomplish this task is greater than a typical development iteration. However, it can be broken down into even more fundamental parts. For instance, you might target a prioritized subset of the dimension attributes.

In the first iteration you’re able to have team members perform the business analysis work required to assess data quality, build a basic data model, and create the ETL to populate this data structure. In the end, you are not able to deliver a complete product. But, you are able to demonstrate progress. And, in each successive iteration you are able to build on this progress, learn from the work of the previous iteration, and ultimately deliver a complete conformed product dimension.

It seems simple enough. And, with a good team, it is. Each step of the way the business stakeholders have insight into what is being done. And, the likelihood of success is greater.

Still, there does needs to be some caution. A BI project is really just a small piece of the over all pie and should be part of a larger BI program within the organization. It is important to have the big picture in mind while working through the individual parts. You need to be conscious of and avoid building silos of data. The goal still needs to be to have a comprehensive and conformed view of the organization. It isn’t that agile doesn’t allow for this just be careful that goals do not get lost during the daily focus of an iteration.

Team Collaboration

Working with a team certainly isn’t something that is unique to agile development. But, there does seem to be a particular focus that shouldn’t be ignored. An effort should be made to have face-to-face interactions between the team members and it should be routine. Any roadblocks, as well as progress, should be brought to the teams attention as quickly as possible. And, attempts to involve business stakeholders should be a priority. After all, a BI project is for the benefit of the business and not just a pet project of IT, right?

Once again, much of this is about transparency. But, it is also about effectively working together and addressing problem early.

An entire book could be written on this subject and I can do it little justice in the limited space I have here. I simply encourage you to research the team methods used by the various agile flavors. And, please, do not overlook the importance of this. Good teamwork can make or break a project.

Adapt

A plague to many BI project (and software projects as well) are rapidly changing requirements. Many times the source of this is simply the result of a project digging deeper and deeper into the dark inner workings of a long running organization. Or, it could be the stakeholders changing their minds mid-stream. Whatever it is, it happens, it isn’t predicable, and you need to be prepared to deal with it.

The short iterative agile cycles are able to easily adapt to this change. While you will still have a high level project plan, required features, goals, and priorities the only thing that is really set in stone at any given moment is the current iteration. If a spec changes it is simply added to the list for future iteration developments. It is no longer an unforeseen showstopper. It is now just another requirement in the overall pool. In many ways this is a very liberating concept. Of course, there are still consequences to scope-creep. But, it is now an integral part of the process as opposed to a wall stopping progress.

Now What?

It goes without saying that agile methodologies are not perfect and that they will not solve all of the problems that a BI project will face. They are, however, flexible and able to provide a good base to build upon. As a part of a larger strategy they can provide important direction and proven guidelines. So, should you choose a specific agile methodology for your BI project?

As stated above, typically they are geared specifically towards software development. The flexibility, however, should allow you to adapt a methodology to a business intelligence focus. In fact, as an IT strategy it may be very possible to use a single methods across multiple project types (Scrum comes to mind). But, agile development methodologies are more about a mindset than a specific series of techniques. So, do not spend too much time dwelling on what some software pundits have turned into a religion.

The bottom line is that if you choose, and you should, to use a more agile development methodology in your BI projects you are going to need to adapt and tailor it to your organization. It is a mistake, however, to dismiss it as not being important or just the latest fad. Keep in mind that this is just a start. I will continue to expand on BI project management in future posts. If you’re not a believer now, just give me some time.

Right now seems like a great time to get into mobile development. Microsoft recently released their Mobile Marketplace along with Windows Mobile 6.5. There is even some fun to be had with game development on the new Zune HD. And, with luck, Windows Mobile 7 will be right around the corner.

So, a few month’s ago fellow Exceptional Geek Robert Fischer and I put together an article for Microsoft’s Coding4Fun blog titled Building a Full Featured Mobile Camera Application: C4FCamera.

In a nutshell, the article details the process of creating a simple Windows Mobile Camera application from start to finish. It uses C# and is targeted at those new to Windows Mobile development. But, it certainly can be fun to play around with at any skill level.

I am happy to report that we have received a tremendous amount of positive feedback from readers. And, we have received some great suggestions on extending the project even further. With that in mind, I am hard at work on crafting a follow-up article that will introduce some additional features as well as some more advanced mobile development concepts. No ETA as of yet, but keep I’ll keep you posted.

So, you should check out the article and let me know what you think.

Related Links:

• CodePlex Project