Selecting systems architectures

Selecting Systems Architectures

Course Information

• Course Code: ADM 3379

• Course Title: System Analysis, Development and Performance

• Semester: Winter 2026

• Institution: École de Gestion Telfer, School of Management

Course Materials

• Textbook:
    - Dennis, A., Wixom, B. H., & Roth, R. M. (2006). Systems Analysis Design (8th ed.). J. Wiley.
    - Focus on Sections 13.1.1, 13.2.5, 13.2.6.

• Supplementary Material:
    - Additional materials and resources will be provided as needed.

Example Scenario

• Context: Building a College Campus
    - Key Considerations:
      - Calculate the number of buildings required and their organization.
      - Assess the size of the campus grounds in relation to its users (students, faculty, academic programs).
      - Decide on building materials and architectural style to be used.

Definition of Architecture

• Source: Merriam-Webster
    - “Architecture is a conscious act of determining the optimal form and structure of a system.”

• Objectives of Architecture in Systems:
    - Model organizational systems comprehensively to mitigate complexity.
    - Provide guidance for planning, designing, and constructing different system aspects while considering operational contexts.
    - Note: Architectural decisions are foundational; changing them post-decision is challenging due to their long-term impact.

• Analogy:
    - Think of architectural foundations like a house: the outer footprint affects the internal layout and design.

Architecture Design

• Focus of Architecture Design:
    - Plan for distributing information system (IS) components across multiple computers, selecting necessary hardware, operating systems, and application software for each computer.
    - Aim: Analyze how software components will be assigned to hardware devices in the system.

• Role of Specialists:
    - Systems architecture is typically performed by specialists, and the notes focus on essential architectural concepts crucial for systems analysts to comprehend.

TOGAF Overview

• History:
    - Originally released in 1995, transitioned to The Open Group in 2005; currently at version 9.2.

• Components:
    - Contains the Architecture Development Model (ADM) to guide architecture creation.

• Questions TOGAF Addresses:
    - How are business goals linked to IT systems?
    - What data does the organization require?
    - Which applications are needed to support business functions?
    - What is the technological infrastructure required?

• Scope of TOGAF:
    - TOGAF goes beyond just technical components; it ensures all organizational systems integrate logically.

High-Level Components in TOGAF

1. Business Model:
      - Definition of the overarching business strategy, organizational structure, and governance.

2. Data Structure:
      - High-level organization of the organization’s data management.

3. Application Interaction:
      - Overview of application interactions within the organization.

4. Technology Configuration:
      - High-level decisions on technology for software development and operation, supporting business, data, and application architectures.

Data Architecture

• Definition (TOGAF):
    - Data architecture “describes the structure of an organization’s logical and physical data assets and data management resources.”

• Data Governance:
    - Involves ensuring data quality, ownership, consistency, and security.

Elements of Organizational Data Architecture

Data Types

• Structured Data:
    - Characteristics:
      - Stored in relational databases, organized in tables, easily searchable and queryable.
    - Examples:
      - Customer records, product inventory, sales transactions, employee data.

• Unstructured Data:
    - Characteristics:
      - Does not follow a fixed structure; often stored in data lakes.
    - Examples:
      - Emails, images (e.g., product photos), videos (e.g., security footage), PDFs, text documents, social media posts (e.g., customer reviews).

Application Architecture

• Definition (TOGAF):
    - Application architecture is described as “a description of the structure and interaction of the applications as groups of capabilities that provide key business functions and manage the data assets.”

• Components Defined By:
    1. Application Groups:
       - Breaks down an enterprise system into modules or capabilities.
    2. Interactions:
       - Through data interfaces for data exchange or direct access/ modification capabilities.
    3. Business Process Relationships:
       - Identifies application support for specific business processes.

Application Architecture Diagram

• Overview: Figure 13-9
    - Illustrates the application architecture showing interdependencies, application interactions, and functionalities.

Developments in Software Architecture

Types of Architectures

1. Monolithic Architecture:
      - A single, unified software application.

2. Service-Oriented Architecture:
      - Involves services interacting over a network.

3. Microservices Architecture:
      - Breaks down applications into smaller, independent services.

TIME Matrix for Managing Application Portfolio

• Overview: Figure 13-11
    - The TIME matrix helps to classify applications based on their lifecycle stage and strategic alignment.

Technology Architectural Components

• Basic Functions of Software Components:
    1. Data Storage:
       - Essential for data retrieval, whether in small files or large databases.
    2. Data Access Logic:
       - Processing to access data, such as database queries.
    3. Application Logic:
       - Detailed in Data Flow Diagrams (DFDs) and functional requirements.
    4. Presentation Logic:
       - User interface and information display.

• **Key Hardware Components: **
    - Client Computers:
      - Input-output devices such as desktops, smartphones, tablets.
    - Servers:
      - Larger multi-user computers for software and data storage.
    - Network:
      - Connectivity technology like high-speed fiber Internet.

Client-Server Architectures

General Overview

• Characteristics:
    - Responsibilities are divided between clients and servers.
    - Clients handle presentation logic, while servers manage data storage and access logic.
    - Application logic may reside on client, server, or both.

Types of Client-Server Architectures

1. Two-Tiered Architecture:
      - Client holds presentation and application logic; server holds data access logic and storage.
      - Thick Client: Most application logic on the client.
      - Thin Client: Minimal application logic, shifted to the server.

2. Three-Tiered Architecture:
      - Introduces specialized application and database servers.
      - Client handles presentation; application server incorporates business logic; database server handles data access and storage.

3. N-Tiered Architecture:
      - Further divides the application layers; common in web-based services.
      - Offers the advantage of load balancing across multiple specialized servers.

Benefits of Client-Server Architectures

• Scalability:
    - Easily adjust storage and processing capabilities.

• Middleware:
    - Facilitates communication between differing operating systems and software.

• Reliability:
    - If a server fails, only dependent applications are affected, making maintenance manageable.

Limitations of Client-Server Architectures

• Complexity:
    - More parts to manage versus traditional systems.

• Update Challenges:
    - Requires simultaneous updates across clients and servers.

• Cost Increases:
    - Each server requires ongoing storage and maintenance.

Mobile Application Architectures

• Considerations:
    - Balance presentation, business, and data access logic between mobile devices and servers.
    - Types:
      1. Rich Client:
         - Local processing using mobile device resources, stores all logic on the mobile device.
      2. Thin Web-Based Client:
         - Relies on server processing; few local resources required.
      3. Rich Internet Application (RIA):
         - Requires a rich UI and minimal local processing.

Cloud Computing Architecture

• Definition of Cloud:
    - A combination of hardware, networks, storage, services, and interfaces providing computing as a service via the Internet.

• Deployment Options:
    1. Public Cloud:
       - Shared resources owned/managed by a provider.
    2. Private Cloud:
       - Exclusive resources for a single organization.
    3. Hybrid Cloud:
       - Combination of on-premise and public cloud resources.

Types of Cloud Services

1. Software as a Service (SaaS):
      - Client application maintained/updated by the vendor (e.g., Microsoft 365).
     - Users control the presentation layer and application configurations.

2. Platform as a Service (PaaS):
      - Software stack provided for users to create their own software while the provider manages backend needs.

3. Infrastructure as a Service (IaaS):
      - Maintenance of servers, networking, and storage managed by the provider; users manage applications and data.

Benefits of Cloud Computing

• Elasticity:
    - Scale resources based on demand (e.g., increasing resources during peak usage).

• Standardized APIs:
    - Simplifies communication between programs and data sources.

• Pay-as-you-go Pricing:
    - Organizations only pay for the resources used.

Architectural Decision Factors

• Selection Starts with Nonfunctional Requirements:
    - Detailed requirements refine the system architecture choice.

• Types of Nonfunctional Requirements:
    1. Operational Requirements:
       - Specifies the system's operational environment, hardware, and software needs.
    2. Performance Requirements:
       - Focuses on system speed, capacity, reliability, and availability.
    3. Security Requirements:
       - Protects against data loss and disruption.
    4. Cultural and Political Requirements:
       - Pertains to country-specific requirements, including multilingual needs and legal constraints.

From Requirements to Architecture

• Business Requirements Impact:
    - Often dictate the technical environment and influence architecture choices.
    - Trade-offs may be necessary due to conflicting nonfunctional requirements (e.g., speed vs security checks).

Project Tasks

1. Identify System Type:
      - Based on business/stakeholder requirements, determine if the application is standalone, web-based, or a mobile app.

2. Model Architecture Components:
      - Create a visual model of system architecture components (client, databases, servers, APIs, security).

3. Group Nonfunctional Requirements:
      - Categorize identified requirements and discuss implications for architecture choices.

Conclusion

• Reminder for Task Submission:
     - Task plan for the final report due by Friday, March 13 (submissions accepted until March 15).

Quiz Information

• Quiz Structure:
     - 4 questions, 4 minutes.
     - Password: client

• Content Focus:
     - Understanding of architecture types, requirements, and technical roles in system design.