|
Architecture Is in Your Best Interest
Decide limits on application performance and reliability well before you write any code
by Peter Varhol
June 27, 2005
The application development life cycle is pretty well defined, and most software development groups follow some variation of it. First, the need is identified, followed by a set of requirements for a software solution. The architect, or application designer, depending on your nomenclature and skill, defines the functions needed by the application and lays out a schematic for building the application and mapping it into the enterprise infrastructure.
Developers code according to that schematic until all of the functions have been included and most of the bugs have been removed. Finally, the application is turned over to testers, who may be formally testing against requirements, or simply looking for bugs. However, by testing the working code, they typically find bugs and other defects, which they characterize, record, and return to development for resolution. Depending on the quality standards used by the group, this back and forth can consume months of time for a single software release.
Within this traditional life cycle is the foundation of the problem. Frequently the testers are the first to test any part of the application against nonfunctional requirements—those requirements that work not with features but rather with the responsiveness, number of concurrent users, or uptime. And guess what? They frequently find that the application has defects, or does not scale to the required number of users, or doesn't respond quickly enough to be convenient. So the application goes back into development, where it is profiled, poked, prodded, and coaxed into somewhat better shape, but often not where it needs to be. It is deployed anyway, and users make do, or it is scrapped as yet another application development failure.
Back to top
|