Architectural Design: Designing Before Design

1. Architectural Design: Designing Before Design J. Fernando Naveda Department of Software Engineering Rochester Institute of Technology jfn@cs.rit.edu

2. Agenda • Brief history of software • Motivation for architectural design • Architecture and quality • Architectural styles • Architectural attributes • From problem to design • Beware of AntiPatterns • Closing remarks

3. A Brief History of Software • In the beginning there was only code • And we all lived in the “hack” • But the creator said “let there be right ways to write code” and... • Coding standards were born • And we designed code 1 of 6

4. A Brief History of Software • And programs grew and grew but… we were still unhappy • And the creator said “let there be ways to structure code” • And program design techniques were born 2 of 6

5. A Brief History of Software • And we all designed prettyprograms… but we were still unhappy • And the creator said “Hey! Take care of your data” • And Abstract Data Types were born 3 of 6

6. A Brief History of Software • And we all designedprograms and dataabstractions... • And ADT-based programming languages were born • And we were still unhappy • The creator then said “Hey! This is still a mess!” • And we invented Objects 4 of 6

7. A Brief History of Software • And objects were good because • They promoted encapsulation of data and designs • They promoted coding to interfaces and... • They facilitated the codification of design patterns 5 of 6

8. A Brief History of Software • Seeing that all was good, the creator rested…but not for long • The creator said “Designs are the matter, have not you been listening?” • And architectural designs were born 6 of 6

9. Why Architectures? • Software systems are not getting smaller • Software systems are not getting simpler • Good designs are difficult to produce • Significant investment in designs

10. The Architectural Concerns • Software Architecture concerns the structure of large software systems • The architectural view is an abstract view: • Implementation details are not important • Algorithmic details are not important • Data representation concentrates on behavior and interaction of black box components

11. A Working Definition • The software architecture of a software system is the structure or structures of the system, which comprise • Software components • The externally visible properties of those components • And the relationships among them

12. We Cannot Ignore • The business side of things • Organizational structure of the software house • Projected life of the system

13. Stakeholders & Priorities • Customer (buildability) • End users (usability, performance) • Developing organization (tech trends) • Business goals (cost, time to market) • Organizational structure (hierarchical) • Maintainers (flexible, testable) • etc.

14. Quality Early On • A system’s architecture is the earliest artifact that enables us to analyze competing priorities: • Performance vs. security • Maintainability vs. reliability • Cost vs. time to market vs. performance

15. Discernable at Runtime • How well does the system satisfy its behavioral requirements? • Does it provide required results? • How good is the response time? • Are outputs correct? • How well does the system behave when connected with other systems? • How quickly can an “average” user learn to use it?

16. Not Discernable at Runtime • How easy is it to test it? • How easy is it to modify? • How expensive was it to develop? • What is the system’s time to market?

17. Quality Attribute Classes • Discernable at runtime • Performance, security, functionality, availability, usability • Not discernable at runtime • Modifiability, portability,reusability, integrability, testability • Business qualities • Qualities of the architecture itself

18. QA Relationships • Knowing something in one category may not tell anything in the other • Runtime requirements vs. modifiability • Qualities within one category may be unrevealing among each other • A highly available system may be unreliable

19. Architectural Dependencies • Modifiability isprimarily architectural • It is determined by allocation of behavior • A system is modifiable if changes do not involve large numbers of distinct components • Of course writing obscure code is not an architectural issue

20. Dependencies • Performance has architectural and non-architectural dependencies • How much communication takes place among components (architectural) • What functionality has been allocated to each component (architectural) • Choice of algorithms (non-architectural) • Implementation decisions (non-architectural)

21. Business Qualities Goals • Cost and schedule • Time to market • Competition, window of opportunity • Software organization may decide to use COTS products or components • Cost • Area of expertise of personnel involved is a factor • Projected lifetime of the system

22. Market and Marketing • Targeted market • Multi-platform(mass market) • Portability, functionality, performance, usability • Large but specific market • Product-line approach • Rollout schedule • Base functionality with many options • Extensive use of legacy systems

23. Qualities of the Architecture • Conceptual integrity • The underlying vision that unifies the design of a system at all levels • Correctness and completeness • Buildability • Can the team build the system by the target time? • Can the system be built using well-understood principles?

24. Architecture Selection • What architectural styles fit the system in question? • How does one select one over others? • How do architects keep conceptual integrity of the system?

25. Architectural Styles Gallery Independent components Event systems Communicating processes Explicit invocation Implicit invocation Data flow Data-centered Pipes and filters Batch sequential Blackboard Repository Call/return Virtual machine Layered Main program and subroutine Object- oriented Interpreter Rule-based system

26. Styles and QAs • Architectural designs meet specific QAs • Data Flow • Quality goals: Re-use and modifiability • Call and Return • Quality goals: Modifiability and scalability

27. What’s a Good Architecture? • Architectures are more or less fit for some stated purpose • There is no such thing as a “bad” architecture

28. From Problem to Design • The problem domain often suggests architectural approaches • Focus on how the end-user(s) • Interact with the current system • Would interact with the new system • Focus on ranked list of QAs • Don’t try to fit your design to any particular style

29. From Problem to Design • Rather, design freely and then see... • Which architectural designs best resemble your design with regards to architecturally sensitive requirements • Bring in the business goals • Use the styles as validation tools

30. Putting it all Together • Know the stakeholders • Map stakeholders concerns to a prioritized list of quality attributes • Develop candidate architectures • Produce one architecture • Have an intellectual owner • The styles are just guides

31. AntiPatterns • Nearly 1/3 of the software projects are cancelled • Two thirds of all S/W projects encountered cost overruns in excess of 200% • Over 80% of all software projects are deemed failure

32. So What are AntiPatterns? • Literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences

33. AntiPattern Types • Software development AntiPatterns • The Blob • Software project management AntiPatterns • Corncob • Software architecture AntiPatterns • Design by committee

34. Closing Remarks • Architecture is critical to the realization of a system’s qualities • Some qualities are not architecturally sensitive • Quality attributes do not exist in isolation • Some quality attributes exist in tension while others support each other • Security vs. Fault Tolerance • Portability vs. Modifiability