Hugtakið hugbúnaðararkítektúr er yfirhlaðið orð og þýðir mismunandi hluti fyrir mismunandi fólk. Við ætlum í þessum fyrirlestri að skilgreina ýmis hugtök tengd arkítektúr til að fá betri skilning á þessu. Við munum einnig skilgreina hvað agile arkítektúr þýðir eða hvað það þýðir ekki. Þá skoðum við monolith arkítektúr sem er hinn hefðbundi arkítektúr sem flestir nota í dag. Vandinn er sá að í dag eru kröfurnar meiri en þessi arkítektúr ræður við og því hafa menn verið að skoða aðrar leiðir eins og lightweight Service Oriented Architecture og hvernig smíða má hugbúnað sem þjónustur eða microapps eða microservice. Við skoðum einnig lagskiptingu en það er elsta trikkið í bókinni og byggir á deila og drottna aðferðinni.

1. HÖNNUN OG SMÍÐI HUGBÚNAÐAR 2015
L02 WHAT IS SOFTWARE ARCHITECTURE?

2. Agenda
Conway’s Law
Architecture in the Post-PC world
Technical Dept
Architecture
Scaling Applications
Service Oriented Architecture
Layering

3. Reading
Brown 1-7
Pattern: Monolithic Architecture
Conway´s Law
Decomposing applications for scalability and deployability
The Scale Cube

4. Conway’s Law

5. Conwey’s Law
Organisations which design systems ... are constrained to
produce designs which are copies of the communication
structures of these organisations
From a 1967 paper “How do Committees Invent?”
by Mel Conway

6. Conwey’s Law
In an organisation with three departments you end up with
three parts of the software applications
Due to communication and power structure - people want
to control their schedule and not depend on others
Directly leads to technical dept
This leads to the saying: “There are not technical
problems, only management problems”

7. Architecture in the Post-PC world

8. Monolithic Architecture
Traditional Web Application Architecture
All code is built into a single application
that is deployed
Simple to develop, test, deploy, scale
Clear layering: Presentation, Domain,
Data Source
Tomcat
ApacheBrowser
WAR
Web Components
Customer
Wallet
Data Source
DB
WAR file = Web
ARchive
Tomcat = web server
for Java Servlets (web
components)

9. 9
Trends in Architecture
Traditional Web Application Architecture
using “monolith” is not a bad way to build
software
However, some things become hard in this
architecture with scale and frequencies of
changes
Demand today is very much agile
The monolithic architecture becomes a
problem in particular in scaling and
organising teams

10. Chris Richardson
Decomposing Applications for Scalability and Deployability

12. Monolith Architecture
Bookstore
UI
Accounting
Payment
Shipping SQL
Web
Browser
Web
Server
Apache

13. ▪ Benefits
– Simple to understand
– Straightforward to develop and test
– One release and deployment
– All linking is a compile type
– Scaling is simple - just duplicate the system and use a load balancer
Monolithic Architecture

14. Monolithic Architecture
▪ Drawbacks
– User interface challenge – old style UI architecture
– Real-time applications (like node.js) don’t fit in easy
– Obstacle to frequent deployment – fear of change
– Overloads your IDE and container – slow build, development
– Obstacle to scaling development teams
– Locks down the technology stack – long term commitment

15. Demand for Rich Interactive User Experience
Web based request response model is fine
for normal content
However for dynamic and
interactive experience, for example
streaming events to the browser
this becomes difficult
From Richardson’s video

16. Big Deployments
Need to redeploy the whole application for small changes
Any change requires knowledge
of the whole system
Deployment becomes risky
Need lots of planning
Become infrequent due to fear
Code waits a long time before its
deployed
From Richardson’s video

17. Container Overload
Overloads your IDE
Takes long time to start the containers
Slows down development
From Richardson’s video

18. Communication Overload
Changes in component might
affect other components
Unwanted dependencies happen
- technical dept
Teams need to plan and
coordinate
From Richardson’s video
Scaling the development becomes difficult

19. Stuck with the Technology Stack
Monoliths require long term
commitments to the stack
New technology is difficult to
adopt
Different problem domains
require different stack
From Richardson’s video
Any changes in the technology stack become difficult

20. Can Result in Technical Debt
Maintenance becomes difficult
People don’t want to work on the
code
Company is not competitive
System becomes obsolete
Cost of Change (CoC) becomes too high

21. Technical Dept

22. Big Ball of Mud
“A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-
baling-wire, spaghetti-code jungle. These systems show unmistakable signs of
unregulated growth, and repeated, expedient repair.”
— Brian Foote and Joseph Yoder, Big Ball of Mud

23. Technical Debt
Concept in programming that reflects the extra development
work that arises when code that is easy to implement in the
short run is used instead of applying the best overall solution
Small decisions that accumulate over time -
“I’ll fix this later”
Hard to see until any small change is
extremely expensive (CoC = Cost of
Change), and then Conway’s Second Law
applies
If the debt is not repaid, then it will keep on
accumulating interest, making it hard to
implement changes later on

25. Why does it Happen?
Lazy programmers?
Sloppy programmers?
Inexperienced programmers?
No power to say no?

26. Source: Baruco 2012: Micro-Service Architecture, by Fred George
https://www.youtube.com/watch?v=2rKEveL55TY
Fred George
Micro-Service Architecture

28. Good design and architecture turn out to be not so good
Using the wrong tools
Shortcuts - “I’ll just inherit this class and change a method”
Calling methods you should not call
It was a good idea at the time, for example God Objects
Bad organisational structure (ignorance of Conway’s Law)
No ownership of code
No restrictions - “we’re agile, anybody can change any code”
Lack of understanding of the design of the code
Code guidelines and principles forgotten or do not exist
Putting code in wrong place due to lack of understanding
Why does it Happen?
Other reasons:

29. Why does it Happen?
Or maybe… University Teachers that teach about concrete inheritance
Object Oriented progamming is good but can be misused

30. Conwey’s Second Law
There’s never enough time to do something right, but
there’s always enough time to do it over

31. Architecture

32. Problem with Software Engineering
People see the same thing
differently or have the same
opinion on different things
The results are that people that
really agree, don’t agree
and people that agree, do not
really

33. Problem with Software Engineering
This leads to bad design and
implementations
Result is technical debt

34. Clear Up a Few Things
Terminology needs to be defined
People must have the same
understanding of terms used
Define and document
We work in a complex industry -
sometimes its good to ask “what
do you mean when you say X”

35. Architecture
Means different things to different people
Big picture,
things difficult to change,
a plan,
a blueprint…

36. Architecture - noun
The decomposition of a
product into a collection of
components/modules and
interactions
Structure

37. Architecture - verb
Understanding what you
need to build, create a
vision and making the right
decisions
vision

38. A component is a software building block that is
independently replaceable
independently upgradable
Component

39. Types of Architecture
There are many different architectures
★ Network, security, data, hardware, enterprise…
All have structure and vision
★ All have multiple constraints such as cost, time,
legal, regulatory

40. Application Architecture
Application is the focus
★ Contains classes, components, design patterns, frameworks,
libraries
Lower-level aspects of software design
★ Concerned with sign technology stack and layering
Technology
stack
Layering
Client
REST service
EJB
Hibernate
Oracle
Presentation
REST service
Service Layer
Domain Layer
Data Layer

41. System Architecture
▪ Focus on multiple applications across a number of tiers and
technologies
▪ Interactions between applications
▪ Overall structure of the end-to-end software system at high-level
▪ Mix of software and hardware

42. Software Architecture
▪ The combination of application and system architecture
▪ Includes the technical practices to build the software
– Design Principles, Programming language
Design patterns, Unit testing
and much more…
▪ Must also include aspects like
– Cross-cutting concerns such as logging and exception handling
Security, Performance, Audit Requirements, constraints,
and much more…

43. Enterprise Architecture
▪ How the enterprise is broken up in groups/departments
▪ Business processes used
▪ Workflows used
▪ May not look at technology in detail rather how to us technology
across the organization to get work done

44. Agile Architecture
▪ Agile refers to a methodology of building software
– moving fast, embracing change, release often, feedback cycles etc.
▪ Does agile development team then build agile architectures?
▪ Agile architecture means it can react to change, is easy to change, is
extendable

45. Agility
▪ Agility means you can use the OODA loop
How
Spotify
builds
products
Observe
Orient
Decide
Act

46. Which
of
the
following
architecture
descriptions
would
be
concerned
with
interactions
between
applications
A) Application
Architecture
B) System
Architecture
C) Software
Architecture
D) Enterprise
Architecture
QUIZ

47. Scaling Applications

48. Monolithic Architecture
Traditional Web Application Architecture
All code is built into a single application
that is deployed
In today’s environment might not be the
best approach
Tomcat
ApacheBrowser
WAR
Web Components
Customer
Wallet
Data Source
DB

50. Scaling Applications
In the Internet world you want to build web
sites that gets lots of users and massive
hit per second
But how can you cope with such load?
Browser
HTTP
Server
Application Database

51. Scale Cube
X scaling: duplicate the system
Z
scaling:Partition
the
data
Yscaling:PartitiontheApplication

52. Service Oriented Architecture

53. Trends in Architecture
Service Oriented Architecture (SOA) dates back to mid 1990s
Web Services meaning XML and SOAP using an Enterprise Services
Bus
Confusions on terminology
SOA is overload term - useless
Means different things to different people
Implies Web Services using SOAP

54. Trends in Architecture
SOA as in Web Services using SOAP

55. Bezos’ Mandate (from Yegge’s Rant)
1. All teams will henceforth expose their data and functionality
through service interfaces
2. Teams must communicate with each other through these
interfaces
3. There will be no other form of interprocess communication allowed
4. It doesn't matter what technology they use
5. All service interfaces, without exception, must be designed from
the ground up to be externalizable. No exceptions.
6. Anyone who doesn't do this will be fired.

56. Service Oriented Architecture
SOA actually means that components of an application
act as interoperable services, and can be used
independently and recombined into other applications.
Engineering Software as a Service by David Patterson and Armando Fox

57. Microservices
In recent years a new term has emerged, Microservices:
The microservice architectural style is an approach to
developing a single application as a suite of small services, each
running in its own process and communicating with lightweight
mechanisms, often an HTTP resource API.
From the Lewis & Fowler article

58. Martin Fowler - Microservices
https://www.youtube.com/watch?v=2yko4TbC8cI
Martin Fowler
Microservices

60. Definition of SOA is useless because it is so overloaded
Microservice architecture is better but needs to be
clarified
Service Architecture

61. Service Oriented Architecture
Software Architecture where all components are designed to be services
Applications composed of interoperable services
Easy to build new services, easy to change
Parts of the systems need to change more than others

62. Single Responsibility Principle (SPR)
states that a class should have one and only
one reason to change, that “reason to
change” is its responsibility.

63. Monolith Architecture
Bookstore
UI
Accounting
Payment
Shipping SQL
Web
Browser
Web
Server
Apache

64. Service Architecture
Bookstore
Service
Account
service
Payment
service
Shipping
service
Bookstore
UI
Web
Browser

65. Partitioning the Monolith into Services
From
http://www.manning.com/rotem/SOAp_SampleCh01.pdf
Arnon
Rotem-­‐Gal-­‐Oz’
SOA
Patterns
figure
1.
One way is to go from Object soup to Services along domain
seams to microservices

66. Microservices or microapps
▪ Each service can be around 100-200 LOC (lines of code)
– Size not the deterministic factor
– Don’t fix it – rewrite it
▪ Microservice can have embedded web server
– Totally independent

68. Drawbacks

70. Which
statement
is
not
true
about
SOA?
A) SOA
does
not
affect
performance
B) No
service
can
access
other
service
data
except
using
APIs
C) SOA
improves
productivity
though
reuse
D) Monoliths
system
must
deploy
all
components
QUIZ

71. Layering

72. Layering
• Software systems can get complicated
• Abstractions are needed
• Layering provides abstraction by separating computer systems in layers
• Higher layers use services from
lower layers
• Each layer has dedicated tasks
and hides complexity from upper
layers

73. Benefits of Layering
• You can understand a single layer as a coherent whole
without knowing much about other layers
• You can substitute layers with alternative implementation of
the same basic service
• You minimize dependencies between layers
• Layers make good places for standardization
• Once you have a layer built, you can use it for many higher-
level services

74. Downsides
▪ Layers encapsulate some, but not all, things well
– Cascading changes
– For example adding a field in the UI requires changes on each layer
▪ Extra layers can harm performance
– At every layer things typically need to be transformed from one
presentation to another

75. The Three Layers
▪ Presentation
– User’s interface to the system
– User can be another system
– Accepts input, displays views
▪ Domain
– The Application of the system
– The “Business logic”
– Tends to creep into presentation and data source
▪ Data Source
– Connection to the database
– Also Persistence

76. Summary
Conway’s Law explains a lot
Architecture in the Post-PC world means scaling
Big complex system can accumulate Technical Dept
Architecture defined
How to Scale Applications
What is Service Oriented Architecture
Layering is the oldest trick in the book