| Without question, the number one reason for a software project's downfall is the failure to gather adequate requirements, and gather them correctly. Anyone undertaking a project to deploy BusinessObjects Enterprise must take the time to discover exactly what the tool is required to accomplish. This need is initially defined by the business problem. Remember, the business problem should be considered the starting point for a BusinessObjects Enterprise solution, allowing the enterprise reporting technology to be embraced and extended to an entire organization. Caution Don't get caught stating technical solutions as requirements rather than the true requirements. For example you might state a requirement that: "I want to produce .pdf files from a report." This is actually a solution statement! If you examine why you made this statement, you might see that you thought an Adobe Acrobat (.pdf) file would enable you to share information over the Web. In that case, your requirement should state: "End users can all see the information on Internet Explorer and Netscape browsers on the corporate network." The technical solution to this problem arrives in the next phase, and stating technical solutions instead of actual requirements is a typical and costly mistake. With these points in mind, some of the key questions that need to be considered when defining the requirements for a deployment of BusinessObjects Enterprise involve four concepts: users, user interfaces, reports, and environments. The following lists show the important questions that should be considered: Users How many users will you have? What are the skill sets of these users: business/end users; power users; administrators; developers? How many concurrent users will you have? Where will your users be located? How many users will be viewing reports only? How many users will design reports? How many users will modify/create reports online? How many users will schedule reports? Will customers be using this application? What are the training requirements for administrators? Report designers? Users?
User Interface What look and feel is required for the user interface? Is this look and feel supposed to inherit the company's intranet appearance and functionality? Will users need to input data or will data extraction and delivery be sufficient? These questions will help determine whether an out-of-the-box BusinessObjects Enterprise interface, such as InfoView, will meet end-user requirements, or if customization to InfoView will be necessary. Some organizations develop a completely custom front-end to BusinessObjects Enterprise based on end-user feedback to the previous questions. In the case of the latter scenario, some organizations integrate BusinessObjects Enterprise information delivery as a portion of a larger application, which can involve data entry as well. Do users need alert notification via e-mail? What merits e-mail attention? The alerting capabilities of BusinessObjects Enterprise call out values that merit special attention and can e-mail end users regarding that value. Do end users need to discuss reports or record reactions to reports?
Reports Are legacy reports in use? If so, in which application environments were they created? Identifying any requirements for support of legacy reports will help identify the extent of the BusinessObjects Enterprise solution. Use of the BusinessObjects Enterprise SDK might be required to link new reports to legacy reports. What type of database(s) will be used with reports in BusinessObjects Enterprise? What is the planned or preferred method of data connectivity, ODBC, OLE-DB, native, Business Views, or something else? Are any existing Crystal Reports connected to the target data sources? It's also important to consider the data source connectivity methods provided with BusinessObjects Enterprise. They might or might not match up with organizational requirements. Native drivers provide for many data sources, but some data sources can be connected to only through ODBC. Is a DBA available that is familiar with the required data sources? Do any reports cross data sources? Are complex row- or column-level security filters required? Is the report developed on one database, and then run in production on another? Does the data source contain complexity that should be hidden from the end user or even report developer? All the questions in this bullet point indicate that Business Views should be developed to ease issues around accessing data. How many reports are required? Are enough human resources available with the skill set to develop all the initial reports required by end users?
When setting out to develop reports, consider whether sufficient human resources are available to develop the reports to meet end-user requirements. If not, a third-party consulting organization might be leveraged here to complete report design. One of the biggest challenges organizations have when deploying BusinessObjects Enterprise has nothing to do with BusinessObjects Enterprise itself. It's with the data source. Understanding the database schema and where the actual data is can be the most complex portion of the deployment. This area is one where a semantic layer, such as Business Views or Universes, can dramatically improve report writing efficiency because a skilled DBA works with the database, allowing less skilled resources to develop reports. This both lowers costs and speeds development. How frequently will reports be scheduled? How many total report instances will be maintained in the BusinessObjects Enterprise system? What is an acceptable length of time for reports to process, from initial user request to completion? Also consider how many report objects BusinessObjects Enterprise will store and manage. A report object in BusinessObjects Enterprise doesn't hold any data. The report instances, reports that have been scheduled, actually contain the data. Chapter 27, "Administering and Configuring BusinessObjects Enterprise," discusses this in more detail. Consider that each report instance occupies space in the File Repository Server. If an organization has 1,000 unique reports and allows 25 scheduled historical instances to be held in BusinessObjects Enterprise for each report, that's 25,000 instances! If each instance held a large amount of data, the File Repository Server would clearly need an ample amount of disk space to manage those instances. Determining the target length of time for a report to run might not necessarily be achievable, but should be established nonetheless. If a report is based off a database stored procedure that takes 12 hours to run in the database, it's unrealistic to blame BusinessObjects Enterprise for the report taking a long time when, in fact, BusinessObjects Enterprise has nothing to do with the long report runtime. Bear in mind that ODBC and native drivers affect report runtime; sometimes ODBC is faster and vice versa.
Environment What are the current software and hardware configurations on client workstations? Although BusinessObjects Enterprise delivers information through a Web browser, there are many mechanisms by which this can be accomplished. For example, choosing to deploy the ActiveX viewer with BusinessObjects Enterprise rather than the DHTML viewer can exclude Netscape viewers from using reports. Perhaps the client workstation is actually a mobile device or phone. Where will the database servers be physically located? The specialized roles of BusinessObjects Enterprise servers, such as the Page and Job Servers, can be maximized through effective placement of physical servers. The Page and Job Servers should be placed close to the actual database servers to which reports connect. Close is a subjective word, in that it implies a substantial amount of bandwidth and low latency available between the services and database if reports contain a large amount of data. This reduces the impact to an organization's WAN traffic by isolating communication between the database and report processing services. Will OLAP data sources be required? If so, which OLAP server types are required? OLAP servers imply that another type of report object, OLAP Intelligence reports, will be stored in BusinessObjects Enterprise. Although Crystal Reports connects to OLAP data sources, it does not provide the same robust interactivity in OLAP report and application creation as OLAP Intelligence. Using OLAP Intelligence reports with BusinessObjects Enterprise also implies that the Web Application Server hosting the WCA will require OLAP server connectivity because this is the hosting point for the OLAP Intelligence server-side services. If, for example, an organization were using Microsoft's OLAP server, SQL Server Analysis Services, to stage data in OLAP cubes, OLAP Intelligence would be required, and the Web Component Adapter service would require some level of network access to the SQL Server. What type of physical network is in place? Although most organizations use standard networking components and protocols, such as 10/100 Ethernet and TCP/IP, the speed of a physical network can affect where BusinessObjects Enterprise server components are placed on the geographic network topology. What is the projected growth of the BusinessObjects Enterprise system? What, if any, dedicated hardware resources are available for BusinessObjects Enterprise? Will additional hardware be required? Planning considerations must be made not only for an imminent BusinessObjects Enterprise deployment, but also for how the system might look one year from now. Most deployments of BusinessObjects Enterprise grow quickly because end users like to share the new source of information they have accessed. What are the security requirements for the reporting environment? Determining a strategy for security can be a daunting one because many options are associated with BusinessObjects Enterprise. BusinessObjects Enterprise provides a native security model where users, groups, and objects can be created and managed without the need for any third-party security components. BusinessObjects Enterprise also supports Windows NT or Active Directory security integration, as well as support for a host of major directory servers through LDAP. As a final option, an organization could use the BusinessObjects Enterprise SDK to link in or create a homegrown security model for BusinessObjects Enterprise. BusinessObjects Enterprise also allows the creation of custom administration modules using the administrative portion of the SDK, which allows for certain users to be restricted to various portions of the product for system administration. What BusinessObjects Enterprise licensing model is the best fit? Several licensing models are available for BusinessObjects Enterprise, so understanding the current licensing program for BusinessObjects Enterprise can save your organization some money when it comes time to purchase. On what operating system will BusinessObjects Enterprise be deployed (Windows, Solaris, or both)? Although BusinessObjects Enterprise XI is available on the Windows, Solaris, Linux and HP platforms, some organizations will deploy a "mixed mode" environment, meaning some BusinessObjects Enterprise services or daemons will be installed on different platforms. The Unix versions have a few minor variations from the Windows version. What bandwidth and latency exist between LAN/WAN sites that will participate in the BusinessObjects Enterprise deployment? As mentioned earlier, different server components of BusinessObjects Enterprise benefit through close physical proximity to database servers. It's important to understand the various functions of the individual BusinessObjects Enterprise servers and what data traffic is passed between them. Chapter 25, "BusinessObjects Enterprise Architecture," covers this in some detail. Understanding this will help the BusinessObjects Enterprise system planner or administrator effectively place server components within a corporate LAN/WAN environment to maximize system performance. Will a firewall be incorporated in the solution? BusinessObjects Enterprise was designed with a "DMZ" or firewall deployment in mind. This means that BusinessObjects Enterprise can be effectively deployed in a multiple-firewall network environment with minimal impact to security because all information and reports delivered by BusinessObjects Enterprise can be DHTML. Will users require dial-up to access the BusinessObjects Enterprise system? This might seem like a trivial consideration because BusinessObjects Enterprise delivers reports that essentially amount to Web pages to an end user through a browser. If, for example, an organization chooses to deliver all reports from BusinessObjects Enterprise as .pdf files rather than Crystal Reports as Web pages through the DHTML viewer, a significant feature is sacrificed: page on demand. Page on demand means that only one page of a report is delivered to an end user at a time. If a report contains 3MB worth of data, the user won't notice this because the server opens the report and delivers the requested page of the report to the viewer. This provides a responsive environment for end users, even in a dial-up session at less than 56Kbps. What is the current load and performance of existing Web servers that BusinessObjects Enterprise will use? BusinessObjects Enterprise is not a Web server. It works with most major Web servers or application servers. Although BusinessObjects Enterprise doesn't place a significant load on a Web server, there is some load nonetheless, especially if an organization decides to install BusinessObjects Enterprise on the physical Web server itself. It's always preferable to have a dedicated server for BusinessObjects Enterprise and offload processing onto a dedicated set of servers for BusinessObjects Enterprise. What is the current skill set of system or network administrators that might support BusinessObjects Enterprise?
BusinessObjects Enterprise is a complex enterprise reporting and information delivery product that involves many systems, from databases to operating systems and development platforms. Troubleshooting issues with BusinessObjects Enterprise might not have anything to do with BusinessObjects Enterprise at all. More often than not, issues with reports often lie with database access, operating system permissions, and the like. It's of paramount importance that system administrators understand the spectrum of these issues. The previous list of questions is by no means complete. It is meant to be a solid foundation from which to formulate an implementation plan. Ideally, the temptation to install any software until after this stage is complete can be resisted. Each answer should lead a BusinessObjects Enterprise deployment manager to create an action item for delivery before, during, and after the project. For example, the answer to the question "What is the projected growth of the BusinessObjects Enterprise system?" might be "Company A currently derives about $100M in annual revenue and has 200 employees. During the next two years we hope to double in size." This can lead to the deduction that, although current hardware availability will allow for an initial implementation of the project without further hardware and software purchase or budgeting, scalability planning should be performed or at least considered for future growth. It might be useful to build these questions into a questionnaire format, breaking the organization down into management, users, and IT department members. Submitting a questionnaire or having interviews with the end-user community are exceptional ways to get buy-in from all project stakeholders. Developing the Application (Customizing BusinessObjects Enterprise) Although BusinessObjects Enterprise comes with several out-of-the-box client applications such as InfoView, this doesn't exclude the customization of one of those applications or development of a completely custom solution from the ground up. The good news is if an organization is deploying InfoView without any customizations, this section can be skipped entirely. The development of a BusinessObjects Enterprise application can be very personal. Whatever the approach, it should follow these guidelines: Pick the proper project manager. Someone must be in command. This is not necessarily going to be a promotion for someone into the lofty ranks of a management position; instead, the person in this role must have the authority, knowledge, and character to implement command and control. The size of the project determines how many members compose the team, but their actions should be managed and they must have someone to refer to for information and direction. If possible, the project manager should be able to focus on the application without having to double hat on other jobs. Plan, plan, plan. There are many project planning tools on the market. A company will probably have its own standard. Whether planning is done on a piece of paper, on a spreadsheet, or in an application, it is another cornerstone of a successful project. No plan survives the first shot of battle, so it is important to keep in mind that this is a work in progress. Without a plan, coordination is impossible, chaos prevails, and the project stands a good chance of going off track. A project plan should involve the following: Build the project team. The project team's skill set must be put together very carefully. If internal team members cannot be found, outsourcing should be considered as a very cost-effective way to improve chances for success. In most cases, consultants with proven track records using the technologies surrounding BusinessObjects Enterprise increase the chance of the project's success. Keep an eye on the prize. Begin with the end in mind. After the project has started, the project manager and team members must be sure that they understand what the end goal is. Control change. Change is inevitable, and the longer a project goes on and the more complex it becomes, the more likely change will occur. Change is a good thing. Without change you would be back where Ug started his tusk movement improvement project. The important thing to remember is that change must be controlled. Team members need to be encouraged to share their ideas and think outside the box. However, a process must be in place to manage this and be sure that any new changes are implemented with the support and knowledge of the project team, management, and end users. Another result of ignoring change management is the bane of any project, scope creep. Scope creep occurs when a project's deliverables, functionality, or look and feel extend past the project plan and definition. Scope creep can blow budgets away, extend project timelines dramatically, and can lead to bad morale on the project team. One good example might be a specification to customize the look and feel of the DHTML viewer. A corporate logo is to be applied to the background of the viewer. After the addition of the logo, the end users ask whether each individual icon image in the viewer can be changed to match other images the company has, such as product images. Although this might seem trivial and seems to add little value to the overall solution, it could set the deployment timeline back at least half a day. Table 26.1 is an example of a change control matrix. Table 26.1. Change Control MatrixChange Number | Description | Requestor | Assigned to: | Completed on: | To Test (date) | Tested by: | Released to and Date: |
|---|
1 | Provide top 10 customers parameter | Dawn Gugoi | Paul Kooker | 4/24/04 | 4/26/04 | Tess Tor | 5/5/04 |
Control risk. Risk mitigation is another cornerstone of success. The key to this mitigation is the ability to spot risk before it happens and plan ahead to be sure it does not happen. A useful way of doing this is to use the simple matrix shown in Table 26.2. Table 26.2. Risk Control MatrixTop Ten | Risk | Chances of It Happening (15) | Damage to Project If It Does Happen (15) | Risk Multiple | What to Do About it |
|---|
1 | Server hardware takes four weeks from order | 4 | 5 | 20 | Be sure server sizing is completed by week 2 and pass to procurement by week 3 |
Get end user buy off ASAP. User acceptance is the make-or-break point of a project. If users do not like what they are given to use on a daily basis, the project will not succeed. It will be relegated to the recycle bin very quickly. Involve users whenever possible from requirements gathering and development and training. Also give users the capability to provide feedback after the application is deployed. Set up environments. Development of your application will be iterative and should go through a process to ensure that users get what they asked for. The standard formats for application development environments are Sandbox (sometimes used) Initial proof of concept testing and development. Development Phased development and testing. Strictly controlled, versioned environment. Test Beta testing only. No development should occur here. Any faults and bugs should be referred back to the development team and tested again in development. Production Application in everyday use.
Documentation. The application development process must be documented at all stages to ensure that if it needs improvement, if key project members leave, or if bugs need to be identified, people are not hunting around for the answers, wasting time unnecessarily. This documentation should be controlled by the project manager, and can also be used by training departments for the education of users and administrators.
Completing User Acceptance Testing and Deployment This phase should deliver the 99.9% finished application to a defined user base. End users should take the BusinessObjects Enterprise application front end and follow a testing script that is given to them at the beginning of the phase. Users then should document and return their findings to the project team, and any last-minute changes will be made to the code. This process could go through as many iterations required for the users to finally put a check in the box that says, "We are satisfied." As mentioned previously, user acceptance ensures a successful project. When the users are happy, the application can be deployed in a production environment. Moving to the Support and Maintenance Phase After the application enters production, users should know who to call for support. This can be achieved through access to defined members of the project team, an organization's internal support desk, or an outsourced tech support organization. The BusinessObjects Enterprise application manager should keep a log of issues, bugs, and any user feedback so that, where relevant, this information can be implemented in the current application and any future releases. |