You won't find a listing for "Software Architects" in the phone book. Nor will you find degree programs in Software Architecture at the college you attended. Yet increasingly large numbers of software professionals assume the title, despite the lack of a clear, common definition for the role. This is a spontaneous, grass-roots trend—as though our industry is responding collectively to the principle that nature abhors a vacuum. Indeed, we've been constructing huge, complex information structures without architects and without blueprints. Great tools and methods and even developers are useless if no one knows what is being built. Whether a structure is made of brick, steel, or code, the process must begin with a client, an architect, and a plan.

The analogy between building construction and software construction is not new. This analogy hs been used to illustrate points—especially to end users—but has never been fully developed. The analogy is sometimes called simplistic by software theorists, or is dismissed as a way to raise questions, but not to supply answers.

However, at the Worldwide Institute of Software Architects (www.wwisa.org) we believe this simple analogy is profoundly true. And it has the elemental power to transform software construction out of its decades-long crisis. The time has come for the paradigm to shift. The analogy empowers not only software professionals, but nontechnical clients and end users, too. Classically, the architect and blueprint provide a bridge between clients and builders. When a house is being built, clients may know nothing about codes, footings, and flashings. But they can read the blueprint, see if their needs are being met, and ensure that what is being built conforms to the plan.

A plainly presented architecture demystifies the entire development process. It removes the need for blind trust from the client. Instead it presents an understandable and verifiable plan of action. And if the blueprints are not enough, the architect can build an actual model. Conversely, without architects and plans, clients and builders shout at each other across a bridgeless chasm.

Architectural design is far more than an engineering design phase or UI refinement. In fact, architecture strategically leverages the broad spectrum of information technology in the client's favor. This essential truth can evade the kind of software professionals who confuse high-level architecture with technical architectures—of the plans for the whole building with the wiring diagram, and of the role of the architect with that of the building contractor. They fail to see that the role of the architect remains the same despite different design styles, technologies, and materials. And it is the classical role of architect that has been missing from the software industry.

Set client expectations
What is needed before software architecture can regarded as a true profession? I believe we must advance on five fronts:

• Common expectations Software architects need to set a common set of expectations for our clients. When we hire a building architect, we have a set of standard expectations in terms of this person's role, skill set, and the general processes. Without a commonly understood level of professionalism, each architect must set the expectations for the client.
• Standard body of shared knowledge Software architecture must develop a standard body of shared knowledge. This includes theories and practices, as well as the tools, techniques, and knowledge needed to perform as a software architect in a way that meets the expectations of clients.
• Consistent education Software architects need to be educated in a fairly consistent way. We need degree programs in software architecture, because we believe architects should be trained differently than software engineers, programmers, or computer scientists. And the current practitioners of software architecture need to assist colleges and universities since no precedence exists—no academic infrastructure, so to speak. Like continuing education for lawyers, physicians, and engineers, ongoing training for software architects is needed to build our body of knowledge, and to help us consistently meet client expectations.
• Code of ethics We need a code of ethics and guiding principles. More than simply taking an oath; this has to do with living up to the title and building trust between us and our clients—trust that we can meet the expectations set for our profession.
• A means of identity And we need to establish a means of identity. This will preferably emerge as a more modern form of identity than certification or control from some meddling governmental agency. But a place needs to exist where clients can go for grievances or peer review. And, once a profession is established, its members must agree to ethics and expectations.

The WWISA was created to help establish the profession of software architecture. Founded in 1998, this nonprofit, membership organization has grown to 400 members in 34 countries. This insert in Enterprise Development magazine is aimed at anyone interested in software architecture, including WWISA members and other software architects, along with other IT people from the CIOs on down, as well as the "inhabitants" of the software systems we build.

WWISA is thankful to Fawcette Technical Publications for recognizing the importance of the profession of software architecture and for supporting us through this publication. On a quarterly basis, WWISA will present articles written from the perspective of practicing architects, including case studies, interviews, architectural perspectives of technology, and discussions of design. In this way, we hope to do our part to develop a common body of knowledge, educate, and advance the profession. We invite you to read, react, and contribute.