''Architect'' is not a verb; ''architecture'' is the operative noun. 

In the classic engineering disciplines like CivilEngineering, ''design'' is the activity that leads to what we call architecture and implementation. Therefore, design is an activity that produces an architecture and implementation.

It had always been so until methodologists seized these words (in the 1970s?) and started treating them as phases.  We can cynically attribute this to the DisciplineEnvy that seems to have been with computer science for a long time.

To me, design has no well-defined starting point. If design is decomposition, then even analysis has elements of design and includes elements of paradigm.  And design has no end.  Some of the most important elements of design come in the low-level structure of blocks and in garbage collection optimization.  Design continues well into testing (DesignForTestability is certainly popular in hardware, and a few insightful software shops have used it) and maintenance.

Because design lingers into implementation and well into the maintenance of the artifact, its product isn't just abstractions, diagrams, or strategies.  Design produces an implementation; this, too, was the sense in the classic engineering disciplines.  It's true for us, and it should be surprising that we don't often recognize or admit it.

I've studied dozens of development organizations, in many companies, in many countries, building everything from switching systems to aerospace software to spreadsheets. Most of these claim to be ISO certified or to have high CMM ratings. In most of these organizations I study the design process.  When I ask them where it starts and where it ends, an hour-long discussion usually ensues.  When I study their coding process I find that it's difficult to separate the coding and design processes in time.  In many organizations, developers have one window open on their code and another on their design document.  Oh, they still give the appearance of design preceding coding by staging the design review well in advance of their code delivery benchmark.  But, in fact, the code is usually done by that time, and the "coding" interval is usually spent on unit verification--or to complete testing the previous feature.

One quickly concludes that design is not a phase. It's an activity that transcends all of development. -- JimCoplien

----

We've had this debate before, several times, on both the newsgroups and the OTUG mailing list. Jim has nailed it. Design is an activity, not a phase. More precisely, design is a ''type'' of activity. Whenever you try to figure out how to solve some problem, you are doing design. Whenever you try to figure out how to describe a problem, you are doing analysis. Whenever you are actually building the solution (typing in source code, dragging icons around, etc.) you are constructing, but this is a nit. Basically, you perform the activities of analysis, design, and construction throughout the entire project, from the very beginning to the very end. This is as true of software as it is any other kind of engineering. -- ScottWhitmire
----
Actually, it is even more profound than that.  See TheSourceCodeIsTheDesign.
----
CategoryPlanning CategoryAnalysis