1
Software Architecture versus
Software Design
Suren K Poruri
2
Problem statement
Architecture/Design are buzz words without
standard and consistent understanding in the
industry.
3
Problem description
Multiple definitions
of architecture definitions/descriptions
Multiple architecture standards ( Togaf ,
4+1, etc.,)
Design means
class/object diagrams, sequence diagrams, etc., Is it really so?
No continuation
between architecture/design/codi
ng.
Architecture/design
created for process
compliance purpose
rather than solution purpose.
4
Causes of the Problem
Project delays/cancellati
ons.
Cost of maintenance is high.
Communication overhea
d
Mismatch in
expectations
No consistency in
the artifacts
Benefits of
architecture not known
to business
. Why should they? Ex:
Building
Consumption
utilization
5
The Need of Architecture ( Analogy 1)The Winchester “Mystery” House
38 years of construction – 147 builders 0 architects160 rooms – 40 bedrooms, 6 kitchens, 2 basements, 950 doors65 doors to blank walls, 13 staircases abandoned, 24 skylights in floorsNo architectural blueprint exists
6
Construction Analogy 2
Can be built by one person
RequiresMinimal ArchitectureSimple processSimple tools
Architecting a house
Built most efficiently and timely by a team
RequiresArchitectureWell-defined processPower tools
Architecting a high rise
Can be built by multiple teams/partnersHeavy duty ArchitectureComplex processSophisticated costly tools
7
Differences
Scale Process Cost Schedule Skills and development teams Materials and technologies Stakeholders Risks
8
Architecture definition
Many definitions available at
cmu web site.
The essence is same• Architectu
re means structure and behavior of a system.
It includes • Horizontal ones
1) Process structure
• Vertical ones 2) Presentation structure 3) Logic structure 4) Data access structure
• 5) Datamodel/ Information structure.
Construction analogy –
pillars+ beams =
structure of the
building.
Process structureUI
structure
Logic structure
Data access structure
Data structu
re
1. Design is structure/behavior of a module.
Design definition
9
Car analogy
SoftwareArchitect
ure
Modules
Modules
Modules
Modules
Interfaces
10
Architecture scope
Navigation structure Page structure
Maintenance Transactions Report
Validation structure – consolidation of client side validations across the system Logging structure – What information need to be logged at a process level, layer level, module level Exception handling structure – System /process/layer level exceptions Use case/processs flow structure ( Presentation to business logic to data access layer) Identification of unique use case flows. Design patterns that we need to use? Deployment decisions Architectural style ( client/server, web , soa etc., ) Layering decision ( How many layers, responsibility of each layer, Layer interfaces etc., ) Business objects representation ( EJB, Pojo, etc., ) Database usage ( data repository only or data repository + business logic) Database access layer structure Security structure ( authentication, authorization, audit etc., )
TemplatePages
11
Design Scope
Internal structure/behavior of each module Concrete UI pages design Algorithms design Class design based on SRP ( Single responsibility
principle)
12
Architecture versus design
Architecture
System decisions
Hard to change
Scope - System
Design
Module decisions
Easy to change
Scope - module
13
14
Here’s the Point!
If functionality is the only thing that matters, any software architecture will do!
Other things that really matter: design constraints quality attributes