Software Architecture versus Software Design Suren K Poruri

Problem statement Architecture/Design are buzz words without standard and consistent understanding in the industry.

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.

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

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 .

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

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

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

Car analogy Software Architecture Modules Modules Modules Interfaces

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

Design Scope Internal structure/behavior of each module Concrete UI pages design Algorithms design Class design based on SRP ( Single responsibility principle)

Architecture versus design System decisions Hard to change Scope - System Design Module decisions Easy to change Scope - module

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