Business Intelligence, Done Right
October 14, 2008
Business Intelligence efforts often fail, not because of the technicians, but because of the disjointed relationships we (IT) have with the business. We fear relationships. We think that our investments and communications are a waste of time because we have a tremendous amount of downward pressure to deliver – so we start quickly and build according to some document that we substitute as face time with our partner. To fix this problem, we need to take the best part of our building experience as ITers and put that together with the best part of relationship management – skills that we often don’t posses, but are vital to successfully delivering value and meeting our partners expectations.
{more on “The Right Way” below}
Kimbal’s methodology calls for the segregation of the three layers of BI and this is fantastic. There are in fact three separate BI tracks that can and should run concurrently. The three tracks are:
1. Technical Architecture
2. Data Architecture
3. Application Architecture
After all, we need to make progress on the technical choices of architecture and tools. What is our environment like, what standard tools do we use, what is our technical strategy to frame and contain our BI effort?
At the same time, we need to start looking at our data. What data will we need to work with, what is it, how should it relate, where does it come from, how do we extract, transform and load it. These are considerations of the data architecture effort.
Again, at the same time, what level of innovation do we need to arrive at? How do we present this to the user and provide the desired interaction to help mine data to craft information.
Kimbal’s Methodology
This methodology is right on! It is triggered by and the scope is managed by the requirements. These requirements are derived from that box that is labeled “Program/Project Planning”. But it’s not enough, it’s not there yet! In my mind, this is a bit limited and really only addresses the “Go” portion of the project – to build. All too often, BI projects fail because of thing that are ‘above’ or before the Go. Here is what I have found to be the differentiating factors.
Requirements should be built from Strategy. Why are we building this BI application? What are the important questions that need to be answered? What is the value that these answers bring; are we making things better or faster or cheaper? A well formulated strategy addresses these questions and should manage the deliverables. When we rely on a set of requirements to build a BI solution, we are abstracted from the strategy and this is not good. When this abstraction occurs, we are removed from the business value and are relegated as a commodity…simply build to this specification.
However, strategy is not born without a birthing process. The birthing process consists of a couple of elements. The first is an alignment or a focus at most senior levels. If we can’t align on the true aspects of the business, we are forced to work in a vacuum and can, at best produce a solution that is severely slanted. This slant often caters to the loudest voice or the biggest ego. Worse, our solution is then forever raised in a silo that contributes to expensive growth and maturity with a limited enterprise appeal. If and only if we get this alignment, we are doomed to deliver value slices rather than holistic value.
This alignment is not enough. After we have a focus, we then have to dive deep within the organization to see what raw materials we have to work with. I refer to this phase as ‘Discovery’. Once we are aligned and focused on the business value, what do we have to work with? What data exists in what format and at what availability and quality?
To state this concisely, we have the following necessary phases that will lead us to success.
1. Alignment – A common focus with enterprise level buy in.
2. Discovery – An exploration to ascertain our resources and an evaluation to ensure it supports the common focus.
3. Strategy – The actual strategy that is an outcome of “What do you want” + “What do we have”.
4. Requirements – The plan of how to get there from here.
Now, we are ready to “Go” forth and multiply! We are ready to build! And we know what we are building (requirements) and how the effort will benefit the organization (strategy). We know what we really have to work with (discovery). And finally, we have those committed at the top who are committed at the deepest levels of the effort and will both support/defend the effort as well as ensure that its accepted and reused across the enterprise.
Putting it all together, let me suggest the following methodology…
Sometimes we are asked “Why are you just sitting there? Do something!” We need to rally and fight the urge to just do something. We need to change that around as ask “Why are you just doing something? Sit there” (and get focused, aligned, discover, produce strategy, birth requirements…then we can “Go” and do something excellent).
The difference between a commodity and a partner is the level of time you invest in the relationship.
Take the time to do it right and it will be celebrated!
The next series of blogs will outline the above components; alignment, discovery, strategy, requirements and the three team approach to building BI solutions. Feel free to shoot me some questions or thoughts you may have regarding these topics.
Enjoy the ride!
~ Scott Felten
Expanding Your Box
April 15, 2008
My wife and I were sitting on the couch the other night and she was complaining that her sweat pants were fitting to tight and cutting into her stomach. Oh did I mention that she is seven months pregnant with our first daughter. Anyway, we were sitting there talking and she suddenly asks ‘Don’t you have sweat pants?’. I said ‘sure’ and she went off to look in the closet. One thing you should know is that even pregnant, I have still have 100+ pounds on my wife. She came back later extremely happy. She had found a pair of my sweat pants and had them pulled up over the baby bulge and fitting comfortably. She looked funny, but she didn’t care. She had solved her problem.
Why do I bring this up? My wife is one to follow her usual processes. Clothes don’t fit = go shopping. She has bought her share of materity cloths, but is becoming more concerned about saving money. She had a problem, but didn’t want to follow her normal process and go shopping. She began thinking outside her ‘box’ of solutions can came up with something that resolved her problem and saved money. (Yeah!)
When developing solutions to IT problem, it is easy to get stuck in your ‘box’ of solutions. It is easier to stay in your comfort zone and create solutions based on what you have done before rather than venturing out and trying new things. I fight with this all the time. I recently had a client that needed to add an admin page to view user account information. They did not have reporting or direct access to the database. If I add a page to the site, then I have to secure it from other users. This can quickly add up to some development time doing the standard solution. What if I extend my thinking outside my ‘box’. They have SharePoint which is used to feed list information to the web site. Why not add the view user page in SharePoint? Security is already setup and they know how to use it.
With the pace that technology and development tools are changing today, it is hard to keep up with everything. It seems like there is a ‘best new way’ of doing something each year. Don’t get comfortable in your ‘box’. Try new technologies. Think of how this new tool can be used to solve problems in place of your old way. Read articles, attend user groups and talk to other people about the new technologies. Get an idea of what they do and how they might be useful to you. You might be surprised on how well they ‘fit’ your problems and can be added comfortably to your ‘box’.
Jeff
More Than Practice
April 11, 2008
Yesterday, my fellow colleague Jeff Morris gave a great presentation on development best practices. Since we had a small group, the presentation quickly turned into a fun and engaging discussion as we exchanged stories and thoughts.
Topics covered:
-
Logging – Be sure to capture those pesky errors and handle them with style.
-
Testing – Trust your code, but verify that trust.
-
Comments – They are only as helpful as you make them!
-
Reviews – Review the application’s functionality, logic, and code as often as possible.
-
Consistency – Use templates and standards.
-
Development Process – It’s important to have a method to the madness.
-
Documentation – Try to make something that will stay alive.
Ignoring these practices will undoubtedly cause a lot of pain and headaches. It is also important to be realistic and remember that constraints (time, money etc…) can make following all of these practices extremely difficult.
When it comes to best practices, the list could go on and on. Each one of these practices represent a building block for success. In summary, creating a solid application requires solid development practices.
Don’t Make Reporting Just An Afterthought
April 10, 2008
When your faced with all the planning, designing and development involved with building a new application, reporting can just become an afterthought on the project schedule. I’ve been on many client projects where reporting is just a week slapped on the end of the project schedule. “We just need to create a few reports and we are done.” This is not true if your building a system of any size or complexity. Ask yourself why the system is being built. All that work to store data and build an interface to input the data, what is it all for? It is to create reports for the business to analyze how the company is doing. A company runs and survives on the quality (and quantity in some cases) of it’s reporting. CEO’s and business leaders rely on these reports to validate the health of the company and steer it’s direction. Do you think they want to hear that everything they rely on was just and afterthought!
Reporting systems can get really complex when you are dealing with business people who like to ‘slice and dice’ the data. It seems like they want 20 reports to slice the data every way possible. Executives don’t want all the detail, but want everything summarized, categorized and broken out by time. Once the business hears about a new system in development, requests for specialized reports above the “10 standard report” you planned can drive development into overtime. The work loads increase, but the amount of time does not. Add on top of that the need for securing the reports based on roles, teams or other categorization. Extending your application security model to include reporting can add time to your already crunched project schedule.
You might think that just starting work on the reporting system earlier will give you plenty of time to address the issues above. That is true, but starting reporting to early in the project schedule can cause other issues. If you start development earlier you will need to plan for reporting to take more time. SAY WHAT! If the main application and database is still in development, things are going to change. Fields are changed, flags are added, data is incomplete. All these thing effect the ability to create a correct report the first time through. As the design of the application changes, reports will need to be changed also. This takes more time and extends the reporting schedule.
There is a positive to starting reporting early. The reports that are created can be used to help validate the system in development. I worked on one project where the business leaders kept coming to me and telling me that the reports were validating were wrong. As I analyzed the data, I found problems with the interface and/or database. Once the issues were corrected, the report was correct. Having reports to validate the system during development can be very useful, especially if you are migrating records from an old legacy system to a new system. Making sure you have all the data and you can match numbers from the old system is critical.
The point of this post is to get you thinking about issues around reporting that may cause delays in your project schedule. I’ve brought up a number of problems, but what can be done about them? Here are some suggestions.
- Don’t make reporting an afterthought. The reporting system can be as critical and complex as the application.
- Allow enough time in your schedule for proper requirements from business leaders. Make sure you are meeting their needs.
- Allow time to do proper architecture and design of the reporting system. Factor it into your security model design.
- Design reports that meet the business needs. A report no one reads is a waste of time.
- Combine reports where you can. Create a single report with more parameters to allow the business to ‘slice’ the data without you needing to maintain 10 copies of a report for different users.
- Write efficient code. If your using sql, spend the time to make sure it if quick and efficient. Speed counts.
- If you are replacing a legacy reporting system, make sure you analyze how the old reports where put together. You may need to match those numbers with the new system.
- Work with business leaders and executives to make sure you are providing the information they need in a format they can use. If they can read a report or two and get everything they need to know, they’ll love you for it and it will help validate the cost of your reporting effort.
- Know you data. I tell anyone who writes reports for me that they can’t write quality report if they do not know and understand the data. SQL is a language that makes it very easy to get the wrong answers.
- Validate your data. You can’t get a correct report with wrong data. Test and development systems need to have real data and lots of it.
- Set expectation with leadership. They need to understand why extra time (and money) is need to create a proper system.
Proper reporting can be the lifeblood of a company. Don’t make it just an afterthought.
Jeff
Why Cats Don’t Make Good Developers
April 2, 2008
Here at LUCRUM we are always looking for ways to provide the best value to our clients. Outsourcing development to India and China can be difficult and is becoming more expensive. We have been conducting research into a new development model to provide our clients greater value for their IT dollar. Our research unfortunately has not returned the results we hoped for, but I thought the results of this extensive research should be shared. Here is why cats do not make good IT developers.
-
Regular flea dips required to squash bugs
-
Excessive requests for nap time cause productivity problems
-
Each one thinks they write purrrrrrrfect code
-
Keep chewing on the mice
-
Tuna breath
-
Delays due to periods of hyper-activity (note to self: catnip *AFTER* work)
-
Equipment gummed up with hairballs
-
Design meetings often result in a lot of hissing and caterwauling
-
Sharpening claws on office furniture
-
Don’t get along with the new dog application testing department also being researched. Research to be published later.
-
Team management forbid from bringing tuna for lunch. There was an incident. Wasn’t pretty.
 |
Bringing the lighter side of LUCRUM- Jeff |
| Lily is expert in .NET, SQL Server and is learning SharePoint 2007 | |