| A few lessons learned regarding prototyping appear below. -
Limit the scope: Limit the functional scope as well as the data scope of each prototype iteration to a specific subset of the application. This helps to focus the business people on one small piece of their overall requirements. They can learn about the capabilities and limitations of the new environment without getting bogged down with the complexities of the whole development effort. It is also a good general training indoctrination in how to use the new technology and the new application. -
Understand database requirements early: The prototype will help the database administrator understand the access path requirements to the BI target databases, the reporting dimensions needed for application development with online analytical processing (OLAP) tools, the levels of aggregation and summarization needed, and what type of data is usually accessed together. The database administrator will be able to start making some database design decisions, such as how to cluster tables and where to place the data sets. The database administrator will also get a sense of the performance expectations and the anticipated size of the databases. -
Choose the right data: Carefully select sample data for the prototype. The sample data set should be a meaningful representation of the source data so that all functions and features of the prototype can be tested . Keep the sample data set small so as not to spend too much time on loading and testing. Try to select clean data for the prototype. You do not want to have your prototype results tarnished because of dirty data. You also do not want to take the time to cleanse data while creating the prototype unless the purpose of the prototype is to test your transformation logic or the transformation functionality of an ETL tool or a data-cleansing tool. -
Test tool usability: Test the usability of the access and analysis tools. Make sure the query tools are easy to use and do not intimidate the business people who need to use them. Test the features of the report writer on one of the more complicated reports . Give the business people hands-on experience with the OLAP tool. Although multidimensional analysis is relatively intuitive for most business people, the capability of dynamically drilling down and rolling up with a tool is still a new experience for many. -
Involve the business people: Test the prototype with more than one business person. Try it with a single business person first, then add more business people from different business units or departments. Be sure to measure the performance of the prototype as you add more people. Observe the business people while they use the prototype. You will be able to see how they react to the prototype when you test it with them. Address any difficulties or misgivings immediately so that the problems do not become roadblocks during application development. Considerations for Prototyping To build a successful prototype and to produce the optimal physical database design, the prototyping team must first understand how the business people will retrieve the data and what they will do with it. The team members should ask such questions as the following: -
Are there frequently asked business questions? -
What dimensions of the data are prevalent on reports? -
Are there reporting patterns among departments? Prototyping is a useful technique to ensure that the business people and the prototyping team understand and agree on the functional business requirements. A prototype could also ensure that everyone agrees on what is expected from the final BI application. Important considerations about developing a prototype are briefly described below. -
Prototyping team: The prototyping team should be small. One of the many reasons why some software companies have become successful is that their project teams are very small. They do not staff their projects with more than seven or eight people. -
Deadline management: When project teams routinely miss deadlines, shrink the size of the team. This is exactly the opposite of what many organizations do. Most organizations put more people on the team, which usually backfires because more people require more time for communication, and that slows down the project even more. By shrinking the size of the team, the people remaining on the team may have more work to do, but they will get things done faster. -
Scope: Try to build "slimware," that is, deliverables with the barest number of features possible to satisfy the purpose of the prototype. This can head off "code bloat" down the road when the application code needs to be written. -
Deliverables: Each prototype should have a well-defined deliverable . Plan to use an iterative process for prototyping, and try to control the activities on each prototype iteration in weekly increments with weekly deliverables. -
Delivery methods : Test the graphical user interfaces (GUIs), Web-enabled interfaces, and other delivery methods. -
Data integration: Try to have only a few data integration requirements in your prototype scope. Prototyping should not be used to address all project requirements but only to get a basic understanding of the major deliverables. -
Business participation: The prototype should include at the most five to eight business people. Consider the politics involved in selecting the right blend of business people for the prototyping activities. -
Success criteria: Encourage business participation in the prototyping process from the beginning, especially during the activities of needs assessment and GUI construction. Be sure to include the business representative and the business sponsor when establishing the success criteria for the prototype. Remember, their definition of success or failure is the one that counts. You may also consider building a coalition comprised of the business representative and the business sponsor, IT managers, and other senior business managers who will support the BI project beyond the prototype. Before starting the prototype, review the Things to Consider section at the beginning of this chapter to determine the overall scope of the prototype, the prototype's purpose, how many business people will participate, and the level of complexity. Use this information to carve out and focus on one or two essential functions that have the highest payback.  |
