It is impossible to argue against the fact that architecture itself, i.e. the process of architecting, is an analytical process, one that ultimately produces a design artefact. Thus arguing that architecture and design should be separated in nonsensical. Many a software engineer have split the design process into an architectural phase, a high-level design and a low-level design phase. In reality, all these are representative of the design effort, albeit at different levels of granularity. An architectural model is an extremely high level view of the system - a design that is fed as input into the next phase, where it is elaborated upon and fed into a yet another phase. This is repeated until an executable solution is derived. But wait, implementation is still largely design. In large systems, often one might find themselves implementing from a class diagram, but the latter does not specify intrinsic details of the source code, merely relations, attributes and method signatures. The implementor still has to design the internals of each method, branching, loop structure, e.g. whether to iterate or recurse. Even testing involves design - the design of test cases, that is.
Conclusion: nearly everything is design. The base term itself should NEVER be used to describe any particular phase of a software engineering effort, and juxtaposing architecture against design is a non-argument. Instead, it is more benificial to draw boundaries between architecture and high-level (or is it mid-level :)) design. Now, this is only a matter of scope, and I can make this distinction in two paragraphs:
1) Architecture - a very high-level view intended primarily to convey the design to ALL stakeholders of the system. Not just developers but customers. This is often the common "textbook" definition, but it doesn't capture everything. Architecture also serves as a "vector" of the remaining development process. All subsequent design decisions must fit within the archictural model, and in effect, imposes constrains on the development effort.
2) High/low level design - models of the system that are NOT intended for ALL stakeholders, but only those who are/will be directly involved in the process of producing the system.
The distinction between the two is clear, and it is a matter of knowing when to stop. The boundary of architecture equates to the boundary of the customer's capacity to comprehend it. Anything more is lower-level elaboration - what is commonly misreferenced to as "design".
> So different softwares designs can actually use the same > architecture. How things transport? Roads to allow > things to travel. What travels and how they travel on > such roads can be designed. >
Annon (Hong),
The analogy you give (with regards to "building the road" versus "who uses the road or how") is akin to a framework (e.g. the Struts MVC framework) and an application (any web-application). Both the framework and the application will have an Architecture and require Design.
Emil's views are along the same lines. The two paragraph summary is interesting as it rightly (IMO) points out the intended recipients of an Architecture and a Design.
In the 2 links that John provided - Signs & Roads respectively - the latter mentions an Architecture proposed by Hans (Monderman), one that discourages Signs, among other things. The same article also mentions the community of Radburn's Architecture for Roads which encourages the use of Signs (the same Architecture is prevalent in much of America where there is an extensive use of Signs). Someone proposing or presenting this architecture would only highlight points like "wide roads and narrow sidewalks" (to clearly separate the space for automobiles from that for humans/animals), "traffic lights", "warning/info signs", etc. Exactly how wide the roads would be or how high/bright the lights would be or how clear/contrasting the Signs would be are left to the imagination of "that" audience; they would be the responsibility of researchers or development teams with the domain knowledge - this is what is indicated in the first link (about the Typeface/Signs).
Previous Topic
