The Application Release Concept


BI projects introduce many new practices: new techniques for business analytics, new prototyping techniques, new design techniques, new architectures, and new technologies. These practices are relatively new not only to organizations but also to the information technology (IT) industry as a whole. In addition, BI projects usually involve a significant level of capital investment. All of these factors add up to make IT managers and business executives quite anxious. When a BI application does not turn out flawless or is not complete on its initial implementation, some IT managers and business executives get very unnerved.

A major shift must occur in how IT managers and business executives approach BI projects. The approach of "get it right the first time" has never worked, even though people have pretended for years that it does ”or that it should. That misconception should have been put to rest long ago. No major invention or significant endeavor has ever worked right the first time. Usually, good things evolve over time. Nature evolves. This fact is generally accepted. Technology evolves (Figure 16.1), and this fact is also accepted. But the truth that software evolves as well is usually not accepted, at least not when the software is developed in-house.

Figure 16.1. Evolving Technologies

graphics/16fig01.gif

When software is purchased from a vendor, it seems to be more palatable to accept an imperfect and evolving product because a software vendor never promises that the first product release will be the last. Vendors also never claim that their software products will not have to be enhanced; on the contrary, we want them to be enhanced. Why, then, do we have exact opposite expectations of internally developed software?

For example, when vendors publish a new release of their products, they include new functionality, new screens, new modules ”and of course some fixes to defective parts of the prior release. Sometimes, the new software release is completely redesigned and is not even compatible with the previous release. We do not hesitate to pay good money to upgrade purchased software products under those conditions. But when the in-house IT technicians have to redesign a BI target database or portions of a BI application after the third or fourth release, the situation is treated like a disaster. Organizations must accept the fact that internally developed applications evolve over time, just as vendor software products do. Hence, it is high time to embrace the application release concept.

Guidelines for Using the Release Concept

When developing BI applications under the release concept, IT and business management must agree on and follow some basic guidelines (Table 16.1). When following these guidelines, there should never be any concern about the completeness of a BI application on its initial release. Any incomplete functionality that was negotiated out of the scope due to unforeseen roadblocks will be bundled with new functionality in the next release or some future release. Business management gets to decide how long to defer the functionality, and the decision will probably be based on the priorities of outstanding requirements.

Table 16.1. BI Application Release Guidelines

Dos and Don ' ts of Application Releases

  • Releases should be delivered every three to six months (the first release will take longer).

  • Releases must have very small and manageable deliverables.

  • Expectations regarding deliverables must be managed continuously and must remain realistic.

  • A release does not have to equal a completed BI application. It may take several releases to complete a BI application.

  • The first release of a BI application should deliver only the basics.

  • Business management must be willing to accept a partial delivery of a BI application (e. g., the basics).

  • Nothing is cast in concrete. Everything is negotiable. That includes scope, schedule, budget, resources, and quality.

  • The enterprise infrastructure, both technical and nontechnical, must be robust.

  • Meta data must be an integral part of each release; otherwise , the releases will not be manageable.

  • The development process must be sound and flexible. Developing releases feels like prototyping, but the effort is more disciplined and controlled because the results are treated as production-worthy deliverables.

  • Designs, programs, and tools must be flexible to allow for occasional redesigns of BI target databases and BI applications.

  • New requirements must be triaged and prioritized; scope is strictly controlled and kept small for every BI release.

  • Small errors or defects are addressed under strict change-control procedures during the development of the release.

  • Large errors or defects are deferred to another release by removing the function or data associated with the problem.

  • When deferred functions or data are implemented in a future release, business management must prioritize the sequence of delivering the deferred requirements.

graphics/hand_icon.gif

If time is a critical project constraint, using the release concept to deliver a partial application of high quality is much better than delivering a completed application with many defects and dirty data.



Business Intelligence Roadmap
Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications
ISBN: 0201784203
EAN: 2147483647
Year: 2003
Pages: 202

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net