Agile Architecture Diego Fontdevila [email_address]

Contents Software A rchitecture The need for architecture The role of the A rchitect Modularity Team

Software A rchitecture

The need for architecture

The role of the A rchitect

Modularity

Team

Software Architecture

Software architecture “ The structure or structures of the system, which comprise software components, the externally visible properties of those components and the relationships among them.” (Bass, Clements, Kazman) Strategic design Decisions we want to get right (Ralph Johnson) What is hard to change (Martin Fowler)

“ The structure or structures of the system, which comprise software components, the externally visible properties of those components and the relationships among them.” (Bass, Clements, Kazman)

Strategic design

Decisions we want to get right (Ralph Johnson)

What is hard to change (Martin Fowler)

Software architecture As much the strategic design activity as the resulting product of that activity. Helps with iterative and incremental development. Might not be apparent. Noticeably affects the quality attributes of the product. Technology sensitive. Usually has a high level of abstraction.

As much the strategic design activity as the resulting product of that activity.

Helps with iterative and incremental development.

Might not be apparent.

Noticeably affects the quality attributes of the product.

Technology sensitive.

Usually has a high level of abstraction.

The need for architecture

The need for architecture Essential complexity No Silver Bullet (Brooks) Flexibility is a basic hygien e requirement Write less code (Poppendiecks) Growing size Pattern of constant growth of our abstractions (Shaw). Distribution Generalized in the '90s Uncerta in number of users Agile Architecture

Essential complexity

No Silver Bullet (Brooks)

Flexibility is a basic hygien e requirement

Write less code (Poppendiecks)

Growing size

Pattern of constant growth of our abstractions (Shaw).

Distribution

Generalized in the '90s

Uncerta in number of users

The role of the architect

The role of the architect Technical lead Has valuable experiences to share (might limit his vision) Mentor, guide and counselor for the team Has business vision Responsible for technical risks Supports communication between stakeholders Helps define the structure of the project Agile Architecture

Technical lead

Has valuable experiences to share (might limit his vision)

Mentor, guide and counselor for the team

Has business vision

Responsible for technical risks

Supports communication between stakeholders

Helps define the structure of the project

Modularity

Modularity What is a module today? Piece of code? Procedure? ADT? Class? Package? Application? Product structure in terms of work assignment (Len Bass et al). Agile Architecture

What is a module today?

Piece of code?

Procedure?

ADT?

Class?

Package?

Application?

Product structure in terms of work assignment (Len Bass et al).

Modularity S ystem size has grown and software use is widespread. Module size is driven by system size. Limitation on the amount of modules of a system is on the human mind. Module size is constantly increasing. In other words, the granularity of our abstractions has been historically growing (Shaw). Agile Architecture

S ystem size has grown and software use is widespread.

Module size is driven by system size. Limitation on the amount of modules of a system is on the human mind.

Module size is constantly increasing. In other words, the granularity of our abstractions has been historically growing (Shaw).

Modularity Modules need to have wel l defined interfaces. Helps reduce dependencies between modules y facilitates working independently. But the loss of dependencies inside a team may affect result eliminating opportunities for interaction and reconception between team members working in different modules (Austin and Devin). Agile Architecture

Modules need to have wel l defined interfaces.

Helps reduce dependencies between modules y facilitates working independently.

But the loss of dependencies inside a team may affect result eliminating opportunities for interaction and reconception between team members working in different modules (Austin and Devin).

Modularity: Language Linguistic Modular Units Pr inciple : Programming language should support the syntax to describe modules (Meyer). How do you say module in you r programming language? Hi gh level languages are a must (Brooks). Their level of abstraction has been steadily growing. Languages are becoming platforms, and there are already architecture level languages. Annotations and Aspects, for instance, allow us to extend languages. Agile Architecture

Linguistic Modular Units Pr inciple : Programming language should support the syntax to describe modules (Meyer).

How do you say module in you r programming language?

Hi gh level languages are a must (Brooks). Their level of abstraction has been steadily growing.

Languages are becoming platforms, and there are already architecture level languages. Annotations and Aspects, for instance, allow us to extend languages.

Team

Team We think only with the wor ds we know. Software as a conversation and collaboration. Technical v ision guides development producing a balanced and harmonic design . Contributions from team members are very important and must be integrated, not evened out: Reconceiving over Compromise (Austin and Devin). Different perspectives help diminish technical uncertainty . Agile Architecture

We think only with the wor ds we know.

Software as a conversation and collaboration.

Technical v ision guides development producing a balanced and harmonic design .

Contributions from team members are very important and must be integrated, not evened out: Reconceiving over Compromise (Austin and Devin).

Different perspectives help diminish technical uncertainty .

Team: Language Architecture serves as the entry point for training new team members. It is usu ally best to use a restricted solution language, based on patterns and frameworks (Bass, Clements, Kazman). Domain Driven Design: There should be a single model for problem and solution (Evans) Domain Model: The T eam and the Customer build a single language for the solution they develop (Evans) Agile Architecture

Architecture serves as the entry point for training new team members.

It is usu ally best to use a restricted solution language, based on patterns and frameworks (Bass, Clements, Kazman).

Domain Driven Design: There should be a single model for problem and solution (Evans)

Domain Model: The T eam and the Customer build a single language for the solution they develop (Evans)

Team: Collaboration Ana lyst: Initial requirements, feasibility Developer: Incremental design , pair programming Tester: Quality attributes strategy, Prototype testing, test harness definitions Agile Architecture

Ana lyst:

Initial requirements, feasibility

Developer:

Incremental design , pair programming

Tester:

Quality attributes strategy, Prototype testing, test harness definitions

Team When does architecture come into our work? When we fir st try to conceive the product as a whole When we propose strategies to fulfill requirements related to quality attributes and when we test them When we distribute work between our teams When we organize our software configuration When we choose languages and technology When we record design rationale Agile Architecture

When does architecture come into our work?

When we fir st try to conceive the product as a whole

When we propose strategies to fulfill requirements related to quality attributes and when we test them

When we distribute work between our teams

When we organize our software configuration

When we choose languages and technology

When we record design rationale

Team: Documentation rules Ar chitecture Documentation/Communication Rules P ut yourself in his shoes (Views) Keep a standard organization (Views?) Avoid ambiguity (Unique language) Avoid unnecesary repetition (and explain notations) Keep documentation current but not too current Record rationale (Decision Log) Review documentation for fitness of purpose (Clements, Garlan, et al) Agile Architecture

Ar chitecture Documentation/Communication Rules

P ut yourself in his shoes (Views)

Keep a standard organization (Views?)

Avoid ambiguity (Unique language)

Avoid unnecesary repetition (and explain notations)

Keep documentation current but not too current

Record rationale (Decision Log)

Review documentation for fitness of purpose

(Clements, Garlan, et al)

Bibliography Austin, Bob, Devin, Lee, Artful Making , What Managers need to know about how artists work, Bass, Len, Clements, Paul, Kazman, Rick, Software Architecture in Practice , SEI Series in Software Engineering, 1998. Brooks, Frederick, No Silver Bullet, Essence and Accidents of Software Engineering , Computer Magazine, 1987. Clements, Paul, et al, Documenting Software Architecture: Views & Beyond , SEI Series in Software Engineering, Addison-Wesley, 2003. Evans, Eric, Domain Driven Design , Tackling Complexity in the Heart of Software, 2003. Agile Architecture

Austin, Bob, Devin, Lee, Artful Making , What Managers need to know about how artists work,

Bass, Len, Clements, Paul, Kazman, Rick, Software Architecture in Practice , SEI Series in Software Engineering, 1998.

Brooks, Frederick, No Silver Bullet, Essence and Accidents of Software Engineering , Computer Magazine, 1987.

Clements, Paul, et al, Documenting Software Architecture: Views & Beyond , SEI Series in Software Engineering, Addison-Wesley, 2003.

Evans, Eric, Domain Driven Design , Tackling Complexity in the Heart of Software, 2003.

Bibliography Austin, Rob, Devin, Lee, Artful Making, What managers need to know about how artists work , Prentice Hall, 2003. Bass, Len, Clements, Paul, Kazman, Rick, Software Architecture in Practice , SEI Series in Software Engineering, 1998. Brooks, Frederick, “No Silver Bullet” , in The Mythical Man-Month, Essays on Software Engineering , Addison-Wesley, 1985. Clements, Paul, Shaw, Mary, "Three Patterns That Help Explain the Development of Software Engineering" , Position paper for Dagstuhl Workshop on Software Architecture, 1996. Agile Architecture

Austin, Rob, Devin, Lee, Artful Making, What managers need to know about how artists work , Prentice Hall, 2003.

Bass, Len, Clements, Paul, Kazman, Rick, Software Architecture in Practice , SEI Series in Software Engineering, 1998.

Brooks, Frederick, “No Silver Bullet” , in The Mythical Man-Month, Essays on Software Engineering , Addison-Wesley, 1985.

Clements, Paul, Shaw, Mary, "Three Patterns That Help Explain the Development of Software Engineering" , Position paper for Dagstuhl Workshop on Software Architecture, 1996.

Bibliography Clements, Paul, et al, Documenting Software Architecture: Views and Beyond , SEI Series in Software Engineering, Addison-Wesley, 2003. Fowler, Martin, “Who Needs an Architect?” , IEEE Software, Volume 20, Issue 4, September 2003, pages 11-13. Meyer, Bertrand, Object-Oriented Software Construction , Prentice-Hall, 1985, 2nd Edition 1997. Poppendieck, Mary, Poppendieck, Tom, Implementing Lean Software Development, From Concept to Cash , Addison-Wesley, 2006.

Clements, Paul, et al, Documenting Software Architecture: Views and Beyond , SEI Series in Software Engineering, Addison-Wesley, 2003.

Fowler, Martin, “Who Needs an Architect?” , IEEE Software, Volume 20, Issue 4, September 2003, pages 11-13.

Meyer, Bertrand, Object-Oriented Software Construction , Prentice-Hall, 1985, 2nd Edition 1997.

Poppendieck, Mary, Poppendieck, Tom, Implementing Lean Software Development, From Concept to Cash , Addison-Wesley, 2006.

Thank you