Title: The Role of the Software Architect Speaker: Hayim Makabee, co-founder of the Israeli Chapter of the International Association of Software Architects (IASA) Abstract: In this talk Hayim will present the practical aspects of the role of the Software Architect, including: - The four areas of expertise: Design, Domain, Technology and Methodology. - The cooperation with stakeholders: Developers, Team Leaders, Project Managers, QA and Technical Writers. Understanding the expected areas of expertise is essential for the architect to develop his/her professional skills. Understanding how to cooperate with the diverse stakeholders is essential to improve the architect's impact and effectiveness.

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

2. Talk Outline
• IASA Overview
• Software Architecture
Skills
• Software Architect’s
Role

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

4. What is IASA?
 Non-Profit Global Professional Association, founded in 2002.
 Target Public:
 Enterprise, Information, Infrastructure, Software and Business
Architects.
 Professional software developers targeting an architect position in
their career path.
 Manages an IT architecture knowledge repository.

5. IASA Chapters & Membership
 8,000 members in over 60 countries
 In 35 chapters on 5 continents
 Locally run by architects
Locally run by volunteer IT architects
8,000 members in 35 chapters

6. Local Chapter Activities
 Events
 Monthly events/meetings
 Virtual presentations/discussions
 Special interest/focus groups
 Conferences
 Mentoring
 Lifeline
 Study Groups
 Training Courses & Workshops
 Certification

7. Software Architecture Skills
 A Software Architect should have expertise in:
 Design
 Domain
 Technology
 Methodology
Expertise = Knowledge + Experience
“The young man knows the rules, but the old man knows the
exceptions.” – Oliver Wendell Holmes

8. The 4 Fields of Expertise
Design
Domain Technology
Methodology

9. Design Expertise
 The Software Architect should be an expert on Software
Design, including diverse methods and approaches:
 OOD, Aspect-Oriented, Event-Driven, Domain-Driven, etc…
 The Software Architect should be able to lead the development
team in the definition of the high-level design.
 The Software Architect should be able to review design
proposals and assess trade-offs among them.
 The Software Architect should be able to coordinate
development efforts and guarantee the integrity of design.

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

11. 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.

12. Domain Expertise
 The Software Architect should be an expert on the domain of
the system being developed.
 The Software Architect should assist in the requirements
elicitation process, assuring consistency and completeness.
 The Software Architect should contribute to the definition of a
domain model for the system being developed.
 The Software Architect should plan for software evolution,
taking in consideration future changes in requirements.

13. 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.

14. Domain Decisions
 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?

15. Technology Expertise
 The Software Architect should be an expert on the available
technologies that may be used to implement the system.
 The Software Architect should coordinate the selection of:
 Programming Languages
 Development Environments
 Frameworks
 Libraries
 Platforms
 Databases
 Protocols

16. Technology Decisions
 Example of technology decision: LAMP stack
 LAMP:
 Linux Operating System
 Apache HTTP Server
 MySQL Database
 PHP Programming Language

17. Methodology Expertise
 The Software Architect should be an expert on software
development methodologies that may be adopted during the
Software Development Life Cycle (SDLC).
 The Software Architect should help the team choose the
appropriate development approaches.
 The planning and evolution of the software architecture during
the SDLC depends on the methodology being used.

18. Methodology Decisions
 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.

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

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

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

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

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

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

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

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

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

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

29. Summary
 A Software Architect should have expertise in:
 Design
 Domain
 Technology
 Methodology
 The Software Architect should work in tight cooperation with:
 Product Owners
 Developers
 Testers
 Technical Writers

30. Thanks!
Q&A