The document discusses the essential role of a software architect, including their participation in methodology decisions, high-level design, domain modeling, and planning for software evolution. It emphasizes the need for cooperation with various stakeholders such as product owners, developers, and testers to ensure the correctness and quality of software architecture. Additionally, it highlights non-functional requirements and testing strategies important for maintaining software integrity.

1. The Role of the Software Architect
Hayim Makabee
International Association of Software Architects in Israel

2. About Me:
 Education:
 Experience:
 Today:

3. Roles in Software Development
Software Architect
Product Owner
Developer
Tester
Technical Writer

4. Methodology Decisions
 The software architect should participate in decisions about the
software development methodology.
 Examples of methodology decisions:
1. Agile methods imply reduced design up-front and thus some form
of emergent or evolutionary design.
2. Test-Driven Development (TDD) reduces the risks associated to
Refactoring and thus requires less detailed design.
3. Pair Programming requires less design and code reviews.

5. Non-Functional Requirements
Non-Functional
Requirements (NFRs)

6. Examples of NFRs
 Latency
 Throughput
 Robustness
 Scalability
 Fault-Tolerance

7. Architecture Planning
(High-Level Design)
Architecture Discussion:
• Frameworks
• Platforms
• Technologies
• Abstraction Layers
• Components
• Design Patterns

8. High-Level Design Decisions
 Examples of high-level design decisions:
1. Service-Oriented Architecture (SOA) based on stateless RESTful
services returning JSON objects.
2. Staged Event-Driven Architecture (SEDA) based on message
queues and adaptive load balancing.

9. Requirements Specification
Use Cases
(Functional Requirements)
Use Cases
Requirements
Discussion:
• Generalizations
• Commonalities
• Patterns
• Exceptions
• Impact on NFRs

10. Domain Modeling Decisions
 Given the Requirements Specification, the software architect
should participate in Domain Modeling.
 Examples of domain modeling decisions:
1. Should a relationship be represented as an object or as an
association between two objects?
2. Should an object have a fixed list of attributes or a dynamic set of
properties?
3. Should an attribute be represented as a primitive type or as an
object?

11. Planning for Software Evolution
 Planning for software evolution requires a good understanding
of the application’s domain:
 Modeling of the main domain entities, their attributes and
relationships.
 Refinement of generalization/specialization hierarchies.
 Identification of the domain aspects that are not represented in the
current requirements.
 Identification of areas of volatility that are likely to change.
 Domain analysis should drive the introduction of mechanisms
for flexibility and extensibility.

12. Design Reviews
Design Review:
• Several design alternatives
• All alternatives satisfy FRs
• Different alternatives have
different impact on NFRs
• Discuss trade-offs

13. Design Integrity
 Software Quality Attributes:
 Correctness
 Modularity
 Coupling
 Cohesion
 Testability
 Maintainability
 Extensibility
 Reusability

14. Multi-product Company
Sharing opportunities:
• Technologies
• Infrastructure
• Components
• Patterns
• Reuse
Product A
Product B
Product C

15. Infrastructure Team
Development of new:
• Infrastructure
• Reusable Components
• Tools
Product A
Product B
Infrastructure Team

16. Non-Functional Testing
Non-Functional Testing:
• Performance Tests
• Load/Stress Tests
• Robustness Tests
• Simulators
• Bombers
• Log Players

17. Internal and External Documents
External Documents:
• User Guides
• Manuals
Internal Documents:
• Infrastructure
• Service Interfaces
• Proprietary Protocols

18. Summary
 The Software Architect works in tight cooperation with:
 Product Owners: Functional and Non-Functional Requirements
 Developers: Domain Modeling and Design Reviews
 Testers: Non-Functional Testing
 Technical Writers: Internal and External Documents
 Multiple Teams: Reuse and Infrastructure

19. Thanks!
Q&A