This write up contains a high level investigation of the Business Intelligence solution offering from Microsoft (SQL Server Reporting Services or SSRS) and the offering from SAP, the Business Objects base reporting package (BOBJ).  While BOBJ does have more options for reporting and presentation, from a basic report feature standpoint both of the tools offer similar functionality and offer the user a great deal of flexibility in the presentation of their data.  The other difference between the two solutions that needs to be considered is the expense associated with the Total Cost of Ownership.  While you will have similar costs in the requirements gathering, design, development, testing, and ongoing administration, there is a significant difference in the licensing cost of these products.  While BOBJ charges by either named user or CPU, SSRS comes with SQL Server so there are no additional costs with adding a BI tool set.

SQL Server and Sharepoint offer a quality BI solution, which meets basic architectural principles and business requirements.  Because of Microsoft’s desire to establish itself in the BI space, it offers the BI components with a license to SQL Server.  The lack of flashy, AJAX style reporting features (which are often shown in demos of BOBJ) may limit the business’s interest in SQL Server.  Additionally, BOBJ’s reporting, ad hoc queries, dashboard, data visualization capabilities are key strengths of the SAP BOBJ product suite and are among top rated BI tools.

When considering the total cost of ownership, a company must consider the individual components that make up this expense.  Total Cost of Ownership (TCO) comes from the High Level Business Requirements, Software Selection Process, Software Installation, Detailed Requirements, Design, Development, System and User Acceptance Testing, Production Software Licenses, the ongoing Maintenance of the solution.   While many of these costs would be similar across the two platforms, a company needs to assess the differences in development time, and ongoing maintenance and understand which tool their personnel and IT infrastructure can support.  Specific costs and return on investments are highly dependent on company’s specific situations and deployment choices.  From our specific client exposure, mid-market companies do not opt for BOBJ, and we find that SQL Server is more prevalent.  An SSRS solution will often be lower cost from a licensing perspective as all components are included with a SQL Server license.  However, SSRS requires a developer to build their reports, where BOBJ supports an end business user self-service model.  So long term technical support and development costs could actually be lower with BOBJ.

Because many companies already own SQL Server licenses within their infrastructure, the ease and low cost benefits of implementation may be too good to pass up.  However, companies either without SQL Server in house or requiring heavily visual reports accessible to business users or self-service access to information with minimal IT support may want to implement BOBJ as their BI stack.

This blog post is part of a series concerning Microsoft Code Contracts. For a complete series directory, please refer to the following list. Articles without a link will be published soon.

I signed up for my Windows Mobile Marketplace account while I was at MIX 2010. I was somewhat disappointed that after I shelled out the $99 for the first year, my Windows Phone 7 Series applications can't be uploaded until sometime in the summer of 2010. I don't have any real interest in writing Windows Mobile 6.5 applications, to be honest. I'm only concerned with writing for the Windows Phone 7 Series because:

Branding Overview

Today I am going to give a high level overview of branding SharePoint 2007.  First, I will give a short description of each of the core elements of a SharePoint brand, and then I will briefly outline how to create a consistent brand across a SharePoint website. 

Custom branding SharePoint is an undertaking that will require significant time and resources to plan, design, develop, and implement.  For our purposes, a basic/core SharePoint brand is composed of Master Pages, Layout Pages, Cascading Style Sheets (CSS), Item Styles, Themes, and Features.  Several factors including the website’s scope, best practices, amount of customization required, and maintainability should be considered when planning how best to design and implement a SharePoint brand.  Below is a brief explanation of each part of a SharePoint brand:

• The Master Page is a container

This article assumes that you already have an optimal data model along with the most efficient data tier in your application.  You’ve spent plenty of time optimizing indexes, poring over the SQL explain plans, and tuning the SQL queries that your application uses to retrieve data from your SQL Server database.  The application has been running fairly smoothly, performance isn’t great but has been acceptable to the end users.

At some point, due to application load from the users, data volume, or other external variables, you notice that the queries you optimized utilizing the Management Studio’s estimated explain plan do not perform as expected. 

Let’s take a look at the table we’ll be querying.  We’re using the VARCHAR data type to store all string data in our database.

In my last post, I covered how to use an unpivot transformation in SSIS.  There are, however, at least two other ways the same output can be achieved.  In addition to the built in transformation, a multicast into a union all or a script task can be used.  While all three methods produce the same dataset, the latter two are slower and one is much less efficient than the native transformation.   If you are interested in each of the three methods, continue reading; otherwise, you can jump to the results. 

During my past BizTalk engagements, I have had the opportunity to work closely with my clients in developing flexible and maintainable applications.  One of the most common issues that I come across is the misuse of some of the shapes available within the Orchestration Designer.  By misuse, I simply mean to say that many BizTalk developers will drag and drop shapes into an orchestration to implement the business process, but do not take into account the implications of doing so.  More often than not, the result of selecting the wrong shape for the job is not seen until the application is tested or even worse, the production environment.  One of the primary reasons that BizTalk is used is the opportunity to build loosely coupled, flexible and scalable applications.  By choosing the wrong shape, many developers will wind up doing exactly the opposite, thus setting the application down the course of tight coupling and brittle implementation. 

BizTalk development on virtual machines has become an essential part of the development process.  The speed with which you can tear down and build up BizTalk VMs means you spend less time configuring environments and more time developing artifacts.  Typically, an instance of one of these environments contains everything (BizTalk, SQL Server, Visual Studio, etc.) running on a single VM machine.  Spinning up a new development environment is as easy cloning your base image.  Occasionally, though, you need a development or sandbox environment that’s a little more than a virtualized BizTalk “island”, of sorts, with everything running on a single VM.  

BACKGROUND

Recently, I was on a project in which the customer needed real time reporting from a custom order management application.  The application ran on a Microsoft SQL Server 2005 back end.  The solution needed to provide reports, pulled from live data, without causing any database contention that would negatively impact the performance of the application.  Normally, this would not be a problem as you can write reports to read uncommitted and not worry about placing locks on database objects.  The problem, as it turned out, is that all end users of the application needed to be able to run reports against the one million+ row order tables.  As you can imagine, giving this functionality to over 100 concurrent users can cause resource availability issues on the server whether or not there is any blocking.  So, I needed a solution that would address this reporting requirement without negatively impacting the application’s performance.