What's richly ironic here (and I live for irony) is that what you two are trying to shoehorn into the word "architecture", building architects are shoehorning into the word "programming"! LOL
The discipline of architectural "programming" (also known as "facilities programming") goes back to the 1960s. Here is a page from a book on the subject: http://www.flickr.com/photos/metanick/2529067762/ . And here's another description of the subject: http://www.wbdg.org/design/dd_archprogramming.php . Let me quote a small excerpt of the latter: *Today, we define architectural programming as the research and decision-making process that identifies the scope of work to be designed. Synonyms include "facility programming," "functional and operational requirements," and "scoping." In the early 1960s, William Peña, John Focke, and Bill Caudill of Caudill, Rowlett, and Scott (CRS) developed a process for organizing programming efforts. Their work was documented in Problem Seeking, the text that guided many architects and clients who sought to identify the scope of a design problem prior to beginning the design, which would be a solution to the problem. ... Now, several generations of architects have little familiarity with architectural programming and the advantages it offers: * Involvement of interested parties in the definition of the scope of work prior to the design effort * Emphasis on gathering and analyzing data early in the process so that the design is based upon sound decisions * Efficiencies gained by avoiding redesign and more redesign as requirements emerge during architectural design.* So I suggest that since we in IT have borrowed metaphors and terminology so heavily from the building professions and trades in the past, we borrow yet again, and call the set of stakeholder involvement and governance activities surrounding "architecture" by the term used in the architectural profession: architecture programming. -- Nick On Tue, May 27, 2008 at 1:06 PM, Steve Jones <[EMAIL PROTECTED]> wrote: > > 2008/5/27 Rob Eamon <[EMAIL PROTECTED]>: > > > --- In [email protected], "Steve Jones" > > <[EMAIL PROTECTED]> wrote: > >> > >> Architecture != high-level design > > > > Well, that's not all that it is but architecture is > > design. "Architecture is the structure...". That sounds very much > > like design. > > I'm beginning to realise that the principles that I've used for many a > long year come from my personal experience. Now I do tend to inflict > this view on people (with some success in terms of improving IT) but > what I'm using now is the IEEE definition where it talks about the > governance of design being architecture. That to me makes quite a bit > of sense. > > > > >> > >> The boundary is the difference between concept and vision and the > >> requirement of implementation. > > > > Based on material at previous links I've posted, and my own > > experience, I disagree. The distinction you're making is simply level > > of abstraction. An architecture may specify detailed constraints > > (e.g. implementation constraints) yet still be an architecture as > > opposed to a detailed design. > > Agreed as these tend to govern the design. You are right in that the > boundary isn't clear but I would say that architecture has become a > massively popular term in the last few years with every man and his > dog doing architecture (I've said it before that most SO work is > really SOD). > > > > >> Design without implementation makes > >> sense in liberal arts but nothing engineering. Design is an > >> engineering discipline, which is distinct from the architecture. > >> This holds for buildings as it does for IT, concept and vision, > >> then take it to live. > >> > >> Its separate levels of abstraction, which is indeed different in the > >> same way as the rules of football are different from the tactics > >> which are different from the play. > > > > I guess we just disagree. Architecture vs. design is not simply > > different abstraction levels, IMO. In the past, I usually described > > architecture as design + explicit principles. I now think there is a > > bit more to it than that and that's what I'm attempting to explore > > here. > > Actually you are right it isn't just levels of abstraction it is > principles. Architecture gives the structure and form (I tend to use > it to organise teams at the start of the project/programme) which then > guides the rest, this is why I think it is different to design. > > It is clear that groups like Open Group and IEEE haven't done a great > job in creating a simple definition of why the two are different.
