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
someone’s 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
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 user’s 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 Clichés 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 we’re
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 1950’ies. They are based on
systems theory which evolved out of a need to deal
with novel complex problems (the
most dramatic of which was NASA’s 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 when the results of a step are testable. The use of a
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
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.