Developers can get too focussed on elegant system architectures evolved with the simplistic motivating forces of immediate cost, time and a description of supposed "user requirements".
Mark Carroll, of Microsoft Corp., presenting to the local chapter of the Worldwide Institute of Software Architects recently, made a plea for an appreciation of the bigger picture and a sharper analysis of other factors which are often "bundled into a general category called 'risk'."
Attention from the beginning to factors such as skills availability and staff aspirations, standards alignment and the availability of third party solutions for part of the problem are often given scant attention, he says, and few developers have a systematic way of taking them all into account -- an impression confirmed by a straw poll of the audience.
If you develop using an effective but unpopular tool, he says, you risk limiting yourself in terms of the skills and outside advice available. Staff and contractors may also be discouraged from taking the project on because experience of such a minority tool adds little to the CV.
Using third party products and services optimally not only means part of the solution is developed in advance, it also opens a fund of expertise in the outside supplier's staff, who can advise on the best way to connect their offering to the rest of your system. This saves the developer a lot of "homework" boning up on a product's features. A poor choice of third party product, on the other hand, can trap a development into severely restricted choices.
Attitudes to standards and methodology range from regarding them as the "Holy Grail" to dismissing them as hogwash. The truth is halfway between, Carroll suggests. "They are not a religion but a risk mitigation strategy." At the least their use earns a "compliance tick" from government and many companies, while neglect means if the system has problems the developer "gets caned" for not adhering to the standards, whether that is the true reason or not.
A "user requirements" document is often the basis of a development, but Carroll says both the commissioning client's requirements and the end user's needs should be separately considered. As a bad example, he cites one system he knew of which met all the client's functional specifications but infuriated the end users because it was based on a web interface and they could no longer drag-and-drop, as they had been used to doing with the earlier system.
The ability to build and deploy a system quickly is naturally vital, but equally attention should be paid to long-term life expectancy. The software at the heart of the system will inevitably date, and customer requirements will change to the point where the system can no longer be updated. Quantification of this in the early stages can be of great value in building a business case; business cases are judged by accountants, who understand the concept of depreciation.
"Talk to the accountants before you construct your business case and learn how they will measure it. There are about 15 different ways of calculating cashflows and net present value. You need to know which they will be using."
Taking all these factors into account from the beginning yield information that can be fed systematically into an evaluation of the project which can then proceed to implementation with greater confidence of success. Reviews later in the life of the system to establish the need for and cost of changes are also likely to run more smoothly. The cost of "retiring" the system at the end of its life and moving to something new should also be factored in from the beginning, Carroll says.