Conceptualization Techniques of Design

8/13/2019 Conceptualization Techniques of Design

1/6

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 processof 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 areally 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. Synthesis6. 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 calledSystem Quality Attributes.

The system cannot acquire them just by itself or by

someones wish. System Quality Attributes 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
http://www.openframetechnologies.net/Architecture/SQA.aspxhttp://www.openframetechnologies.net/Architecture/SQA.aspx


2/6

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 tosoftware 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, andengineer 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

amous orders of architecture that we can see

in every classical architecture are rigorously

defined in the books. It also gathers three

undamental 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 designa 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


3/6

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 concreteprinciple 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 forgeneric structuresthat 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 aNissan.

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 theyare 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


4/6

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 engagedto 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 understandthe 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 designtheory 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


5/6

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 thisbasis 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 singularframework 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


5

from beginning to end; getting to understand the

design task is very much related tocreating 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 workprocess 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 designstrategies. 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 designmethod 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


6/6

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 properlywe

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 andparties who have a mandate on a


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.

Documents

Conceptualization Techniques of Design