See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/236870571

What is Software Architecture

Conference Paper · October 2012

DOI: 10.1145/2389836.2389879

CITATIONS READS

12 6,969

1 author:

Fritz Solms
Solms Training & Consulting & Stellenbosch University
45 PUBLICATIONS   210 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Fritz Solms on 15 May 2014.

The user has requested enhancement of the downloaded file.

 What is Software Architecture?

Fritz Solms
Department of Computer Science
University of Pretoria
South Africa
[email protected]

ABSTRACT General Terms

Currently there is no consensus on what exactly software Design
architecture is or where the boundary between software archi-
tecture design and application design lies. In this paper the Keywords
concept of a software architecture is analyzed from a num- software architecture, reference architecture
ber of different perspectives. In particular, it is argued that
a software reference architecture is a relatively pure spec-
ification of a software architecture as it addresses only in- 1. INTRODUCTION
frastructural and quality concerns and does not provide any The responsibilities of a software architect include the de-
application functionality. Two examples of widely adopted sign, documentation, assessment and evolution of a software
reference architectures are analyzed in order to gain a deeper architecture within which functionality can be deployed and
understanding of the concept of a software architecture. executed in such a way that the quality requirements for the
system are met [5]. It is understood that the software archi-
Current definitions of software architecture are analyzed and tecture specification contains many of the important design
three classes of software architecture definitions are identi- decisions and that these decisions are hard to change at a
fied. The differences of the concept of software architecture later stage [14].
across these classes is discussed and their relationships to
current architecture description languages are explored. It However, even though software architecture is not a new
is argued that none these definitions provide a sound ba- field, we do not yet have consensus on what exactly soft-
sis for differentiating between application and architecture ware architecture is. We have a range of definitions which
components. differ in some significant ways. Most of definitions are such
that the boundary between architecture and application de-
Based on insights obtained from the analyzed reference ar- sign is left open for interpretation. Application design is
chitectures, the paper proposes a new definition of software defined here as the design of the components addressing the
architecture as well as a specification of the elements of a functional requirements of the user. The resultant applica-
software architecture specification. Software architecture is tion components are deployed in a software architecture ad-
defined as the software infrastructure within which applica- dressing the architectural requirements including the quality
tion components providing user functionality can be speci- requirements for the system.
fied, deployed and executed. It is argued that a software
architecture description should include, across levels of gran- The different approaches to software architecture manifest
ularity, the basic concepts and constraints within which ap- themselves in a wide range of Architecture Description Lan-
plication components are to be specified, the architectural guages (ADLs) which differ in what aspects of a software
components addressing technical concerns, the integration architecture they can specify. Furthermore, one’s choice of
infrastructure, and the architectural strategies used to con- a definition of software architecture influences the content of
cretely address quality requirements. an architectural requirements specification, how the archi-
tectural design is done and its deliverables, and how software
architectures are to be assessed. Consequently the choice of
Categories and Subject Descriptors definition of software architecture directly impacts on the
D.2.11 [Software Engineering]: Software Architecture responsibilities of and skills requirements for software archi-
tects. There would thus be significant benefits if the software
development community reached consensus on the concept
of software architecture.

The remainder of the paper is organized as follows. In sec-

tion 2 some general insights into software architecture are
discussed. It is argued that reference architectures are rel-
atively pure representations of software architectures and
SAICSIT ’12, October 01 - 03 2012, Pretoria, South Africa Copyright 2012 that these can be studied in order to deepen one’s under-
ACM 978-1-4503-1308-7/12/10âòe$15.00. standing of the concept of software architecture. Two of
the more widely used reference architectures are introduced
in order to analyze various aspects of software architecture
and to highlight the boundary between software architecture
and application functionality. In section 3 different classes of
software architecture definitions are identified and analyzed.
A new definition of software architecture is proposed in sec-
tion 4. The corresponding elements of a software architec-
ture specification is discussed and it is highlighted that these
are present across levels of granularity. The section also in-
cludes a discussion around the interplay between architec-
ture and application design. In section 5 the work is put
into context of some related work. Finally some conclusions
are drawn and outlook for future work is discussed. Figure 1: At the first level of granularity the infras-
tructure of the application server is based on the
layered architectural pattern.
2. SOME INSIGHTS INTO SOFTWARE
ARCHITECTURE
In this section we study software architectures from various tion of the architectural elements and strategies specified
perspectives in order to assimilate an understanding of the by a reference architecture. A specific system architecture
concept of software architecture. Based on the insights dis- based on the template provided by the reference architecture
cussed in this section, we will propose a definition for the is called an instance architecture. Such an instance architec-
concept of software architecture and identify its elements. ture may or may not be realized within a framework.

In this paper we use these two commonly adopted reference

2.1 Reference architectures architectures to discuss the concept of a software architec-
Since we currently do not have consensus on the definition of ture.
software architecture, we also do not have a single definition
for a reference architecture. Lloyd and Galambos define [19] 2.1.1 Short overview of the Java-EE reference archi-
reference architectures as domain-specific architectural tem-
plates which aim to address the architectural concerns for a tecture
particular class of problems. This is the definition chosen Java-EE was introduced in 1999 via a community process
for the purpose of this paper. led by Sun Microsystems. At the time of writing the cur-
rent version was version 6. Java-EE is implemented in a wide
For example, a gaming platform might provide a suitable range of open-source and proprietary frameworks including
referance architecture into which a certain class of computer JBoss, Apache Geronimo, IBM Websphere and Oracle We-
games can be deployed into, whilst a reference architecture bLogic Application Server. These Java-EE frameworks
for enterprise systems addresses the infrastructure and qual-
ity concerns of a certain class of enterprise systems. • enforce a layered architectural style containing the ar-
chitectural layers defined in the Java-EE reference archi-
Zhu, Staples and Tosic, on the other hand view reference ar- tecture,
chitectures as template systems with implemented template
business processes for specific business domains[31]. This • and provide
paper differentiates between a reference architectures which
address the infrastructural and quality concerns of a class of – access and integration infrastructures,
system, and a reference applications which provide template – a persistence infrastructure for storing, retrieving
application functionality. and updating objects which are ultimately stored
in relational databases, and
Examples of widely used reference architectures for enter- – a set of implemented architectural strategies1 to
prise systems include the Java-EE (Java Enterprise Edition) address quality requirements for typical enterprise
reference architecture as well as services oriented architec- systems, including reliability, scalability, security,
tures (SOAs). These reference architectures have simplified performance, and integrability with a particular
the responsibility of architecture design for typical enterprise emphasis on the first three.
systems by providing a template solution which addresses
common architectural concerns for such systems.
The main architectural element of the Java-EE reference
A reference architecture does not contain application logic. architecture is an application server within which applica-
It provides an infrastructure within which application logic tions addressing the functional requirements of application
can be deployed and executed. As such they provide exam- users are realized. The architectural pattern2 used at this
ples of relatively pure software architecture specifications for highest level of granularity is the layered architectural pat-
which the separation of application and architecture logic tern (see figure 2.1.1). Application servers provide an access
has been enforced. 1
Architectural strategies are also know as architectural tac-
tics.
An implementation of a reference architecture is called a 2
Architectural patterns are sometimes called architectural
framework. A framework provides a concrete implementa- styles.
layer, an process execution layer, and an integration layer
which provides, amongst other things, integration to rela-
tional databases.

The access layer contains a web container which hosts hu-

man and system adapters in the form of web front-ends and
a web services broker. System access can also be provided
through message queues, RMI (the Java Remote Method In-
vocation interface based on CORBA, the Common Object
Request Broker Architecture) and CORBA.

The process execution layer is represented by an EJB (Enter-

prise Java Beans) container. It hosts the application compo- Figure 2: At the first level of granularity Java-EE
nents which provide the application functionality. In Java- application structures are constrained by the refer-
EE these components are represented by enterprise beans ence architecture enforcing a layered architectural
which are either stateless and stateful session beans or mes- pattern on the application structure.
sage driven beans. The Java-EE specification requires that
the components are decoupled via component interfaces and
dependency injection. EJB containers maintain and opti- plications are also based on the layered architectural pattern
mize thread pools for these application components. with the layers corresponding to the infrastructural layers of
the application server itself. This is depicted in figure 2.1.1.
The integration layer contains adapters to other systems.
One of these is the persistence context which provides the The Java-EE reference architecture enforces, at lower levels
integration channel to a database. Enterprise systems com- of granularity, further application structure constraints. For
monly use relational database management systems (DBMSs) example, application elements in the presentation layer are
as their preferred persistence technology. The persistence guided JSF to the Model-View-Controller (MVC) pattern.
context maintains an object cash and uses an object-relational
mapper to map domain objects used in the processes layer 2.1.2 Short overview of a SOA-based reference archi-
onto persistent storage, i.e. a database. tecture
Services-Oriented Architectures (SOAs) are commonly used
Java-EE frameworks use a range of architectural strategies
to provide an integration infrastructure between enterprise
to address common quality requirements of typical enter-
systems of larger organizations. Whilst there is no authori-
prise systems. Scalability and reliability is addressed through
tative specification of the SOA reference architecture, there
support for clustering, thread and connection pooling, ob-
is nevertheless general agreement on the core components of
ject/data caching, transactions, and messaging. Security
a SOA. Most of the lower level elements are based on public
is addressed through authentication, authorization and en-
standards maintained by the World-Wide-Web Consortium,
cryption support. Modifiability is enhanced through en-
W3C. The Java Business Integration reference architecture
forced decoupling through interfaces, dependency injection,
(JBI) is a concrete reference specification of a SOA refer-
the ability to use interception to add further functionality
ence architecture. Apache Servicemix and Open-ESB are
to existing functionality, and hot deployment (the ability
two open-source frameworks which implement the JBI SOA
to deploy, update and undeploy application functionality
specification.
at run-time). Interfaces and dependency injection improve
flexibility by facilitating pluggability of components across
Like Java-EE, a SOA targets the domain of enterprise sys-
levels of granularity. Integrability is addressed by support-
tems. But whilst Java-EE puts the main emphasis on scala-
ing standard integration technologies like CORBA and web
bility, reliability and security, SOA puts the main emphasis
services and providing features which automate access to
on integrability and modifiability.
application functionality through different integration chan-
nels. In Java-EE one can simply annotate a class operation
At the highest level of granularity, SOA is based on the
as a web service. The architecture can automatically gen-
mikrokernel architectural pattern (see figure 2.1.2. The mikro-
erate the web services contract, and the infrastructure for
kernel itself is represented by a services bus which provides
making the service available through SOAP/HTTP. Perfor-
an integration infrastructure between service providers and
mance is improved through thread pooling, object and data
service consumers. It provides routing of services requests
caching, and connection pooling.
to different service providers (servers) as well as an adapter
layer to adapt to these service providers. Internal servers
In Java-EE effort has been made to keep architectural con-
are systems within the organization whilst external servers
cerns out of the application logic. Architectural information
provide the services which are sourced from outside the or-
(e.g. whether a service should be made available as a web ser-
ganization.
vice) is not specified in code, but instead through meta-data
which is provided either in separate deployment descriptors
SOA also specifies the existence of a services registry where
or in the form of annotations.
service contracts and services which realize these contracts
are registered. Process specification languages like the Busi-
The architecture also introduces concepts and constraints
ness Process Specification Language (BPEL) are used to “or-
for application development. At the high level, Java-EE ap-
chestrate” higher level services across lower level services.
 Note that both reference architectures contain extensive ar-
chitectural functionality, but that neither aims to address
any user functionality (like the “business” logic for process-
ing a withdrawal from an account).

2.3 Concerns of software architecture

Both reference architectures discussed in section 2.1 specify

• a set of basic concepts and constraints within which

application functionality is to be specified and inte-
grated.
• architectural components addressing technical concerns,
Figure 3: At the first level of granularity the infras-
tructure of the application server is based on the • access and integration channels through which the ap-
layered architectural pattern. plication functionality can be accessed and through
which application logic can access externally provided
functionality, and
The processes are executed within process execution engines
• architectural strategies through which quality require-
which can interpret the process specification language used.
ments are concretely addressed.
These process engines are commonly referred to as Business
Process Execution Engines (BPEE).
2.3.1 Basic concepts and constraints
The BPEEs are deployed within a lower level software archi- A software architecture may introduce architecture-specific
tecture providing the actual execution infrastructure like ac- concepts and may specify constraints around these concepts.
cess to threads and memory. Common examples are EJB or The concepts and constraints are often specified in the form
Spring containers. of architectural styles or patterns with concepts which are
specific to the style or pattern.
Like Java-EE, SOA based architectures use a range of ar-
chitectural strategies to concretely address quality require- The highest level of granularity of Java-EE specifies that ap-
ments. Recently we have also seen increasing attention on plication logic should be specified across three layers, a pre-
defining self-adapting SOA-based architectures which dy- sentation layer containing web application, a (business) pro-
namically choose different architectural strategies to achieve cesses layer containing the business/domain logic as enter-
the required quality of service [22, 4, 21]. prise beans and a domain objects layer containing entities. It
is important that there are not only concepts and constraints
Component based architectures require that application logic in the form of architectural patterns for the application code,
should be deployed as pluggable components which poten- but that the architectural components themselves may be
tially maintain state across service requests. SOA, on the organized within architectural styles or patterns. For exam-
other hand, requires that application logic should be spec- ple, at the highest level of granularity, both the architectural
ified within stateless services. Application logic is specified and application components are constrained within hierar-
within the pipes-and-filters architectural style, i.e. higher chical patterns. Whilst the application logic is constrained
level services are assembled (“orchestrated”) from lower level to a presentation layer, a business logic and a domain ob-
services by connecting them through pipes. Service may not jects layer, the high-level architectural components are an
have a direct dependency on each other. These services real- access layer containing the web container, a processing layer
ize service contracts which are specified in the Web Services containing the EJB container and an infrastructure layer
Description Language, WSDL. containing the persistence manager and integration compo-
nents.

2.2 Architecture functionality versus applica- On the other hand, the basic application components of an
tion functionality architecture based on a Services-Oriented Architecture ref-
In order to clarify the concept of software architecture, we erence architecture a service contract and a service realizing
introduce the concepts of application and architecture func- that service contract. Constraints include that every service
tionality. must be stateless (no state is maintained across service re-
quests), that it is self-healing (i.e. failure in the rendering of
We define application functionality as the functionality re- one service should not impact on the ability to realize the
quired to address the user’s functional requirements, i.e. next service request), and that services are assembled from
functional requirements in the problem domain and archi- lower level services within a pipes and filters architectural
tecture functionality as the functionality required to address style.
technical concerns like, for example, the functionality re-
quired to implement architectural strategies (resource pool- 2.3.2 Architectural components
ing, load balancing, . . . ) addressing quality requirements Both reference architectures specify a set of architectural
or the functionality within the persistence or integration in- components addressing technical concerns. In Java-EE the
frastructure. high-level architectural component is an application server.
The next lower level components are the web container pro- high-level infrastructure within which application logic can
viding web-based access, the EJB container providing an be deployed and executed, but an infrastructure which spans
execution environment and entity manager providing access across a large number of levels of granularity. The architec-
to relational databases. tural concerns discussed in section 2.3 are present across
levels of granularity. We may thus have architectural archi-
SOA defines as core architectural components a services bus, tectural concepts, constraints (e.g. styles/patterns), archi-
a service registry for registering service contracts and service tectural components, integration channels and strategies at
providers, and a business process execution engine for exe- any level of granularity.
cuting business processes.
Let us look, for example, at Java-EE. At the highest level of
These components provide standard APIs. For example, an granularity represented by the application server, Java EE
application server implements a standard API for deploying introduces
applications and any implementation of an entity manager
implements the Java Persistence API.
• the layered architectural style with the concepts of ac-
cess, processing and infrastructure layers,
2.3.3 Access and integration channels
Both reference architectures specify access and integration • the web and EJB containers and entity manager as
channels for components of the application server,
• integration channels between these components,
• accessing functionality deployed within the architec-
ture, • architectural strategies like clustering, and

• for deployed application logic to access externally de- • infrastructural functionality like that of deploying and
fined functionality, and undeploying applications.

• integration channels between the architectural compo-

nents defined for the architecture. At the next lower level of granularity we have, for example,
the EJB container which introduces the concepts of enter-
prise beans as business logic components. At this lower level
For example, Java-EE specifies a web-based access channel of granularity it uses the flyweight pattern to achieve scal-
for human users, and web-services, CORBA and RMI chan- ability across a potentially large number of stateful compo-
nels for systems. Access between application components is nents. There is lower level functionality like those of obtain-
via local or remote Java calls. ing a session context or an entity manager. At even lower
levels of granularity there are the details of the thread pool-
In SOA-based architectures access between system compo- ing, the implementation of the interception framework and
nents is generally standardized as either synchronous or asyn- so on.
chronous web services access. The latter is generally via
message queues. The basic concepts and constraints for application logic are
also specified across levels of granularity. We saw that Java
2.3.4 Implement architectural strategies EE requires application logic to be specified across a presen-
Frameworks based on either of the reference architectures, tation layer, a processes layer and a domain objects layer.
provide an implementation of a range of architectural strate- The presentation layer is represented by a web application.
gies in order to address quality requirements. At the next lower level of granularity, Java-EE constrains
the web application to be based on the MVC pattern, intro-
For example, they commonly implement clustering, a strat- ducing facelets for the views, backing beans for the models
egy which groups computers together in such a way that maintaining the state of the views, and binding beans for
they behave like a single computer. Requests are load is the controllers which act on user events.
distributed across the different computers within the clus-
ter which process these requests concurrently. If a computer Note, however, that none of the above architectural com-
within a cluster fails, no further requests are channeled to ponents represent objects from the problem domain. Also,
it. Clustering can thus be used to improve scalability, per- none the above functionality addresses any of the functional
formance and reliability. requirements from the problem domain.

Architectural strategies are also implemented at lower lev- 2.5 Architecture is a matter of perspective
els of granularity. For example EJB containers use thread It needs to be pointed out, though, that whether something
pooling, Java connectors use connection pooling and entity is architecture or application functionality depends on what
managers use object caching to achieve a higher level of scal- application one is developing.
ability and performance.
Consider, for example, the scenario depicted in figure 2.5. If
2.4 Architecture across levels of granularity one is developing, say, a banking system, then the applica-
Often software architecture is viewed as a high level abstrac- tion functionality would include those of opening and clos-
tion of a software system. Note, however, that both refer- ing accounts, processing transaction, and so on. In order to
ence architectures analyzed in this paper provide not only a address the non-functional requirements of the application,
 3.1 Classes of software architecture definitions
The first class of software architecture definitions defines
software architecture as a high-level abstraction of a
software system [30, 28, 14, 23]. For example, Zhang &
Goddard define software architecture as a high level abstrac-
tion representing the structure, behaviour, and non-functional
properties of software systems[30]. Viewing architecture as a
high-level system abstraction raises a number of questions.
For example, what exactly is high-level and where is the
boundary between architecture and application functional-
ity? If one focuses on a particular component of a software
system, is there still architecture. How does one know? Fur-
thermore, since in such a definition architecture needs to ad-
dress both, high-level functional and non-functional require-
ments, would one not need the same requirements elements
Figure 4: Architecture is a matter of perspective.
for architecture and application functionality and where is
the boundary between these? How are non-functional re-
quirements at lower levels of granularity addressed if there
one may choose to use a Java-EE based software architec- is no architecture at these lower levels of granularity? Note
ture which would contain the application server a database, also that this class of definitions identifies high-level abstrac-
. . . , as architectural components. tions of different aspects of a software system, e.g. high-level
structural and functional abstractions. This prompts Bara-
If, on the other hand, one is busy developing an applica- gry and Reed to question whether there is a single concept
tion server, then the application is the application server for software architecture [6]. The different abstractions are
itself. It realizes the functional requirements of the appli- usually modeled using either different views onto a single ar-
cation server users (e.g. the business system developers and chitectural model as in, for example, the Kruchten 4+1 View
system administrators). model of a software architecture [18], or by using different
architectural models as is supported by the IEEE Recom-
The point of this section is to highlight that software archi- mended Practice for Architectural Description of Software-
tecture is not an absolute concept. The concept of a software Intensive Systems [1].
architecture is relative to the application one is developing.
The second class of software architecture definitions views
From the perspective of the banking system developer, the software architecture as the structure and externally
banking application needs to provide the functionality re- visible properties of a software system [7, 10, 1]. This
quired by the banking system users, whilst the application class of definitions does not include functionality in the def-
server would be a core architectural component - it does not inition of software architecture and keeps the question on
provide any banking functionality. On the other hand, for whether architecture is only high-level open. The focus is
the application server developer, the application server ap- on components and relationships between the components
plication needs to address the functional requirements for themselves as well as relationships between the components
the application server itself which may include functionality and the system environment. One such commonly refer-
like load balancing, role based authorization, thread and ob- enced definition is that provided by Bass, Clements and
ject pooling and so on. This functionality provided by the Katzman [7] which defines software architecture as the struc-
application server is the functionality which is required to ture or structures of the system, which comprise software el-
address non-functional requirements in the banking system ements, the externally visible properties of those elements,
domain. and the relationships among them. Even though these def-
initions make it more feasible to separate architectural and
The same piece of software, the application server in our functional aspects of a system, they still raise a number of
case, may thus be part of the architecture from the perspec- questions. For example, what would the components be?
tive of some developers and the actual application providing Would they provide application functionality (e.g. an ac-
application logic for others. These developers are, however, count management system) or should one include only com-
developing applications from different domains. In our case ponents addressing more abstract infrastructural or tech-
an application for the business domain and an application nical concerns (e.g. a services bus). The above definition
for a high-level technical domain. speaks of software elements in general and does not distin-
guish between architectural and application elements. It
caters for quality attributes of a software system through
3. CURRENT DEFINITIONS OF the externally visible properties. But externally visible com-
SOFTWARE ARCHITECTURE ponents can also refer to aspects of the system related to
In this section we group commonly used definitions of soft- its functionality. The boundary between architectural and
ware architecture into three classes. We analyze the differ- application functionality is thus again not clearly specified.
ences between these classes and critically assess them from
the perspective of whether and how they are able to define The UML 1.3 definition of software architecture also falls
the boundary between architecture and application function- within the class of structure-based software architecture defi-
ality. nitions. But unlike other definitions, it explicitly states that
software architecture needs to be specified across levels of 3.2 Relation to ADLs
granularity. UML 1.3 defines the architecture of a system It is well known that Architecture Description Languages
as the organizational structure of a system. An architec- (ADLs) differ extensively in what aspects of a software archi-
ture can be recursively decomposed into parts that interact tecture they are able to describe [24, 17, 30]. Here we point
through interfaces, relationships that connect parts, and con- out that features of the different classes of software archi-
straints for assembling parts. Parts that interact through tecture definitions are supported by different ADLs.
interfaces include classes, components and subsystems[8].
Even though such a definition acknowledges the existence The commonality across the classes of software architecture
of software architecture across levels of granularity, it still definitions is reflected in virtually all ADLs having the abil-
does not provide a any guidelines on whether one should ity to specify components and relationships between them.
or how one would differentiate between architectural com- For example, Wright [2], Acme [16], and their derivatives
ponents and application classes and interfaces required for are all based on a core of architectural components and re-
application functionality. lationships.

The third class of software architecture definitions places The first class of architecture definitions includes the spec-
the focus on an architecture introducing fundamental con- ification of functionality as part of the architecture. Many
cepts and constraints within which the software sys- ADLs including Wright [2], Darwin [20], MADL [27], and
tem is to be designed and developed[13, 28]. The most CBabel [9] include the ability to specify behaviour. This
widely referenced example of this class of software architec- is typically done using formal process specification tech-
ture definitions is the IEEE specification of a Recommended nologies like π-calculus or Concurrent Sequential Processes
Practice for Architectural Description of Software-intensive (CSP).
Systems[13]. The latest version, ISO/IEC/IEEE 42010, de-
fines a software architecture as the fundamental concepts The second class of software architecture definitions includes
or properties of a system in its environment embodied in externally visible properties as part of the definition. These
its elements, relationships, and in the principles of its de- are commonly seen as quality attributes of the system. Most
sign and evolution [13]. The fundamental concepts cater ADLs do not provide explicit support for specifying quality
for concepts within which application logic can be defined attributes or strategies through which these are addressed.
(e.g. a service and a services contract in a service-oriented A notable exception is the aspect-oriented ADLs [25, 26]
architecture). The fundamental properties generally refer to which use aspects to apply architectural strategies to ad-
quality attributes of a system. Finally, fundamental princi- dress quality attributes. Another approach is that followed
ples of the system design and evolution can be used to refer by Menase et al. [22]. They define a set of what they call
to core design constraints. These are often specified as ar- architectural patterns representing concrete designs of archi-
chitectural styles. Examples of architectural styles include tectural strategies. They show that components implement-
pipes and filters, layering, blackboard, microkernel, hierarchi- ing these patterns can not only be statically selected in the
cal, and others. The above definition also refers to system software architecture specification, but can also be dynami-
elements without distinguishing between architectural and cally selected by self-adapting software architectures.
application or functional elements, leaving once again the
boundary between architecture and application design open The third class of software architecture definitions puts em-
for interpretation. phasis on the definition of fundamental concepts and prin-
ciples of design. These are commonly represented by archi-
In summary, we have three classes of software architecture tectural styles which introduce style-specific concepts (e.g.
definitions which view a software architecture as (1) a high layers, pipes and filters, . . . ) and define constraints on how
level abstraction of a software system, (2) the structure of these design elements may be assembled. Some ADLs, no-
a software system or (3) the fundamental concepts, prop- tably Acme [16], have explicit support for specifying archi-
erties and principles of design of a software system. Note tectural styles and constraints.
that there is significant overlap across these classes of soft-
ware architecture definitions. All definitions include system
components and relationships between them as part of the 4. WHAT IS SOFTWARE ARCHITECTURE?
definition. However, the focus of each of these classes of Based on the insights obtained from reference architectures
definitions is fundamentally different. Also, the definitions we will introduce a simple definition of software architec-
differ on whether software architecture ture, discuss its elements and show that these are present
across levels of granularity. Finally we discuss the interplay
between architecture and functional design.
• is a high level infrastructure or there is architecture
across levels of granularity,
4.1 Definition of software architecture
• focuses on components and relationships or whether it We propose the following very simple definition for software
is more concerned with introducing fundamental con- architecture:
cepts and constraints for the system,
• includes the specification of behaviour and functional-
ity, and Software architecture is the software infras-
tructure within which application components pro-
• explicitly includes the specification of ways in which
viding user functionality can be specified, de-
non-functional requirements are to be addressed.
ployed and executed.
The definition does rely on the definition of an application
component [3] which we define as follows:

Application components are software compo-

nents which address functional requirements of
the software system.

4.2 Elements of software architecture

In our analysis of reference architectures we have identi-
fied the concerns addressed by these reference architectures.
From this we identify the elements of software architecture
as

• basic concepts and constraints within which applica-

tion components providing user functionality are spec-
ified,

• a set of architectural components addressing technical

concerns,

• the integration channels to the environment as well as

the internal integration infrastructure for both, archi-
tectural and application components, and
Figure 5: Conceptual versus implementation archi-
• a set of architectural strategies which are used to con- tecture.
cretely address the quality requirements for the soft-
ware system.
4.5 Conceptual versus implementation archi-
4.3 Boundary between architecture and appli- tecture
One commonly differentiates between the conceptual archi-
cation design tecture and the implementation architecture. The concep-
Our definition does not restrict architecture to a high-level
tual architecture may introduce concepts and constraints
abstraction of the system, but to an environment within
within which applications are developed, abstract architec-
which user functionality is deployed and executed. A sys-
tural components addressing infrastructural concerns, ar-
tem element is either part of the architecture or part of an
chitectural strategies which are to be used to address non-
application depending on whether it contains logic which ad-
functional requirements.
dresses functional requirements from the problem/application
domain or logic implementing architectural functionality ad-
The implementation architecture may provide a concrete in-
dressing technical concerns.
frastructure for application components, enforce some of the
application component constraints, provide concrete imple-
4.4 Architecture and application components mentations of the abstract architectural component of the
conceptual architecture and concrete implementations of the
across levels of granularity architectural strategies.
Our definition of software architecture does not refer to high-
level infrastructure. Software architecture is the full software
infrastructure, across levels of granularity, within which the 4.6 Contextualization within MDE
user functionality is deployed. There is thus both, functional In the context of model-driven engineering (MDE) the com-
and architecture design, across levels of granularity. putation independent model (CIM) would be purely in the
problem (e.g. business) domain, independent of the software
From the perspective of the definition of software architec- architecture.
ture proposed in this paper, there are this architectural and
application components across levels of granularity with the The platform independent model (PIM) would be a map-
former addressing infrastructural and quality concerns and ping of the CIM within the infrastructure as specified by
the latter addressing concerns around application function- the conceptual architecture, using the application concepts
ality. of the application architecture.

In the analysis of reference architectures it was shown that The PIM would then be mapped onto a platform specific
all architectural elements may exist across levels of granu- model (PSM) which is specific to the implementation archi-
larity. This includes architectural patterns, concepts, com- tecture and ultimately onto an implementation within code
ponents, relationships and strategies. and other artifacts.
4.7 Interplay between infrastructural and func- concerns like reliability and maintainability form application
tional design logic. They address these concerns in a separate framework
So far we have said that anything which does not address within which the application logic is deployed and discuss
the functional requirements of the problem domain is part the benefits of separating these concerns. Dlodlo and Bam-
of architecture. However, whether a particular component ford [12] looked at how to separate the human adapter (user
is an architectural or a functional component depends on interface) from the application functionality. None of these
one’s perspective. papers provide a definition or a detailed discussion of the
elements of software architecture.
For example, whilst implementing, say, an online retail ap-
plication which is to be deployed in an application server, Alexander Ran [28] highlights that a software architecture
the application server is part of the architecture. It contains introduces a set of fundamental concepts used to define a
no logic about retailing and solely addresses non-functional system. He defines software architecture as a set of concepts
requirements like integration requirements and providing a and design decisions about structure and texture of software
deployment and execution infrastructure within which the that must be made prior to concurrent engineering to en-
reliability, scalability and security requirements of the retail able effective satisfaction of architecturally significant, ex-
application are addressed. plicit functional and quality requirements, and implicit re-
quirements of the problem and the solution domains. The
If however, ones perspective changes from developing the definition is, however, to some extent a circular definition as
retail application to developing the application server itself, it relies on the concept of “architecturally significant” which
then the application is the application server itself. It will in turn depends on the definition of architecture itself.
have to implement functional requirements around cluster-
ing, persistence and managing thread pools. 6. CONCLUSIONS AND OUTLOOK
Different classes of definitions of software architecture have
The application server, in turn, would have to be deployed been identified. These classes differ on whether architecture
and executed in an environment which addresses its non- is a high level abstraction of the various system aspects (e.g.
functional requirements. The choice of suitable architecture its structure and functionality), whether it is the system
would be made by selecting a suitable operating system. structure and externally visible properties across levels of
granularity or whether the focus is on introducing concepts
Thus, even though a software architecture does not realize and constraints for the application development. It is not
the functional requirements from the application domain, it clear from either of these definition classes where exactly
has its own functional requirements which would themselves the boundary between architecture and functional design is.
have to be addressed through functional design. This uncertainty of architecture has significant implications
for architecture requirements and descriptions, as well as
architecture design and assessment approaches.
5. RELATED WORK
We have a variety of definitions of software architecture. It has been shown that reference architectures are relatively
These definitions have been abstracted into software archi- pure software architecture specifications and implementing
tecture classes which have been discussed in section 3. frameworks as relatively pure software architecture imple-
mentations. These reference architectures provide an infras-
Baragry and Reef [6] discuss reasons why is is difficult to de- tructure within which application functionality is deployed
fine software architecture. They compare software architec- and executed. These reference architectures are consistent
ture with other disciplines of architecture in order to high- with defining a software architecture as the software in-
light the differences in the concept of architecture across frastructure within which application components providing
different domains. Based on these differences, they ques- user functionality can be specified, deployed and executed. A
tion whether it makes sense to base the concept of software software architecture specification based on the above def-
architecture on the analog of buildings architecture. The inition of software architecture introduces basic concepts
authors point out that the high-level abstractions of dif- and constraints within which application components are
ferent aspects of a software system including those of its to be specified, architectural components addressing infras-
structure and functionality have to be specified in different tructural and quality concerns (including integration chan-
representations of software architecture and not merely dif- nels), and architectural strategies which are to be used to
ferent views of a single concept. Comparing these different concretely address quality requirements. Both, application
representations to the general notion of architecture, they and architecture design needs to be done across levels of
conclude that each of these separate representations could granularity, i.e. there are architectural components address-
be seen as the software architecture itself. The definition of ing infrastructural and quality concerns as well as applica-
software architecture provided in this paper does not define tion components providing user functionality across levels of
architecture as a high level abstraction but as an infrastruc- granularity.
ture within which application logic is deployed and executed.
This is indeed a single concept. It has been pointed out that whether a system component
is an architectural or an application component depends on
A number of authors have previously focused on separat- one’s perspective. In particular, one may develop a frame-
ing architectural concerns from application logic. This is work implementing a software architecture specification, ad-
similar to the approach taken in this paper. Deconinck, dressing the non-functional requirements for the applications
De Florio and Botti [11] focused on separating architectural to be defined, deployed and executed. Such a framework,
which would be an architectural component of the “busi- J. Stafford. Documenting Software Architectures:
ness” application will, once again, have functional and non- Views and Beyond. Addison-Wesley Professional, 2
functional requirements. The former are addressed through edition, Oct. 2010.
application design and the latter by selecting an appropriate [11] G. Deconinck, V. De Florio, and O. Botti. Separating
architecture within which that architectural component can recovery strategies from application functionality:
be deployed and executed. experiences with a framework approach. In Reliability
and Maintainability Symposium, 2001. Proceedings.
Future work will focus on whether current architecture de- Annual, pages 246 –251, 2001.
scription languages have sufficient semantics to describe a [12] N. Dlodlo and C. Bamford. Separating application
software architecture and on defining an architecture analy- functionality from the user interface in a distributed
sis and design methodology which can be used in conjunction environment. In EUROMICRO 96. ’Beyond 2000:
with the URDAD methodology[15, 29] for technology and Hardware and Software Design Strategies’.,
architecture neutral analysis and design. In addition, this Proceedings of the 22nd EUROMICRO Conference,
work opens opportunities for revisiting architecture analysis pages 248 –255, sep 1996.
methods as well as architecture design methods. [13] D. Emery and R. Hilliard. Every Architecture
Description Needs a Framework: Expressing
7. ACKNOWLEDGEMENTS Architecture Frameworks Using ISO/IEC 42010. In
The author would like to thank Stefan Gruner for valuable Joint Working IEEE/IFIP Conference on Software
discussions and guidance and the University of Pretoria for Architecture, 2009 & European Conference on
funding the research. Software Architecture. WICSA/ECSA 2009, pages
31–40. IEEE, Sept. 2009.
8. REFERENCES [14] M. Fowler. Design - who needs an architect? Software,
[1] IEEE Std 1471-2000: IEEE Recommended Practice IEEE, 20(5):11 –13, 2003.
for Architectural Description of Software-Intensive [15] Fritz Solms and Dawid Loubser. URDAD as a
Systems. Specification, IEEE-SA Standards Board, semi-formal approach to analysis and design.
Sept. 2000. Innovations in Systems and Software Engineering,
[2] R. Allen. A Formal Approach to Software Architecture. 6:155–162, 2010. 10.1007/s11334-009-0113-4.
PhD thesis, Carnegie Mellon, School of Computer [16] D. Garlan, R. T. Monroe, and D. Wile. Acme:
Science, Jan. 1997. Issued as CMU Technical Report Architectural Description of Component-Based
CMU-CS-97-144. Systems. In G. T. Leavens and M. Sitaraman, editors,
[3] A. Ambroziewicz and M. Smialek. Application logic Foundations of component-based systems, pages 47–67.
patterns reusable elements of user-system interaction. Cambridge University Press, New York, NY, USA,
In Proceedings of the 13th international conference on 2000.
Model driven engineering languages and systems: Part [17] S. Giesecke, J. Bornhold, and W. Hasselbring.
I, MODELS’10, pages 241–255, Berlin, Heidelberg, Middleware-Induced Architectural Style Modelling for
2010. Springer-Verlag. Architecture Exploration. In The Working IEEE/IFIP
[4] P. Avgeriou. Run-time Reconfiguration of Conference on Software Architecture, 2007. WICSA
Service-Centric Systems. In Proceedings of the 11th ’07, pages 21–21. IEEE, Jan. 2007.
European Conference on Pattern Languages of [18] P. Kruchten. The 4+1 view model of architecture.
Programs (EuroPLoP 2006), Irsee, Germany, 2006. Software, IEEE, 12(6):42 –50, nov 1995.
[5] F. Bachmann, L. Bass, M. Klein, and C. Shelton. [19] P. T. L. Lloyd and G. M. Galambos. Technical
Designing Software Architectures to Achieve Quality reference architectures. IBM Systems Journal,
Attribute Requirements. IEE Proceedings - Software, 38(1):51–75, 1999.
152(4):153–165, Aug. 2005. [20] J. Magee, N. Dulay, S. Eisenbach, and J. Kramer.
[6] J. Baragry and K. Reed. Why is it so hard to define Specifying distributed software architectures. Software
software architecture? In Software Engineering Engineering—ESEC’95, pages 137–153, 1995.
Conference, 1998. Proceedings. 1998 Asia Pacific, [21] S. Malek, N. Esfahani, D. A. Menasce, J. P. Sousa,
pages 28 –36, dec 1998. and H. Gomaa. Self-Architecting Software SYstems
[7] L. Bass, P. Clements, and R. Kazman. Software (SASSY) from QoS-annotated activity models. In
Architecture in Practice, Second Edition. Proceedings of the 2009 ICSE Workshop on Principles
Addison-Wesley Professional, Apr. 2003. of Engineering Service Oriented Systems, PESOS ’09,
[8] G. Booch, J. Rumbaugh, and I. Jacobson. The Unified pages 62–69, Washington, DC, USA, 2009. IEEE
Modeling Language user guide. Addison Wesley Computer Society.
Longman Publishing Co., Inc., Redwood City, CA, [22] D. A. Menasce, J. P. Sousa, S. Malek, and H. Gomaa.
USA, 1999. Qos architectural patterns for self-architecting
[9] C. Bouanaka and F. Belala. Towards a mobile software systems. In Proceedings of the 7th
architecture description language. In Computer international conference on Autonomic computing,
Systems and Applications, 2008. AICCSA 2008. ICAC ’10, pages 195–204, New York, NY, USA, 2010.
IEEE/ACS International Conference on, pages 743 ACM.
–748, Apr. 2008. [23] M. Nagl. Software Engineering – Methodological
[10] P. Clements, F. Bachmann, L. Bass, D. Garlan, Programming-in-the-Large (in German).
J. Ivers, R. Little, P. Merson, R. Nord, and Springer-Verlag, 1990.
 [24] C. Pahl, S. Giesecke, and W. Hasselbring. An [28] A. Ran. Fundamental concepts for practical software
Ontology-Based Approach for Modelling Architectural architecture. In Proceedings of the 8th European
Styles. In F. Oquendo, editor, Software Architecture, software engineering conference held jointly with 9th
volume 4758, pages 60–75. Springer Berlin Heidelberg, ACM SIGSOFT international symposium on
Berlin, Heidelberg, 2007. Foundations of software engineering, ESEC/FSE-9,
[25] M. Pinto and L. Fuentes. AO-ADL: An ADL for pages 328–329, New York, NY, USA, 2001. ACM.
Describing Aspect-Oriented Architectures. In [29] F. Solms, C. Edwards, A. Paar, and S. Gruner. A
A. Moreira and J. Grundy, editors, Early Aspects: Domain-Specific Language for URDAD Based
Current Challenges and Future Directions, volume Requirements Elicitation. In Proceedings of the South
4765, pages 94–114. Springer Berlin Heidelberg, African Institute of Computer Scientists and
Berlin, Heidelberg, 2007. Information Technologists Conference on Knowledge,
[26] M. Pinto, L. Fuentes, and J. M. Troya. Specifying Innovation and Leadership in a Diverse,
aspect-oriented architectures in AO-ADL. Information Multidisciplinary Environment, SAICSIT ’11, pages
and Software Technology, 53(11):1165 – 1182, 2011. 224–230, New York, NY, USA, 2011. ACM.
<ce:title>AMOST 2010</ce:title> [30] S. Zhang and S. Goddard. xSADL: an architecture
<ce:subtitle>AMOST 2010</ce:subtitle>. description language to specify component-based
[27] W. Qin and S. Malik. A Study of Architecture systems. In International Conference on Information
Description Languages from a Model-based Technology: Coding and Computing, 2005. ITCC
Perspective. In Microprocessor Test and Verification, 2005, volume 2, pages 443– 448 Vol. 2. IEEE, Apr.
2005. MTV ’05. Sixth International Workshop on, 2005.
pages 3 –11, Nov. 2005. [31] L. Zhu, M. Staples, and V. Tosic. On Creating
Industry-Wide Reference Architectures. In 12th
International IEEE Enterprise Distributed Object
Computing Conference, 2008. EDOC ’08, pages 24–30.
IEEE, Sept. 2008.

View publication stats