Download to read offline
More Related Content
Similar to CPSA-F Day1CPSA-F Day1CPSA-F Day1CPSA-F Day1CPSA-F Day1.pptx
More from FutureTechnologies3
CPSA-F Day1CPSA-F Day1CPSA-F Day1CPSA-F Day1CPSA-F Day1.pptx
- 1. Click to editMaster title style 1 Certified Professional for Software Architecture – Foundation Level B y : E n g . M o h a m e d S a l e m
- 2. Click to editMaster title style 2 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
- 3. Click to editMaster title style 3 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
- 4. Click to editMaster title style 4 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?"
- 5. Click to editMaster title style 5 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.
- 6. Click to editMaster title style 6 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.
- 7. Click to editMaster title style 7 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).
- 8. Click to editMaster title style 8 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.
- 9. Click to editMaster title style 9 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.
- 10. Click to editMaster title style 10 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.
- 11. Click to editMaster title style 11 Thank You
Editor's Notes
- #2 This is our roadmap for Day 1. We'll start by establishing a common understanding of the fundamentals before diving into how architectures are developed. The structure follows the iSAQB (International Software Architecture Qualification Board) knowledge units, which are the basis for the CPSA-F certification.
- #3 It's crucial to understand that an architect's role extends far beyond writing code. They are a bridge between business, management, and development teams. The mindset shift is from "How do I build this feature?" to "How do we build a system where this feature, and many others, can be built, maintained, and scaled effectively?" Ask the audience: What do you think is the most challenging part of an architect's role? (Often, the answer is "managing conflicting stakeholder expectations").
- #4 The key takeaway is that architecture is about the significant elements and their relationships. It's about the "what" and "why," while implementation is about the "how." Emphasize that the line between architecture and design can be blurry, but the core idea is the impact of the decision. An architectural decision has wide-ranging consequences.
- #5 Use a metaphor: Building a house without an architect might be faster initially, but you'll pay much more later for adding a second story or fixing a foundational crack. The goal is not to create a "perfect" architecture, but a fit-for-purpose one that supports the business goals and is sustainable.
- #6 Stress that architecture is a continuous activity. It's not a document you write at the start and forget. The architect is involved throughout the lifecycle. In Agile, we practice "Just Enough" Architecture Upfront (JEAUF). We make the big, hard-to-change decisions early and delay more detailed decisions until the "last responsible moment."
- #7 This is the basic vocabulary we will use throughout the course. Understanding these terms is essential. Example: In a web application, a "UserService" (Component) exposes a REST API (Interface). It communicates with another "EmailService" (Component) via a message broker like RabbitMQ (Connector). All of this resides in the "Application Layer" (Layer).
- #8 These principles are the foundation of managing complexity. They are the "why" behind most patterns and best practices. Analogy: A kitchen has separate areas for prep, cooking, and cleaning (Separation of Concerns). The utensils in the knife block are highly cohesive; they are all for cutting. The blender (module) is loosely coupled from the oven (another module); you can replace one without affecting the other.
- #9 Crucial point: Functional requirements tell you what to build, but quality attributes tell you how to build it. They are the primary drivers of architectural shape. Example: The requirement "The system must support 10,000 concurrent users" (a performance/scalability quality attribute) drives the decision to use a load balancer and a distributed cache. It's not about a single function, but about the system's overall structure.
- #10 Briefly recap the key messages. Thank the participants for their engagement. Open the floor for any final questions on today's material. Build excitement for Day 2, where we move from theory to more concrete models and patterns.