Are you a developer or designer aspiring to become an architect? Do you want to learn about the architecture of open source applications? Do you want to learn software architecture through case studies and examples? If you have answered “yes” to any of these questions, this workshop is certainly for you. This workshop will introduce you to key topics in software architecture including architectural principles, constraints, non-functional requirements (NFRs), architectural styles and design patterns, viewpoints and perspectives, and architecture tools. A special feature of this workshop: it covers examples and case studies from open source applications. What’s more, you’ll also get exposed to some free or open source tools used by practicing software architects.

1. Ganesh Samarthyam
ganesh@codeops.tech
www.codeops.tech
Software Architecture:
Principles, Patterns, and Practices

2. Why do you want to
become an
architect?
What skills are
required for an
architect?
Who is an architect?
What essential
knowledge is required
for an architect?

3. What is software
architecture?
How to evolve an
architecture?
What is the software
architecture
development process?
What factors influences
software architecture?

4. Generalist
Specialist
Source: Software Architecture for Developers, Simon Brown, LeanPub, 2014

5. What is software
architecture?

6. “The software architecture of a program
or computing system is the structure or
structures of the system, which comprise
software elements, the externally visible
properties of those elements, and the
relationships among them”
Source: So)ware Architecture in Prac2ce (2nd edi2on), Bass, Clements, Kazman; Addison-Wesley 2003:

7. “Architecture is a set of
principal design decisions
about a software system”
Source: R. N. Taylor, N. Medvidovic, and E. M. Dashofy. 2009. Software Architecture: Foundations, Theory, and Practice.
Wiley Publishing.

8. “The architecture of a
deployed software is
determined by those aspects
that are hardest to change”
Source: R. N. Taylor, N. Medvidovic, and E. M. Dashofy. 2009. Software Architecture: Foundations, Theory, and Practice.
Wiley Publishing.

9. Architecture represents the significant
design decisions that shape a
system, where significant is measured
by cost of change.
- Grady Booch (2006)

10. NFRs
Constraints
TechnologyCross-cutting
concerns
Others
(e.g.: overall
structure)
Dimensions of ADs

11. Cross-cutting concerns
Error/Exception handling
ConcurrencyPersistence
Event handling
Interaction and presentation
Source: SWEBOK v3

13. Architecture?**
Network*
architecture*
Solu2on*
architecture*
Applica2on*
architecture*
Pla6orm*
architecture*
…*
Data*
architecture*
Hardware*
architecture*
Web*
architecture**

15. Source: Software Architecture for Developers, Simon Brown, LeanPub, 2014

16. Architecture/design
determines qualities
Understandability Changeability Extensibility
Reusability Testability Reliability
Arch/
Design
impacts
impacts
impacts

17. Architecture principles and styles
Architectural principles:
Axis, symmetry, rhythm, datum, hierarchy, transformation

18. Dravidian styleRenaissance style
Mughal style
Post-modern style

19. What architectural style is
this?
Image source: http://ashokbasnet.com.np/wp-content/uploads/2011/03/wx_thumb-5B1-5D.jpg

20. Example: Abstracting for
portability using layering
• Helps'abstract'pla-orm0
specific'details'abstrac4ng'
hardware'specific'aspects''
Hardware'
Abstrac4on'
Layer'(HAL)'
• Abstracts'OS'specific'
func4onality'and'provides'
a'generic'interface'to'
underlying'OS'
Opera4ng'
System'
Abstrac4on'
Layer'(OSAL)'
• Hides'database'specific'
aspects'by'providing'a'
generic'interface''
Database'
Abstrac4on'
Layer'(DAL)'

21. Layering style: Benefits
+ Reuse of layers
+ Support for standardization
+ Dependencies are kept local
+ Exchangeability
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal. 1996. Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons, Inc., NY, USA.

22. Layering style: Liabilities
- Cascades of changing behavior
- Lower efficiency
- Unnecessary work
- Difficulty in establishing the correct
granularity of layers
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal. 1996. Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons, Inc., NY, USA.

23. What architectural style is
this?

24. $ cat limerick.txt
There was a young lady of Niger
Who smiled as she rode on a tiger.
They returned from the ride
With the lady inside
And a smile on the face of the tiger.

25. $ cat limerick.txt | tr -cs "[:alpha:]" "n" | awk '{print
length(), $0}' | sort | uniq
1 a
2 as
2 of
2 on
3 And
3 Who
3 she
3 the
3 was
4 They
4 With
4 face
4 from
4 lady
4 ride
4 rode
5 Niger
5 There
5 smile
5 tiger
5 young
6 inside
6 smiled
8 returned

26. List<String> lines
= Files.readAllLines(Paths.get("./limerick.txt"), Charset.defaultCharset());
Map<Integer, List<String>> wordGroups
= lines.stream()
.map(line -> line.replaceAll("W", "n").split("n"))
.flatMap(Arrays::stream)
.sorted()
.distinct()
.collect(Collectors.groupingBy(String::length));
wordGroups.forEach( (count, words) -> {
words.forEach(word -> System.out.printf("%d %s %n", count, word));
});
1 a
2 as
2 of
2 on
3 And
3 Who
3 she
3 the
3 was
4 They
4 With
4 face
4 from
4 lady
4 ride
4 rode
5 Niger
5 There
5 smile
5 tiger
5 young
6 inside
6 smiled
8 returned

27. Real-world pipes-and-filters
sediment
pre-
carbon
ultra-filter
post-
carbon
Filtered
water

28. Pipe-and-filter: Benefits
+ Flexibility by filter exchange
+ Flexibility by recombination
+ Reuse of filter components
+ Rapid prototyping of pipelines
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal. 1996. Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons, Inc., NY, USA.

29. Pipe-and-filter: Liabilities
- Sharing state information is expensive or
inflexible
- Efficiency gain by parallel processing is
often an illusion
- Data transformation overhead
- Difficult to handle errors
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal. 1996. Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons, Inc., NY, USA.

30. POSA - before and after

31. Layered
Pipe-and-Filter
Broker
Client-Server
Peer-to-Peer
Blackboard

32. What is the
architecture
style followed
by World Wide
Web (WWW)?

35. SOA (Service Oriented
Architecture)
Lambda Style
Microservices
REST (Representational State Transfer)
Map-Reduce
CQRS (Command-Query Responsibility
Segregation )
Software Containers
Event Sourcing

36. Command Query Responsibility
Segregation (CQRS) pattern
source: https://msdn.microsoft.com/en-us/library/jj591573.da82141c6f9950d64c1263fa4da825ec(l=en-us).png

37. Event Sourcing pattern
source: https://msdn.microsoft.com/en-us/library/dn589792.aspx

38. Map-Reduce pattern
Input
Sara
Booch
Thayer
Merlin
Sara
Ralph
Merlin
Tim
Sara
Christian
Ralph
Cormen
…
Computer Cluster
map
map
map
Sara, 1
Ralph, 1
Merlin, 1
Tim, 1
Sara, 1
Booch, 1
Thayer, 1
Merlin, 1
Sara, 1
Christian, 1
Ralph, 1
Cormen, 1
reduce
reduce
Sara, 3
Booch, 1
Thayer,1
Merlin, 2
Ralph, 2
Tim, 1
Christian, 1
Cormen, 1
…
OutputSara, 1
Sara, 1
Sara, 1
Booch, 1
Thayer, 1
Merlin, 1
Merlin, 1
Ralph, 1
Ralph, 1
Tim, 1
Christian, 1
Cormen, 1

39. What style is this?
Batch layer
Serving layerSpeed layer

40. Lambda style
source: https://spark-summit.org/2014/wp-content/uploads/2014/07/Lambda-Architecture-Jim-Scott..pdf

41. Microservices is an
architectural style

42. Complex application =
composed of tiny services

43. Communicate over REST API
HTTPGET
HTTPPUT
HTTP POST
HTTPDELETE

44. Underlying philosophy
“do one thing and do it well”

45. Amazon’s rules for teams
• All teams will henceforth expose their data and functionality
through service interfaces.
• Teams must communicate with each other through these
interfaces.
• There will be no other form of inter-service/team communication
allowed: no direct linking, no direct reads of another team’s
datastore, no shared memory model, no backdoors whatsoever.
• The only communication allowed is via service interface calls
over the network.
• It doesn’t matter what technology they [other services] use.
• All service interfaces, without exception, must be designed from
the ground up to be externalizable.
• That is to say, the team must plan and design to be able to
expose the interface to developers in the outside world.

46. Service = a team can DURS
(Deploy, Update, Replace, Scale)
Microservices = Damn U R Sexy

47. Amazon case study
2-tier
architecture
SOA Microservices

49. Triggering microservices
Source: DevOps: A Software Architect's Perspective, Len Bass, Ingo Weber, Liming Zhu, Addison-Wesley Professional, 2015

50. Separate data stores

51. A process for architecting
using scenarios
Source: http://msdn.microsoft.com/en-us/library/ee658084.aspx

52. Strategies and tactics
A tactic is a design decision that
influences the control of a quality
attribute response
A collection of tactics is known as “strategies”
Source: Len Bass, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice (2 ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

53. Example: Security tactics
Security
Resisting
Attacks
Detecting
Attacks
Recovering
From attack
! Authenticate users
! Authorize users
! Maintain data
confidentiality
! Maintain integrity
! Limit exposure
! Limit access
Restoration Identification
Stimulus:
Attack Response:
System
detects,
resists, or
recovers from
attacks
See “Availability“ Audit Trail
Intrusion
Detection
Source: Len Bass, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice (2 ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

54. Exercise: Tactics for
achieving qualities
Availability
The property of software that it there and ready to carry out
its task when you need it to be
Testability
The ease with which software can be made to demonstrate
its faults through (typically execution-based) testing
Security
Measure of the system’s ability to protect data and
information from unauthorised access while still providing
access to people and systems that are authorized
Performance The software’s ability to meet timing requirements
Modifiability
The ease with which the software can be modified (with
minimal risk and cost)
Source: Len Bass, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice (2 ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

55. Tactics for availability
Use$fault$detec,on$tac,cs$such$as$
ping/echo,$heartbeat,$,me$
stamping,$sanity$checking,$
condi,on$monitoring,$and$self:test$
Use$fault$recovery$tac,cs$such$as$
rollback$(to$a$previous$known$
good$state),$providing$“spares”$for$
redundancy,$retry$the$opera,on,$
ignoring$faulty$behavior,$and$
degrade$(gracefully$reduce$system$
func,onality)$
Use$fault$preven,on$tac,cs$such$
as$removal$from$service$
(temporarily$remove$the$faulty$
component),$use$transac,onal$
seman,cs$(ACID$proper,es),$
prevent$system$excep,ons$from$
occurring.$
Source: Len Bass, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice (2 ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

56. Tactics for modifiability
Reduce&size&of&the&module,&for&
example&by&spli7ng&module&(to&
reduce&the&average&cost&of&future&
changes)&
Increase&seman>c&cohesion&of&the&
module&(by&ensuring&that&the&a&
responsibili>es&serving&the&same&
purpose&are&placed&in&the&same&
module)&
Reduce&coupling&through&
encapsula>on&(by&providing&explicit&
interfaces&and&hiding&internal&details),&
introducing&intermediate&
dependencies&(e.g.,&introduce&
dynamic&lookup&of&services&with&SOA&
using&directory&as&an&intermediary)&&&
Source: Len Bass, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice (2 ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

57. Tactics for performance
Control'resource'demand'through'requiring'
smaller'demand'on'resources'to'service'the'
events;'for'instance,'reducing'the'sampling'
frequency'(for'capturing'environmental'data),'
limi;ng'event'response'(by'queuing'the'events),'
priori;zing'events'(by'ranking'the'events'
according'to'their'importance'and'processing'
them),'reducing'overheads'(by'consuming'lesser'
resources),'bound'execu;on';mes,'and'increase'
resource'efficiency.'
Manage'the'resources'more'effec;vely'by'
increasing'resources,'introducing'concurrency,'
maintaining'mul;ple'copies'of'computa;on,'
bounding'queue'sizes,'and'scheduling'resources.''
Source: Len Bass, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice (2 ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

58. Tactics for security
Detect%a'acks%by%looking%for%
known%pa'erns%of%intrusion,%
detec8ng%service%denial,%
verifying%message%integrity%
before%using%them,%detec8ng%
message%delay%(to%detect%man=
in=the=middle%a'acks).%
Resist%a'acks%by%iden8fying,%
authen8ca8ng,%and%authorizing%
actors%(note:%actors%are%sources%
of%external%input%to%the%system),%
limi8ng%access%to%resources,%and%
limi8ng%exposure%of%the%system.%
React%to%a'acks%when%an%a'ack%
is%underway%by%revoking%access,%
lock%computer,%or%inform%
relevant%actors.%%
Source: Len Bass, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice (2 ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

59. Tactics for testability
Control'and'observe'system'state'by'
providing'specializing'interfaces,'record/
playback'faults,'localize'state'storage'
(instead'of'distribu;ng'the'state),'
abstract'input'data'sources,'sandbox'(by'
isola;ng'the'system'from'the'real'world),'
and'introduce'executable'asser;ons'(to'
check'if'the'program'is'in'a'faulty'state)'
Limit'complexity'(by'reducing'cyclic'
dependencies,'limi;ng'dependencies'to'
external'components,'etc;'in'OO'
systems,'limit'depth'of'inheritance'tree,'
reduce'dynamic'calls;'and'having'high'
cohesion,'low'coupling'and'separa;on'of'
concerns);'also'limit'nonCdeterminism.'
Source: Len Bass, Paul Clements, and Rick Kazman. 2003. Software Architecture in Practice (2 ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

60. Opensource tools

61. InFusion/InCode

62. PMD CPD

63. ArchiMate
Source: http://www.archimatetool.com/img/archi_out.png

64. Sonarqube
Sonarqube
http://www.sonarqube.org

65. ArgoUML
Source: http://a.fsdn.com/con/app/proj/argouml/screenshots/52103.jpg

66. Nitric

67. Open source
examples

68. Reference architectures
Source: Alessandro Bassi, Martin Bauer, Martin Fiedler, Thorsten Kramp, Rob Van Kranenburg, Sebastian Lange, and Stefan Meissner. 2013.
Enabling Things to Talk: Designing IoT Solutions with the IoT Architectural Reference Model. Springer

69. Use reference architectures
when relevant ones are
available (don’t reinvent the
wheel)

70. Glasgow Haskell Compiler
Source: http://aosabook.org/en/ghc.html

71. OpenSAR (Automotive Open Software
Architecture)

72. Pony-Build
Source: http://aosabook.org/en/integration.html

73. It is hard to recognise
architecture styles
from block diagrams

74. GNU Debugger
Source: http://aosabook.org/en/gdb.html

75. Nginx
Source: http://aosabook.org/en/nginx.html

76. Dynamic Language Runtime
Source: http://aosabook.org/en/ironlang.html

77. Asterix
Source: http://aosabook.org/en/asterisk.html

78. Both informal diagrams (e.g.
block diagrams) and semi-
formal diagrams (e.g., UML)
are used in practice

79. FreeRTOS Layers
Source: http://aosabook.org/en/freertos.html

80. GPSD
Image source: http://aosabook.org/en/gpsd.html

81. Open MPI
Image source: http://aosabook.org/en/openmpi.html

82. Layering continues to
be the most widely
used architecture style

83. Image Hosting System
Source: http://aosabook.org/en/distsys.html

84. Image Hosting System
Source: http://aosabook.org/en/distsys.html
Split reads and writes

85. Image Hosting System
Source: http://aosabook.org/en/distsys.html
with redundancy

86. Image Hosting System
Source: http://aosabook.org/en/distsys.html
with partitioning

87. Start with the “simplest
possible thing that works”
and evolve the architecture

88. Linux: Intended Architecture

89. Linux: Extracted Architecture

90. As-IS architecture is almost
always different than intended
architecture
Solution: architecture oversight

91. Dependencies in OpenJDK

92. Refactoring cycles
Remove one of the dependencies
Change dependency direction
Move one of the dependencies

93. Continual refactoring is the
best weapon to deal with
architecture degradation

94. “Cities grow, cities evolve, cities
have parts that simply die while other
parts flourish; each city has to be
renewed in order to meet the needs of its
populace… Software-intensive systems
are like that. They grow, they evolve,
sometimes they wither away, and
sometimes they flourish…”
Grady Booch in the foreword for “Refactoring for Software Design Smells: Managing Technical Debt”, Girish Suryanarayana, Ganesh Samarthyam, Tushar Sharma, Morgan Kaufmann/Elsevier, 2014.

95. CodeCity tool

97. Code Query Language (NDepend, Architect, …)

98. Look at the world differently for
creative design solutions

99. Who coined
the term
“code smell”?
Hint: He also
originated the
terms TDD and XP

100. Kent Beck

101. Who coined the
acronym
“SOLID”?
(as in SOLID
principles)
Hint: He is the
author of the book
“Working effectively
with legacy code”

102. Michael
Feathers
S
Single Responsibility
Principle
Every object should have a single responsibility and
that should be encapsulated by the class
O Open Closed Principle
Software should be open for extension, but closed for
modification
L
Liskov’s Substitution
Principle
Any subclass should always be usable instead of its
parent class
I
Interface Segregation
Principle
Many client specific interfaces are better than one
general purpose interface
D
Dependency Inversion
Principle
Abstractions should not depend upon details. Details
should depend upon abstractions

103. Who coined
the term
“technical
debt”?
Hint: He is the
creator of “wiki”

104. Ward
Cunningham
When, due to constraints, I design
quickly and dirty, my project is
loaded with technical debt

105. Number of Accessed Variables
Cyclomatic Complexity

106. Newly Added Service
Percentage of Newly Added Service

107. Infusion
www.intooitus.com/products/infusion

108. Violates Single
Responsibility
Principle (SRP)

110. Published in Journal of Object Technology (Vol. 12, No. 2, 2013)
S G Ganesh, Tushar Sharma, Girish Suryanarayana. Towards a Principle-based
Classifica4on of Structural Design Smells. In Journal of Object Technology, vol.
12, no. 2, 2013, pages 1:1–29.doi:10.5381/jot.2013.12.2.a1
URL: hLp://www.jot.fm/issues/issue_2013_06/arPcle1.pdf (open access)

113. "This is a good book about ‘Design Smells’ – actually
a great book – nicely organized - clearly written with
plenty of examples and a fair sprinkling of
anecdotes."
- Will Tracz (Principal Research Scientist & Fellow,
Lockheed Martin)
(review in ACM SIGSOFT Software Engineering
Notes)

114. Believe in your ideas:
how small or “insignificant” it may
appear to be!

115. "The critical design tool for software development
is a mind well educated in design principles"
- Craig Larman

116. Interface Segregation
Principle (ISP)
Clients should not be forced to depend upon interfaces they do not use

117. Example of ISP violation
// using java.util.Date
Date today = new Date();
System.out.println(today);
$ java DateUse
Wed Dec 02 17:17:08 IST 2015
Why should we get the
time and timezone details if
I only want a date (e.g.,
date of birth)? Can I get rid
of these parts? No!

118. JSR 310: Java Date and Time API
Stephen Colebourne

119. Example of a fix (java.time)
// using java.time.LocalDate
LocalDate today = LocalDate.now();
System.out.println(today);
$ java DateUse
2015-12-02
I can use (and hence
depend upon) only date
related functionality (not
time, zone, etc)

120. Example of a fix (java.time)
You can use only date,
time, or even timezone,
and combine them as
needed (in java.time)!
LocalDate today = LocalDate.now();
System.out.println(today);
LocalTime now = LocalTime.now();
System.out.println(now);
LocalDateTime todayAndNow = LocalDateTime.now();
System.out.println(todayAndNow);
ZonedDateTime todayAndNowInTokyo =
ZonedDateTime.now(ZoneId.of("Asia/Tokyo"));
System.out.println(todayAndNowInTokyo);
2015-12-02
17:37:22.647
2015-12-02T17:37:22.648
2015-12-02T21:07:22.649+09:00[Asia/Tokyo]

121. More types from java.time

122. Principles*
Abstrac/on*
Encapsula/on*
Modulariza/on*
Hierarchy*

123. Know and apply design principles

125. How to separate:
a) code generation logic
from node types?
b) how to support different
target types?
class Plus extends Expr {
private Expr left, right;
public Plus(Expr arg1, Expr arg2) {
left = arg1;
right = arg2;
}
public void genCode() {
left.genCode();
right.genCode();
if(t == Target.JVM) {
System.out.println("iadd");
}
else { // DOTNET
System.out.println("add");
}
}
}

126. class Plus extends Expr {
private Expr left, right;
public Plus(Expr arg1, Expr arg2) {
left = arg1;
right = arg2;
}
public Expr getLeft() {
return left;
}
public Expr getRight() {
return right;
}
public void accept(Visitor v) {
v.visit(this);
}
}
class DOTNETVisitor extends Visitor {
public void visit(Constant arg) {
System.out.println("ldarg " + arg.getVal());
}
public void visit(Plus plus) {
genCode(plus.getLeft());
genCode(plus.getRight());
System.out.println("add");
}
public void visit(Sub sub) {
genCode(sub.getLeft());
genCode(sub.getRight());
System.out.println("sub");
}
public void genCode(Expr expr) {
expr.accept(this);
}
}

127. Source: “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Addison-Wesley,1994

128. ❖ Many distinct and unrelated
operations need to be
performed on objects in an
object structure, and you want
to avoid “polluting” their
classes with these operations
Represent an operation to be performed on the elements of an object structure.
Visitor lets you define a new operation without changing the classes of the
elements on which it operations
❖ Create two class
hierarchies:
❖ One for the elements
being operated on
❖ One for the visitors that
define operations on the
elements

129. {
mv = cw.visitMethod(ACC_PUBLIC + ACC_STATIC, "printOne", "()V", null, null);
mv.visitCode();
mv.visitFieldInsn(GETSTATIC, "java/lang/System", "err", "Ljava/io/PrintStream;");
mv.visitLdcInsn("CALL println");
mv.visitMethodInsn(INVOKEVIRTUAL, "java/io/PrintStream", "println", "(Ljava/lang/String;)V", false);
mv.visitFieldInsn(GETSTATIC, "java/lang/System", "out", "Ljava/io/PrintStream;");
mv.visitLdcInsn("Hello World");
mv.visitMethodInsn(INVOKEVIRTUAL, "java/io/PrintStream", "println", "(Ljava/lang/String;)V", false);
mv.visitFieldInsn(GETSTATIC, "java/lang/System", "err", "Ljava/io/PrintStream;");
mv.visitLdcInsn("RETURN println");
mv.visitMethodInsn(INVOKEVIRTUAL, "java/io/PrintStream", "println", "(Ljava/lang/String;)V", false);
mv.visitInsn(RETURN);
mv.visitMaxs(2, 0);
mv.visitEnd();
}
Use of visitor pattern in
ASM tool (coding
example of usage)
source: http://web.cs.ucla.edu/~msb/cs239-tutorial/

130. Apply relevant design patterns for
creating high-quality designs

132. Extract
Superclass

134. Modularize JDK & JRE
Hide platform internal details such as sun.misc
Provide a module system for Java developers
Reference: http://paulbakker.io/java/java-9-modularity/

136. Perform periodic refactoring
(floss or root canal)

137. When,&due&to&constraints,&I&design&
quickly&and&dirty,&my&project&is&
loaded&with&technical&debt&

138. Sonarqube
http://www.sonarqube.org

139. Use technical debt approach to get
buy-in for refactoring

142. Desirable relationship between
architect and manager: partnership

143. Steve Jobs is viewed as an excellent
speaker, business person, and leader. But
not much as an architect.
He is an excellent architect.
Why?

145. In the movie Steve Jobs, he gives an example of
a music composer. The composer directs the
people and focuses on the orchestra.
That is the case with a software architect as well.

146. So, what’s next?

147. Examples from
Open Source
architectures
• Architecture descriptions
from well-known open
source software from key
contributors
• You can get insights on
the architecture from
practical illustrations
http://www.aosabook.org/en/index.html

148. Practical book on SA
• Useful to get an overview of
software architecture
• Especially useful if you are a
programmer
• Complete presentation
available here.

149. Good first
book on SA
• Shares practical
experiences in
architecting enterprise IT
systems
• If you want to learn about
enterprise architecture,
read this

150. SEI’s book on
SA
• Good coverage of
Attribute Driven Design,
Architecture Trade-off
Analysis Method, Quality
Attributes, etc
• If you want an in-depth
understanding, read this

151. In-depth treatment on SA
• Covers a wide range of
topics in detail (stypes,
modelling, visualisation,
analysis, etc)
• Perhaps the most
comprehensive/in-depth
discussion on important
SA topics
• Slides available online
here

152. THE book on design
patterns
• One of the earliest and
best books on design
patterns
• Presents a catalog of 23
design patterns
• Classified as creational,
structural, and
behavioral patterns

153. THE book on architectural
patterns
• One of the earliest and
best books on
architectural patterns
• Presents a catalog of
architectural patterns with
detailed discussion
• Referred to as POSA
book
• First book in the series
of books on patterns/
styles

154. Anti-patterns in
development,
architecture, …
• A practical book that
covers anti-patterns in
software architectures as
well as projects
• Important to know anti-
patterns so that we can
avoid them

155. Architectural
refactoring is
tough!
• The focus is on refactoring
techniques, tools, and
processes in the large-
scale (i.e., architectural
level)
• Covers architectural
smells as well

156. Getting a
systems
perspective
• Emphasises on working with
stakeholders, and using
viewpoints and perspectives
• Read this if you are looking
for gaining an in-depth
understanding of working
with stakeholders and using
viewpoints and perspectives

157. An early take
on SA
• Provides a good overview
of architectural patterns
• If you are interested in
architectural styles, tools,
languages and notations,
etc, read this

158. Tips/
techniques
perspective on
SA
• Provides a collection of
advices from working
architects
• If you are already an
architect and want to
know best practices, read
this

159. And don’t forget ours!
Forewords by
Grady Booch and Dr.
Stephane Ducasse

160. What were your key
takeaways?

161. Image Credits
• http://it-ebooks.info/images/ebooks/3/restful_web_services_cookbook.jpg
• http://southfloridaclassicalreview.com/wp-content/uploads/
2012/11/03THECLEVELANDORCHESTRA-CPJ.jpg
• http://www.ndepend.com/NS/images/CodeQuery.jpg
• https://www.toadworld.com/cfs-file/__key/communityserver-blogs-components-
weblogfiles/00-00-00-00-57/DN_2D00_4a.jpg
• http://d152tffy3gbaeg.cloudfront.net/2015/02/AIBA-World-Boxing-
Championships.jpg
• http://www.lucidica.com/wp-content/uploads/2014/03/www.jpg
• http://restfulwebapis.org/images/rws-cover.jpg
• http://akamaicovers.oreilly.com/images/0636920021575/cat.gif
• http://it-ebooks.info/images/ebooks/6/pro_rest_api_development_with_node.js.jpg
• https://www.packtpub.com/sites/default/files/9781783285754.jpg
• https://www.packtpub.com/sites/default/files/
B04843_RESTful%20Web%20Services%20with%20Scala_.jpg
• http://i.ndtvimg.com/i/2015-02/sholay-still_640x480_61423213425.jpg

162. ganesh@codeops.tech @GSamarthyam
www.codeops.tech slideshare.net/sgganesh
+91 98801 64463 bit.ly/sgganesh