Software architecture

Software architecture
Software architecture refers to the high level structures
of a software system, the discipline of creating such struc-
tures, and the documentation of these structures. These
structures are needed to reason about the software sys-
tem. Each structure comprises software elements, rela-
tions among them, and properties of both elements and
relations.[1]
The architecture of a software system is a
metaphor, analogous to the architecture of a building.[2]
Software architecture is about making fundamental struc-
tural choices which are costly to change once imple-
mented. Software architecture choices include specific
structural options from possibilities in the design of soft-
ware. For example, the systems that controlled the space
shuttle launch vehicle had the requirement of being very
fast and very reliable. Therefore, an appropriate real-time
computing language would need to be chosen. Addition-
ally, to satisfy the need for reliability the choice could be
made to have multiple redundant and independently pro-
duced copies of the program, and to run these copies on
independent hardware while cross-checking results.
Documenting software architecture facilitates commu-
nication between stakeholders, captures early decisions
about the high-level design, and allows reuse of design
components between projects.[3]:pp.29–35
1 Scope
Opinions vary as to the scope of software architectures:[4]
• Overall, macroscopic system structure;[5]
this refers
to architecture as a higher level abstraction of a soft-
ware system that consists of a collection of computa-
tional components together with connectors that de-
scribe the interaction between these components.
• The important stuff—whatever that is;[6]
this refers
to the fact that software architects should concern
themselves with those decisions that have high im-
pact on the system and its stakeholders.
• That which is fundamental to understanding a system
in its environment”[7]
• Things that people perceive as hard to change;[6]
since designing the architecture takes place at the
beginning of a software system’s lifecycle, the archi-
tect should focus on decisions that “have to” be right
the first time. Following this line of thought, archi-
tectural design issues may become non-architectural
once their irreversibility can be overcome.
• A set of architectural design decisions;[8]
software ar-
chitecture should not be considered merely a set of
models or structures, but should include the deci-
sions that lead to these particular structures, and the
rationale behind them. This insight has led to sub-
stantial research into software architecture knowl-
edge management.[9]
There is no sharp distinction between software archi-
tecture versus design and requirements engineering (see
Related fields below). They are all part of a “chain
of intentionality” from high-level intentions to low-level
details.[10](p18)
2 Characteristics
Software architecture exhibits the following:
Multitude of stakeholders: software systems have to
cater to a variety of stakeholders such as business man-
agers, owners, users and operators. These stakeholders
all have their own concerns with respect to the system.
Balancing these concerns and demonstrating how they are
addressed is part of designing the system.[3]:pp.29–31
This
implies that architecture involves dealing with a broad va-
riety of concerns and stakeholders, and has a multidisci-
plinary nature.
Separation of concerns: the established way for archi-
tects to reduce complexity is to separate the concerns
that drive the design. Architecture documentation shows
that all stakeholder concerns are addressed by modeling
and describing the architecture from separate points of
view associated with the various stakeholder concerns.[11]
These separate descriptions are called architectural views
(see for example the 4+1 Architectural View Model).
Quality-driven: classic software design approaches (e.g.
Jackson Structured Programming) were driven by re-
quired functionality and the flow of data through the sys-
tem, but the current insight[3]:pp.26–28
is that the archi-
tecture of a software system is more closely related to
its quality attributes such as fault-tolerance, backward
compatibility, extensibility, reliability, maintainability,
availability, security, usability, and other such –ilities.
Stakeholder concerns often translate into requirements on
these quality attributes, which are variously called non-
functional requirements, extra-functional requirements,
1

2 4 HISTORY
behavioral requirements, or quality attribute require-
ments.
Recurring styles: like building architecture, the soft-
ware architecture discipline has developed standard ways
to address recurring concerns. These “standard ways”
are called by various names at various levels of abstrac-
tion. Common terms for recurring solutions are archi-
tectural style,[10]:pp.273–277
tactic,[3]:pp.70–72
reference ar-
chitecture[12][13]
and architectural pattern.[3]:pp.203–205
Conceptual integrity: a term introduced by Fred
Brooks in The Mythical Man-Month to denote the idea
that the architecture of a software system represents an
overall vision of what it should do and how it should do
it. This vision should be separated from its implemen-
tation. The architect assumes the role of “keeper of the
vision”, making sure that additions to the system are in
line with the architecture, hence preserving conceptual
integrity.[14]:pp.41–50
3 Motivation
Software architecture is an “intellectually graspable” ab-
straction of a complex system.[3]:pp.5–6
This abstraction
provides a number of benefits:
• It gives a basis for analysis of software systems’ be-
havior before the system has been built.[2]
The abil-
ity to verify that a future software system fulfills
its stakeholders’ needs without actually having to
build it represents substantial cost-saving and risk-
mitigation.[15]
A number of techniques have been
developed to perform such analyses, such as ATAM.
• It provides a basis for re-use of elements and deci-
sions.[2][3]:p.35
A complete software architecture or
parts of it, like individual architectural strategies
and decisions, can be re-used across multiple sys-
tems whose stakeholders require similar quality at-
tributes or functionality, saving design costs and mit-
igating the risk of design mistakes.
• It supports early design decisions that impact a sys-
tem’s development, deployment, and maintenance
life.[3]:p.31
Getting the early, high-impact decisions
right is important to prevent schedule and budget
overruns.
• It facilitates communication with stakeholders, con-
tributing to a system that better fulfills their
needs.[3]:p.29–31
Communicating about complex sys-
tems from the point of view of stakeholders helps
them understand the consequences of their stated re-
quirements and the design decisions based on them.
Architecture gives the ability to communicate about
design decisions before the system is implemented,
when they are still relatively easy to adapt.
• It helps in risk management. Software architecture
helps to reduce risks and chance of failure.[10](p18)
• It enables cost reduction. Software architecture is
a means to manage risk and costs in complex IT
projects.[16]
4 History
The comparison between software design and (civil) ar-
chitecture was first drawn in the late 1960s ,[17]
but the
term software architecture became prevalent only in the
beginning of the 1990s.[18]
The field of computer sci-
ence had encountered problems associated with complex-
ity since its formation.[19]
Earlier problems of complex-
ity were solved by developers by choosing the right data
structures, developing algorithms, and by applying the
concept of separation of concerns. Although the term
“software architecture” is relatively new to the industry,
the fundamental principles of the field have been applied
sporadically by software engineering pioneers since the
mid-1980s. Early attempts to capture and explain soft-
ware architecture of a system were imprecise and dis-
organized, often characterized by a set of box-and-line
diagrams. [20]
Software architecture as a concept has its origins in the re-
search of Edsger Dijkstra in 1968 and David Parnas in the
early 1970s. These scientists emphasized that the struc-
ture of a software system matters and getting the structure
right is critical. During the 1990s there was a concerted
effort to define and codify fundamental aspects of the
discipline, with research work concentrating on architec-
tural styles (patterns), architecture description languages,
architecture documentation, and formal methods.[21]
Research institutions have played a prominent role in fur-
thering software architecture as a discipline. Mary Shaw
and David Garlan of Carnegie Mellon wrote a book ti-
tled Software Architecture: Perspectives on an Emerging
Discipline in 1996, which promoted software architec-
ture concepts such as components, connectors, and styles.
The University of California, Irvine's Institute for Soft-
ware Research’s efforts in software architecture research
is directed primarily in architectural styles, architecture
description languages, and dynamic architectures.
IEEE 1471−2000, Recommended Practice for Architec-
ture Description of Software-Intensive Systems, was the
first formal standard in the area of software architecture.
It was adopted in 2007 by ISO as ISO/IEC 42010:2007.
In November 2011, IEEE 1471–2000 was superseded by
ISO/IEC/IEEE 42010:2011, Systems and software engi-
neering — Architecture description (jointly published by
IEEE and ISO).[11]
While in IEEE 1471, software architecture was about
the architecture of “software-intensive systems”, defined
as “any system where software contributes essential in-

5.1 Architecture supporting activities 3
fluences to the design, construction, deployment, and
evolution of the system as a whole”, the 2011 edition
goes a step further by including the ISO/IEC 15288
and ISO/IEC 12207 definitions of a system, which em-
brace not only hardware and software, but also “humans,
processes, procedures, facilities, materials and naturally
occurring entities”. This reflects the relationship be-
tween software architecture, Enterprise Architecture and
Solution Architecture.
5 Architecture activities
There are many activities that a software architect per-
forms. A software architect typically works with project
managers, discusses architecturally significant require-
ments with stakeholders, designs a software architec-
ture, evaluates a design, communicates with designers
and stakeholders, documents the architectural design and
more.[22]
There are four core activities in software archi-
tecture design.[23]
These core architecture activities are
performed iteratively and at different stages of the initial
software development life-cycle, as well as over the evo-
lution of a system.
Architectural Analysis is the process of understanding
the environment in which a proposed system or systems
will operate and determining the requirements for the sys-
tem. The input or requirements to the analysis activity
can come from any number of stakeholders and include
items such as:
• what the system will do when operational (the func-
tional requirements)
• how well the system will perform runtime non-
functional requirements such as reliability, operabil-
ity, performance efficiency, security, compatibility
defined in ISO/IEC 25010:2011 standard [24]
• development-time non-functional requirements such
as maintainability and transferability defined in ISO
25010:2011 standard [24]
• business requirements and environmental contexts
of a system that may change over time, such as legal,
social, financial, competitive, and technology con-
cerns [25]
Architectural Synthesis or design is the process of cre-
ating an architecture. Given the architecturally signifi-
cant requirements determined by the analysis, the cur-
rent state of the design and the results of any evalua-
tion activities, the design is created and improved. See
[3]:pp.311–326[23]
for a discussion of various techniques for
improving a current design.
Architecture Evaluation is the process of determining
how well the current design or a portion of it satisfies the
requirements derived during analysis. An evaluation can
occur whenever an architect is considering a design de-
cision, it can occur after some portion of the design has
been completed, it can occur after the final design has
been completed or it can occur after the system has been
constructed. Some of the available software architec-
ture evaluation techniques include Architecture Tradeoff
Analysis Method (ATAM) and TARA.[26]
Frameworks
for comparing the techniques are discussed in frame-
works such as SARA Report [15]
and Architecture re-
views: practice and experience.[27]
Architecture Evolution is the process of maintaining
and adapting an existing software architecture to meet
requirement and environmental changes. As software ar-
chitecture provides a fundamental structure of a software
system, its evolution and maintenance would necessarily
impact its fundamental structure. As such, architecture
evolution is concerned with adding new functionality as
well as maintaining existing functionality and system be-
haviour.
Architecture requires critical supporting activities. These
supporting activities take place throughout the core soft-
ware architecture process. They include knowledge man-
agement and communication, design reasoning and deci-
sion making, and documentation.
5.1 Architecture supporting activities
Software architecture supporting activities are carried out
during core software architecture activities. These sup-
porting activities assist a software architect to carry out
analysis, synthesis, evaluation and evolution. For in-
stance, an architect has to gather knowledge, make de-
cisions and document during the analysis phase.
• Knowledge Management and Communication is
the activity of exploring and managing knowledge
that is essential to designing a software architec-
ture. A software architect does not work in isolation.
They get inputs, functional and non-functional re-
quirements and design contexts, from various stake-
holders; and provides outputs to stakeholders. Soft-
ware architecture knowledge is often tacit and is re-
tained in the heads of stakeholders. Software ar-
chitecture knowledge management activity is about
finding, communicating, and retaining knowledge.
As software architecture design issues are intricate
and interdependent, a knowledge gap in design rea-
soning can lead to incorrect software architecture
design.[22][28]
Examples of knowledge management
and communication activities include searching for
design patterns, prototyping, asking experienced de-
velopers and architects, evaluating the designs of
similar systems, sharing knowledge with other de-
signers and stakeholders, and documenting experi-
ence in a wikipage.
• Design Reasoning and Decision Making is the

4 6 SOFTWARE ARCHITECTURE TOPICS
activity of evaluating design decisions. This activ-
ity is fundamental to all three core software archi-
tecture activities.[8][29]
It entails gathering and asso-
ciating decision contexts, formulating design deci-
sion problems, finding solution options and evalu-
ating tradeoffs before making decisions. This pro-
cess occurs at different levels of decision granu-
larity, while evaluating significant architectural re-
quirements and software architecture decisions, and
software architecture analysis, synthesis, and evalu-
ation. Examples of reasoning activities include un-
derstanding the impacts of a requirement or a de-
sign on quality attributes, questioning the issues that
a design might cause, assessing possible solution op-
tions, and evaluating the tradeoffs between solutions.
• Documentation is the activity of recording the de-
sign generated during the software architecture pro-
cess. A system design is described using several
views that frequently include a static view showing
the code structure of the system, a dynamic view
showing the actions of the system during execution,
and a deployment view showing how a system is
placed on hardware for execution. Kruchten’s 4+1
view suggests a description of commonly used views
for documenting software architecture;[30]
Docu-
menting Software Architectures: Views and Beyond
has descriptions of the kinds of notations that could
be used within the view description.[1]
Examples of
documentation activities are writing a specification,
recording a system design model, documenting a de-
sign rationale, developing a viewpoint, documenting
views.
6 Software architecture topics
6.1 Software architecture description
Main article: Software architecture description
Software architecture description involves the principles
and practices of modeling and representing architectures,
using mechanisms such as: architecture description lan-
guages, architecture viewpoints, and architecture frame-
works.
6.2 Architecture description languages
Main article: Architecture description language
An architecture description language (ADL) is any means
of expression used to describe a software architecture
(ISO/IEC/IEEE 42010). Many special-purpose ADLs
have been developed since the 1990s, including AADL
(SAE standard), Wright (developed by Carnegie Mel-
lon), Acme (developed by Carnegie Mellon), xADL (de-
veloped by UCI), Darwin (developed by Imperial Col-
lege London), DAOP-ADL (developed by University of
Málaga), SBC-ADL (developed by National Sun Yat-Sen
University), and ByADL (University of L'Aquila, Italy).
6.3 Architecture viewpoints
Main article: View model
Software architecture descriptions are commonly orga-
4+1 Architectural View Model.
nized into views, which are analogous to the different
types of blueprints made in building architecture. Each
view addresses a set of system concerns, following the
conventions of its viewpoint, where a viewpoint is a spec-
ification that describes the notations, modeling and anal-
ysis techniques to use in a view that express the archi-
tecture in question from the perspective of a given set of
stakeholders and their concerns (ISO/IEC/IEEE 42010).
The viewpoint specifies not only the concerns framed
(i.e., to be addressed) but the presentation, model kinds
used, conventions used and any consistency (correspon-
dence) rules to keep a view consistent with other views.
6.4 Architecture frameworks
Main article: Architecture framework
An architecture framework captures the “conventions,
principles and practices for the description of architec-
tures established within a specific domain of applica-
tion and/or community of stakeholders” (ISO/IEC/IEEE
42010). A framework is usually implemented in terms of
one or more viewpoints or ADLs.
6.5 Architectural styles and patterns
Main article: Software Architecture styles and patterns
An architectural pattern is a general, reusable solution to
a commonly occurring problem in software architecture

6.7 Software architecture erosion 5
within a given context. Architectural patterns are often
documented as software design patterns.
Following traditional building architecture, a 'software
architectural style' is a specific method of construc-
tion, characterized by the features that make it notable”
(Architectural style). “An architectural style defines: a
family of systems in terms of a pattern of structural or-
ganization; a vocabulary of components and connectors,
with constraints on how they can be combined.”[31]
“Ar-
chitectural styles are reusable 'packages’ of design deci-
sions and constraints that are applied to an architecture to
induce chosen desirable qualities.”[32]
There are many recognized architectural patterns and
styles, among them:
• Blackboard
• Client-server (2-tier, 3-tier, n-tier, cloud computing
exhibit this style)
• Component-based
• Data-centric
• Event-driven (or Implicit invocation)
• Layered (or Multilayered architecture)
• Monolithic application
• Peer-to-peer (P2P)
• Pipes and filters
• Plug-ins
• Representational state transfer (REST)
• Rule-based
• Service-oriented
• Microservices architecture
• Shared nothing architecture
• Space-based architecture
Some treat architectural patterns and architectural styles
as the same,[33]
some treat styles as specializations of pat-
terns. What they have in common is both patterns and
styles are idioms for architects to use, they “provide a
common language”[33]
or “vocabulary”[31]
with which to
describe classes of systems.
6.6 Software architecture and agile devel-
opment
Main article: Agile development
There are also concerns that software architecture leads
to too much Big Design Up Front, especially among pro-
ponents of Agile software development. A number of
methods have been developed to balance the trade-offs of
up-front design and agility,[34]
including the agile method
DSDM which mandates a “Foundations” phase during
which “just enough” architectural foundations are laid.
IEEE Software devoted a special issue[35]
to the interac-
tion between agility and architecture.
6.7 Software architecture erosion
Software architecture erosion (or “decay”) refers to the
gap observed between the planned and actual architecture
of a software system as realized in its implementation.[36]
Software architecture erosion occurs when implementa-
tion decisions either do not fully achieve the architecture-
as-planned or otherwise violate constraints or principles
of that architecture.[2]
The gap between planned and ac-
tual architectures is sometimes understood in terms of the
notion of technical debt.
As an example, consider a strictly layered system, where
each layer can only use services provided by the layer im-
mediately below it. Any source code component that does
not observe this constraint represents an architecture vio-
lation. If not corrected, such violations can transform the
architecture into a monolithic block, with adverse effects
on understandability, maintainability, and evolvability.
Various approaches have been proposed to address ero-
sion. “These approaches, which include tools, techniques
and processes, are primarily classified into three generic
categories that attempt to minimise, prevent and repair
architecture erosion. Within these broad categories, each
approach is further broken down reflecting the high-level
strategies adopted to tackle erosion. These are: process-
oriented architecture conformance, architecture evolu-
tion management, architecture design enforcement, ar-
chitecture to implementation linkage, self-adaptation and
architecture restoration techniques consisting of recov-
ery, discovery and reconciliation.”[37]
There are two major techniques to detect architectural
violations: reflexion models and domain-specific lan-
guages. Reflexion model (RM) techniques compare a
high-level model provided by the system’s architects with
the source code implementation. Examples of com-
mercial RM-based tools include the Bauhaus Suite (de-
veloped by Axivion), SAVE (developed by Fraunhofer
IESE) and Structure-101 (developed by Headway Soft-
ware). There are also domain-specific languages with fo-
cus on specifying and checking architectural constraints,
including .QL (developed by Semmle Limited) and DCL
(from Federal University of Minas Gerais).

6 8 SEE ALSO
6.8 Software architecture recovery
Main article: Software architecture recovery
Software architecture recovery (or reconstruction, or
reverse engineering) includes the methods, techniques
and processes to uncover a software system’s architecture
from available information, including its implementation
and documentation. Architecture recovery is often nec-
essary to make informed decisions in the face of obso-
lete or out-of-date documentation and architecture ero-
sion: implementation and maintenance decisions diverg-
ing from the envisioned architecture.[38]
7 Related fields
7.1 Design
Main article: Software design
Architecture is design but not all design is architectural.[1]
In practice, the architect is the one who draws the line
between software architecture (architectural design) and
detailed design (non-architectural design). There are no
rules or guidelines that fit all cases, although there have
been attempts to formalize the distinction. According
to the Intension/Locality Hypothesis,[39]
the distinction
between architectural and detailed design is defined by
the Locality Criterion,[39]
according to which a statement
about software design is non-local (architectural) if and
only if a program that satisfies it can be expanded into
a program that does not. For example, the client–server
style is architectural (strategic) because a program that
is built on this principle can be expanded into a program
that is not client–server—for example, by adding peer-to-
peer nodes.
7.2 Requirements Engineering
Main article: Requirements engineering
Requirements engineering and software architecture can
be seen as complementary approaches: while soft-
ware architecture targets the 'solution space' or the
'how', requirements engineering addresses the 'problem
space' or the 'what'.[40]
Requirements engineering en-
tails the elicitation, negotiation, specification, validation,
documentation and management of requirements. Both
requirements engineering and software architecture re-
volve around stakeholder concerns, needs and wishes.
There is considerable overlap between requirements en-
gineering and software architecture, as evidenced for ex-
ample by a study into five industrial software architecture
methods that concludes that “the inputs (goals, constrains,
etc.) are usually ill-defined, and only get discovered or
better understood as the architecture starts to emerge” and
that while “most architectural concerns are expressed as re-
quirements on the system, they can also include mandated
design decisions”.[23]
In short, the choice of required be-
havior given a particular problem impacts the architec-
ture of the solution that addresses that problem, while at
the same time the architectural design may impact the
problem and introduce new requirements.[41]
Approaches
such as the Twin Peaks model [42]
aim to exploit the
synergistic relation between requirements and architec-
ture.
7.3 Other types of 'architecture'
Main articles: Computer architecture, Systems architec-
ture and Enterprise architecture
Computer architecture Computer architecture targets
the internal structure of a computer system, in terms
of collaborating hardware components such as the
CPU – or processor – the bus and the memory.
Systems architecture The term systems architecture
has originally been applied to the architecture of
systems that consists of both hardware and software.
The main concern addressed by the systems archi-
tecture is then the integration of software and hard-
ware in a complete, correctly working device. In an-
other common – much broader – meaning, the term
applies to the architecture of any complex system
which may be of technical, sociotechnical or social
nature.
Enterprise architecture The goal of enterprise archi-
tecture is to “translate business vision and strategy
into effective enterprise”.[43]
Enterprise architec-
ture frameworks, such as TOGAF and the Zachman
Framework, usually distinguish between different
enterprise architecture layers. Although terminol-
ogy differs from framework to framework, many
include at least a distinction between a business
layer, an application (or information) layer, and a
technology layer. Enterprise architecture addresses
among others the alignment between these layers,
usually in a top-down approach.
8 See also
• Architectural pattern (computer science)
• Anti-pattern
• Architecture Centric Design Method
• Attribute-driven design

7
• Computer architecture
• Distributed Data Management Architecture
• Distributed Relational Database Architecture
• Systems architecture
• Systems design
• Software Architecture Analysis Method
• Time-triggered system
9 References
[1] Clements, Paul; Felix Bachmann; Len Bass; David Gar-
lan; James Ivers; Reed Little; Paulo Merson; Robert
Nord; Judith Stafford (2010). Documenting Software Ar-
chitectures: Views and Beyond, Second Edition. Boston:
Addison-Wesley. ISBN 0-321-55268-7.
[2] Perry, D. E.; Wolf, A. L. (1992). “Foundations
for the study of software architecture” (PDF). ACM
SIGSOFT Software Engineering Notes 17 (4): 40.
doi:10.1145/141874.141884.
[3] Bass, Len; Paul Clements; Rick Kazman (2012). Software
Architecture In Practice, Third Edition. Boston: Addison-
Wesley. ISBN 978-0-321-81573-6.
[4] SEI (2006). “How do you define Software Architecture?".
Retrieved 2012-09-12.
[5] Garlan & Shaw (1994). “An Introduction to Software Ar-
chitecture” (PDF). Retrieved 2012-09-13.
[6] Fowler, M. (2003). “Design – Who needs an
architect?". IEEE Software 20 (5): 11–44.
doi:10.1109/MS.2003.1231144.
[7] ISO/IEC/IEEE 42010: Defining “architecture”. Iso-
architecture.org. Retrieved on 2013-07-21.
[8] Jansen, A.; Bosch, J. (2005). “Software Architec-
ture as a Set of Architectural Design Decisions”. 5th
Working IEEE/IFIP Conference on Software Architecture
(WICSA'05). p. 109. doi:10.1109/WICSA.2005.61.
ISBN 0-7695-2548-2.
[9] Ali Babar, Muhammad; Dingsoyr, Torgeir; Lago, Patri-
cia; van Vliet, Hans (2009). Software Architecture Knowl-
edge Management. Dordrecht Heidelberg London New
York: Springer. ISBN 978-3-642-02373-6.
[10] George Fairbanks (2010). Just Enough Software Architec-
ture. Marshall & Brainerd.
[11] ISO/IEC/IEEE (2011). “ISO/IEC/IEEE 42010:2011
Systems and software engineering – Architecture descrip-
tion”. Retrieved 2012-09-12.
[12] Muller, Gerrit (August 20, 2007). “A Reference Archi-
tecture Primer” (PDF). Gaudi site. Retrieved November
13, 2015.
[13] Angelov, Samuil; Grefen, Paul; Greefhorst, Danny.
“A Classification of Software Reference Architec-
tures: Analyzing Their Success and Effectiveness”.
Proc. of WICSA/ECSA 2009 (IEEE): 141–150.
doi:10.1109/WICSA.2009.5290800. Retrieved 13
November 2015.
[14] Brooks, Jr., Frederick P. (1975). The Mythical Man-
Month - Essays on Software Engineering. Addison-
Wesley. ISBN 0-201-00650-2.
[15] Obbink, H.; Kruchten, P.; Kozaczynski, W.; Postema,
H.; Ran, A.; Dominick, L.; Kazman, R.; Hilliard, R.;
Tracz, W.; Kahane, E. (Feb 6, 2002). “Software Archi-
tecture Review and Assessment (SARA) Report” (PDF).
Retrieved November 1, 2015.
[16] Poort, Eltjo; van Vliet, Hans (September 2012). “RCDA:
Architecting as a risk- and cost management discipline”.
The Journal of Systems and Software (Elsevier) 85 (9):
1995–2013. doi:10.1016/j.jss.2012.03.071.
[17] P. Naur and B. Randell, Eds.,, ed. (1969). “Software
Engineering: Report of a conference sponsored by the
NATO Science Committee, Garmisch, Germany, 7–11
Oct. 1968.” (PDF). Brussels: NATO, Scientific Affairs
Division,. Retrieved 2012-11-16.
[18] P. Kruchten, H. Obbink & J. Stafford (2006). “The past,
present and future of software architecture”. Retrieved
2012-11-12.
[19] University of Waterloo (2006). “A Very Brief History of
Computer Science”. Retrieved 2006-09-23.
[20] IEEE Transactions on Software Engineering (2006).
“Introduction to the Special Issue on Software Architec-
ture”. Retrieved 2006-09-23.
[21] Garlan & Shaw (1994). “An Introduction to Software Ar-
chitecture” (PDF). Retrieved 2006-09-25.
[22] Kruchten, P. (2008). “What do software architects really
do?". Journal of Systems and Software 81 (12): 2413–
2416. doi:10.1016/j.jss.2008.08.025.
[23] Christine Hofmeister, Philippe Kruchten, Robert L. Nord,
Henk Obbink, Alexander Ran, Pierre America (2007).
“A general model of software architecture design derived
from five industrial approaches”.
[24] ISO/IEC (2011). “ISO/IEC 25010:2011 Systems and
software engineering – Systems and software Quality Re-
quirements and Evaluation (SQuaRE) – System and soft-
ware quality models”. Retrieved 2012-10-08.
[25] Osterwalder and Pigneur (2004). “An Ontology for e-
Business Models": 65–97.
[26] Woods, E. (2012). “Industrial architectural assessment
using TARA”. Journal of Systems and Software 85 (9):
2034–2047. doi:10.1016/j.jss.2012.04.055.
[27] Maranzano, J. F.; Rozsypal, S. A.; Zimmerman, G. H.;
Warnken, G. W.; Wirth, P. E.; Weiss, D. M. (2005). “Ar-
chitecture Reviews: Practice and Experience”. IEEE Soft-
ware 22 (2): 34. doi:10.1109/MS.2005.28.

8 11 EXTERNAL LINKS
[28] Babar, M.A.; Dingsøyr, T.; Lago, P.; Vliet, H. van
(2009). Software Architecture Knowledge Management:
Theory and Practice (eds.), First Edition. Springer. ISBN
978-3-642-02373-6. Cite uses deprecated parameter
|coauthors= (help)
[29] Tang, A.; Han, J.; Vasa, R. (2009). “Software Ar-
chitecture Design Reasoning: A Case for Improved
Methodology Support”. IEEE Software 26 (2): 43.
doi:10.1109/MS.2009.46.
[30] Kruchten, Philippe (1995, November). Architectural
Blueprints — The “4+1” View Model of Software Archi-
tecture. IEEE Software 12 (6), pp. 42–50.
[31] Shaw, Mary; Garlan, David (1996). Software architec-
ture: perspectives on an emerging discipline. Prentice Hall.
ISBN 978-0-13-182957-2.
[32] UCI Software Architecture Research – UCI Software Ar-
chitecture Research: Architectural Styles. Isr.uci.edu.
Retrieved on 2013-07-21.
[33] Chapter 3: Architectural Patterns and Styles.
Msdn.microsoft.com. Retrieved on 2013-07-21.
[34] Boehm, Barry; Turner, Richard (2004). Balancing Agility
and Discipline. Addison-Wesley. ISBN 0-321-18612-5.
[35] “IEEE Software Special Issue on Agility and Architec-
ture”. April 2010. Retrieved 14 September 2012.
[36] Terra, R., M.T. Valente, K. Czarnecki, and R.S. Bigonha,
“Recommending Refactorings to Reverse Software Ar-
chitecture Erosion”, 16th European Conference on Soft-
ware Maintenance and Reengineering, 2012. http://gsd.
uwaterloo.ca/sites/default/files/Full%20Text.pdf
[37] de Silva, L. and D. Balasubramaniam, “Controlling soft-
ware architecture erosion: A survey”, Journal of Systems
and Software 01/2012; 85:132–151.
[38] Lungu, M. “Software architecture re-
covery”, University of Lugano, 2008.
http://www.slideshare.net/mircea.lungu/
software-architecture-recovery-in-five-questions-presentation
[39] Amnon H. Eden, Rick Kazman (2003). “Architecture De-
sign Implementation” (PDF).
[40] C. Shekaran, D. Garlan, M. Jackson, N.R. Mead, C. Potts,
H.B. Reubenstein (1994). “The Role of Software Archi-
tecture in Requirements Engineering”.
[41] Remco C. de Boer, Hans van Vliet (2009). “On the simi-
larity between requirements and architecture”.
[42] Bashar Nuseibeh (2001). “Weaving together require-
ments and architectures”.
[43] Definition of Enterprise Architecture, Gartner
10 Further reading
• Paul Clements, Felix Bachmann, Len Bass, David
Garlan, James Ivers, Reed Little, Paulo Merson,
Robert Nord, Judith Stafford: Documenting Soft-
ware Architectures: Views and Beyond, Second Edi-
tion. Addison-Wesley, 2010, ISBN 0-321-55268-7.
This book describes what is software architecture
and shows how to document it in multiple views, us-
ing UML and other notations. It also explains how
to complement the architecture views with behav-
ior, software interface, and rationale documentation.
Accompanying the book is a wiki that contains an
example of software architecture documentation.
• Len Bass, Paul Clements, Rick Kazman: Software
Architecture in Practice, Third Edition. Addison
Wesley, 2012, ISBN 0-321-81573-4 (This book,
now in third edition, eloquently covers the funda-
mental concepts of the discipline. The theme is cen-
tered on achieving quality attributes of a system.)
• Amnon H. Eden, Rick Kazman. Architecture, De-
sign, Implementation. On the distinction between
architectural design and detailed design.
• Javier Garzás and Mario Piattini. An ontology for
micro-architectural design knowledge, IEEE Soft-
ware Magazine, Volume: 22, Issue: 2, March–April
2005. pp. 28 – 33.
• Philippe Kruchten: Architectural Blueprints – the
4+1 View Model of Software Architecture. In: IEEE
Software. 12 (6) November 1995, pp. 42–50 (also
available online at the Rational website(PDF))
• Tony Shan and Winnie Hua (2006). Solution Archi-
tecting Mechanism. Proceedings of the 10th IEEE
International EDOC Enterprise Computing Confer-
ence (EDOC 2006), October 2006, p 23–32
• Martin Fowler (with Ralph Johnson) Who Needs an
Architect? IEEE Software, Jul/Aug 2003
• SOMF: Bell, Michael (2008). “Service-Oriented
Modeling: Service Analysis, Design, and Architec-
ture”. Wiley.
11 External links
• Explanation on IBM Developerworks
• Collection of software architecture definitions at
Software Engineering Institute (SEI), Carnegie
Mellon University (CMU)
• International Association of IT Architects (IASA
Global), formerly known as the International Asso-
ciation for Software Architects (IASA)

9
• SoftwareArchitecturePortal.org — website of IFIP
Working Group 2.10 on Software Architecture
• SoftwareArchitectures.com — independent re-
source of information on the discipline
• Software Architecture, chapter 1 of Roy Fielding's
REST dissertation
• When Good Architecture Goes Bad
• The Spiral Architecture Driven Development – the
SDLC based on Spiral model is to reduce the risks
of ineﬀective architecture

10 12 TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES
12 Text and image sources, contributors, and licenses
12.1 Text
• Software architecture Source: https://en.wikipedia.org/wiki/Software_architecture?oldid=713244324 Contributors: Guppie, Roadrun-
ner, Edward, Michael Hardy, Nixdorf, Kku, SebastianHelm, Poor Yorick, Kaihsu, Greenrd, Bweﬂer, RedWolf, Masao, Techtonik,
Rholton, Hadal, Remy B, Khalid hassani, Vanished user wdjklasdjskla, Dvavasour, Mberteig, Pinguin.tk~enwiki, Liuti, Abdull, Jayjg,
Freakofnurture, Leibniz, ZeroOne, AndrewTaylor, S.K., Szquirrel, Marx Gomes, Jonon, Shanes, Felagund, Smalljim, La goutte de pluie,
Gnyus, Mdd, Felyduw, Zachlipton, Stephan Leeds, Neetij, Tomlzz1, SteinbDJ, Stephen, Rocastelo, Maccoy, Ruud Koot, Marudubshinki,
Bpp198, Aasch, DugDownDeep, DVdm, Bhny, Gaius Cornelius, Yrithinnd, Wiki alf, Welsh, Gareth Jones, Stephen e nelson, Jpbowen,
Codes02, Webreloaded, K.Nevelsteen, Richard@lbrc.org, Tvarnoe~enwiki, Rwwww, Eoinwoods, TuukkaH, Sardanaphalus, SmackBot,
Gigs, Brick Thrower, Anwar saadat, Optikos, DHN-bot~enwiki, Colonies Chris, Hongooi, Frap, Mpandrews, JonHarder, Allan McInnes,
Normxxx, Jmlk17, MichaelBillington, Kuru, Yan Kuligin, RfHilliard, Neerajsangal, Antonielly, IronGargoyle, 16@r, Wikidrone, Mr
Stephen, Johnmc, David.alex.lamb, Hu12, Hetar, IvanLanin, AGK, Fdp, Unixguy, Pmerson, Euzuncaova, Cydebot, Pronob, Pindakaas,
LeeG, Deemery, Dawnseeker2000, AntiVandalBot, Spencer, W1k1th1nk, Fbahr, MER-C, 100110100, Srinaveen, SiobhanHansa, Crea-
con, Wwmbes, Cander0000, Oicumayberight, Nickmalik, Firebrandck, R'n'B, CommonsDelinker, Tonyshan, Bobianite, L.W.C. Nirosh,
Maile66, Philip Trueman, TXiKiBoT, Sujayg, Rainco, Clairestreb, Kchampcal, Damien Cassou, Troddel, Hcagri, Barkeep, Equilibri-
oception, Flyer22 Reborn, JCLately, Mcpatnaik, Miniapolis, Lightmouse, Tafenau, OKBot, Wikitect, Anchor Link Bot, Pinkadelica,
ImageRemovalBot, ClueBot, Jan Hoeve, Skwa, Hamid nazari, Alexbot, PixelBot, SchreiberBike, 9Nak, XLinkBot, AngelaMartin2008,
Srikant.sharma, Tomrbj, Addbot, Melab-1, Maria C Mosak, SEI Publications, Pellicci, ‫,רנדום‬ Legobot, Luckas-bot, Yobot, KamikazeBot,
AnomieBOT, Materialscientist, Citation bot, Khmalak, LilHelpa, Villeez, FrescoBot, Mark Renier, Goswamivijay, Brettright, I dream of
horses, RedBot, MastiBot, Bsonderg, Trappist the monk, Ienumerable, BenediktG, Jelabra, Primefac, K6ka, Rcdeboer, ZéroBot, Andrpere,
Nav102, Architectchao, Rnkazman, Bomazi, ChuispastonBot, ClueBot NG, Sofmlb, Inﬁnifold, Helpful Pixie Bot, Wbm1058, BG19bot,
Vrravalos, Rprgrmr, Compfreak7, AdventurousSquirrel, BattyBot, David.moreno72, Wimute, Stigmatella aurantiaca, Dexbot, FoCuSan-
dLeArN, Voithos, Hithem.aly, TwoTwoHello, Antonystang, Eltjopoort, Mtvalente, Phamnhatkhanh, Acetotyce, Maura Driscoll, My name
is not dave, Monkbot, Tal.architect, Glen Eyre Hall, Rademers, Ranjeetshah247, KasparBot, Lindenc, PLEASEHP1, Mynameisjohnsmith
and Anonymous: 236
12.2 Images
• File:4+1_Architectural_View_Model.jpg Source: https://upload.wikimedia.org/wikipedia/commons/f/f2/4%2B1_Architectural_
View_Model.jpg License: CC BY-SA 3.0 Contributors: Own work Original artist: Marcel Douwe Dekker
• File:Commons-logo.svg Source: https://upload.wikimedia.org/wikipedia/en/4/4a/Commons-logo.svg License: CC-BY-SA-3.0 Contribu-
tors: ? Original artist: ?
• File:Folder_Hexagonal_Icon.svg Source: https://upload.wikimedia.org/wikipedia/en/4/48/Folder_Hexagonal_Icon.svg License: Cc-by-
sa-3.0 Contributors: ? Original artist: ?
• File:Wikiquote-logo.svg Source: https://upload.wikimedia.org/wikipedia/commons/f/fa/Wikiquote-logo.svg License: Public domain
Contributors: ? Original artist: ?
12.3 Content license
• Creative Commons Attribution-Share Alike 3.0

Software architecture

More Related Content

What's hot (20)

Similar to Software architecture (20)

Recently uploaded (20)

Software architecture