On Wed, May 28, 2008 at 12:15 PM, Rob Eamon <[EMAIL PROTECTED]> wrote: > Sweet. So "architecture" has evolved from referring to the completed > building (old, old definition), to the models that describe the > building (still the predominant definition?) to the process that > creates the models (Gartner). (Sigh)
Yes. Though there are ways of distinguishing these three facets (as is, as described, and as performed) when the intended facet is not clear from context: 1. realized architecture or embedded architecture or instantiated architect: the actual components and their actual relationship in the physical object in question 2. architecture description: IEEE-1471's term for the "blueprints" 3. architecture process or architectural programming: the process that creates and evolves the blueprints > As a process, wouldn't it be architect*ing* (or architecture > programming) and the resulting work products would comprise the > architect*ure*? No. "architect-ing" refers to executing the process, not the process itself. The same distinction holds between "living" vs. "life". Life is a process and living is the execution of that process. As I said, "architectural programming" is definitely a less ambiguous name. But it is not well known, so it would have been hard to convince our clients to use it. > But even that seems off a bit. There still seems to me to be an > intangible aspect to architecture. Take the Burj Dubai tower. Simply > taking the requirements and principles from the stakeholders, how > does one end up with a tower as striking as the Burj Dubai > (http://www.burjdubai.com)? Obviously functional and engineering > aspects are accounted for but it is the aesthetic eye and creativity > of the architect(s) that provide the punch. Keep in mind that the architects are some of the stakeholders! So are the contractors who build it, so is the city government in which the building exists, so are the users of the building. All are included in the term "requirements", and that's why requirements are always evolving. The biggest problem in architecture of ANY kind is not the problem of implementing the architecture, eg building the building. The biggest problem is evolving the architecture once it has been implemented, eg evolving the building. The diversity and conflicting interests of all the stakeholders in a building or development is one reason why building architects often use charrettes <http://en.wikipedia.org/wiki/Charrette> to expose, socialize, generate support for, and defuse opposition to requirements. I advise enterprise architects to do the same thing. > This begs a question (as Gervas touched on): should the word > architecture be anywhere near business and software system design? Obviously, I think the answer is yes. If the structure of a system can be described and said descriptions can be used to control (or at least influence) the implementation or evolution of said system, then said controlling/influencing process is the architecture. Since businesses and software systems fit this requirement, then they have architectures. My favorite example of a business architecture is a franchise business model. Believe me, the business model of a McDonald's franchise it heavily architected. About the only variation now allowed the franchisee is which teenagers to hire to run the franchise! -- Nick
