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/coding.
Architecture/design created for process compliance purpose rather than solution purpose.

4. Causes of the Problem Project delays/cancellations.
Cost of maintenance is high.
Communication overhead
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 architects
160 rooms – 40 bedrooms, 6 kitchens, 2 basements, 950 doors
65 doors to blank walls, 13 staircases abandoned, 24 skylights in floors
No architectural blueprint exists .

6. Construction Analogy 2 Architecting a house Architecting a high rise
Built most efficiently and timely by a team
Requires
Architecture
Well-defined process
Power tools
Can be built by one person
Requires
Minimal Architecture
Simple process
Simple tools
Can be built by multiple teams/partners
Heavy duty Architecture
Complex process
Sophisticated costly tools
Architecting a high rise

7. Differences Scale Process Cost Schedule Skills and development teams
Materials and technologies
Stakeholders
Risks

8. Architecture definition
Design definition
Many definitions available at cmu web site.
The essence is same
Architecture 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.
Design is structure/behavior of a module.
Process structure
UI structure
Logic structure
Data access structure
Data structure

9. Car analogy Software Architecture 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., )
Template
Pages

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
System decisions
Hard to change
Scope - System
Design
Module decisions
Easy to change
Scope - module

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