Conceptualization Techniques of Design Architectural Concepts Traditionally architectural concepts have been the designer's way of responding to the

design situation presented in the program. They have been the means for translating the non-physical problem statement into the physical building product. Every project has within it what might be described as prime organizers, central themes, critical issues or problem essences. Some general categories under which the concerns and issues of a building may be listed and addressed in design are: 1. Functional zoning 2. Architectural space 3. Circulation and building form 4. Response to Context 5. Building Envelope Contexts for Concept Getting 1. General philosophy and life values of the designer. 2. Design Philosophy of the Designer. 3. View of the problem by the designer presented with a specific design project. Examples of Design Concepts Prism Sculpture Living in Capsules Creativity Some people are more creative than others. However there are ways in which you can increase your idea production, which is the basis of creativity. In short creativity is the process of coining up with new ideas. 3 Essentials to Development of Creative Skills 1. Ideation-refers to the mental process itself. To ideate means "to think" and that is of course, how to train one's self think in new and unique ways. 2. Idea Quantity-means that the person who is capable of producing the largest number of ideas per unit of time has the greatest chance of producing the trully significant one. In other words, the odds of your coming up with a really creative idea are best if you have a lot of ideas from which to select. 3. lmagineering -letting your imagination soar and then engineering it back to reality. Be careful to proceed in this order. In other words, don't confine yourself to reality and all of its constrain before you begin thinking of ideas. Think outlandishly, originally, and recklessly at first. The longer you spend thinking of ideas, the more apt you are to

produce a really wild one. Example, before, a zoo is where you cage animals and people roam around to watch them, now in some countries it is the reverse. The people are caged inside their cars and the animals roam free. Stages in Designing 1. Design Analysis 2. Tentative Solutions 3. Criticisms 4. Operational Process 5. Geometric Methodology - systematic method of problem solving Methods: 1. Prestatement 2. Problem Statement 3. Information 4. Analysis 5. Synthesis 6. Evaluation

Architecture: Conceptualization Objective: System Delivery It is critical and urgent that the system is delivered as soon as resources allow. We would like to establish that a design (or architecture, per se) and documentation are not deliverables. The finished system is the deliverable. Everything that comes before is just a phase, a stage, or a milestone. The objective is the successfully completed system. Strategic Approach In order to achieve the final objective, a system must acquire specific attributes: - corresponding to the business requirements and expectations for successful business functioning; - providing ability to compensate resources and efforts spent during unsuccessful attempts; - facilitating business effectiveness; - supporting prospective business changes, enhancements, and diversification. Such attributes are called System Quality Attributes. The system cannot acquire them just by itself or by someones wish. System Quality Attrib utes must be planned. Quality of a software system is not acquired automatically and not applied to a system in place. If a system does not have a certain quality attribute it is

extremely difficult to force such quality in. This will require substantial reorganization (re-design) of the system. Quality must be designed in, so that the system is empowered with capability to propagate quality throughout and across all system elements and processes. In order for the system to be capable for that, it must have a consistent and recognizable pattern in design and functioning. Such a pattern is called Conceptual Integrity. No architecture (civic or software) may be created or exist without System Conceptual Integrity. If Conceptual Integrity does not exist in a system, the system by definition is said "lacking (or missing) architecture". System Conceptual Integrity System conceptual integrity is central to system quality. This principle is by no means limited to software systems, but to the design of any complex construct, whether a computer, an airplane, a Strategic Defense Initiative, a Global Positioning System. Conceptual Integrity unites all system elements and quality attributes by enduing them with the same common characteristics and technological ideas. When architecture is created, a system design must be able to: accommodate a Conceptual Integrity; acquire a System Metaphor; propagate a conception (technical concept) to all elements and components; embody System Quality Attributes, both functional and structural, into each component and process; create a structure supporting functionality. Vitruvian Triad It is well known and established by principles of Architectural Theory that the conceptual integrity of a system (any systematic technical structure) is achieved by applying the Vitruvian Triad. Vitruvius was a Roman writer, architect, and engineer active in the 1st century BC. He was the most prominent architectural theorist known today, having written De Architectura, (known today as The Ten Books of Architecture). It is the only surviving major book on architecture from classical antiquity, and it is the only contemporary source on classical architecture to have survived. The famous orders of architecture that we can see

in every classical architecture are rigorously defined in the books. It also gathers three fundamental laws that Architecture must obey, in order to be so considered: Firmitas, Utilitas, Venustas. All architecture is comprised of three elements: function (utilitas), structure (firmitas), and concept (venustas). The three architectural elements are called the Vitruvian Triad. This triad has formed the basis of architecture and forms the theoretical basis of software architecture.

Utilitas represents the function of the structure, functionality. Firmitas represents the means, materials, and logistics of the structure. Venustas represents the design a layout and combination of structural elements to meet the functional needs. In the case of software architectural design: - Utilitas is a set of System Quality Attributes Discernable at Runtime - Firmitas is System Quality Attributes Not Discernable at Runtime - Venustas is the Conceptual Intergrity brining Utilitas and Firmitas together.

System Concept (Venustas) Applying or utilizing a technical idea at a level of each individual component. It does not create a system. In order to create an organic system (i.e., systematic structure), we should apply a technical concept at the system level and facilitate propagation of the technical concept throughout the entire system and into each element of the system on all levels. This ensures that all components, elements, and processes within the system will share same characteristics and quality attributes. Components, elements, and processes become organic parts of the system not because they have similar (patternal, for example) characteristics, but because the system makes them its parts by delegating to them its conception and quality

attributes. Product conceptual integrity means uncompromised adherence of the whole and entire system to the one and only software architectural concept and the implementation design, - in each and every programming unit, body of code, object, and component, as well as in process of creating architecture and producing the software product. In a system having product integrity there may not be embodied any unit that does not follow the system conceptual guidelines and design. This approach produces consistency in both system development and users interaction with the system and its components (applications). When a new element is implemented (in software development an "element" means a method, a rule, an object, a component, etc), there must always be a prescribed way to do that applying a concrete principle of system conceptual integrity established by the architectural design idea of the system. It must be strictly prohibited to implement any element not following the system concept. Disparate Structures and Absence of Conceptual Integrity Conceptual definition brings the structure and the functionality together. t is almost impossible to implement all System Quality Attributes using only structural engineering or functional implementation. Neither structure nor functionality acquires necessary or expected quality automatically. When we design a system considering quality attributes it is expected to have, we are contributing to a system concept. If we attempt to inherit or re-use some kind of existing third-party structure or component, we are risking to not obtain necessary quality because that structure may not be based on any concept or may (and most likely does) possess a technical parameters that do not correspond to our system concept. A structure may not be based on any concept because it is created for structural re-utilization purposes only (such as a re-usable component or block) created outside the system being designed. This is specifically true for generic structures that are created in attempt to satisfy common needs of any system. Thus, such structures do not address particular requirements of concrete business scenarios. Such structures expose risk of not being correspondent or relevant to the business process requirements at hand. Structural or engineering concepts may drive only interactions of internal elements of a structure. If we attempt to "connect" such a structure to our conceptual model, we need to make substantial effort to align our system concept with the structure functional capabilities. At best, it creates tight coupling between the entire system we are creating and components of the structure. This leads to limitations to extensibility and maintainability (and thus, it deprives the system of important quality attributes). At worst, it creates a dysfunctional system. The only solution to these scenarios is creation of an "integration" layer between two or more structures built with different specifications. This is similar to construction engineering efforts of connecting two buildings (different in design) with a pedestrian overpass. Or attempts to install a Toyota engine on a Nissan. Examples of a Connector Between Two Different Structures Being unable to vest System Quality Attributes to the system, in this situation we will have to attempt to force such attributes into the integration layer. Let alone engineers supposed to acquire a full technical knowledge of both structures to address weak points of interconnections. External generic structural blocks (sometimes they are confusingly called "re-usable"), are unable to provide implementation of most System Quality Attributes to a particular system because such blocks have no knowledge of a system they are intended for. Therefore, particularly the resulting systems utilizing such generic components will have deficiency in such System Quality as high performance, security, extensibility and many others. Implementation of Conceptual Integrity Conceptual Integrity resolves the problems outlined above and many others. Furthermore, if a concept is designed in at early stages, System Quality Attributes are also designed into the system and become available on the structural and functional levels. Conceptual Integrity is an abstract characteristic of a system. Conceptual Integrity is implemented by defining a System Metaphor and via applying specific design techniques. Each technique may

address one or more System Quality Attributes. For example, Component Loose Coupling design technique ensures that the system will possess Extensibility, Integrability, and Scalability. Interface Consistency, as another principle, enhances system understanding and design knowledge transfer between parts of the system and between builders. An emphasis on consistency contributes to the discovery of commonality and opportunities for reuse, while unnecessary diversity in component design and implementation typically leads to decidedly negative consequences, such as brittle system structure. The following non-exhaustive list specifies architectural design principles used to implement Conceptual Integrity and achieve System Quality Attributes: Conceptual System Metaphor including: - Conceptual System Subject; - Conceptual System Process operating on the System Subject; Logical System Metadata: - Definition of Core System Elements; - Definition of System Communication; - Components Metadata. The following non-exhaustive list specifies certain techniques (principles) used to implement Conceptual Integrity and achieve System Quality Attributes: System Object types definitions using Published Interfaces (Facades); Component Loose Coupling; Separation of Concerns; Single Responsibility; Principle of Least Knowledge; Technology Transparency; JIT (Just-In-Time) process design; Single Design Point; Plug-In/Out and Switch-It-On/Off Approaches; Industry Patterns, Standards and Clichs used within System Concept. Each technique comprises several more detailed and concrete techniques on the engineering level. Cross-cutting Concerns Cross-cutting concerns are features of design that may apply across all layers, components, and tiers. They are also known as "services". Typically, in an ideal world a business process would have perfectly functioned without them. Examples of cross-cutting concerns and services are: Authentication and Authorization;

Communication; Configuration Management; Exception Management; Logging and Instrumentation. These services may or may not be included into conceptual design depending on whether we need to create such services and impose the System Metaphor and Conceptual Integrity upon them, or were planning to use an external components provided by third parties.

ADMS selected work 2003-2007 4 Design methods and design theory for architectural design management Dr.ir. Henri Achten Most parties that an architectural design manager meets in daily practice are engaged to some degree with design. What these parties are actually doing in a project is contingent with the concrete design project. Additionally, each party has some stake, and may employ different strategies to solve their part of the work. The architectural design manager therefore needs a good sense how design processes function so he or she can adequately meet what may otherwise seem as a chaotic and haphazard business. Next to other approaches discussed elsewhere in this text, design theory and design methods provide a framework to understand the basic characteristics of a given project. Design theory The oldest known written source on architecture are Vitruvius Ten Books on Architecture from the first century BC. Ever since (and very likely long before) architects have been documenting their ideas about architecture. Such documents often record a normative stance (Rowe 1987), indicating what architects should do rather than what they are actually doing. Rigorous scientific investigations in design theory are much more recent, having their origin in the 1950ies. They are based on systems theory which evolved out of a need to deal with novel complex problems (the most dramatic of which was NASAs space program) for which tried and tested existing methods were inadequate (Jones 1980). In general, the field was called design

methodology. Throughout its years of development, the understanding of design problems and design process has been revised considerably (Cross 1984 provides a good reading). It is fair to claim that our current understanding of design is still incomplete. Researchers are struggling between two quite different paradigms of design: design as rational problem solving versus design as reflective practice. Put very concisely, design as rational problem solving poses problem decomposition, design as search, solving (sub) problems, and integrating partial solutions to whole solutions. So, if possible, quantifiable methods are preferred compared to qualitative methods. Design as reflective practice on the other hand, proposes that the architect continuously decomposes the problem, but each time different as the need occurs (naming), on this basis sets up a (sub)-design problem (framing), creates a partial solution (moving), and checks whether the result is moving in the right direction (evaluating). Rational problem solving has a sound theoretical background, but does not sound familiar to an architect; whereas reflective practice has a weak theoretical background, but sounds much more true to an architect (see Dorst 1997 for a very good comparison between the two). Design theory and ADMS That there is no commonly accepted singular framework to describe design does not mean that we are at a loss. For the architectural design managers, it is important to understand a number of widely subscribed key concepts about design. The main one is that design problems are ill-structured at best, or even wicked (Rittel and Webber 1973). The implication is that there is no single problem decomposition that will stick ADMS selected work 2003-2007 5 from beginning to end; getting to understand the design task is very much related to creating design solutions. Design teams therefore need the freedom to reformulate the design problem, while on the other hand it is necessary to keep track of all the relevant issues. A common misconception that may occur is that there is one optimal, or best, solution. This is however in many cases impossible to determine. Architects

therefore, aim to satisfies rather than optimize (Simon 1996). Design method As stated above, design methodology in the formative years was a blend of design methods and scientific study of design. Both areas are now more distinct, and it is appropriate to talk about design research on the one hand and design methodology on the other. Design methods are relevant when trying to find a design solution will take a long time (for example because the architect works a novel design that he or she has no experience with); when the cost of not succeeding is very high; when the process has to be accounted for; when the design task is very complex; and when a high number of parties are involved in the design project. Design methods are a somewhat controversial subject for architects. Many architects dislike talking about their work process in terms of method, because it suggests a repetitiveness that is contradictory to creativeness. Under the influence of Information & Communication Technology, many architect and architectural firms have started experimenting with new design methods. Internet has changed communication structures and allows the creation of design teams spread world-wide that can work 24 hours by cycling through time zones. Innovations in CAAD software; in particular parametric modeling also requires different design strategies. Such trends have an impact on the design process without people talking about these changes in terms of design methods. Within ADMS, we employ a fairly strict interpretation of a design method. Something is a design method when it states a clear goal within the design process; when it defines steps and the proper order of steps; when it can be applied in more than one case; when other people can use it; and when the results of a step are testable. The use of a design method does not necessarily guarantee a good outcome. A design method by definition leaves out many aspects about a design problem that ultimately have to be solved. What a design method does, however, is indicate which steps are critical, and in which order to deal with these steps. Design method and ADMS For the architectural design manager it is necessary to understand when and how a

design method can make a useful contribution in a design team. Something which does not fulfill all requirements of a design method still can function properly we just do not call it a design method. Using a method therefore is fine, but it should not lead to a false sense of security because a method always leaves out aspects which later may turn out to be quite important to a project. Furthermore, using a method does not relieve the architect from being knowledgeable about the design; methods therefore, are for specialist users. Design theory, methods, and selected works In most cases, the works described in this book concern studies in which the architectural design manager was confronted with a new organization of which he or she did not have any knowledge. In the framework of design theory, a number of projects were analyzed on the concept of level and parties who have a mandate on a ADMS selected work 2003-2007 6 particular level. Through this work, the complexity of a project can be mapped. In the framework of design methods, a number of projects were analyzed in terms of the checklist of aspects. This helped the architectural design manager to understand the design processes of the various projects.