The Role of the Software Architect


Published on

Title: The Role of the Software Architect

Speaker: Hayim Makabee, co-founder of the Israeli Chapter of the International Association of Software Architects (IASA)

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.

Published in: Software
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

The Role of the Software Architect

  1. 1. The Role of the Software Architect Hayim Makabee International Association of Software Architects in Israel
  2. 2. Talk Outline • IASA Overview • Software Architecture Skills • Software Architect’s Role
  3. 3. About Me:  Education:  Experience:  Today:
  4. 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. 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. 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. 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. 8. The 4 Fields of Expertise Design Domain Technology Methodology
  9. 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. 10. Design Integrity  Software Quality Attributes:  Correctness  Modularity  Coupling  Cohesion  Testability  Maintainability  Extensibility  Reusability
  11. 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. 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. 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. 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. 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. 16. Technology Decisions  Example of technology decision: LAMP stack  LAMP:  Linux Operating System  Apache HTTP Server  MySQL Database  PHP Programming Language
  17. 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. 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. 19. Roles in Software Development Software Architect Product Owner Developer Tester Technical Writer
  20. 20. Non-Functional Requirements Non-Functional Requirements (NFRs)
  21. 21. Examples of NFRs  Latency  Throughput  Robustness  Scalability  Fault-Tolerance
  22. 22. Architecture Planning (High-Level Design) Architecture Discussion: • Frameworks • Platforms • Technologies • Abstraction Layers • Components • Design Patterns
  23. 23. Requirements Specification Use Cases (Functional Requirements) Use Cases Requirements Discussion: • Generalizations • Commonalities • Patterns • Exceptions • Impact on NFRs
  24. 24. Design Reviews Design Review: • Several design alternatives • All alternatives satisfy FRs • Different alternatives have different impact on NFRs • Discuss trade-offs
  25. 25. Multi-product Company Sharing opportunities: • Technologies • Infrastructure • Components • Patterns • Reuse Product A Product B Product C
  26. 26. Infrastructure Team Development of new: • Infrastructure • Reusable Components • Tools Product A Product B Infrastructure Team
  27. 27. Non-Functional Testing Non-Functional Testing: • Performance Tests • Load/Stress Tests • Robustness Tests • Simulators • Bombers • Log Players
  28. 28. Internal and External Documents External Documents: • User Guides • Manuals Internal Documents: • Infrastructure • Service Interfaces • Proprietary Protocols
  29. 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. 30. Thanks! Q&A
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.