"The term architecture is used here to describe the
attributes of a system as seen by the programmer, i.e., the conceptual
structure and functional behavior, as distinct from the organization of the
data flow and controls, the logical design, and the physical implementation." (Gene Amdahl et al, "Architecture of the IBM System", IBM Journal
of Research and Development. Vol 8 (2), 1964)
"In computer design three levels can be distinguished:
architecture, implementation and realisation; for the first of them, the
following working definition is given: The architecture of a system can be
defined as the functional appearance of the system to the user, its
phenomenology. […] The inner structure of a system is not considered by the
architecture: we do not need to know what makes the clock tick, to know what
time it is. This inner structure, considered from a logical point of view, will
be called the implementation, and its physical embodiment the
realisation." (Gerrit A Blaauw, "Computer Architecture", 1972)
"There always is an architecture, whether it is defined
in advance - as with modern computers - or found out after the fact - as with
many older computers. For architecture is determined by behavior, not by words.
Therefore, the term architecture, which rightly implies the notion of the arch,
or prime structure, should not be understood as the vague overall idea. Rather,
the product of the computer architecture, the principle of operations manual,
should contain all detail which the user can know, and sooner or later is bound
to know." (Gerrit A Blaauw, "Computer Architecture", 1972)
"The design of a digital system starts with the specification
of the architecture of the system and continues with its implementation and its
subsequent realisation... the purpose of architecture is to provide a function.
Once that function is established, the purpose of implementation is to give a
proper cost-performance and the purpose of realisation is to build and maintain
the appropriate logical organisation." (Gerrit A Blaauw, "Specification of
Digital Systems", Proc. Seminar in Digital Systems Design, 1978)
"With increasing size and complexity of the implementations
of information systems, it is necessary to use some logical construct (or
architecture) for defining and controlling the interfaces and the integration
of all of the components of the system." (John Zachman, "A Framework for
Information Systems Architecture", 1987)
"Every software system needs to have a simple yet powerful
organizational philosophy (think of it as the software equivalent of a sound
bite that describes the system's architecture). [A] step in [the] development
process is to articulate this architectural framework, so that we might have a
stable foundation upon which to evolve the system's function points." (Grady
Booch, "Object-Oriented Design: with Applications", 1991)
"As the size of software systems increases, the algorithms
and data structures of the computation no longer constitute the major design problems.
When systems are constructed from many components, the organization of the
overall system - the software architecture - presents a new set of design
problems. This level of design has been addressed in a number of ways including
informal diagrams and descriptive terms, module interconnection languages,
templates and frameworks for systems that serve the needs of specific domains,
and formal models of component integration mechanisms." (David Garlan & Mary
Shaw, "An introduction to software architecture", Advances in
software engineering and knowledge engineering Vol 1, 1993)
"Software architecture involves the description of elements
from which systems are built, interactions among those elements, patterns that
guide their composition, and constraints on these patterns. In general, a
particular system is defined in terms of a collection of components and
interactions among those components. Such a system may in turn be used as a
(composite) element in a larger system design." (Mary Shaw & David Garlan,"Characteristics of Higher-Level Languages for Software Architecture", 1994)
"If a project has not achieved a system architecture,
including its rationale, the project should not proceed to full-scale system
development. Specifying the architecture as a deliverable enables its use
throughout the development and maintenance process." (Barry Boehm, 1995)
"Our experience with designing and analyzing large and
complex software-intensive systems has led us to recognize the role of business
and organization in the design of the system and in its ultimate success or
failure. Systems are built to satisfy an organization's requirements (or
assumed requirements in the case of shrink-wrapped products). These
requirements dictate the system's performance, availability, security,
compatibility with other systems, and the ability to accommodate change over
its lifetime. The desire to satisfy these goals with software that has the
requisite properties influences the design choices made by a software
architect." (Len Bass et al, "Software Architecture in Practice", 1998)
"Generically, an architecture is the description of the set
of components and the relationships between them. […] A software architecture
describes the layout of the software modules and the connections and
relationships among them. A hardware architecture can describe how the hardware
components are organized. However, both these definitions can apply to a single
computer, a single information system, or a family of information systems. Thus 'architecture' can have a range of meanings, goals, and abstraction levels,
depending on who’s speaking." (Frank J Armour et al, "A big-picture look at
enterprise architectures", IT professional Vol 1 (1), 1999)
"An architecture framework is a tool which can be used for
developing a broad range of different architectures [architecture
descriptions]. It should describe a method for designing an information system
in terms of a set of building blocks, and for showing how the building blocks
fit together. It should contain a set of tools and provide a common vocabulary.
It should also include a list of recommended standards and compliant products
that can be used to implement the building blocks." (TOGAF, 2002)
"The aim of architectural design is to prepare overall specifications, derived from the needs and desires of the user, for subsequent design and construction stages. The first task for the architect in each design project is thus to determine what the real needs and desires of the user are […]" (George J Klir & Doug Elias, "Architecture of Systems Problem Solving" 2nd Ed, 2003)
"The software architecture of a system or a family of
systems has one of the most significant impacts on the quality of an
organization's enterprise architecture. While the design of software systems
concentrates on satisfying the functional requirements for a system, the design
of the software architecture for systems concentrates on the nonfunctional or
quality requirements for systems. These quality requirements are concerns at
the enterprise level. The better an organization specifies and characterizes the
software architecture for its systems, the better it can characterize and
manage its enterprise architecture. By explicitly defining the systems software
architectures, an organization will be better able to reflect the priorities
and trade-offs that are important to the organization in the software that it
builds." (James McGovern et al, "A Practical Guide to Enterprise
Architecture", 2004)
"The traditional view on software architecture suffers from a
number of key problems that cannot be solved without changing our perspective
on the notion of software architecture. These problems include the lack of
first-class representation of design decisions, the fact that these design
decisions are cross-cutting and intertwined, that these problems lead to high
maintenance cost, because of which design rules and constraints are easily
violated and obsolete design decisions are not removed." (Jan Bosch, "Software architecture: The next step", 2004)
"As a noun, design is the named (although sometimes
unnamable) structure or behavior of a system whose presence resolves or
contributes to the resolution of a force or forces on that system. A design
thus represents one point in a potential decision space. A design may be
singular (representing a leaf decision) or it may be collective (representing a
set of other decisions). As a verb, design is the activity of making such
decisions. Given a large set of forces, a relatively malleable set of
materials, and a large landscape upon which to play, the resulting decision
space may be large and complex. As such, there is a science associated with
design (empirical analysis can point us to optimal regions or exact points in
this design space) as well as an art (within the degrees of freedom that range
beyond an empirical decision; there are opportunities for elegance, beauty,
simplicity, novelty, and cleverness). All architecture is design but not all
design is architecture. Architecture represents the significant design
decisions that shape a system, where significant is measured by cost of change." (Grady Booch, "On design", 2006)
"The goal for our software architecture is to provide the key
mechanisms that are required to implement a wide variety of cross-layer
adaptations described by our taxonomy. Our strategy for developing such an
architecture is actually to create two architectures, a 'conceptual' one,
followed by a 'concrete' one." (Soon H Choi, "A Software Architecture for
Cross-layer Wireless Networks", 2008)
"A good system design is based on a sound conceptual
model (architecture). A system design that has no conceptual structure and
little logic to its organization is ultimately going to be unsuccessful. Good
architecture will address all the requirements of the system at the right level
of abstraction." (Vasudeva Varma, "Software Architecture: A Case
Based Approach", 2009)
"Architecting is both an art and a science - both synthesis and analysis, induction and deduction, and conceptualization and certification - using guidelines from its art and methods from its science. As a process, it is distinguished from systems engineering in its greater use of heuristic reasoning, lesser use of analytics, closer ties to the client, and particular concern with certification of readiness for use." (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)
"Architecting is creating and building structures - that is, 'structuring'. Systems architecting is creating and building systems. It strives for fit, balance, and compromise among the tensions of client needs and resources, technology, and multiple stakeholder interests." (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)
"Taking a systems approach means paying close attention to results, the reasons we build a system. Architecture must be grounded in the client’s/user’s/customer’s purpose. Architecture is not just about the structure of components. One of the essential distinguishing features of architectural design versus other sorts of engineering design is the degree to which architectural design embraces results from the perspective of the client/user/customer. The architect does not assume some particular problem formulation, as “requirements” is fixed. The architect engages in joint exploration, ideally directly with the client/user/customer, of what system attributes will yield results worth paying for." (Mark W Maier, "The Art Systems of Architecting" 3rd Ed., 2009)
"An architecture is the response to the integrated collections of models and views within the problem area being examined." (Charles D Tupper, "Data Architecture: From Zen to Reality", 2011)
"An architecture represents combined perspectives in a structured format that is easily viewable and explains the context of the area being analyzed to all those viewing it." (Charles D Tupper, "Data Architecture: From Zen to Reality", 2011)
"Using architecture leads to foundational stability, not rigidity. As long as the appropriate characteristics are in place to ensure positive architectural evolution, the architecture will remain a living construct. Well-developed architectures are frameworks that evolve as the business evolves." (Charles D Tupper, "Data Architecture: From Zen to Reality", 2011)
"A software architecture encompasses the significant decisions about the organization of the software system, the selection of structural elements and interfaces by which the system is composed, and determines their behavior through collaboration among these elements and their composition into progressively larger subsystems. Hence, the software architecture provides the skeleton of a system around which all other aspects of a system revolve." (Muhammad A Babar et al, "Agile Software Architecture Aligning Agile Processes and Software Architectures", 2014)
"Good architecture is all about splitting stuff reliably into self-contained parcels that allow work on them to continue relatively independently in parallel (often these days in different locations)." (Richard Hopkins & Stephen Harcombe, "Agile Architecting: Enabling the Delivery of Complex Agile Systems Development Projects", 2014)
"Good architecture provides good interfaces that separate the shear layers of its implementation: a necessity for evolution and maintenance. Class-oriented programming puts both data evolution and method evolution in the same shear layer: the class. Data tend to remain fairly stable over time, while methods change regularly to support new services and system operations. The tension in these rates of change stresses the design." (James O Coplien & Trygve Reenskaug, "The DCI Paradigm: Taking Object Orientation into the Architecture World", 2014)
"In more ways than one, architecture is all about avoiding bottlenecks. In architecture, the term bottleneck typically refers to a design problem that is preventing processing from occurring at full speed. [...] A good architecture will avoid bottlenecks in both." (Richard Hopkins & Stephen Harcombe, "Agile Architecting: Enabling the Delivery of Complex Agile Systems Development Projects", 2014)
"There is a tendency to believe that good architecture leads to systems that perform better and are more secure, but such claims relate less to any given architectural principle than to the timing of big-picture deliberations in the design cycle and to the proper engagement of suitable stakeholders." (James O Coplien & Trygve Reenskaug, "The DCI Paradigm: Taking Object Orientation into the Architecture World", 2014)
"Any software project must have a technical leader, who is responsible for all technical decisions made by the team and have enough authority to make them. Responsibility and authority are two mandatory components that must be present in order to make it possible to call such a person an architect." (Yegor Bugayenko, "Code Ahead", 2018)
"Just by making the architect role explicit, a team can effectively resolve many technical conflicts." (Yegor Bugayenko, "Code Ahead", 2018)
"To make technical decisions, a result-oriented team needs a strong architect and a decision making process, not meetings." (Yegor Bugayenko, "Code Ahead", 2018)
"[...] an architect’s work [...] comprises the set of strategic and technical models that create a context for position (capabilities), velocity (directedness, ability to adjust), and potential (relations) to harmonize strategic business and technology goals." (Eben Hewitt, "Technology Strategy Patterns: Architecture as strategy" 2nd Ed., 2019)
"Software architecture is the process and product of creating technical systems designs. Architecture may include a specification of resources, patterns, conventions, and communication protocols, among other details." (Morgan Evans, "Engineering Manager's Handbook", 2023)
"Systems architecture is the portion of any project over which the engineering team has the most control. This design is usually less of a collaboration between different functions and more clearly in the domain of engineers. As such, engineering managers have a high responsibility to own this process and its decisions. To produce the best decisions possible, you must have the right decision-building blocks: complete information to work from and a structured methodology to guide you." (Morgan Evans, "Engineering Manager's Handbook", 2023)
"Architecture begins where engineering ends." (Walter Gropius, [speech])
"Architecture is the tension between coupling and cohesion." (Neal Ford)
"Programming without an overall architecture or design
in mind is like exploring a cave with only a flashlight: You don't know where
you've been, you don't know where you're going, and you don't know quite where
you are." (Danny Thorpe)
"The fundamental organization of a system embodied in its
components, their relationships to each other, and to the environment, and the
principles guiding its design and evolution." (ANSI/IEEE Std 1471: 2000)
