The systems development life cycle has been around for as long as computerized applications have been built and is all too familiar to most practitioners. Although it can be articulated in a number of ways, it basically consists of defining the requirements of an application, then analyzing the business problem domain, then designing an application, then building it, then testing and debugging it, and then running the application in production. There are a number of variations on this theme, such as a final obsolescence phase or iterative building, testing and debugging steps. A major problem, however, is that the systems development life cycle looks very hit-and-miss if you compare it to other engineering activities such as building bridges or aircraft. Bridge builders and aircraft designers certainly look at requirements and do design work, but they create detailed specifications that are used to build things in a way that never seems to happen in software development. In fact, the way in which we do software development never rises to the level of true "engineering" despite new methodologies that seem to come along every couple of years. These methodologies often promise that they will supplant the traditional systems development life cycle, but always seem to end up just being variations on it. There are legitimate grounds to ask if the business rules approach is just another variation to dealing with business logic, or if it really does not fit with the systems development life cycle. We may have to wait a while to get the definitive answer, but there is evidence that the business rules approach does not fit the systems development life cycle.

The programmers of today may work in a high-tech arena, but the way in which they do their work often seems to resemble the practices of medieval craftsmen. There is surprisingly little automation and not many good productivity aids. Everything seems to require attention and work by humans, and all work products have a "one-off" feel about them. There is some division of labor, but making sure that a team of programmers works together effectively takes a lot of management effort. The result of these efforts is hand-crafted program source code, some of which can be of very high quality, but much of which falls by the wayside. As a friend of mine is apt to point out, scrap software, unlike scrap metal, has zero value, which is a pity because there is an awful lot of it. It is my belief that the systems development life cycle is inevitable if business logic is going to be implemented by labor-intensive programming activities carried out by human beings.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access