Design should be an intention, preferably a planned intention. In that intention, design requires more groundwork than a simple thought-train such as the following, "I planned to write a module that functions; since the module functions, my designs are working." Some situations do exist where true design really is less important than successful functionality. Determining the appropriate level of design and preparation offers an interesting question to every architect. At the lowest level, standards and practices present suitable patterns that can serve as a design skeleton for those low-level or isolated items not requiring a heavy-handed blueprint.
For any organization, even one of modest size, it is extremely practical to have standards and practices supporting the development tasks, including aspects which support structuring the actual code. However, as software applications increase in complexity, more design sophistication becomes necessary. Commonly, those responsible for design determine when these complexity thresholds arrive. In general, the factors supporting the need for increased design sophistication involve an evaluation of necessary reuse, integration, ease-of-scalability, and resource availability.
Significant design involvement is usually expected on certain projects and major enhancements. Alternately, grey areas exist in some situations where deciding when to raise concerns regarding design may be less clear. Ideally, management must engage the proper talent and avoid proceeding with a project before adequate design assessment has identified a project's requirements. Application, data, network, and other specialty architects coordinate with subject matter experts and the project team to establish the necessary pieces, and the best description of the global picture so those pieces can settle into all the right spots.
The old adage about a picture being worth a thousand words comes alive during design phases, as diagrams emerge that describe the matter at hand from varying perspectives, thereby allowing for an understanding of important concepts. Pattern languages and metaphors provide a semantic foundation to explain and detail how everything fits together. Any issue or controversy with the language in use merits serious consideration, as what seems a simple quirk or inconsistency can mature into a problem area that can threaten the project's life.
Assuming the inevitability that every thing has to be somewhere, when considering applications, rather than simply being somewhere, it is more important that each item be exactly where it is supposed to be. Application design involves the ability to do more than write code that functions; it involves planning the right location for all of the code, regardless of who writes the actual code. The code, modules, and groups of modules should have a structure that transcends each single command and operand. Additions should have an obvious placement both within and across modules. Ideally, a design should be simple, yet able to absorb a virtually infinite level of complexity, as long as that complexity follows simple rules. Achieving such grand ends as the right places for all the right things requires talent and effort. The data architect and the application architect must work as a team toward common goals as well as share a common language. Each designer must understand what each process needs along with recognizing the data that must exist to support this process. Data modeling and database design spill over into application domain modeling, with nowhere to hide. Both applications and databases have this touch-point that brings them together as a single concept; each area requires the other to rationalize their existence. Leveraging these skills in architecting an application allows for establishing a framework on which the application can operate and grow throughout its lifecycle. This circumstance only occurs with purposeful intent and, at times, unwavering dedication to make it transpire.