Software Architecture

Jonathan Aldrich, Ph.D.

Associate Professor
Institute for Software Research
School of Computer Science
Carnegie Mellon University

January 2014
© 2014 Jonathan Aldrich These materials may not be duplicated or distributed without advance
written permission from the author.
 Outline
• What is software architecture?
• What are its benefits?

© 2014 Jonathan Aldrich

• How to develop a software architecture?
• How to document a software architecture?
• Conclusion and takeaways

Software Architecture
 What is (Building) Architecture?
And why is it useful?

© 2014 Jonathan Aldrich

Example Architecture:
Potsdam Observatorium

Software Architecture
 What is Software Architecture?

Software architecture represents the high-level design

© 2014 Jonathan Aldrich

of a software system, showing how desired system
properties are achieved
High-Level Design

Example Architecture:
Potsdam Observatorium

Software Architecture
 Where Architecture Fits
• Requirements What
– What the system should do
– What properties it should have

© 2014 Jonathan Aldrich

• Architecture
– High-level design, how properties are achieved

• Detailed design
– Lower-level design, how system functions

• Code How

– How the system actually works

Software Architecture
 Two Architectures for Web Search
Architecture
Altavista A
search engine Architecture
Google B
search engine

requests requests

© 2014 Jonathan Aldrich

...
network
switch

Big server
Cluster of
commodity
How does architecture affect system properties? servers
• Modifiability / ease of change
• Consistency of results
• System cost
• Scalability of system
• Reliability of system
Software Architecture
 Two Architectures for Sending Email
sendmail qmail
Modules within sendmail process Processes implementing qmail

© 2014 Jonathan Aldrich

Which architecture was better in 1980? Which was better in 2000?
Factors to consider
• Simplicity
• Efficiency
• Security
Software Architecture
 Two Architectures for Sending Email
sendmail qmail

requests requests

© 2014 Jonathan Aldrich

...
network
switch

Big server
Cluster of
• Sendmail was the dominant email client from 1982 until 2000.
commodity
• In 1988 the Morris worm, the first internet worm, took advantage of a
servers
sendmail vulnerability; many other vulnerabilities have been found
since.
• By 2000 sendmail had begun a steep and permanent decline, and
qmail was growing exponentially.

Software Architecture
 Architecture is an Abstraction
• Focus on principal design decisions
– Structure – components and connections
– Behavior – responsibilities of each component,
high level algorithms
– Interaction – rules governing how components communicate

© 2014 Jonathan Aldrich

– Quality attributes – strategy for achieving
– Implementation – language, platform, libraries, etc.

– Any decision that impacts key stakeholder concerns or has

global impact on the program

• Elide unimportant details

– Decisions that are internal to a component
• i.e. which other components cannot depend on
• e.g. internal algorithms, data structures, local design patterns
– AND do not impact key stakeholder concerns

Architecture is design, but not all design is architectural

Software Architecture
 Outline
• What is software architecture?
• What are its benefits?

© 2014 Jonathan Aldrich

• How to develop a software architecture?
• How to document a software architecture?
• Conclusion and takeaways

Software Architecture
 Architecture Benefits: System Properties

• Architecture is not about a system’s function,

but rather the system’s properties

© 2014 Jonathan Aldrich

• Some properties and their consequences
– Fitness: performance, reliability, security competitive advantage
– Modifiability/ease of changing business agility
– Reuse of code reduced cost

Software Architecture
 Business Case: Cell Phones [M. Bass]
• Market is driven by killer products
– e.g. Razr, iPhone
• Most profit is made at initial release
– Premium charged on initial sales
– Drops rapidly when copycats arrive

© 2014 Jonathan Aldrich

• Business model
– Be first to market with new features
• Software quality attributes
– Ability to change rapidly and at low cost
• True story: effect of architecture
– Leading cell phone manufacturer
• not enough new products
• starts to lose market share, decides to release faster
• leads to trouble: e.g. tone so loud it damages hearing recalls
– Analysis
• software structure did not enable rapid change
• too costly to rewrite software from scratch
• eventually left cell phone business entirely

Software Architecture
 Telecom Architecture Scenario
• Context: telecommunications wholesaler
– Provides services both to end users and resellers
– 8 legacy applications built with different interfaces, technologies

© 2014 Jonathan Aldrich

• Challenges
– Duplicate functionality between end user / reseller channels
– Several manual steps in process; difficult to automate
– Difficult to roll out new services
– Need to free reserved resources when an operation is canceled

• What would you do?

Software Architecture
 Telecom Architecture Solution
• Service-Oriented Architecture
– Wrap legacy applications with a standard web services interface
– Automate tasks using scripting (BPEL)

© 2014 Jonathan Aldrich

– Share common operations, services between the different
channels
– Incorporate undoing reservations into the script
• Impacts
– Common interface enabled automation lower cost
– Also facilitates replacing components agility
– Scripts make business operation changes easier agility
– Reuse of common components lower cost
– Built-in undo avoids wasting resources reliability, lower cost

Software Architecture
 Outline
• What is software architecture?
• What are its benefits?

© 2014 Jonathan Aldrich

• How to develop a software architecture?
• How to document a software architecture?
• Conclusion and takeaways

Software Architecture
 How to Develop a Software Architecture

• Investment driven by complexity and scale

• Fitness evaluated by key risks
• Design appropriate for the domain

© 2014 Jonathan Aldrich

• Structure aligned with the organization

Software Architecture
 Tradeoffs in Architecture Investment

© 2014 Jonathan Aldrich

Source: Boehm,
Valerdi, Honour
2008

Software Architecture
 Driving Architecture via Risks
• Low risk little investment needed
– Typically use a reference architecture (e.g. 3-tier web)
– Reference architectures capture (“hoist”) known domain risks

© 2014 Jonathan Aldrich

• Otherwise, evaluate architecture fitness using risks

• Major risks are architectural drivers

• Example drivers and architectural analysis approaches
– Maintainability/Reuse: variation, interface standards
– Performance: queuing theory, real-time analysis
– Security: threat modeling
– Distributed development: interfaces between teams

Software Architecture
 Domain-Specific Architectures
• Pattern: A reusable solution to a recurring architecture design problem

web

© 2014 Jonathan Aldrich

requests
presentation logic data
tier tier tier

• Example: 3-tier web applications

– Data tier stores data in a database
– Logic tier implements business logic
– Presentation tier handles web requests
– Benefits?

Software Architecture
 Domain-Specific Architectures
• Pattern: A reusable solution to a recurring architecture design problem

web

© 2014 Jonathan Aldrich

requests
presentation logic data
tier tier tier

• Example: 3-tier web applications

– Data tier stores data in a database
– Logic tier implements business logic
– Presentation tier handles web requests
– Benefits include modifiability, scalability

Software Architecture
 Architecture-Organization Alignment

© 2014 Jonathan Aldrich

• Conway’s Law
Any organization that designs a system...will inevitably
produce a design whose structure is a copy of the
organization's communication structure (Conway, 1968)

• Case example: product line

– Applications initially developed independently
– Desired reusable library to reduce cost, increase agility
– Failed to build library using existing teams
– Success required a team dedicated to the core library.
Software Architecture
 Outline
• What is software architecture?
• What are its benefits?

© 2014 Jonathan Aldrich

• How to develop a software architecture?
• How to document a software architecture?
• Conclusion and takeaways

Software Architecture
 Architectural Views
• Many possible “views” of architecture
– Implementation structures
• Modules, packages

© 2014 Jonathan Aldrich

• Modifiability, Independent construction, …
– Run-time structures
• Components, connectors
• Interactions, dynamism, reliability, …
– Deployment structures
• Hardware, processes, networks
• Security, fault tolerance, …

Software Architecture
 Why Document Architecture?
• Blueprint for the system
– Artifact for early analysis

© 2014 Jonathan Aldrich

– Primary carrier of quality attributes
– Key to post-deployment maintenance and
enhancement
• Documentation speaks for the architect,
today and 20 years from today
– As long as the system is built, maintained, and
evolved according to its documented architecture

Software Architecture
 What is Wrong Today?
• In practice today’s documentation
consists of
– Ambiguous box-and-line diagrams

© 2014 Jonathan Aldrich

– Inconsistent use of notations
– Confusing combinations of A
viewtypes
• Many things are left unspecified: B C

– What kind of elements?

– What kind of relations? D

– What do the boxes and arrows

mean?
– What is the significance of the
layout?

Software Architecture
 What could the arrow mean?

© 2014 Jonathan Aldrich

A B

Software Architecture
 What could the arrow mean?
• Many possibilities
– A passes control to B

© 2014 Jonathan Aldrich

– A passes data to B A B

– A gets a value from B

– A streams data to B
– A sends a message to B
– A creates B
–…

Software Architecture
 Representing C&C Views
system

© 2014 Jonathan Aldrich

connector

component

port role

Software Architecture
 Guidelines: Avoiding Ambiguity
• Always include a legend
• Define precisely what the boxes mean

© 2014 Jonathan Aldrich

• Define precisely what the lines mean
• Don’t mix viewtypes unintentionally
– Recall: Module (classes), C&C (components)
• Supplement graphics with explanation
– Very important: rationale (architectural intent)
• Do not try to do too much in one diagram
– Each view of architecture should fit on a page
– Use hierarchy

Software Architecture
 Technique: Hierarchy
• Use hierarchy to define elements in more
detail in separate views

© 2014 Jonathan Aldrich

• Helps keep an architectural description
manageable

Software Architecture
 Top-level C&C View Legend

Web Component

Administrator Façade
Console Component LDAP Directory

RDBMS

Direct Adapter

Engine

© 2014 Jonathan Aldrich

Viewer
Join

Meta
Rule & Integrated
Configuration Data Rep Indirect Adapter
DB
Controller

Viewer

Interface
Transaction Log

SOAP Connector
& roles
LDAP Connector
& roles

Manager
Adapter
DB Connector
Adapter1

Adapter2

Aapter2
Change Log Indirect
Aapter1
Indirect
Direct

Direct

& roles
RMI Connector
& roles
Event Bus
Connector
& roles
Adapter
Registry
System Boundary

External External External External

LDAP1 LDAP2 DB1 DB1

Software Architecture
 Showing Details of Component

Legend

Message
Handler

© 2014 Jonathan Aldrich

Rule Set Interface
Manager
Call &
Return

Transaction
Agent
Coordinator

Send port
Receive port

Context
<Façade
Rule Router Component>
Receiver
Translator

<Configuration DB>
Rule and

Engine
Join
<Event Bus>

Software Architecture
 Outline
• What is software architecture?
• What are its benefits?

© 2014 Jonathan Aldrich

• How to develop a software architecture?
• How to document a software architecture?
• Conclusion and takeaways

Software Architecture
 Conclusion: Key Takeaways
• Architecture captures high-level design of software
– Structure and communication
– Key design decisions

© 2014 Jonathan Aldrich

• Enables desired properties of system
– Reuse reduce cost
– Modifiability business agility
– Fitness for use competitive advantage

Software Architecture
 Extra: Architecture Research at CMU

• Architecture modeling and analysis

– Verify security, performance properties

© 2014 Jonathan Aldrich

– Ensure an architecture is realizable

• Architecture adaptation models

– React to breakdowns, security breaches
– Adapt to changing resources (e.g. network bandwidth)

• Architecture-based development
– Synchronizing code and architecture
– Verifying constraints at architectural interfaces

Software Architecture
 References and Further Reading
References Software Architecture: Perspectives on an Emerging
Discipline. Mary Shaw and David Garlan. Prentice Hall, 1996.
Software Architecture: Foundations, Theory, and Practice.

© 2014 Jonathan Aldrich

Taylor, Medvidovic, and Dashofy. Wiley, 2009.

Further ▪ Software Architecture in Practice. Bass, Clements, and

Reading Kazman. Addison-Wesley, 2003.
▪ Just Enough Software Architecture. George Fairbanks.
Marshall & Brainerd, 2006.

Software Architecture