CPSA-F Day1CPSA-F Day1CPSA-F Day1CPSA-F Day1CPSA-F Day1.pptx

gh

1. Certified Professional for Software Architecture – Foundation Level By: Eng. Mohamed Salem

2. Course Agenda - Day 1 What We'll Cover Today: Knowledge Unit: Foundation (FOU) The Role of a Software Architect Defining Software Architecture Why Architecture Matters Architecture in the Development Lifecycle Key Terminology Knowledge Unit: Development of Software Architectures (DES) Core Design Principles Linking Architecture to Requirements 2

3. The Role of a Software Architect The Software Architect: More Than Just a Senior Developer Responsibilities: Making fundamental structural decisions. Analyzing technical and business requirements. Selecting appropriate technologies and patterns. Ensuring alignment between business goals and technical implementation. Managing stakeholder communication. Key Skills & Mindset: Technical Breadth and Depth Strategic Thinking & Decision-Making Communication and Facilitation Leadership and Influence (without direct authority) Pragmatism and Risk Management 3

4. What is Software Architecture? Defining Software Architecture Formal Definition (ISO/IEC/IEEE 42010):  "Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution." Simpler Definition:  The  "big decisions"  — the ones that are hard to change and shape the entire system. Architecture vs. Design vs. Implementation: Architecture:  "Are we using a microservices or a monolith? What is our primary database?" Design:  "How will the 'Order Service' interact with the 'Payment Service'? What are the module boundaries?" Implementation:  "How do I code this specific class or function?" 4

5. Why Architecture Matters The Business Value of Good Architecture Cost of Poor Architecture (Technical Debt): Slows down feature development over time. Increases bug-fixing and maintenance costs. Makes system evolution and adaptation risky and expensive. Business Alignment: A good architecture enables the system to meet its  Quality Attributes  (e.g., performance, security, scalability), which are often the real business differentiators. It's an investment that reduces long-term cost and risk. 5

6. Architecture in the Development Lifecycle Architecture is Not a One-Time Phase Inception/Early Phase:  Understand key requirements, especially quality attributes. Identify major technical risks. Create a  candidate architecture . Construction/Implementation:  The architecture evolves and is refined. The architect ensures the team adheres to architectural constraints and principles. Deployment & Operation:  Architecture decisions directly impact deployability , monitorability, and runtime qualities. Agile Context:  Architecture emerges and is refined iteratively, but key decisions must be made early to avoid rework. 6

7. Key Architectural Terminology Speaking the Language: Core Concepts Component:  A modular, replaceable part of a system with a well-defined interface (e.g., a service, a module, a class). Connector:  A mechanism for communication and coordination between components (e.g., HTTP, a message queue, a shared database). Interface:  A contract that defines how a component can be interacted with. Layer/Tier:  A logical grouping of components, often representing a separation of concerns (e.g., Presentation Layer, Business Logic Layer, Data Access Layer). 7

8. Core Design Principles Guiding Principles for Good Architecture (DES) Separation of Concerns:  Break down a system into distinct features with minimal overlap.  Why?  Simplifies development and maintenance. Modularity:  Decompose a system into cohesive, loosely coupled modules. High Cohesion:  Elements within a module should be strongly related and focused on a single purpose. Low Coupling:  Modules should have minimal dependencies on each other. Changes in one module should not require changes in others. 8

9. Architecture and Requirements From Requirements to Structure Functional Requirements:   What  the system should do (e.g., "The user shall be able to place an order"). These are primarily implemented by choosing and designing components. Quality Attributes (Non-Functional Requirements):   How well  the system should perform its functions (e.g., performance, security, availability). These are primarily implemented and validated through  architectural decisions . The Link:  Every significant architectural decision should be traceable to one or more quality attributes. 9

10. Day 1 Wrap-Up & Look Ahead Summary: Day 1 The architect is a strategic role balancing technical, business, and social aspects. Architecture is the set of fundamental, hard-to-change decisions. Good architecture reduces long-term costs and enables business goals. It's a continuous process throughout the software lifecycle. Core principles like Separation of Concerns and Low Coupling guide us. Quality Attributes are the key drivers of architectural decisions. Preview for Day 2:  Tomorrow, we'll get into the practical tools: how to describe architecture using views and documentation, the common patterns you can use, and a deep dive into quality attributes. 10

11. Thank You