The software landscape is a mixed field of successes and failures. Along with notably successful software packages for every task from payroll to party invitations, we find notable failures, some of them spectacular. As one measure, a 1979 US Government Accounting Office review of nine software projects for the Department of Defense showed that about 2 percent of the allocated funds were spent on software that was delivered and in use, about 25 percent were spent on software that was never delivered, and about 50 percent were spent on software that was delivered, but was never used (Neumann, 1995). This example may represent an extreme case, but everyone in the software industry knows that such problems are widespread and are of large magnitude. Software engineering---a discipline of designed invented in the 1960s to address the “software crisis”---has unwittingly created an illusion that a rigorous process of transforming requirements into systems is the key to reliable design. With this illusion comes a false sense of security that the solution to the crisis is at hand--- and that we will obtain it faster by throwing more research collars at the problem.
We believe that the shortcoming is not due to a lack of effort or intelligence among software practitioners. We believe that the problem is of a different kind -- that the standard engineering design process produces a fundamental blindness to the domains of action in which the customers of software systems live and work. The connection between measurable aspects of the software and the satisfaction of those customers is, at best, tenuous. We propose a broader interpretation of design that is based on observing the repetitive actions of people in a domain and connecting those action-processes to supportive software technologies. We call this activity action-centered design and we propose it as the basis of a discipline of software architecture.