TGO Budgeting Solution – The Big Picture
Posted by Alan on January 24, 2011
So here is my first detailed post on the budgeting solution we are currently developing that I mentioned in an earlier post. Right now we are calling it the “TGO Budgeting Solution”. I know it would seem cooler if we had some neat sounding project code name like “Wildcat” or “Everest” or “Backscratcher” but we have chosen to go the generic route.
As I document the life cycle of our development process you will see that our design is drawing upon what we feel are the best feature sets of the 5 solutions that TGO Consulting has worked with in the past. These would be straight Excel, the Enterprise Reporting and Forecaster products from the Microsoft Dynamics group, PerformancePoint Server and Clarity CPM. What we hope to do is mimic (and improve upon) the functionality that we really liked in those products while minimizing the stuff that caused us grey hairs and raised our blood pressure.
Our first major decision point was the scope of our product — not in terms of version 1.0 features and functions, but in terms of whether or not we were going to build a full CPM product or just a planning/budgeting solution. Rather quickly we decided that the value TGO can add to the universe would be to develop a superior planning tool and not a complete CPM solution. Our platform is going to be Microsoft-based and why should we reinvent the wheel when we could simple integrate to the great set of tools (SharePoint, Excel, SQL Server) that Microsoft already produces. I think when the final design is presented, you will see why this tact makes sense.
The next question we asked ourselves was whether or not this crazy idea of building our own solution was feasible or just some wild pipe dream. We thought the concept made technical and business sense, but decided it might be wise to poll some different contacts and get some outside objective opinions. We got feedback from a couple of large clients as well as from some different Microsoft people including some ex-PerformancePoint team members and some current SQL Server folk. The responses were unanimous in the fact that our vision, if we could pull it off, was a solution that would definitely fill a gap in the marketplace.
Then things got philosophical and we asked ourselves how much did we want to custom develop versus using out-of-the-box functionality of existing software. The decision was that whenever possible we will leverage out-of-the-box functionality of the platforms we are building upon. And even if that out-of-the-box functionality was only a 85% or 90% match then we would still utilize it and adjust our design accordingly. Afterall, Microsoft’s pockets are much deeper than ours and the less we have to do initially means we can get a solution out the door that much faster. Granted, this decision was definitely much easier to make given the extensibility of the platform upon which we have chosen to build.
So that brings us to the platform of our solution. I think our decision would be best summed up as “go with what you know” and because of that our solution would be around Excel 2010, SharePoint 2010 and SQL Server 2008 R2 (with an eye towards Denali). The reasons for each are below:
Excel 2010: Easy call here as almost everyone in the world knows how to use Excel and frankly it is ideal for budgeting. The traditional problems that comes with using Excel are due to the fact that for each additional user you add to the budgeting process the management and administration requirements grow exponentially. I have worked with clients who literally had to create, maintain and ultimately merge hundreds of different Excel workbooks and read through thousands of emails just to do their yearly budget. Our solution will allow end-users to utilize all the Excel functionality they are used to using while giving the organization as a whole the control over the process it needs.
SharePoint 2010 Enterprise: We knew we needed a place for administrators to manage the system and the process and we thought web-based made the most sense. We also knew we were going to have to store budgeting templates. So when you put those two together, SharePoint became the answer. It is easy to forget that SharePoint is as much a platform for developing applications as it is an application in and of itself. So for our solution, SharePoint becomes the interface for managing users and security and for storing templates and assignments. It will also be utilized for the workflow, but not in the way you might be thinking. To understand why you are going to have to wait for a future post. I expect we are going to get a far more in-depth knowledge of just how far you can push SharePoint Lists, Metadata/Taxonomy Management and Business Connectivity Services.
SQL Server 2008 R2 Enterprise: Our solution will be a hybrid relational/cube based planning solution and therefore we chose the Enterprise version of SQL Server. Not only can we leverage the Master Data Services and PowerPivot capabilities if we choose, but the Enterprise version has some specific features that are critical for a planning solution including:
That pretty much gives the introduction into what we are doing. Future posts are going to go more in-depth into how we are using the components I mentioned above as well as some of the v1 features we will be building into the product. So you will see details on end-user interaction, template building, the administration functions and SQL Server design.
Until next time.