I thought I would share my expertise and experience on best practices in planning a new deployment for a reporting environment. I have had a ton of experience with many different organizations and industries, worldwide. I have seen alot of successful deployments and I have seen alot of…well…unsuccessful deployments.
While much of what I am about to discuss could be applicable to any software deployment, I will focus this specifically on a IBM Cognos BI, IBM Reporting for Development Intelligence and IBM Rational Insight deployment. There are many different aspects to take into consideration when you are trying to scope and plan a new reporting environment. Here is my advice on what you should do.
Start small and grow big!
You cannot address all of your needs or solve all of your problems in the first phase of your deployment. It is a common mistake to onboard too many users too quickly or over scope the initial deployment. This can lead to many issues including performance problems, server stability, user frustration, an abundance of problem tickets and even canceling the entire project effort.
You should take an incremental approach to your deployment and you will should do this in an iterative fashion. First, you need to scope a type of topology based on your current, and what you believe to be, your future needs (eg clustered , non-clustered, IHS server/Cognos Gateway or a standard distributed environment). To do this, you need to review your overall business goals, translate those to operational objectives and then break those down into individual tasks.
Here are some questions you should address when attempting to plan for a new Reporting environment:
- What are my expected number of users in the first 3 months, 6 months, 1 year?
- What types of reports will these users be running (live, trend, saved)?
- Will the reports be run individually or through dashboards or schedule and emailed to stakeholders?
- Will my users be accessing the Report server directly or through another interface (eg Rational Team Concert dashboard)?
Once you have understood these items and identified your topology type based on this, you now have the foundation for your initial deployment (note: it is possible to change your deployment topology after the fact, such as going from a vertical to horizontal cluster). Remember, start small and grow big.
The next thing you need to do is identify a small set of users (eg ~50) who will access the deployment as early adopters. You also need to identify a small set of reports (eg 5-10) to develop and deploy into production for use. Again, do not try to do too much too fast. History and experience has shown me that this approach of trying to do too much too fast has a significantly lower percentage of success.
Once you go live with your initial deployment, you need to closely monitor it and look at these key elements:
- How are my servers performing?
- How are my cpu and memory utilization?
- Are my servers crashing?
- How is the network behaving?
Usage model / User activity
- Are my users consuming the solution as expected?
- Are they logging into the Report server portal directly?
- Are they accessing reports through other means such as a Rational Team Concert dashboard widgets?
- Are they scheduling reports and having them emailed to stakeholders?
- Are they running individual reports or viewing a dashboard of reports? How many reports (and what type) are being run in each dashboard?
- What are my users saying? What is their experience with the deployment?
- Am I getting alot of problem tickets or emails about errors?
- Are they getting any value from the deployment?
I highly recommend that you set milestones for your deployment. Here is an example of a high level roadmap. This is just an example! You can scale this however you deem appropriate so long as you start small and expand incrementally.
As you progress through milestones, you should be making adjustments based on your observations of what I mentioned that you need to monitor. You may find that you need double the amount of servers you had scoped. In this case you would either need to expand your topology quicker or onboard users at a slower rate. You may also find that you have more than enough of power within your server environment. In this case, you could either scale back a few servers, downgrade some of the machine specs or onboard more users at a faster rate.
The key to success is to start small and grow big!