9 Thou shalt plan for change

#9 Thou shalt plan for change

The best developers and architects plan for change during all phases of the software life cycle. During the course of an average one year development cycle, not only will the design be subject to change, so too will the user requirements, the development tools, the third party software libraries, the DBMS system, the operating system, the hardware, the network, the programmers, and many other aspects of the application that cannot possibly be foreseen or otherwise planned for. Some aspects of change, such as a new release of the operating system, can certainly be planned for by discussing schedules with the vendor and making a decision whether a new release should be installed or not. Sometime during the application's life, however, the underlying operating system will probably have to be upgraded so it's really just a matter of when changes such as these are done. In either case, you still have to plan for the changes.

The longer the expected project lifetime, the more important it is to plan for change. The Cassini mission to Saturn, operated by JPL, was launched in October of 1997. With any luck, the spacecraft will enter orbit around Saturn in 2004. The JPL engineers running the Cassini ground station definitely must plan for changes in hardware and software prior to the spacecraft's encounter with Saturn in 2004. Any company that designs a long lifetime product with an embedded hardware or software component must pay careful attention to planning for change. Back down on earth, for instance, every high-end Xerox printer contains an embedded workstation controller. Typically these workstations are commercial off-the-shelf products with an average lifespan of eighteen months. Xerox high-end printers are designed for five to ten or more years of continuous operation. Xerox must plan for change in the embedded workstation component for each of its printer lines.

There are many ways to plan for change. For starters, allow extra budget and schedule in your project for unforeseen changes. At the start of the project, work to clearly identify all risk items that could lead to a possible change somewhere in the future. During the design, look for ways to mitigate the risk of a change further downstream. At the coding level, look for ways to quickly and easily set up code to be adapted to new situations and events within your business. For instance, use tabular definitions whenever possible versus " hardcoding " these parameters into your code. Here is a real life example of two companies that implemented the same application, and how they did (or didn't) plan for change.

We worked with two companies of about the same size that implemented the Oracle Financials application package in early 1997. In both companies, various business units wanted to modify the standard financials applications to meet some unique need of the business unit. Much of Oracle Financials operation is table driven with those tables residing in a DBMS. The IT department thus entertained each business unit's request as most of the changes could be done by a database administrator with little or no coding. The first company went ahead, approved, and implemented the customizations for each business unit. In the second company, they planned ahead for change and considered what the impact of making the customizations would be the next time Oracle Financials came out with a major upgrade. The latter company decided the marginal business benefits of providing the customization was outweighed by the future costs to maintain these upgrades.

Well, as you might guess, in 1998, Oracle Financials released a major revision, based on their Network Computing Architecture (NCA). With NCA, the Oracle Financials client could be deployed via a web browser, versus loading client software on each desktop requiring access to the application. NCA offers tremendous business advantages to corporations through reduced application administration costs along with the improved functionality that is bundled into the release. The company who did the customization is still evaluating how to roll out Oracle's NCA as the customization they performed prevents a simple upgrade and the DBAs who did the initial customization are not yet trained on NCA. By contrast, the second company, with no extensive customization, was able to complete the upgrade to NCA in a single weekend . They have been enjoying the added functionality and client administration cost savings ever since.



Software Development. Building Reliable Systems
Software Development: Building Reliable Systems
ISBN: 0130812463
EAN: 2147483647
Year: 1998
Pages: 193
Authors: Marc Hamilton

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