$30 off During Our Annual Pro Sale. View Details »

Solution Architecture

Solution Architecture

To Build Cloud Native Apps
Using Composable Enterprise Architecture

System Context Diagram (DFD L0),
Data Flow Diagrams L0, L1, L2
4+1 Model of Architecture
ISO/IEC/IEEE 42010:2011 / 42010:2022
Views, Viewpoints, Perspectives

To Manage
SpecOps: From Specs to Ops

1. Business Requirements
2. End-user Requirements
3. Infrastructure Requirements
4. Project Timelines
5. Global Teams
6. Global Compliance
7. Technology Selection
8. Solution Implementation
9. Solution Maintenance

Araf Karsh Hamid

March 18, 2023
Tweet

More Decks by Araf Karsh Hamid

Other Decks in Technology

Transcript

  1. @arafkarsh arafkarsh
    8 Years
    Network &
    Security
    6+ Years
    Microservices
    Blockchain
    8 Years
    Cloud
    Computing
    8 Years
    Distributed
    Computing
    Architecting
    & Building Apps
    a tech presentorial
    Combination of
    presentation & tutorial
    ARAF KARSH HAMID
    Co-Founder / CTO
    MetaMagic Global Inc., NJ, USA
    @arafkarsh
    arafkarsh
    1
    Solutions
    Architecture
    To Build Cloud Native Apps
    Using Composable Enterprise Architecture
    To Manage
    SpecOps: From Specs to Ops
    Introduction to 15 Part Series

    View Slide

  2. @arafkarsh arafkarsh
    BPB
    Building Cloud
    Native Apps
    2

    View Slide

  3. @arafkarsh arafkarsh
    Topics
    3
    1. Understanding the Context
    2. Software Architecture
    3. Case Study: Viewpoints & Views
    4. Case Study: Perspectives
    5. Solutions Architect

    View Slide

  4. @arafkarsh arafkarsh
    Understanding the Context
    • From Specs to Ops
    • Application Modernization
    • Enterprise Architecture
    • Solutions Architect
    • What Architect Need to do?
    4
    1

    View Slide

  5. @arafkarsh arafkarsh
    Management
    Pipeline Automation
    Architecture
    SpecOps Workflow - SDLC
    5
    Green
    Field
    Brown
    Field
    Domain Driven Design
    Event Sourcing / CQRS
    Migration Patterns
    Strangler Fig, CDC…
    Build
    Design Develop Test Stage Ops
    Cloud
    • Fault Tolerance
    • Reliability
    • Scalability
    • Traffic Routing
    • Security
    • Policies
    • Observability
    • Unit Testing
    • Component
    • Integration
    • Contract
    • Package
    Repositories
    • Mvn, npm,
    docker hub
    • Infrastructure
    • Containers
    • Orchestration
    • Serverless
    • Traffic Routing
    • Security (mTLS, JWT)
    • Policies (Network / Security
    • Observability
    Infra Code
    • Feature
    Code
    • Configs
    Source Code
    Specs

    View Slide

  6. @arafkarsh arafkarsh
    Modernization Journey towards Cloud Native Apps
    6
    Source:
    Page 16
    US DoD Enterprise
    DevSecOps 2.0
    Fundamentals

    View Slide

  7. @arafkarsh arafkarsh
    Enterprise Architecture
    7
    Business Architecture:
    Describes the organization's
    business processes, functions,
    and capabilities.
    Data Architecture:
    Describes the organization's
    data structures, data flows,
    and data storage.
    Application Architecture:
    Describes the organization's software
    applications and their
    interconnections.
    Technology Architecture:
    Describes the organization's
    software applications and
    their interconnections.
    Security Architecture:
    Describes the organization's
    security policies, procedures,
    and controls.
    The benefits of EA include:
    1. Improved alignment between business and technology.
    2. Increased efficiency and effectiveness of business processes.
    3. Reduced complexity and cost of technology infrastructure.
    4. Better management of technology risks.
    5. Increased agility and ability to respond to changing business
    needs.

    View Slide

  8. @arafkarsh arafkarsh
    Solutions Architecture
    8
    High-Level Blueprint of a System that defines
    Structure
    of its components.
    Behaviour Relationship
    It describes how the system will be
    Designed Developed Deployed
    It may include specifications for
    Hardware /
    Software
    Data Security Ops

    View Slide

  9. @arafkarsh arafkarsh 9
    Solutions
    Architecture
    Global
    Teams
    5
    Global
    Compliance
    6
    Business
    Requirements
    End User
    Requirements
    Infrastructure
    Requirements
    Budget
    Project
    Timelines
    1. Non-Functional
    2. Functional
    1
    2
    3
    4
    0 Technology
    Selection
    Solution
    Implementation
    Solution
    Maintenance
    7
    8
    9

    View Slide

  10. @arafkarsh arafkarsh 10
    Role
    A software architect should be
    responsible for making high-level
    design choices, defining technical
    standards, and guiding the overall
    software architecture.
    Technical
    Expertise
    Ensure that the software architect
    has a strong technical background,
    with deep knowledge of software
    engineering principles, design
    patterns, and best practices
    Leadership &
    Communication
    A software architect should have strong
    leadership and communication skills. They
    should be able to work closely with various
    stakeholders, including project managers,
    developers, and clients, to clearly communicate
    architectural decisions and their rationale. Collaboration
    The software architect
    should be open to
    receiving input from
    others, while also
    proactively sharing their
    knowledge and expertise.
    Adaptability
    A good software architect should be
    adaptable and open to change, recognizing
    that requirements and technologies may
    evolve over time. They should be able to
    reassess and update the architecture as
    needed.
    Continuous
    Learning
    A software architect
    should stay up-to-date
    with the latest trends,
    technologies, and best
    practices in the software
    industry.
    To Summarize… What Architect need to do?

    View Slide

  11. @arafkarsh arafkarsh
    Software Architecture
    • System Context Design, Data Flow Diagram Level 0,1,2 Diagrams
    • 4+1 Architecture View of Software
    • ISO/IEC/IEEE 42010:2011 & 42010:2022
    • View, Viewpoints & Perspectives
    • Non-Functional Requirements
    11
    2

    View Slide

  12. @arafkarsh arafkarsh
    From Object Modeling to Process Modeling
    12
    Developers with Strong Object
    Modelling will experience
    a big Mind Shift to
    transition to Process based
    modelling with Events.
    The Key is:
    1. App User’s Journey
    2. Business Process
    3. Ubiquitous Language – DDD
    4. Capability Centric Design
    5. Outcome Oriented The Best tool to define your process and its tasks.
    How do you define your End User’s Journey & Business Process?
    • Think It
    • Build It
    • Run IT

    View Slide

  13. @arafkarsh arafkarsh
    Business Solution & Business Process
    13
    q Business Solution focuses on the entire Journey of the
    User, which can run across multiple Microservices.
    q Business Solution comprises a set of Business
    Processes.
    q A specific Microservice functionality will be focused
    on a Business Process / Concern.
    q Business Processes can be divided further into
    Business Functions.

    View Slide

  14. @arafkarsh arafkarsh
    Case Study: Healthcare App
    14
    Theme / Initiative Epic User Story Sprint
    Healthcare / We Care
    1. Patient
    2. Healthcare Staff
    3. Appointments
    4. Diagnosis
    5. Lab
    6. Pharmacy
    7. Auth
    4. Diagnosis
    Release 1
    1. Pre-Checkup
    2. Search Medical
    History
    3. Diagnosis &
    Prescription
    Release 2
    1. Prescribe for Lab
    Tests
    Stories
    1. Pre-Checkup
    2. Search Medical
    History
    3. Diagnosis &
    Prescription
    4. Prescribe for Lab
    Tests

    View Slide

  15. @arafkarsh arafkarsh
    User Journey with Story Map & Release Cycles
    15
    1. Register 3. Make Appointment 4. Diagnosis & Prescription 6. Get Medicine
    5. Lab Tests
    Health Staff Appointment Pharmacy
    Lab
    Diagnosis
    2. Search & Select Doctor
    Patient
    User Journey
    Minimum Viable Product
    Upload Medical
    Docs
    Add Doctor / Nurse Cancel
    Appointment
    R2 Lab Tests
    View Medical
    History
    Duty Calendar
    R3 Reschedule
    Register Search Doctor
    Available Dates
    Book Appointment Medical History
    Check
    Verify
    Prescription
    Pack
    Medicines
    R1
    Pre-Checkup
    Diagnosis &
    Prescription
    Appointment
    Upload
    Results
    Schedule Duty Time
    Make
    Payment
    Share Medical
    Docs
    R4 Appointment
    Calendar
    Make
    Payment
    View
    Appointments
    Email
    SMS

    View Slide

  16. @arafkarsh arafkarsh
    System Context Diagrams
    Data Flow Diagrams
    • Data Flow Diagrams L0, L1, L2 Diagrams
    • Compare Data Flow Diagrams and Flow Charts
    16

    View Slide

  17. @arafkarsh arafkarsh
    Components of Data Flow Diagram
    17
    Entity
    Process
    Output
    Data Store
    External Entity
    Process
    Output
    Data Flow
    Data Store
    • A Data Flow Diagram (DFD) is a
    visual representation that
    illustrates the data flow within a
    system.
    • It depicts how data enters, leaves,
    and is stored within the system.
    • A DFD provides a comprehensive
    description of the data flow
    throughout the system.
    • DFD was highlighted in the book
    “Structured Design” by Ed Yourdon and
    Larry Constantine in the 1970s

    View Slide

  18. @arafkarsh arafkarsh
    5 Main methods of Notations used in DFD
    18
    External
    Entity
    Process
    Store
    Data Flow
    Yourdon +
    De Marco
    SSADM
    Chris Gane &
    Trish Sarson
    <>
    Unified
    <>
    Duplicate
    Entity
    Entity
    1 3
    2 4 5
    Structured Systems
    Analysis and Design
    Method, UK 1980
    Structured Design
    Mid-1970s
    Late1970s
    Mid-1990s. UML
    doesn’t have DFD. It
    has Activity Diagrams

    View Slide

  19. @arafkarsh arafkarsh
    Levels of Data Flow Diagram
    19
    0-level DFD / System Context Design:
    It represents the entire system as a single bubble and
    provides an overall picture of the system.
    0
    Business
    Solution
    1-level DFD:
    It represents the main Processes of the system and
    how they interact with each other.
    1
    Business
    Process
    2-level DFD:
    It represents the sub-processes within each Main
    Process of the system and how they interact with
    each other.
    2
    Business
    Function

    View Slide

  20. @arafkarsh arafkarsh
    Data Flow Diagram – Rules
    20
    Entity 1
    Patient
    Entity 2
    Doctor
    Data can not flow between two Entities.
    • Data flow must be between Entity and Process or Process & Entity.
    • Multiple Data flows are allowed between Entity and Process.
    Patient DB Diagnosis DB
    Data can not flow between two Data Stores.
    • Data flow must be between Process & Data Stores or Vice versa.
    • Data can flow from 1 Data Store to multiple Processes.
    Patient DB
    Data can not flow directly from Entity to Data Stores.
    • A Process must process Data Flow from an Entity before going to
    the Data Store and vice versa.
    Entity 1
    Patient
    Diagnosis
    Process
    In Out
    A Process must have at least 1 input and 1 output data flow.
    • Every process must have input data flow to process the data and
    an output data flow for the processed data.

    View Slide

  21. @arafkarsh arafkarsh
    Data Flow Diagram Rules
    21
    In Out
    A Data Store must have at least 1 input and 1 output data flow.
    • Every Data Store must have input data flow to Store the data and
    an output data flow for the Retrieved data.
    Diagnosis DB
    Diagnosis
    Process
    A Process must be linked to at least 1 Data Store
    • All the Processes in the system must be linked to at least 1 data
    store.
    Diagnosis DB
    Two Data Flows can not cross each other.

    View Slide

  22. @arafkarsh arafkarsh
    How to create a System Context Diagram
    22
    Step 1: Establish the initial boundary by identifying the product or project you want
    to contextualize and placing it in a circle at the center of your diagram. Also, identify
    the roles and processes that should go inside this boundary.
    Step 2: Identify all external Entities or Agents and list them around your initial
    boundary. Place entities with similar functions close to each other.
    Step 3: Determine data flows by ascertaining what data, services, or processes each
    external entity can expect from the main product and vice versa. Assign a data flow
    to each external entity until all have been accounted for.
    Step 4: Complete your context diagram by reviewing it and verifying the accuracy of
    each element. Delete any external entities that have no interactions with your
    product, correct any misplaced entities within the project’s scope, and ensure no
    missing agents or flows.

    View Slide

  23. @arafkarsh arafkarsh
    System Context Diagram / Data Flow Diagram – L0
    23
    • System Context
    Diagram or Level 0.
    • An abstraction view
    • Shows the system as a
    single process with its
    relationship to external
    entities.
    • It represents the entire
    system as a single
    bubble with input and
    output data indicated
    by incoming/outgoing
    arrows.

    View Slide

  24. @arafkarsh arafkarsh
    Data Flow Diagram – L1
    24
    • The L0 Context
    diagram is
    decomposed into
    multiple bubbles /
    processes.
    • Highlight the
    system's primary
    functions and
    • Break down the
    high-level process of
    0-level DFD into
    subprocesses.

    View Slide

  25. @arafkarsh arafkarsh
    Data Flow Diagram – L2
    25
    • The L1 Data Flow
    Diagram is
    decomposed into
    multiple bubbles /
    processes.
    • Highlights the
    details of that
    Specific Business
    Process.
    • It also shows the
    data stores
    associated with that
    Sub Process.

    View Slide

  26. @arafkarsh arafkarsh
    Drawbacks of Data Flow Diagrams
    26
    1. Limited to Data Flow: DFDs are primarily focused on the data flow within a system and may not
    capture other aspects of the system, such as user interfaces or hardware components.
    2. May Oversimplify the System: DFDs may oversimplify the system by focusing only on the data
    flow and ignoring other important aspects of the system. This can lead to an incomplete
    understanding of the system and its functions.
    3. May Not Be Able to Represent Complex Systems: DFDs may be unable to represent complex
    systems with many processes and data effectively flowing. This can lead to a confusing or
    cluttered diagram.
    4. May Not Account for Error Handling or Exceptions: DFDs may not account for error handling or
    exceptions in the system. This can lead to a diagram that does not accurately represent the
    system’s actual behavior.
    5. May Not Capture the Dynamic Nature of the System: DFDs may not be able to capture the
    dynamic nature of the system, where processes and data flows can change over time. This can
    lead to an outdated or inaccurate diagram as the system evolves.
    6. May Not Be Useful for Implementation: DFDs may not be useful for implementation, as they
    may not capture the necessary details required for actual implementation of the system.

    View Slide

  27. @arafkarsh arafkarsh
    Benefits of Data Flow Diagrams
    27
    1. Clarifying System Boundaries: SCDs provide a clear and concise view of the system and its interactions with
    external entities. It helps stakeholders understand the scope and boundaries of the system and identify areas
    for improvement or further development.
    2. Effective Communication: SCDs visually represent the system and its relationships with external entities. It
    helps stakeholders communicate and collaborate effectively by providing a shared understanding of the
    system and its components.
    3. Identifying Dependencies and Interactions: SCDs help identify the dependencies and interactions between
    the system and external entities. It helps stakeholders understand the impact of external factors on the
    system and vice versa.
    4. Easy to Understand: SCDs are easy to understand and interpret, even for non-technical stakeholders. It helps
    stakeholders from different backgrounds and disciplines to have a common understanding of the system.
    5. Saves Time and Effort: SCDs can save time and effort in the system development process by providing a
    starting point for more detailed analysis and design activities. It helps to identify areas that require further
    investigation and those that can be ignored.
    6. Reduced Complexity: SCDs simplify complex systems by breaking them into manageable components. It
    helps stakeholders understand the system's complexity and identify areas for simplification.

    View Slide

  28. @arafkarsh arafkarsh
    Best Practices
    28
    1. Start with a context diagram: Begin by creating a context diagram that shows the system as a
    single process and all external entities that interact with it.
    2. Use consistent naming conventions: Use consistent naming conventions for all processes, data
    flows, data stores, and external entities. This helps to ensure that everyone who reads the
    diagram can understand it.
    3. Avoid crossing data flow lines: Do not cross data flow lines in a DFD, as this can make it
    challenging to understand the data flow.
    4. Keep it simple: DFDs should be simple and easy to understand. Avoid overcomplicating the
    diagram by including unnecessary detail or information.
    5. Group related processes together: Group related processes in the diagram to make
    understanding the relationships between them more manageable.
    6. Include clear labels and annotations: Include clear labels and annotations in the DFD to help
    readers understand the different components and their relationships.
    7. Verify the diagram's accuracy: Verify the DFD’s accuracy by reviewing it with stakeholders,
    comparing it to other system documentation, and testing it against real-world scenarios.

    View Slide

  29. @arafkarsh arafkarsh
    Software Architecture
    4+1 Architecture View Model
    ISO/IEC/IEEE 42010:2011 & 2022
    Views, Viewpoints & Perspectives
    29

    View Slide

  30. @arafkarsh arafkarsh
    4+1 Architecture View Model in Software
    30
    Logical View
    Process View
    Development View
    Physical View
    Use Cases
    Software
    Philippe Kruchten:
    Inventor of the
    4+1 Architectural View Model
    Class & State Diagrams
    Systems
    Functionality
    Systems Runtime
    Behavior
    Sequence, Communication, Activity
    Component Diagram
    Developers
    Perspective
    Deployment Diagram
    Implementation View
    Deployment View
    System Engineers
    Perspective
    Use Case Diagram
    Product Owner Perspective
    IEEE, November 1995
    Architectural Blueprints – The 4+1 View
    Model of Software Architecture

    View Slide

  31. @arafkarsh arafkarsh
    4+1 Architecture View Model in Software
    31
    View Logical Process Development Physical Scenarios
    Components Class Task Module
    Subsystem
    Node Step
    Scripts
    Connectors Association
    Inheritance
    Containment
    Rendezvous
    Message
    Broadcast
    RPC, etc.
    Dependencies LAN
    WAN
    Bus
    Containers Class Category Process Subsystem
    (Library)
    Physical
    Subsystem
    Web
    Stakeholders End-User System Designer,
    Integrator
    Developer
    Manager
    System
    Engineer
    Product Owner
    End User
    Developer
    Concerns Functionality Behavior
    Performance
    Availability
    Fault Tolerance
    Organization Scalability
    Performance
    Availability
    Fault Tolerance
    Understand-ability
    UML Diagrams Class & State Sequence
    Communication
    Activity
    Component Deployment Use Case
    IEEE, November 1995: Architectural Blueprints – The 4+1 View Model of Software Architecture

    View Slide

  32. @arafkarsh arafkarsh
    32
    ISO/IEC/IEEE
    42010-2011
    Standard
    Source: https://www.iso.org/standard/50508.html
    Only for Architecture Descriptions of
    Software & Systems

    View Slide

  33. @arafkarsh arafkarsh
    ISO/IEC/IEEE 42010-2011 Standard
    33
    1. Architecture: The fundamental organization of a system, its
    components, relationships, and the principles governing its design and
    evolution.
    2. Architecture Description (AD): A collection of artifacts that documents
    an architecture, including its rationale, decisions, and constraints.
    3. Stakeholder: Stakeholders are individuals, groups, or organizations
    holding Concerns for the System of Interest. Ex., client, owner, user,
    consumer, supplier, designer, maintainer, auditor, CEO, certification
    authority, and architect.
    4. Concern: Examples of concerns are (system) purpose, functionality,
    structure, behavior, cost, supportability, safety, and interoperability.
    Source: https://www.iso.org/standard/50508.html

    View Slide

  34. @arafkarsh arafkarsh
    ISO/IEC/IEEE 42010-2011 Standard
    34
    5. Architecture Viewpoint: A perspective from which the system's architecture is
    considered, addressing a specific set of stakeholder concerns.
    6. Architecture View: A representation of a system from the perspective of a
    specific viewpoint applied to a particular system.
    7. Architecture Model: A Collection of Model Kinds that represents the
    Architecture of the system OR any other representations; for Ex, a textual
    description of the system’s architecture could also serve as an Architecture
    Model, outlining the key components and their interactions in a narrative
    format.
    8. Model Kind: It represents a specific UML Diagram like a Component diagram,
    Sequence diagram, Activity diagram, etc., OR ER Diagrams, DFD – Data Flow
    Diagrams, BPMN – Business Process Model Annotation.
    Source: https://www.iso.org/standard/50508.html

    View Slide

  35. @arafkarsh arafkarsh
    ISO/IEC/IEEE 42010-2011 Standard
    35
    9. Architecture Rationale refers to the reasoning, justification, and decision-
    making process behind the design choices in a system's architecture. It captures
    the trade-offs, constraints, assumptions, and stakeholder concerns influencing
    the architectural decision.
    Ex. Choice of a specific NoSQL database to handle variety in data or velocity.
    10. Correspondence Rule is a relationship that connects elements in different
    Architecture Models or between Architecture Models and other artifacts in the
    architecture description, for Ex.
    In a web application, an Architecture Model may depict functional
    requirements with a UML Use Case Diagram and other display system
    components using a UML Component Diagram. Correspondence Rules link use
    cases to corresponding components, ensuring traceability and consistency
    between requirements and system structure.
    Source: https://www.iso.org/standard/50508.html

    View Slide

  36. @arafkarsh arafkarsh
    ISO/IEC/IEEE 42010-2011 Standard
    36
    11. Correspondence: Correspondence embodies Correspondence Rules in
    architecture descriptions, representing relationships between elements in
    different Architecture Models or artifacts. It maintains consistency,
    traceability, and coherence, helping stakeholders understand and analyze
    various aspects of the system.
    Ex. The Correspondence would be the actual links or mappings between the
    use cases in the functional requirements model and the components in the
    system structure model, as established by the Correspondence Rule.
    Source: https://www.iso.org/standard/50508.html

    View Slide

  37. @arafkarsh arafkarsh
    37
    ISO/IEC/IEEE
    42010-2022
    Standard
    Source: https://www.iso.org/standard/74393.html
    Only for Architecture Descriptions of any
    entity of interest, including software,
    systems, enterprises, systems of systems,
    families of systems, products (goods or
    services), product lines, service lines,
    technologies and business domains.

    View Slide

  38. @arafkarsh arafkarsh 38
    ISO/IEC/IEEE 42010-2022 Standard
    1. Entity of Interest: An entity of interest is a system, product, or service that is being
    architected. It is the object of the architecture description.
    2. Stakeholder Perspective: It is a point of view or way of thinking about an entity of
    interest. It is a way of framing the architecture description to focus on the concerns of a
    particular stakeholder group. Ex. Customer Perspective, Developer Perspective, Manager
    Perspective.
    3. Architecture Aspect is a particular concern or focus area of architecture. For example, an
    architectural aspect of an e-commerce application might be the user experience, the
    functional requirements, or the technical implementation. The Aspect will be reflected in
    an Architecture View.
    4. A View component is part of an architecture description focusing on a particular
    architectural aspect. For example, a view component for the user experience of an e-
    commerce application might be a use case diagram that shows how users can interact
    with the system.

    View Slide

  39. @arafkarsh arafkarsh
    ISO/IEC/IEEE 42010-2022 Standard
    39
    View Component (2022) Architecture Model (2011)
    1
    A view component is part of an
    Architecture Description (AD) focusing on a
    particular architectural aspect.
    An architecture model is a representation
    of the architecture of an entity of interest.
    2
    View components can be used to
    communicate the architecture of an Entity
    of Interest to specific stakeholders.
    Architecture models can be used to
    communicate the architecture of a System
    of Interest to all stakeholders.
    3
    View components can be used to focus on
    the concerns of particular stakeholders.
    Architecture models can be used to show
    the entire architecture of an entity of
    interest.
    4
    View components can be used to show
    how the different parts of the architecture
    fit together from a particular perspective.
    Architecture models can be used to show
    how the different parts of the architecture
    fit together.

    View Slide

  40. @arafkarsh arafkarsh
    ISO/IEC/IEEE 42010-2022 Standard
    40
    Architecture Aspect
    User Experience
    Functional
    Requirements
    Technical
    Implementation
    Security
    Performance
    Scalability
    Model Kind
    Structural Model
    Behavioral Model
    Functional Model
    Data Model
    Performance Model
    Security Model
    Architecture View Is reflected In
    Architecture
    Viewpoint
    Governs
    View Component
    Use Case Diagram
    Wireframe
    Class, State Diagram
    Activity Diagram
    Sequence Diagram
    Data Flow Diagram
    Governs

    View Slide

  41. @arafkarsh arafkarsh
    41
    ISO/IEC/IEEE
    42010-2011
    Standard
    ISO/IEC/IEEE
    42010-2022
    Standard

    View Slide

  42. @arafkarsh arafkarsh
    View
    42
    Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives. Pearson
    Education India.
    • A view represents all (or part of) an architecture—
    • A way to document its architecturally significant features according to a related
    set of concerns.
    • A view captures a description of one or more of the architectural structures of
    the system.
    • Architects use views to explain the system’s architectural structure to
    stakeholders and demonstrate that the architecture will meet their concerns.
    • A view comprises a set of tangible architectural products, such as principles and
    models; the complete set of architectural views forms the AD (Architectural
    Description).

    View Slide

  43. @arafkarsh arafkarsh
    Viewpoints
    43
    • It guides the process of creating a particular
    type of view.
    Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives.
    Pearson Education India.
    • Defines the concerns addressed by the view
    and the approach for creating and describing
    that aspect of the architecture.

    View Slide

  44. @arafkarsh arafkarsh
    Perspectives
    44
    Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives.
    Pearson Education India.
    • Guides the design process so that the system will exhibit one
    or more essential qualities.
    • Considered Comparable to a viewpoint but for a related set
    of quality properties rather than a type of architectural
    structure.
    • It results in changes to the architectural views (i.e., the
    system’s structures) rather than creating new structures. We
    also use perspectives to capture common problems and
    pitfalls and identify solutions.

    View Slide

  45. @arafkarsh arafkarsh
    45
    Viewpoints
    Functional
    Viewpoint
    Information
    Viewpoint
    Concurrency
    Viewpoint
    Development
    Viewpoint
    Deployment
    Viewpoint
    Operational
    Viewpoint
    Context Viewpoint
    Describes the relationships, dependencies, and interactions between the system and its environment
    (the people, systems, and external entities with which it interacts).
    Functional,
    Information,
    Concurrency
    Viewpoints
    characterize
    the
    fundamental
    organization of
    the system.
    The Development
    viewpoint exists
    to support the
    system’s
    construction.
    Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives. Pearson Education India.
    The Deployment
    & Operational
    viewpoints
    characterize the
    system once in
    its live
    environment.
    Use Case
    Diagram
    Class,
    ER
    Diagram
    Activity,
    Sequence
    Diagram
    Component
    Diagram
    Deployment
    Diagram
    System Context Diagram Level 0, 1
    Network
    Infrastructure
    Diagram

    View Slide

  46. @arafkarsh arafkarsh
    46
    Viewpoints are connected to Software Design
    Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives. Pearson Education India.

    View Slide

  47. @arafkarsh arafkarsh
    Most important Views for Typical Systems
    47
    Viewpoints OLTP
    Information
    System
    Calculation
    Service /
    Middleware
    DSS / MIS
    System
    High Volume
    Web Site
    Enterprise
    Package
    Context High Low High Medium Medium
    Functional High High Low High High
    Information Medium Low High Medium Medium
    Concurrency Low High Low Medium Varies
    Development High High Low High High
    Deployment High High High High High
    Operational Varies Low Medium Medium High
    Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives.
    Pearson Education India.

    View Slide

  48. @arafkarsh arafkarsh
    Architecture Perspectives
    48
    An architectural perspective is a
    • collection of architectural activities, tactics, and guidelines
    • used to ensure that a system exhibits a particular set of related quality
    properties
    • that require consideration across several of the system’s architectural
    views.
    Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives.
    Pearson Education India.
    The issues addressed by perspectives are often referred to as cross-
    cutting concerns or nonfunctional requirements of the architecture.

    View Slide

  49. @arafkarsh arafkarsh
    49
    Functional Viewpoint
    Information Viewpoint
    Concurrency Viewpoint
    Development Viewpoint
    Deployment Viewpoint
    Operational Viewpoint
    Context Viewpoint
    Security Perspective
    Performance Perspective
    Availability Perspective
    Usability Perspective
    Accessibility Perspective
    Location Perspective
    Regulation Perspective
    Evolution Perspective
    Internationalization Perspective

    View Slide

  50. @arafkarsh arafkarsh
    Architecture Perspectives
    50
    Viewpoints Security Performance &
    Scalability
    Availability &
    Resilience
    Evolution
    Context Medium Low Low Medium
    Functional Medium Medium Low High
    Information Medium Medium Low High
    Concurrency Low High Medium Medium
    Development Medium Low Low High
    Deployment High High High Low
    Operational Medium Low Medium Low
    Perspectives
    Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives.
    Pearson Education India.

    View Slide

  51. @arafkarsh arafkarsh
    Perspective Catalog
    51
    Perspective Desired Quality
    Accessibility The ability of the system to be used by people with disabilities.
    Availability &
    Resilience
    The ability of the system to be wholly or partly operational as and
    when required to handle failures that could affect system
    availability effectively.
    Evolution The ability of the system to be flexible in the face of the inevitable
    change that all systems experience after deployment is balanced
    against the costs of providing such flexibility.
    Inter-
    nationalization
    The ability of the system to be independent of any particular
    language, country, or cultural group.
    Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives.
    Pearson Education India.

    View Slide

  52. @arafkarsh arafkarsh
    Perspective Catalog
    52
    Perspective Desired Quality
    Location The ability of the system to overcome problems brought about by the
    absolute location of its elements and the distances between them
    Performance &
    Scalability
    The ability of the system to predictably execute within its mandated
    performance profile and to handle increased processing volumes in the future
    if required.
    Regulation The ability of the system to conform to local and international laws, quasi-
    legal regulations, company policies, and other rules and standards.
    Security The ability of the system to reliably control, monitor, and audit who can
    perform what actions on which resources and the ability to detect and
    recover from security breaches.
    Usability The ease with which people who interact with the system can work
    effectively.
    Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives.
    Pearson Education India.

    View Slide

  53. @arafkarsh arafkarsh
    Most Important Perspectives for a Typical System
    53
    Perspectives
    OLTP
    Information
    System
    Calculation
    Service /
    Middleware
    DSS / MIS
    System
    High Volume
    Web Site
    Enterprise
    Package
    Accessibility Varies Low High High High
    Availability &
    Resilience
    Varies High
    Medium
    High Medium
    Evolution Varies Low High Varies Medium
    Internationalizati
    on
    Varies Low Varies High Varies
    Location Varies Low Low High Varies
    Performance &
    Scalability
    Varies High Varies High Varies
    Regulation Varies Low Varies Varies Varies
    Security Varies Low Medium High High
    Usability Medium Low Low High Medium
    Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives.
    Pearson Education India.

    View Slide

  54. @arafkarsh arafkarsh
    54
    Source: Nick Rozanski. Software Systems Architecture: With
    Stakeholders Using Viewpoints and Perspectives.
    Pearson Education India.
    To Summarize…
    • Architectural Elements
    • Architecture
    • Architectural Description
    • Views
    • Viewpoints
    • Perspectives

    View Slide

  55. @arafkarsh arafkarsh
    55
    Source: Nick Rozanski. Software Systems Architecture: With
    Stakeholders Using Viewpoints and Perspectives.
    Pearson Education India.
    Architects
    Role

    View Slide

  56. @arafkarsh arafkarsh
    Viewpoints on Views
    1. Case study: eCommerce App
    2. Case Study: Healthcare App
    56
    3

    View Slide

  57. @arafkarsh arafkarsh
    Case Study: eCommerce App
    57
    1. Context 5. Development
    6. Deployment
    7. Operational
    2. Functional
    3. Information
    4. Concurrency

    View Slide

  58. @arafkarsh arafkarsh
    1. Context Viewpoint
    58
    Type Details
    Diagrams Used System Context Design – Level 0 (L0), Level 1 (L1)
    Stakeholders Business Owners, Developers, System Administrators, IT Support Staff, Software Architects
    The Context Viewpoint focuses on the relationships and interactions between the eCommerce system and its
    external entities. It helps stakeholders understand the system's boundaries and its place within the larger context.
    L0 System Context Diagram
    It provides a high-level overview of the eCommerce
    system and its external entities. The system is
    depicted as a single "black box" with no internal
    structure details.
    • Customers
    • Business Owners
    • Payment Gateway
    • Shipping Service
    • Inventory System
    L1 System Context Diagram
    Decomposes the eCommerce system into its primary
    components or subsystems, providing more detail about
    its architecture.
    Customer Service
    Product Service
    Cart Service
    Order Processing
    Payment Integration
    Shipping Integration

    View Slide

  59. @arafkarsh arafkarsh
    2. Functional Viewpoint
    59
    Type Details
    Diagrams Used Use Case Diagram, Story Maps
    Stakeholders Customers, Business Owners
    The Functional Viewpoint addresses the system’s functional requirements
    and services. The Use Case Diagram illustrates user interactions,
    • such as browsing products,
    • adding items to the cart,
    • managing user accounts,
    • and completing purchases.
    This viewpoint is essential for understanding the system's features and
    capabilities from an end-user perspective.

    View Slide

  60. @arafkarsh arafkarsh
    3. Information Viewpoint
    60
    Type Details
    Diagrams Used Class, Entity-Relationship (ER) Diagram
    Stakeholders Developers, Business Owner
    The Informational Viewpoint focuses on the organization, storage, and
    retrieval of data within the system. The ER Diagram depicts the
    relationships between entities like
    • products,
    • customers,
    • orders, and
    • categories.
    This viewpoint helps stakeholders understand how data is modeled,
    managed, and accessed in the eCommerce application.
    There is a big difference in Entity
    modeling when building Microservice
    based architecture.

    View Slide

  61. @arafkarsh arafkarsh
    4. Concurrency Viewpoint
    61
    Type Details
    Diagrams Used Sequence or Activity Diagram
    Stakeholders Developers, System Administrators
    Viewpoint addresses how the system manages multiple simultaneous user
    requests and handles concurrency-related aspects. The Sequence or Activity
    Diagram illustrates the flow of control and data between components involved
    in processing multiple user requests, such as the
    • frontend,
    • backend services, and
    • the database.
    This viewpoint helps stakeholders understand the system's ability to handle
    concurrent requests and potential bottlenecks or synchronization issues.

    View Slide

  62. @arafkarsh arafkarsh
    5. Development Viewpoint
    62
    Type Details
    Diagrams Used Component Diagram, Package Diagram
    Stakeholders Developers, Software Architects
    • The Development Viewpoint focuses on the system's organization into
    modules, components, dependencies, and interactions.
    • The Component Diagram or Package Diagram represents the structure of
    the software, showing how different components, such as the front end,
    backend services, and database, work together.
    • This viewpoint is crucial for developers and architects working on the
    system, as it helps them understand the codebase organization and
    component relationships.

    View Slide

  63. @arafkarsh arafkarsh
    6. Deployment Viewpoint
    63
    Type Details
    Diagrams Used Deployment Diagram
    Stakeholders System Administrators, IT Support Staff, DevOps
    (SRE) Engineers
    The Deployment Viewpoint addresses the system's deployment and
    runtime environment. The Deployment Diagram depicts the
    distribution of the application components across
    • servers, networks, and other infrastructure elements,
    • such as load balancers, firewalls, and storage devices.
    This viewpoint helps stakeholders understand how the system is
    deployed and operates in a production environment.

    View Slide

  64. @arafkarsh arafkarsh
    7. Operational Viewpoint: Infrastructure and Platform
    64
    Type Details
    Diagrams Used Network Topology Diagram, Infrastructure Diagram
    Stakeholders System Administrators, IT Support Staff, DevOps (SRE)
    Engineers
    • The Infrastructure and Platform View focuses on the system's underlying
    infrastructure, such as the hardware, operating systems, middleware, and
    third-party services that support the eCommerce application.
    • It represents the relationships between these elements, helping
    stakeholders understand the dependencies and requirements of the
    system and ensuring the necessary resources are available for its
    operation.

    View Slide

  65. @arafkarsh arafkarsh
    7. Operational Viewpoint: Monitoring & Management
    65
    Type Details
    Diagrams Used Dashboard Mockups, Graphs, Visualizations
    Stakeholders System Administrators, IT Support Staff, DevOps (SRE)
    Engineers
    • The Monitoring and Management View deals with the monitoring,
    management, and maintenance aspects of the system.
    • This view may include dashboard mockups, graphs, and other
    visualizations representing monitoring tools, performance metrics,
    log analysis, backup and recovery procedures, and other operational
    aspects. This viewpoint helps stakeholders understand how to keep
    the system healthy.

    View Slide

  66. @arafkarsh arafkarsh
    Case Study: Healthcare App
    66
    1. Context 5. Development
    6. Deployment
    7. Operational
    2. Functional
    3. Information
    4. Concurrency

    View Slide

  67. @arafkarsh arafkarsh
    1. Context Viewpoint
    67
    Type Details
    Diagrams Used System Context Design – Level 0 (L0), Level 1 (L1)
    Stakeholders Business Executives, Regulatory Authorities, End-Users
    This viewpoint shows how the healthcare app interacts with its environment. It illustrates relationships with
    external entities like healthcare providers, patients, and external systems.
    L0 System Context Diagram
    It provides a high-level overview of the Healthcare
    system and its external entities. The system is
    depicted as a single "black box" with no internal
    structure details.
    • Patient
    • Nurse
    • Doctor
    • Lab
    • Pharmacy
    L1 System Context Diagram
    Decomposes the Healthcare system into its primary
    components or subsystems, providing more detail about
    its architecture.
    Onboarding Process
    Appointment Process
    Diagnosis Process
    Lab Process
    Pharmacy Process

    View Slide

  68. @arafkarsh arafkarsh
    2. Functional Viewpoint
    68
    Type Details
    Diagrams Used Use Case Diagram, Story Maps
    Stakeholders Business Analysts, Development Team, User Experience Designers
    Focuses on the functionality provided by the healthcare app, breaking down the system into its main
    functionalities like Patient Management, Appointments, and Pharmacy Services.
    Actors
    1. Patient
    2. Healthcare Staff
    3. Pharmacy Staff
    4. Lab Technician
    5. Admin
    Use Cases
    1. Patient Registration (Onboarding)
    2. Book Appointment
    (Appointments/Schedules)
    3. View Medical Records (Patient)
    4. Diagnose Patient (Diagnosis)
    5. Prescribe Medication (Pharmacy)
    6. Request Lab Test (Lab Process)
    7. View Lab Results (Lab Process)
    8. Cancel Appointment
    (Appointments/Schedules)
    Use Case Diagram:
    • Actors would be shown as
    stick figures.
    • Use cases would be
    represented as ovals.
    • Lines connecting actors to use
    cases represent interactions.

    View Slide

  69. @arafkarsh arafkarsh
    3. Information Viewpoint
    69
    Type Details
    Diagrams Used Class, Entity-Relationship (ER) Diagram
    Stakeholders Database Administrators, Backend Developers, Compliance Officers
    Describes the information the app manages, such as patient records, appointment schedules, and lab results,
    and how these pieces of information relate to each other. The ER Diagram depicts the relationships between
    entities like:
    This viewpoint helps stakeholders understand how data is modeled, managed, and accessed in the
    Healthcare application.
    Entity Attributes
    Patient Patient_ID (Primary Key), Name, Birthdate, Gender, Contact
    Healthcare Staff Staff_ID (Primary Key), Name, Position, Department
    Pharmacy Pharmacy_ID (Primary Key), Name, Location
    Lab Lab_ID (Primary Key), Name, Location
    Appointment Appointment_ID (Primary Key), Patient_ID (Foreign Key), Staff_ID (Foreign Key), Date, Time,
    Status
    Diagnosis Diagnosis_ID (Primary Key), Patient_ID (Foreign Key), Staff_ID (Foreign Key), Details
    Lab Process LabProcess_ID (Primary Key), Lab_ID (Foreign Key), Diagnosis_ID (Foreign Key), Results
    Pharmacy Process PharmacyProcess_ID (Primary Key), Pharmacy_ID (Foreign Key), Diagnosis_ID (Foreign Key),
    Medication
    There is a big difference
    in Entity modeling when
    building Microservice
    based architecture.

    View Slide

  70. @arafkarsh arafkarsh
    4. Concurrency Viewpoint
    70
    Type Details
    Diagrams Used Sequence / State Transition / Activity Diagrams
    Stakeholders Developers, Quality Assurance, System Architects
    Viewpoint addresses how the system manages multiple simultaneous user
    requests and handles concurrency-related aspects. The Sequence or Activity
    Diagram illustrates the flow of control and data between components involved
    in processing multiple user requests, such as the
    • frontend,
    • backend services, and
    • the database.
    Deals with system states and transitions, focusing on how tasks are performed
    concurrently within the app, such as simultaneous access to patient records or
    appointment scheduling.

    View Slide

  71. @arafkarsh arafkarsh
    5. Development Viewpoint
    71
    Type Details
    Diagrams Used Component Diagram, Package Diagram
    Stakeholders Developers, Software Architects
    • The Development Viewpoint focuses on the system's organization into
    modules, components, dependencies, and interactions.
    • The Component Diagram or Package Diagram represents the structure of
    the software, showing how different components, such as the front end,
    backend services, and database, work together.
    • Offers a high-level view of how the app's software components are
    organized and how they interact, helpful in understanding the software
    engineering aspects.

    View Slide

  72. @arafkarsh arafkarsh
    6. Deployment Viewpoint
    72
    Type Details
    Diagrams Used Deployment Diagram
    Stakeholders System Administrators, IT Support Staff, DevOps (SRE)
    Engineers
    The Deployment Viewpoint outlines how the healthcare app’s
    components will be distributed across hardware and shows how these
    elements are connected. The Deployment Diagram depicts the
    distribution of the application components across
    • servers, networks, and other infrastructure elements,
    • such as load balancers, firewalls, and storage devices.
    This viewpoint helps stakeholders understand how the system is deployed
    and operates in a production environment.

    View Slide

  73. @arafkarsh arafkarsh
    7. Operational Viewpoint: Infrastructure and Platform
    73
    Type Details
    Diagrams Used Network Topology Diagram, Infrastructure Diagram
    Stakeholders System Administrators, IT Support Staff, DevOps (SRE)
    Engineers
    • The Infrastructure and Platform View focuses on the system's underlying
    infrastructure, such as the hardware, operating systems, middleware, and
    third-party services that support the eCommerce application.
    • It represents the relationships between these elements, helping
    stakeholders understand the dependencies and requirements of the
    system and ensuring the necessary resources are available for its
    operation.

    View Slide

  74. @arafkarsh arafkarsh
    7. Operational Viewpoint: Monitoring & Management
    74
    Type Details
    Diagrams Used Dashboard Mockups, Graphs, Visualizations
    Stakeholders System Administrators, IT Support Staff, DevOps (SRE)
    Engineers
    • The Monitoring and Management View deals with the monitoring,
    management, and maintenance aspects of the system.
    • This view may include dashboard mockups, graphs, and other
    visualizations representing monitoring tools, performance metrics,
    log analysis, backup and recovery procedures, and other operational
    aspects. This viewpoint helps stakeholders understand how to keep
    the system healthy.

    View Slide

  75. @arafkarsh arafkarsh
    Perspectives on Viewpoints
    Case Study: eCommerce App
    • Security
    • Performance
    • Availability
    75
    4
    • Usability
    • Accessibility
    • Evolution
    • Internationalization
    • Regulation
    • Location

    View Slide

  76. @arafkarsh arafkarsh
    1. Security Perspective
    76
    Viewpoint Perspectives
    1 Functional
    Ensure that the system supports secure user authentication,
    authorization, and access control mechanisms.
    2 Informational
    Ensure data protection through encryption, secure storage, and data
    integrity measures.
    3 Concurrency
    Address potential security vulnerabilities related to concurrent
    access and processing, such as race conditions or denial-of-service
    attacks.
    4 Development
    Incorporate secure coding practices, vulnerability scanning, and
    security testing throughout the development process.
    5 Deployment
    Implement secure network configurations, firewalls, and other
    security measures to protect the system's infrastructure.
    6 Operational
    Monitor and manage security incidents, perform regular security
    audits, and establish incident response procedures.

    View Slide

  77. @arafkarsh arafkarsh
    2. Performance Perspective
    77
    Viewpoint Perspectives
    1 Functional
    Optimize the performance of critical user interactions, such as browsing
    products or completing purchases.
    2 Informational
    Design efficient data structures, indexes, and queries to minimize latency
    and maximize throughput.
    3 Concurrency
    Implement efficient concurrency control mechanisms, such as caching or
    load balancing, to handle a high volume of user requests.
    4 Development
    Use performance profiling, benchmarking, and optimization techniques
    during the development process.
    5 Deployment
    Deploy the system on appropriately sized and configured hardware with
    sufficient resources to meet performance requirements.
    6 Operational
    Monitor and manage system performance, identifying bottlenecks and
    implementing performance improvement measures as needed.

    View Slide

  78. @arafkarsh arafkarsh
    3. Availability Perspective
    78
    Viewpoint Perspectives
    1 Functional
    Implement fault-tolerant features and graceful degradation mechanisms for
    critical user interactions.
    2 Informational
    Ensure data redundancy, backup, and recovery mechanisms are in place to
    protect against data loss and minimize downtime.
    3 Concurrency
    Implement measures to handle load spikes and prevent resource
    contention, ensuring the system remains responsive under varying loads.
    4 Development
    Incorporate resilience and fault-tolerance principles into the system's
    design and development process.
    5 Deployment
    Design a highly available infrastructure using techniques such as
    redundancy, replication, or failover, to minimize the impact of failures.
    6 Operational
    Establish monitoring, incident management, and maintenance procedures
    to quickly detect, diagnose, and recover from failures.

    View Slide

  79. @arafkarsh arafkarsh
    4. Usability Perspective
    79
    Viewpoint Perspectives
    1 Functional
    Design user interactions, such as browsing products
    or completing purchases, with user-friendly interfaces
    and workflows.
    2 Informational
    Organize and display information in a clear, concise,
    and easily understandable format.
    3 Development
    Incorporate user-centered design principles and user
    feedback into the development process.
    4 Operational
    Monitor and manage user feedback, and usability
    issues, and implement improvements as needed.

    View Slide

  80. @arafkarsh arafkarsh
    5. Accessibility Perspective
    80
    Viewpoint Perspectives
    1 Functional
    Implement accessible features, such as keyboard navigation,
    screen reader support, and alternative text for images.
    2 Informational
    Design information presentation to be easily perceivable and
    understandable by users with various abilities, such as using
    appropriate text sizes, contrasts, and clear language.
    3 Development
    Incorporate accessibility guidelines, such as the Web Content
    Accessibility Guidelines (WCAG), into the development
    process.
    4 Operational
    Monitor and manage accessibility issues, user feedback, and
    implement improvements to ensure ongoing accessibility.

    View Slide

  81. @arafkarsh arafkarsh
    6. Evolution Perspective
    81
    Viewpoint Perspectives
    1 Functional
    Design modular and extensible features that can accommodate new
    requirements or changes in user needs.
    2 Informational
    Design flexible data structures and storage mechanisms that can evolve as
    the system's information needs change.
    3 Concurrency
    Implement scalable concurrency mechanisms to support the system's
    growth and changing performance requirements.
    4 Development
    Adopt agile development practices, version control, and continuous
    integration and deployment to enable iterative development and evolution.
    5 Deployment
    Design a flexible and adaptable deployment architecture that can
    accommodate changes in infrastructure and technology.
    6 Operational
    Monitor and manage the system's evolution, including changes to
    requirements, technologies, and the environment, to ensure its ongoing
    relevance and effectiveness.

    View Slide

  82. @arafkarsh arafkarsh
    7. Internationalization Perspective
    82
    Viewpoint Perspectives
    1 Functional
    Implement support for multiple languages, currencies, and
    date/time formats in user interfaces and interactions.
    2 Informational
    Design data structures and storage mechanisms for
    international character sets, language-specific sorting, and
    searching rules.
    3 Development
    Incorporate internationalization frameworks and libraries into
    the development process to simplify localization and
    adaptation to different regions.
    4 Operational
    Monitor and manage the system's performance and user
    experience in different countries and languages, adapting as
    necessary.

    View Slide

  83. @arafkarsh arafkarsh
    8. Regulation Perspective
    83
    Viewpoint Perspectives
    1 Functional
    Implement features that address regulatory requirements,
    such as privacy controls, data protection, and age restrictions.
    2 Informational
    Design data handling and storage mechanisms that comply
    with data protection regulations, such as GDPR (General Data
    Protection Regulation) or CCPA (California Consumer
    Protection Act).
    3 Development
    Ensure the system's infrastructure and third-party services
    adhere to relevant regulations and standards.
    4 Operational
    Establish processes for monitoring and managing regulatory
    compliance, including audits, risk assessments, and incident
    management.

    View Slide

  84. @arafkarsh arafkarsh
    9. Location Perspective
    84
    Viewpoint Perspectives
    1 Functional
    Design user interactions that account for varying network
    conditions, such as latency or bandwidth limitations, to ensure
    a responsive user experience.
    2 Concurrency
    Implement load balancing, caching, and content delivery
    mechanisms that optimize the system's performance in
    different locations.
    3 Deployment
    Deploy the system's infrastructure and services in
    geographically distributed data centers or cloud regions to
    minimize latency and improve user experience.
    4 Operational
    Monitor and manage the system's performance and user
    experience in different locations, adjusting infrastructure and
    configurations to optimize performance.

    View Slide

  85. @arafkarsh arafkarsh
    Solutions Architect
    1. Business Requirements
    2. End User Requirements
    3. Infra Requirements
    85
    5
    4. Project Timelines
    5. Global Teams
    6. Global Compliance
    7. Technology Selection
    8. Solution Implementation
    9. Solution Maintenance

    View Slide

  86. @arafkarsh arafkarsh 86
    Solutions
    Architecture
    Global
    Teams
    5
    Global
    Compliance
    6
    Business
    Requirements
    End User
    Requirements
    Infrastructure
    Requirements
    Budget
    Project
    Timelines
    1. Non-Functional
    2. Functional
    1
    2
    3
    4
    0 Technology
    Selection
    Solution
    Implementation
    Solution
    Maintenance
    7
    8
    9

    View Slide

  87. @arafkarsh arafkarsh 87
    1 2 3 4 5 6 7 8 9
    Let us dive into these sections

    View Slide

  88. @arafkarsh arafkarsh
    Requirements
    o Non-Functional Requirements
    o Functional Requirements
    88
    1 2

    View Slide

  89. @arafkarsh arafkarsh
    Non-Functional Requirements
    89
    Disaster
    Recovery
    Business
    Continuity
    Security &
    Compliances
    Application
    Performance
    Load &
    Scalability
    High
    Availability
    1

    View Slide

  90. @arafkarsh arafkarsh
    Functional Requirements – Epics / Stories
    90
    Theme / Initiative Epic User Story Sprint
    ShopEasy – eCommerce Application
    1. Customer Management
    2. Search Product
    3. Catalogue
    4. Shopping Cart
    5. Order Processing
    6. Payments
    2. Search Product
    Release 1
    1. Global Search
    Release 2
    1. Search by Brand
    2. Search by Price
    Range
    Release 3
    1. Search by Model
    2. Search by Rating
    Stories
    1. Global Search
    2. Search by Brand
    3. Search by Price
    Range
    4. Search by Model
    5. Search by Rating
    1

    View Slide

  91. @arafkarsh arafkarsh
    Functional Requirements: User Story
    91
    Role-Feature-Reason Matrix
    Story Card
    These three elements
    (WHO, WHAT, WHY)
    are the building blocks
    of User stories.
    Element Example
    Role WHO: As an e-Commerce Retailer
    Feature WHAT:
    I want to know who my Gold
    Customers are
    Reason WHY: So that I sell more
    Element Definition
    WHO:
    Establishes the user or users or another
    service.
    WHAT:
    Describes the Activity – Key Axis of the
    Story. What the user does in the story.
    WHY: This describes the purpose of the story.
    Source: User Story A Pragmatic View, Page 9. Published 0ct 19, 2019
    User stories are NOT
    1. IEEE 830 Software Specs
    2. Use Cases
    Use Cases are a combination of User
    Story and Acceptance Criteria
    3. Scenarios
    1

    View Slide

  92. @arafkarsh arafkarsh
    Functional Requirement: Acceptance Criteria / BDD
    92
    Source: https://dannorth.net/introducing-bdd/
    Given Customer John Doe exists
    When he buys products ABC for $1000 USD
    Then He becomes a Gold Customer
    BDD Construct
    Acceptance Criteria
    The definition of Done – As per Scrum
    These three elements
    (GIVEN WHEN THEN)
    are the building blocks
    of Acceptance Criteria.
    Typical SDLC Life Cycle
    Analyst Specifies the Use Case
    Developer Developer builds software based on Specific
    Usage scenarios with respect to the Use Case
    Tester Tester builds test cased based on Use Case
    Scenarios and finds issues.
    The Gaps identified in this
    process is filled up by
    linking the User Stories
    with Acceptance Criteria.
    1
    BDD – Behaviour Driven Development

    View Slide

  93. @arafkarsh arafkarsh
    End User Requirements
    93
    Browse Products Add to Shopping Cart Select Shipping Address Confirm Order Make Payment
    Catalogue Shopping Cart Order Payment
    Customer
    View Product
    Search
    User Journey
    Search by Price Image Gallery Update Qty Use UPI
    R2
    Global Search Product Details Add to Cart
    Delete Item
    Select Address Confirm Order
    Pay Credit Card
    Make
    Payment
    R1
    Registration
    Minimum Viable Product
    Scrum Sprint Cycle
    Search by Price Image Gallery Update Qty Use UPI
    Kanban Cycle: Each of the Story can be released without waiting for other stories to be completed resulting
    in Shorter Releases as all the stories are independent!
    Microservices / User Journey /
    Story Map & Release Cycles
    2

    View Slide

  94. @arafkarsh arafkarsh
    Infrastructure
    o Containers / Virtual Machines
    o Container Orchestration
    o Cloud X as a Service
    o SDN / Zero Trust / Service Mesh
    o Hybrid / Multi-Cloud
    94
    3

    View Slide

  95. @arafkarsh arafkarsh
    Infrastructure: Servers / Virtual Machines / Containers
    95
    Hardware
    Host OS
    HYPERVISOR
    App 1 App 1 App 1
    Guest
    OS
    BINS
    / LIB
    Guest
    OS
    BINS
    / LIB
    Guest
    OS
    BINS
    / LIB
    Type 2 Hypervisor
    App 2
    App 3
    App 2
    OS
    Hardware
    Desktop / Laptop
    BINS
    / LIB
    App
    BINS
    / LIB
    App
    Container 1 Container 2
    Type 1 Hypervisor
    Hardware
    HYPERVISOR
    App 1 App 1 App 1
    Guest
    OS
    BINS
    / LIB
    Guest
    OS
    BINS
    / LIB
    Guest
    OS
    BINS
    / LIB
    App 2
    App 3
    App 2
    Guest OS
    Hardware
    Type 1 Hypervisor
    BINS
    / LIB
    App
    BINS
    / LIB
    App
    BINS
    / LIB
    App
    Container 1 Container 2 Container 3
    HYPERVISOR
    Virtualizes the OS
    Create Secure Sandboxes in OS
    Virtualizes the Hardware
    Creates Virtual Machines
    Hardware
    OS
    BINS / LIB
    App
    1
    App
    2
    App
    3
    Server
    Data Center
    No Virtualization
    Cloud Elastic Computing
    3

    View Slide

  96. @arafkarsh arafkarsh
    Compare Type 1 and Type 2 Hypervisor
    96
    Feature Type 1 Hypervisor Type 2 Hypervisor
    Base Platform Bare-metal Host OS
    Performance High Lower
    Security Higher (due to isolation) Lower
    Resource Efficiency High Moderate to Low
    Use Case Enterprise, Data Centers Development, Testing
    Examples VMware ESXi, Xen
    VMware Workstation,
    VirtualBox
    3

    View Slide

  97. @arafkarsh arafkarsh
    Deployment – Updates and rollbacks, Canary Release
    D
    ReplicaSet – Self Healing, Scalability, Desired State
    R
    Worker Node 1
    Master Node (Control Plane)
    Kubernetes
    Architecture
    97
    POD
    POD itself is a Linux
    Container, Docker
    container will run inside
    the POD. PODs with single
    or multiple containers
    (Sidecar Pattern) will share
    Cgroup, Volumes,
    Namespaces of the POD.
    (Cgroup / Namespaces)
    Scheduler
    Controller
    Manager
    Using yaml or json
    declare the desired
    state of the app.
    State is stored in
    the Cluster store.
    Self healing is done by Kubernetes using watch loops if the desired state is changed.
    POD POD POD
    BE
    1.2
    10.1.2.34
    BE
    1.2
    10.1.2.35
    BE
    1.2
    10.1.2.36
    BE
    15.1.2.100
    DNS: a.b.com 1.2
    Service Pod IP Address is dynamic, communication should
    be based on Service, which will have routable IP
    and DNS Name. Labels (BE, 1.2) play a critical role
    in ReplicaSet, Deployment, & Services etc.
    Cluster
    Store
    etcd
    Key Value
    Store
    Pod Pod Pod
    Label Selector selects pods based on the Labels.
    Label
    Selector
    Label Selector
    Label Selector
    Node
    Controller
    End Point
    Controller
    Deployment
    Controller
    Pod
    Controller
    ….
    Labels
    Internet
    Firewall K8s Virtual
    Cluster
    Cloud Controller
    For the cloud providers to manage
    nodes, services, routes, volumes etc.
    Kubelet
    Node
    Manager
    Container
    Runtime
    Interface
    Port 10255
    gRPC
    ProtoBuf
    Kube-Proxy
    Network Proxy
    TCP / UDP Forwarding
    IPTABLES / IPVS
    Allows multiple
    implementation of
    containers from v1.7
    RESTful yaml / json
    $ kubectl ….
    Port 443
    API Server
    Pod IP ...34 ...35 ...36
    EP
    • Declarative Model
    • Desired State
    Key Aspects
    N1
    N2
    N3
    Namespace 1
    N1
    N2
    N3
    Namespace 2
    • Pods
    • ReplicaSet
    • Deployment
    • Service
    • Endpoints
    • StatefulSet
    • Namespace
    • Resource Quota
    • Limit Range
    • Persistent
    Volume
    Kind
    Secrets
    Kind
    • apiVersion:
    • kind:
    • metadata:
    • spec:
    Declarative Model
    • Pod
    • ReplicaSet
    • Service
    • Deployment
    • Virtual Service
    • Gateway, SE, DR
    • Policy, MeshPolicy
    • RbaConfig
    • Prometheus, Rule,
    • ListChekcer …
    @
    @
    Annotations
    Names
    Cluster IP
    Node
    Port
    Load
    Balancer
    External
    Name
    @
    Ingress
    3

    View Slide

  98. @arafkarsh arafkarsh
    Infrastructure Specs
    98
    Applications
    Data
    Runtime
    Middleware
    OS
    Virtualization
    Servers
    Storage
    Networking
    On Premise
    Applications
    Data
    Runtime
    Middleware
    OS
    Virtualization
    Servers
    Storage
    Networking
    IaaS
    Applications
    Data
    Runtime
    Middleware
    OS
    Virtualization
    Servers
    Storage
    Networking
    SaaS
    Customer Managed Cloud Provider Managed
    Applications
    Data
    Runtime
    Middleware
    OS
    Virtualization
    Servers
    Storage
    Networking
    PaaS
    Applications
    Data
    Container
    K8s
    OS
    Virtualization
    Servers
    Storage
    Networking
    PaaS
    Applications
    Data
    Container
    K8s / Knative
    OS
    Virtualization
    Servers
    Storage
    Networking
    FaaS
    3

    View Slide

  99. @arafkarsh arafkarsh
    Analytics: Apache Flink Architecture
    99
    3

    View Slide

  100. @arafkarsh arafkarsh
    SDN Architecture
    Software Defined Network
    100
    Control
    Plane
    Management
    Plane
    Data
    Plane
    Southbound APIs
    Northbound APIs
    Security
    Controller
    QoS
    MPLS…
    Routing
    • OpenFlow
    • SNMP
    • NetConf
    RESTful or Java APIs
    Business Applications
    Network Elements
    Controller
    Application
    Layer
    Control
    Layer
    Infrastructure
    Layer
    East – West APIs
    Multiple Controllers to avoid
    Single Point of Failure
    vRouter vSwitch vFirewall SDN Appliance – vEdge.
    vController
    vManage
    3

    View Slide

  101. @arafkarsh arafkarsh 101
    Mana
    SD-WAN
    Edge
    Appliances
    Routers
    MPLS
    DIA
    DSL
    4G/5G
    Branch Remote Data Center Branch Cloud Branch
    • Zero Touch Provisioning
    • On-Premise or Cloud
    • Physical or Virtual
    Data Plane
    vSmart Controllers
    • Routing and Security Policies
    • Horizontal Scaling
    Control Plane
    vManage
    • Single Pane of Glass
    • RBAC and APIs
    • Monitoring / Troubleshooting
    Management Plane
    Cisco
    SD-WAN
    (Viptela)
    Architecture
    vEdge
    vEdge
    vAnalytics • Carrier Performance
    • Bandwidth Forecasting
    • Machine Learning
    Analytics Plane
    SD-WAN
    Fabric
    vEdge Cloud
    Overlay
    Network
    Source: Cisco SD-WAN
    Getting Started Guide
    Cloud /
    On-Premise
    vBond
    3

    View Slide

  102. @arafkarsh arafkarsh
    Traditional VPN Vs. Zero Trust
    102
    Enterprise
    VPN
    User System
    VPN
    Client
    User
    App
    VPN
    Server IAM
    WAN
    WAN
    Split
    Tunnel
    Optional
    Resource = Data, Documents, Apps, Services, Files etc.
    Relies on Shared secret
    and/or Shared root of Trust
    If Split tunneling is enabled
    only traffic to Enterprise
    will be tunneled.
    Zero Trust
    User System
    Agent
    PEP
    User
    App
    PEP
    Encrypted Tunnel
    Normal Traffic
    LAN
    IAM
    PDP
    PEP PEP
    • Dynamically adjust the Context
    • Multiple Entry Points
    • Support Remote and On Premise
    Resource
    Resource Resource
    Resource
    3

    View Slide

  103. @arafkarsh arafkarsh
    Cisco SD-Access
    103
    Source: Cisco SDA Enabling Intent based Networking, 2nd Edition – Page 20
    o Software- Defined Access is the industry’s first intent- based net working.
    o An intent- based network treats the network as a single system that provides
    the translation and validation of the business intent (or goals) into the network
    and returns actionable insights.
    3

    View Slide

  104. @arafkarsh arafkarsh
    Infrastructure: Service Mesh: Istio Security
    104
    Source: https://istio.io/docs/concepts/security/
    It provide strong identity, powerful policy, transparent TLS encryption, and authentication,
    authorization and audit (AAA) tools to protect your services and data. The goals of Istio
    security are
    • Security by default: no changes
    needed for application code
    and infrastructure
    • Defense in Depth: integrate
    with existing security systems to
    provide multiple layers of
    Defense
    • Zero-trust network: build
    security solutions on untrusted
    networks
    3

    View Slide

  105. @arafkarsh arafkarsh
    Infrastructure: Distributed Cloud / Multi Cloud
    105
    Clouds
    Public
    Cloud
    On Premise
    Edge
    Network
    K8s K8s K8s
    Cloud On-Prem Edge
    DevOps
    o Consistent Environment
    o Auto Scale Across Env
    DevOps
    o Portable Workloads
    o AI/ML Across All Environment
    DevSecOps
    o Governance
    o Security Policies
    o Network Policies
    Private Cloud
    Technology Stack
    o Containers
    o Kubernetes
    o Service Mesh
    3

    View Slide

  106. @arafkarsh arafkarsh
    Product / Team
    o Delivery Model
    o Process
    o Timelines
    106
    4 5

    View Slide

  107. @arafkarsh arafkarsh
    Product Discovery
    107
    Increasing
    level of
    Evidence of
    Value
    Increasing level of Effort
    Developing a product without finding evidence of
    its value is a waste of time and resources.
    Observe &
    Interact Protypes
    Explainer
    Videos
    Landing
    Pages
    Concierge
    MVP
    Wizard
    of OZ
    MVP
    Beta
    Release
    Product
    Launch
    Design
    Thinking Lean Agile
    Explore the
    Problem
    Build the
    right things
    Build the
    things right
    If You are NOT doing these
    Then this is waste
    Single
    Customer
    Example
    Amazon had
    Human Book
    Reviewers
    before they
    automated it
    Example
    Dropbox: Customer
    interests went up
    from 5K to 70K
    4

    View Slide

  108. @arafkarsh arafkarsh
    Project Timelines
    108
    Kanban
    Preparation
    Requirements
    Design
    Development
    Testing
    Release
    1 Day – 1 Weeks Cycle
    Scrum
    4-6 Weeks (Max) Cycle
    1 or 2 Weeks Cycle
    also allowed
    4

    View Slide

  109. @arafkarsh arafkarsh
    Project Timelines: Kanban Board
    109
    Backlog
    Done
    Work breakdown
    Active Done
    To Do List
    A Backlog item is broken down to
    tasks and each Task should NOT
    take more than 1-3 days at max.
    It’s a good practice to keep all the
    tasks of similar size.
    Tasks are assigned to respective
    team members.
    4
    Work In Progress
    Active Done
    Track
    Task blocked due to
    Dependency.
    Once the dependent
    Task is ready the
    blocked task will be
    moved to Active State
    Max items in WIP must be
    1.4x of total Resources

    View Slide

  110. @arafkarsh arafkarsh
    Global Teams: Business Capability Centric Design
    110
    Business Centric Development
    • Focus on Business Capabilities
    • The entire team is aligned towards
    Business Capability.
    • From Specs to Operations – The
    team handles the entire spectrum
    of Software development.
    • Every vertical will have its own
    Code Pipeline, Build Pipeline.
    Front-End-Team Back-End-Team Database-Team
    In a typical Monolithic way, the team is
    divided based on technology / skill set
    rather than business functions. This leads
    to not only bottlenecks but also lack of
    understanding of the Business Domain.
    QA Team
    QA = Quality Assurance
    PO = Product Owner
    Vertically sliced Product Team
    Front-End
    Back-End
    Database
    Business
    Capability 1
    QA
    PO Ops
    Front-End
    Back-End
    Database
    Business
    Capability 2
    QA
    PO Ops
    Front-End
    Back-End
    Database
    Business
    Capability - n
    QA
    PO Ops
    5

    View Slide

  111. @arafkarsh arafkarsh
    Management
    Pipeline Automation
    Architecture
    Global Teams: Engineering Pods
    111
    Build
    Design Develop Test Stage Production
    Specs
    Cloud
    Manager
    Cloud
    Architect
    Cloud
    Sr. Engineer
    Cloud
    Engineers
    Product
    Owner
    Elastic Engineering Pod
    2-6 Engineers
    Customer 1-3 Engineers
    5

    View Slide

  112. @arafkarsh arafkarsh
    Global Teams: Roles & Responsibilities
    112
    Category Role Type Responsibilities
    1 Customer Product Owner External
    • Complete Product Vision
    • Specifications
    2 Engineering Pod
    Cloud Manager /
    Analyst
    Internal
    • Analyst & Specifications (User Stories, Acceptance Criteria)
    • Feature Management in Production & Focused on Outcome
    • Scrum Master & Team Management
    3 Engineering Pod Cloud Architect Internal
    • Technology Stack, Mentor / Guiding Team on Technology
    • Data Models and Interface Definitions (Hexagonal Architecture)
    • Research & Coding (Feature and Infra Code)
    4 Engineering Pod Cloud Sr. Engineer Internal
    • Mentor / Guiding Team on Technology
    • All the Responsibilities of Cloud Engineer also
    5 Engineering Pod
    Cloud Engineer /
    SRE
    Internal
    • Feature Coding (Open API Specs)
    • Feature Test Cases (Unit, Component, Contract, Integration)
    • Infra Coding (Infra, Security, Network)
    • Build Pipeline Automation
    6 Engineering Pod
    Cloud Network /
    Security Lead
    External
    Specialist
    • Define Network Policies
    • Define Security Policies
    • Review Infra Code for Network & Security Policies
    7 Engineering Pod
    Cloud User
    Experience Lead
    External
    Specialist
    • Usability Guidelines
    • Data Flow Guidelines
    5

    View Slide

  113. @arafkarsh arafkarsh
    Compliance
    o Global Compliance
    o GDPR / PCI-DSS / HIPAA
    o FHIR
    113
    6

    View Slide

  114. @arafkarsh arafkarsh
    Global Compliance
    114
    6
    • General Data Protection Regulation
    • The GDPR aims to give individuals greater control over their personal data, and to ensure that
    organizations that collect, use, and store personal data do so in a transparent, secure, and
    lawful manner. It applies to all organizations that process personal data of individuals in the
    EU and EEA (European Economic Area), regardless of where the organization is based.
    • Payment Card Industry – Data Security Standard
    • PCI-DSS is a set of 12 requirements that cover various aspects of data security, including
    maintaining a secure network, protecting cardholder data, regularly monitoring and testing
    security systems, and maintaining an information security policy.
    Compliance Examples from Personal Data, Payment Industry & Health
    • Health Insurance Portability and Accountability Act
    • A US federal law that sets the standards for protecting sensitive patient health information.
    • HIPAA compliance applies to all entities that handle protected health information (PHI),
    including healthcare providers, insurance companies, business associates, and other entities
    that have access to PHI.

    View Slide

  115. @arafkarsh arafkarsh
    FHIR – Fast Healthcare Interoperability Resources
    115
    6
    The first draft was published in 2011 by HL7 (Health Level Seven International) Founded in 1987
    FHIR is designed to be easier to implement and more expressive than previous HL7
    versions. It's a next-generation standard that leverages the latest web standards
    and applies a more modern, resource-oriented approach.
    Components:
    • Resources: Basic building blocks in FHIR, representing healthcare concepts like
    patients, medications, and devices.
    • RESTful API: Enables access to FHIR resources over standard web protocols.
    Advantages:
    • Built for the modern web
    • JSON and XML formats
    • High level of granularity
    Use Cases:
    • Data exchange in mobile health, cloud
    communications, EHR-based data sharing
    • Real-time integration
    • It is also useful for analytics and machine learning
    applications in healthcare

    View Slide

  116. @arafkarsh arafkarsh
    FHIR Global Adoption
    116
    FHIR is increasingly being adopted worldwide, not just in the United States. Various
    countries have FHIR implementations for national healthcare systems, including:
    1. United States: Through programs like the 21st Century Cures Act, FHIR is part of
    the mandate for healthcare interoperability.
    2. United Kingdom: NHS (National Health Service) has been moving towards FHIR
    for its digital services.
    3. Australia: The Australian Digital Health Agency supports FHIR as a part of its
    National API strategy.
    4. Canada: Infoway, which drives digital health in Canada, has FHIR-based services.
    5. Other Countries: Many countries are adopting or considering FHIR for their
    healthcare systems.
    6

    View Slide

  117. @arafkarsh arafkarsh
    FHIR Data Models: Patient, Observation
    117
    6

    View Slide

  118. @arafkarsh arafkarsh
    FHIR Data Models: Condition
    118
    6
    • clinicalStatus: Describes the current status of the condition, whether
    it's active, in remission, etc.
    • verificationStatus: Indicates whether the condition is confirmed,
    provisional, differential, etc.
    • code: Specifies the type of condition or diagnosis using a
    standardized coding system like SNOMED CT.
    • subject: Refers to the patient who has the condition.
    • onsetDateTime: The date when the condition was first noticed or
    diagnosed.
    • recordedDate: The date when this record of the condition was
    created.
    • asserter: Refers to the healthcare provider who made the diagnosis.
    This resource would be extremely useful for healthcare providers to
    track the status of various conditions over time, and it would be an
    essential component in any clinical decision support system or electronic
    health record (EHR) system.

    View Slide

  119. @arafkarsh arafkarsh
    FHIR Data Models: Medication, Device
    119
    6

    View Slide

  120. @arafkarsh arafkarsh
    FHIR Data Models: Practitioner
    120
    6

    View Slide

  121. @arafkarsh arafkarsh
    Technology Selection
    o Technology Selection
    o Backend Tech Stack
    o Frontend Tech Stack
    121
    7

    View Slide

  122. @arafkarsh arafkarsh
    Technology Selection
    122
    Microservices with Multiple Technology Stack – Kubernetes (K8s) for Networking
    Event Stream / Queues / Pub-Sub / Storage / CDC
    Users
    API Gateway (K8s/Istio Ingress Controller / Spring Cloud Stack)
    Web Services
    Business Logic
    Database Layer
    Cart
    Micro
    Service
    Shopping Cart
    SE 8
    Load Balancer
    Circuit Breaker
    Load Balancer (K8s Linux IPVS / Spring)
    Circuit Breaker
    Web Services
    Business Logic
    Database Layer
    Product
    SE 17
    Product
    Microservice
    With 4 node cluster
    Load Balancer
    Circuit Breaker
    Web Services
    Business Logic
    Database Layer
    Customer
    Customer
    Microservice
    With 2 node
    cluster
    Virtual
    Private
    Network
    Load Balancer
    Circuit Breaker
    Web Services
    Business Logic
    Database Layer
    Order
    Order
    Microservice
    With 2 node
    Cluster
    7
    Spring Cloud / Config
    OR
    Kubernetes
    API GW /
    LB /
    Service
    Discovery
    (DNS)
    Service
    Mesh
    External Load Balancer
    Angular / React
    Flutter / React Native
    HTML 5 / JavaScript
    Kotlin / Dart / Swift
    FE: UI Layer
    FE: Front End
    BE: Backend
    BE BE BE BE

    View Slide

  123. @arafkarsh arafkarsh
    Technology Selection: Backend
    123
    7
    • MongoDB: Document Database –
    Shopping Cart
    • Complex Schema (JSON)
    • Supports Schema Changes
    • Schema Extensions
    • Redis DB: Key Value Database –
    Customer, Shipping Service
    • Supports Schema Changes
    • Schema Extensions
    • Geo Location based on Address
    • Location based Features
    (Latitude/Longitude)
    • Kafka Distributed Logs
    (Scalable & Resilient)
    • Pub / Sub (Highly Scalable)
    • Streaming Data
    • Change Data Capture (CDC)
    • Kubernetes – Container Orchestration
    • Container Management
    • API Gateway & Traffic Routing
    • Network Policies
    • Docker – Containers
    • Microservice Packaging
    • Write Once, Deploy Anywhere
    • Dev / Staging / Production Parity
    • Istio – Service Mesh
    • Observability
    • Advanced Traffic Routing
    • Security: Defense in Depth
    • Policies: Security & Network

    View Slide

  124. @arafkarsh arafkarsh
    Technology Selection: Front End
    124
    # Features Native Apps Cross Platform Hybrid Progressive Web Apps
    1 Build
    Using Android
    or iOS SDK
    Different Programming Languages
    Compiled Native Platform
    JS, HTML, CSS
    Bundled as a Web App and Runs in a Web
    Container inside the Browser (Web View)
    A Web App Running with a link to
    run as Smart Device App and
    works inside a Web Browser
    2 Performance High Medium Low Low
    3 Code Base
    Multiple
    Codebase
    Single Codebase
    Build differently
    Single Codebase Single Codebase
    4 Cost High Medium Medium Low
    5
    Hardware
    Support
    Full
    Limited - Additional Coding is
    required in some cases Bluetooth,
    NFC, AR/VR etc.
    Limited - Additional Coding is required in
    some cases Bluetooth, NFC, AR/VR etc.
    Limited - Additional Coding is
    required in some cases Bluetooth,
    NFC, AR/VR etc.
    6 UX High Medium Medium Medium
    7 Languages
    Swift for iOS
    Java for Android
    Dart for Flutter
    JS for React Native
    C# for Xamarin
    JS, HTML, CSS JS, HTML, CSS
    8 Tools
    iOS SDK
    Android SDK
    Google: Flutter
    Facebook: React Native
    Microsoft: Xamarin
    Apache Cordova, Ionic
    7

    View Slide

  125. @arafkarsh arafkarsh
    What is Apache Flink
    125
    Stateful Computations over Data Streams
    Batch
    Processing
    Process Static &
    historic Data
    Data Stream
    Processing
    Realtime Results
    from Data Streams
    Event Driven
    Applications
    Data Driven Actions
    and Services
    Instead of Spark + Hadoop
    7

    View Slide

  126. @arafkarsh arafkarsh
    Use Case: Periodic ETL vs Streaming CTL
    126
    Traditional
    Periodic ETL
    • External Tool
    Periodically
    triggers ETL
    Batch Job
    Batch
    Processing
    Process Static &
    historic Data
    Data Stream
    Processing
    Realtime Results
    from Data Streams
    Continuous
    Streaming Data
    Pipeline
    • Ingestion with
    Low Latency
    • No Artificial
    Boundaries
    Streaming
    App
    Ingest Append
    Real Time Events
    Event Logs
    Batch
    Process
    Module
    Read
    Write
    Transactional Data
    Extract, Transform, Load Capture, Transform, Load
    State
    Source: GoTo: Intro to Stateful Stream Processing – Robert Metzger
    7

    View Slide

  127. @arafkarsh arafkarsh
    Use Case: Data Analytics
    127
    • Great for Ad-Hoc Queries
    • Queries changes faster than data
    Batch
    Analytics
    Stream
    Analytics
    Ingest
    K-V Data Store
    Real Time Events
    Batch
    Analytics
    Read Write
    Recorded Events
    • High Performance Low Latency Result
    • Data Changes faster than Queries
    Analytics
    App
    State
    State
    Update
    Source: GoTo: Intro to Stateful Stream Processing – Robert Metzger
    7

    View Slide

  128. @arafkarsh arafkarsh
    Use Case: Event Driven Application
    128
    • Compute & Data Tier Architecture
    • React to Process Events
    • State is stored in (Remote) Database
    Traditional
    Application
    Design
    Event Driven
    Application
    • High Performance Low Latency Result
    • Data Changes faster than Queries
    Application
    Read Write
    Events
    Trigger
    Action
    Ingest
    Real Time Events
    Application
    State
    Append
    Periodically write
    asynchronous checkpoints
    in Remote Database
    Event Logs
    Event Logs
    Trigger
    Action
    Source: GoTo: Intro to Stateful Stream Processing – Robert Metzger
    7

    View Slide

  129. @arafkarsh arafkarsh
    Cloud: Amazon Web Services
    o Infra: IAM / VPC / Route 53 / EC2 / S3 / RDS
    o Security: WAF / Shield / Guard Duty / Inspector
    o DevOps and Build Process
    o Container Orchestration
    o Monitoring & Logging
    129
    7

    View Slide

  130. @arafkarsh arafkarsh
    AWS IAM – Identity & Access Management
    130
    Key Components:
    • Users: Represents a person
    or service.
    • Groups: A collection of
    users.
    • Policies: Defines
    permissions.
    • Roles: Defines a set of
    permissions for making AWS
    service requests.
    Security Perspective:
    • Granular permission control
    • Multi-Factor Authentication
    (MFA)
    IAM lets you manage access to AWS services and resources securely.
    7
    Source: AWS IAM: https://aws.amazon.com/iam/

    View Slide

  131. @arafkarsh arafkarsh
    AWS VPC – Virtual Private Cloud
    131
    Key Components:
    • Subnets: Range of IP
    addresses in your VPC.
    • Route Tables: Set of
    rules for traffic routing.
    • Internet Gateways:
    Enable access to the
    internet.
    Security Perspective:
    • Isolation of resources
    • Network Access Control
    Lists (ACLs)
    • Security Groups
    VPC lets you provision an isolated section of the AWS Cloud where you can launch resources in a virtual
    network.
    Source: AWS VPC: https://aws.amazon.com/vpc/
    7

    View Slide

  132. @arafkarsh arafkarsh
    AWS Route 53: DNS Service
    132
    7
    Generic Features:
    • Domain Registration: Register
    domain names.
    • DNS Routing: Translate
    domain names to IP
    addresses.
    Source: AWS Route 53: https://aws.amazon.com/route53/
    Amazon Route 53 is a scalable domain name system (DNS) service.

    View Slide

  133. @arafkarsh arafkarsh
    AWS EC2 – Elastic Compute Cloud
    133
    Amazon EC2 provides scalable computing capacity in the AWS cloud. It allows you to run virtual machines,
    known as instances.
    Generic Features:
    • Instance Types: Variety of instances for different workload requirements.
    • Elastic Load Balancer: Distributes incoming traffic across instances.
    • Auto-Scaling: Automatically adjusts computing capacity.
    Source: AWS EC2: https://aws.amazon.com/ec2/
    Run cloud-native and
    enterprise applications
    Amazon EC2 delivers
    secure, reliable, high-
    performance, and cost-
    effective compute
    infrastructure to meet
    demanding business
    needs.
    Scale for HPC
    applications
    Access the on-demand
    infrastructure and
    capacity you need to
    run HPC applications
    faster and cost-
    effectively.
    Develop for Apple
    platforms
    Build, test, and sign on-
    demand macOS workloads.
    Access environments in
    minutes, dynamically scale
    capacity as needed, and
    benefit from AWS’s pay-as-
    you-go pricing.
    Train and deploy ML
    applications
    Amazon EC2 delivers the
    broadest choice of
    compute, networking (up
    to 400 Gbps), and storage
    services purpose-built to
    optimize price
    performance for ML
    projects.
    Use Cases
    7

    View Slide

  134. @arafkarsh arafkarsh
    AWS S3: Simple Storage Service
    134
    Amazon S3 provides scalable object storage.
    Generic Features:
    • Storage Classes: Different classes for various use-cases (Standard, Intelligent-Tiering, One Zone, Glacier).
    • Data Lifecycle Management: Automated rules to move data between storage classes.
    Source: AWS S3: https://aws.amazon.com/s3/
    7

    View Slide

  135. @arafkarsh arafkarsh
    AWS RDS
    135
    • Managed Databases: Supports multiple database engines like MySQL, PostgreSQL, and SQL Server.
    • High Availability: Offers Multi-AZ deployments.
    • Scalability: Read replicas and automatic vertical scaling.
    • Backup: Automated backups and manual snapshots.
    • Monitoring: Integrated with CloudWatch.
    Source: AWS RDS: https://aws.amazon.com/rds/#
    7

    View Slide

  136. @arafkarsh arafkarsh
    AWS WAF: Web Application Firewall
    136
    Key Components:
    • Rules: Customizable rules to block, allow, or monitor web
    requests.
    • WebACLs: A set of rules acted upon when a request is forwarded.
    AWS WAF is a web application firewall that helps protect web apps from common web exploits.
    Security Perspective:
    • SQL Injection and XSS protection
    • Rate-based rules to mitigate DDoS
    attacks
    Source: AWS WAF: https://aws.amazon.com/waf/
    7

    View Slide

  137. @arafkarsh arafkarsh
    AWS Shield
    137
    Key Components:
    • Shield Standard:
    Network and transport
    layer protections.
    • Shield Advanced:
    Additional protections
    against more significant
    attacks.
    Security Perspective:
    • Real-time DDoS attack
    diagnosis
    • Protection against
    infrastructure and
    application layer attacks
    AWS Shield is a managed DDoS protection service.
    Source: AWS Shield: https://aws.amazon.com/shield/
    7

    View Slide

  138. @arafkarsh arafkarsh
    AWS Guard Duty
    138
    GuardDuty is a threat detection service that continuously monitors for malicious activity.
    Key Components:
    • Findings: Alerts are generated when a
    potential threat is detected.
    Security Perspective:
    • Anomaly detection
    • Unauthorized access monitoring
    Source: AWS Guard Duty: https://aws.amazon.com/guardduty/
    7

    View Slide

  139. @arafkarsh arafkarsh
    AWS Inspector
    139
    Key Components:
    • Assessment Targets: Specific AWS resources to assess.
    • Assessment Templates: Configurations for assessment runs.
    AWS Inspector is an automated security assessment service to improve security and compliance.
    Security Perspective:
    • Vulnerability assessment
    • Security best practice checks
    Source: AWS Inspector: https://aws.amazon.com/inspector/
    7

    View Slide

  140. @arafkarsh arafkarsh
    Analytics: AWS Kinesis – Architecture (Flink)
    140
    AWS Cloud
    Kinesis Data Analytics
    Elastic Kubernetes Service
    Job Manager
    Task Manager
    Task Manager Task Manager
    S3 Bucket
    Auto Scaling
    Zookeeper
    Cloud Watch
    Cloud Watch Logs
    Flink Web UI
    7

    View Slide

  141. @arafkarsh arafkarsh
    AWS DevOps
    141
    1. AWS CodeCommit: This fully managed source control service hosts Git repositories. It’s similar
    to GitHub but tightly integrated into the AWS ecosystem.
    2. AWS CodeBuild: This build service compiles your code, runs tests, and produces packages ready
    to deploy.
    3. AWS CodeDeploy: This service automates code deployments to any instance, including EC2
    instances and servers running on-premises.
    4. AWS CodePipeline: This CI/CD service automates your release process’s build, test, and
    deployment phases.
    5. AWS CloudFormation: This IaC service helps you manage resources as code. It lets you define
    resource stacks using templates.
    6. AWS Elastic Beanstalk: This Platform as a Service (PaaS) simplifies deploying and scaling web
    applications.
    7. AWS OpsWorks: This configuration management service uses Chef or Puppet for automation.
    8. AWS X-Ray: A distributed tracing service that helps you debug and analyze applications.
    7

    View Slide

  142. @arafkarsh arafkarsh
    AWS Build Process
    142
    1. Source Control: The first step usually involves committing code to AWS CodeCommit. The repository can be
    private or public.
    2. CI Pipeline: After committing the code, you set up a CI pipeline using AWS CodePipeline. This would usually
    integrate with AWS CodeBuild for compiling the code and running unit tests.
    3. Build Phase: AWS CodeBuild will create a build environment (Docker container or a managed build
    environment), clone your repository, and then execute the build specifications which are usually defined in
    a buildspec.yml file.
    4. Artifact Storage: Post-build, the artifacts are usually stored in Amazon S3 for future deployments.
    5. Deployment: AWS CodeDeploy takes over here. It deploys the build artifacts to EC2 instances, Lambda
    functions, or even on-prem servers. It can also integrate with Elastic Beanstalk or ECS/EKS for containerized
    deployments.
    6. Monitoring: Once the application is deployed, monitoring and logging come into play using AWS
    CloudWatch and AWS X-Ray.
    7. IaC: Throughout the pipeline, AWS CloudFormation can be used to handle infrastructure as code.
    8. Configuration Management: If you need to manage configuration and automate operational tasks, you can
    integrate AWS OpsWorks into your pipeline.
    7

    View Slide

  143. @arafkarsh arafkarsh
    AWS Stack for Deployment: Containers
    143
    Feature AWS ECS AWS EKS AWS Fargate
    Managed Service Yes Yes Yes (Serverless)
    Orchestration Engine ECS Kubernetes ECS or Kubernetes
    Ease of Use Easier (Fewer abstractions) Moderate (Kubernetes learning curve) Easiest (Serverless)
    AWS Integration Deep Moderate
    Deep (with ECS), Moderate (with
    EKS)
    Scalability High High High
    Resource Optimization Instance Level Node Level Task/Container Level
    Customizability Moderate High (Kubernetes-based) Limited
    Data Persistence EFS, EBS EFS, EBS EFS, EBS
    Networking Features AWS VPC, Service Discovery AWS VPC, Kubernetes Networking AWS VPC, Service Discovery
    Monitoring Tools CloudWatch, X-Ray CloudWatch, X-Ray, Prometheus CloudWatch, X-Ray
    Security Features IAM Roles, Security Groups IAM Roles, Kubernetes RBAC IAM Roles, Security Groups
    Batch Processing ECS Batch Kubernetes Jobs ECS Batch or Kubernetes Jobs
    Pricing Model Pay for underlying EC2 instances
    Pay for control plane and worker
    nodes
    Pay per vCPU and GB Memory per
    second
    7

    View Slide

  144. @arafkarsh arafkarsh
    Monitoring & Management
    144
    Feature AWS CloudWatch AWS X-Ray AWS App Mesh AWS CloudTrail
    Primary Use-Case Monitoring & Alarming Distributed Tracing Service Mesh (Microservices) Governance & Auditing
    Data Collection Metrics, Logs, Alarms Request traces Metrics, Request/Response data API Call Logs
    Integration
    Broad AWS & Third-party
    support
    AWS services & SDKs AWS services & Envoy Proxy
    Broad AWS & Third-party
    support
    Real-Time Monitoring Yes Yes Yes
    Near Real-Time (Some
    Latency)
    Historical Data Yes Partial No Yes (up to 7 years)
    Granularity High (down to 1-second) Fine-grained trace data Fine-grained routing control Event-Level
    Anomaly Detection Yes No No No
    Routing Control No No Yes No
    Error Analytics Limited Deep (Error rates, latencies) Limited Limited (API Errors)
    Infrastructure View Yes Partial (Only as part of traces)
    No (Focused on Service-to-
    Service)
    Yes (API-Level)
    Supported Languages N/A (Infrastructure Level) Java, Node.js, .NET, Go, etc. N/A (Infrastructure Level) N/A (Infrastructure Level)
    Service Health Dashboard Yes No Partial (through CloudWatch) No
    Compliance HIPAA, GDPR, etc. HIPAA HIPAA HIPAA, GDPR, etc.
    Pricing Model Pay-as-you-go Pay-per-trace Pay-per-processed GB of data Pay-per-event
    Alerts Yes
    No (But can send trace data
    to CloudWatch)
    No (But can integrate with
    CloudWatch)
    Yes (via CloudWatch Alarms)
    7

    View Slide

  145. @arafkarsh arafkarsh
    Solution Implementation
    o Specs, Architecture, Design & Packaging
    o 15 Factor Methodology
    o Composable Enterprise Architecture
    o Event-Driven Architecture
    o Microservices Architecture
    o Domain Driven Design
    145
    8

    View Slide

  146. @arafkarsh arafkarsh
    Specs, Architecture, Design, Packaging
    146
    EPIC
    Bounded
    Context
    Micro
    Service
    Pod
    User Stories
    MVP
    Domain Driven
    Design
    Service
    Architecture
    Container
    Orchestration
    Design Thinking
    Lean Startup
    Agile (Scrum/Kanban)
    CI/CD/CD,
    DevSecOps
    Specs Deploy
    Design / Develop
    Code
    Process
    Test Automation Code, Continuous Integration / Delivery / Deployment, Infra Code
    8

    View Slide

  147. @arafkarsh arafkarsh 147
    12 Factor App Methodology
    4 Backing Services Treat Backing services like DB, Cache as attached resources
    5 Build, Release, Run Separate Build and Run Stages
    6 Process Execute App as One or more Stateless Processes
    7 Port Binding Export Services with Specific Port Binding
    8 Concurrency Scale out via the process Model
    9 Disposability Maximize robustness with fast startup and graceful exit
    10
    Dev / Staging /
    Production Parity
    Keep Development, Staging and Production as similar as possible
    Checkout the Shift – Left in DevOps (Slide No. 48., Section 9)
    11 Logs Treat logs as Event Streams
    12 Admin Process
    Run Admin Tasks as one of Process (Eg. DB Migration, Software
    upgrades, etc..)
    Factors Description
    1 Codebase One Code base tracked in revision control
    2 Dependencies Explicitly declare dependencies
    3 Configuration Configuration driven Apps
    Source: https://12factor.net/
    8

    View Slide

  148. @arafkarsh arafkarsh 148
    Additional Factors Description
    13 API
    API Driven
    Contract Driven Development
    14 Telemetry
    Application Monitoring, Domain Specific
    Telemetry, Health & System Logs
    15 Security
    Authentication & Authorization
    Implement RBAC (Role Based Access Control)
    Auth and Authorization Tokens
    15 Factor App Methodology
    8

    View Slide

  149. @arafkarsh arafkarsh
    API Architecture Maturity Levels
    149
    Source: https://www.apiscene.io/lifecycle/7-layers-of-api-architecture-maturity/
    • REST & gRPC – API Communication in Microservices: https://www.apiscene.io/lifecycle/rest-grpc-api-communication-in-microservices/
    • A Postman API Governance Collection: https://www.apiscene.io/lifecycle/a-postman-api-governance-collection/
    • Impact of Distributed Architecture to API Lifecycle: https://www.apiscene.io/lifecycle/what-is-the-impact-of-distributed-architecture-to-api-lifecycle/

    8

    View Slide

  150. @arafkarsh arafkarsh
    Composable Enterprise Architecture
    150
    Source: Gartner: Future of Applications: Delivering the Composable Enterprise | Why does it matter?
    On Demand
    Scalability
    Service & Apps
    Integrated
    with Clients &
    Devices
    Automated
    On Demand
    Services
    Self Service
    Options for
    App & Data
    MASA
    Mesh App & Service
    Architecture
    Enterprise Data
    Available, Accessible, &
    Integrated into Data Flow
    Delivers > Packaged Business Capabilities
    8

    View Slide

  151. @arafkarsh arafkarsh
    Architecture Styles, Patterns & Design Patterns
    151
    • Component-based
    • Client-server
    • Event-driven
    • Layered Architecture
    • Monolithic application
    • Plug-ins
    • Publish-subscribe
    • Service Based
    • Service-Oriented
    • Microservices
    Architecture Style:
    1. How to Organize the Code,
    2. Creating high-level modules
    & layers and how they
    interact each other.
    Architecture Patterns:
    A Recurring solution to a
    recurring problem.
    Providing the Solution to
    an Architecture Style. Ex.
    How a request is processed
    from the outer layer to
    inner layer.
    • Three Tier
    • Micro Kernel
    • Model View Controller
    • Event Sourcing and CQRS
    • Domain Driven Design
    Design Patterns:
    The scope of the Design
    Patterns is much
    narrower compared to an
    Architecture Pattern.
    It focuses on instantiating
    an object, and its
    behaviour of the object.
    • Adapter
    • Builder / Factory
    • Saga
    • Repository
    • Aggregate Root
    Wider Scope Narrow Scope
    Critical Architectural Styles & Patterns
    8

    View Slide

  152. @arafkarsh arafkarsh
    Event Driven & Pub Sub Architectures
    152
    Check Out
    Cart
    4. Data Durability (Replication)
    5. Ordering Guarantee (Per
    Partition)
    Use Partition Key
    Kafka Producer API
    Kafka
    Consumer API
    Order Topic (Total Partitions 6)
    Kafka Storage
    Replicated Logs
    Kafka Cluster
    5 6 7 8
    7 8
    What will happen to
    Inventory Instance 7 and 8?
    As there are only 6 Partitions
    Kafka can serve ONLY 6
    consumers within a partition
    1 2 3 4
    1 2 3 4
    3 4
    Service
    Instances
    2 5
    1
    All the above Consumers will get same
    orders available in the Order Topic
    Broadcast Orders to following
    Consumers
    Order Consumer Group Inv Consumer Group Multiple Subscriber
    1. Highly Scalable
    2. Multi Subscriber
    3. Loosely Coupled
    Systems
    8

    View Slide

  153. @arafkarsh arafkarsh
    Microservices Characteristics
    153
    We can scale our operation independently, maintain
    unparalleled system availability, and introduce new
    services quickly without the need for massive
    reconfiguration. —
    Werner Vogels, CTO, Amazon Web Services
    Modularity ... is to a technological economy
    what the division of labor is to a
    manufacturing one.
    W. Brian Arthur,
    author of e Nature of Technology
    The key in making great and growable systems is
    much more to design how its modules communicate
    rather than what their internal properties and
    behaviors should be.
    Alan Kay, 1998 email to the Squeak-dev list
    Components
    via
    Services
    Organized around
    Business
    Capabilities
    Products
    NOT
    Projects
    Smart
    Endpoints
    & Dumb Pipes
    Decentralized
    Governance &
    Data Management
    Infrastructure
    Automation
    via IaC
    Design for
    Failure
    Evolutionary
    Design
    Source: US DoD DevSecOps Fundamentals Playbook. Page 6
    8

    View Slide

  154. @arafkarsh arafkarsh
    Microservices Architecture
    154
    /ui
    /productms
    /auth
    /order
    Gateway
    Virtual Service
    Deployment / Replica / Pod Nodes
    Istio Sidecar - Envoy
    Load Balancer
    Kubernetes
    Objects
    Istio Objects
    Firewall
    P M C
    Istio Control Plane
    UI Pod N5
    v2
    Canary
    v2
    User X = Canary
    Others = Stable
    v1 UI Pod
    UI Pod
    UI Pod
    UI
    Service
    N1
    N2
    N2
    Destination
    Rule
    Stable / v1
    EndPoints
    Internal
    Load Balancers
    Source: https://github.com/meta-magic/kubernetes_workshop
    Users
    Product Pod
    Product Pod
    Product Pod
    Product
    Service
    MySQL
    Pod
    N4
    N3
    Destination
    Rule
    EndPoints
    Review Pod
    Review Pod
    Review Pod
    Review
    Service
    N1
    N4
    N3
    Service Call
    Kube DNS
    EndPoints
    8

    View Slide

  155. @arafkarsh arafkarsh
    Domain Driven Design – Tactical Design
    155
    Source: Domain-Driven Design Reference by Eric Evans
    8

    View Slide

  156. @arafkarsh arafkarsh
    Monolithic Data Models across bounded contexts.
    Source: Patterns, Principles and Practices of DDD – Page 124
    This model shows multiple
    responsibilities of the
    shared Model – Product.
    This is a classic example of
    Big Ball of Mud.
    156
    8

    View Slide

  157. @arafkarsh arafkarsh
    Product Model in Different Bounded Context
    157
    Catalogue
    Product
    • Product UUID
    • Name
    • Description
    • SKU
    • Product Price
    • Currency
    • Product Images
    • Brand
    • Manufacturer
    Cart
    Product
    • Product UUID
    • Name
    • Value
    • Quantity
    o Product Model has different attributes in different contexts. So, it avoids storing
    all the Product info in one place and then sharing that across multiple Bounded
    Contexts (Microservices).
    o If you want to change Product details related to Package, then only Order
    Bounded Context (Microservice) needs to be updated.
    Order
    Product
    • Product UUID
    • Name
    • Value
    • Quantity
    • Shipping Type
    • Package Type
    8

    View Slide

  158. @arafkarsh arafkarsh
    Process
    • Define your Business Processes. Eg. Various aspects of Order
    Processing in an E-Commerce Site, Movie Ticket Booking,
    Patient visit in Hospital.
    1
    Commands • Define the Commands (End-User interaction with your App) to
    execute the Process. Eg. Add Item to Cart is a Command.
    2
    Event Sourced
    Aggregate
    • Current state of the Aggregate is always derived from the Event
    Store. Eg. Shopping Cart, Order etc. This will be part of the Rich
    Domain Model (Bounded Context) of the Micro Service.
    4
    Projections
    • Projections focuses on the View perspective of the Application.
    As the Read & Write are different Models, you can have
    different Projections based on your View perspective.
    5
    Write
    Data
    Read
    Data
    Events • Commands generates the Events to be stored in Event Store.
    Eg. Item Added Event (in the Shopping Cart).
    3
    Event Storming – Concept
    158
    8

    View Slide

  159. @arafkarsh arafkarsh
    Event Sourcing Intro
    159
    Standard CRUD Operations – Customer Profile – Aggregate Root
    Profile
    Address
    Title
    Profile Created
    Profile
    Address
    New Title
    Title Updated
    Profile
    New
    Address
    New Title
    New Address added
    Derived
    Profile
    Address
    Notes
    Notes Removed
    Time T1 T2 T4
    T3
    Event Sourcing and Derived Aggregate Root
    Commands
    1. Create Profile
    2. Update Title
    3. Add Address
    4. Delete Notes
    2
    Events
    1. Profile Created Event
    2. Title Updated Event
    3. Address Added Event
    4. Notes Deleted Event
    3
    Profile
    Address
    New Title
    Current State of the
    Customer Profile
    4
    Snapshot
    Event store
    Single Source of Truth
    Greg
    Young
    8

    View Slide

  160. @arafkarsh arafkarsh
    Event Sourcing: Case Study: Shopping Site – Event Sourcing / CQRS
    160
    Catalogue Shopping Cart Order Payment
    • Search Products
    • Add Products
    • Update Products
    Commands
    • Add to Cart
    • Remove Item
    • Update Quantity
    Customer
    • Select Address
    • Select Delivery Mode
    • Process Order
    Events
    • Product Added
    • Product Updated
    • Product Discontinued
    • Item Added
    • Item Removed /
    Discontinued
    • Item Updated
    • Order Initiated
    • Address Selected
    • Delivery Mode Selected
    • Order Created
    • Confirm Order for
    Payment
    • Proceed for Payment
    • Cancel Order
    • Payment Initiated
    • Order Cancelled
    • Order Confirmed
    • OTP Send
    • Payment Approved
    • Payment Declined
    Microservices
    • Customer
    • Shopping Cart
    • Order
    Customer Journey thru Shopping Process
    2
    Processes 1
    Customers will browse through the Product catalogue to find the products, their ratings and reviews. Once the product is
    narrowed down, the customer will add the product to the shopping cart. Once the customer is ready for the purchase, he/she
    will start the order processing by selecting the Delivery address, delivery method, and payment option. Once the payment is
    made, the customer will get the order tracking details.
    ES Aggregate 4
    Core Domain
    Sub Domain Sub Domain Sub Domain Generic Domain
    3
    8

    View Slide

  161. @arafkarsh arafkarsh
    Event Sourcing: Case Study: Patient Diagnosis and Treatment
    161
    Payment
    • Register
    Patient
    • Search Doctor
    Commands
    • Add Patient
    Info
    • Add Details
    • Add BP
    • Add Diagnosis
    • Add
    Prescription
    Events
    • Doctor
    Scheduled
    • Patient Added
    • Patient Info
    Added
    • Details Added
    • BP Added
    • Diagnosis
    Added
    • Prescription
    Added
    • Add
    Medicine
    • Add Bill
    • Medicine
    Added
    • Bill Prepared
    • Payment
    Approved
    • Payment Declined
    • Cash Paid
    The patient registers and makes an appointment with the doctor. Patient details and history is recorded. The
    doctor makes the diagnosis and creates the prescription. The patient buys the medicine from the Pharmacy.
    A ward appointment is scheduled and disclosed to the ward if a patient needs to be admitted. Once the
    treatment is over, the patient is discharged from the Hospital.
    Microservices
    • Diagnosis
    • Prescription
    • Hospital Bill
    • Discharge Summary
    Patient Journey thru Treatment Process
    Registration
    • Add Doctor
    • Add
    Appointment
    • Add Patient File
    • Doctor Added
    • Appointment
    Added
    • Patient File Added
    ES Aggregate
    2 4
    Processes 1
    Doctors Diagnosis Pharmacy
    Ward
    Patient
    • Add Checkup
    • Add Treatment
    • Add Food
    • Add Discharge
    • Checkup Added
    • Treatment
    Added
    • Food Added
    • Discharge Added
    Core Domain Sub Domain Sub Domain
    Sub Domain
    Sub Domain Generic Domain
    Sub Domain
    3
    8

    View Slide

  162. @arafkarsh arafkarsh
    Design Pattern
    1 Decomposition Identify the Modules and Boundaries
    2 Strangler Fig Product Service (Query Only with Apache Solr)
    3 Branch By Abstraction Shopping Cart as Service using Monolithic DB
    4 Decorating Collaborator New Shipping Service with Database
    5 Change Data Capture Enhance Loyalty Module as a new Service
    6 Aggregate API Expose Customer API on Monolith
    7 Split Table
    Product Split into 2 Services as Product Management
    and Warehouse
    8 Change Data Ownership Order Service using Monolithic DB
    9 Move Foreign Key to Code
    Foreign Key in Order (item) with Product Table moved to
    Order Service Code
    10 Strangler Fig Move out Customer Module and decommission the Monolith
    Legacy Migration Design Patterns
    162
    • Prioritize the Modules / Services For Implementation & Deployment
    Setup
    Transition Plan: Example Shopping Portal
    UI Layer
    WS
    BL
    DL
    Database
    Cart
    Order
    Customer
    Product
    Monolith
    8

    View Slide

  163. @arafkarsh arafkarsh
    Migration Design Patterns: Strangler Fig Pattern
    163
    API Gateway / Proxy
    Web Services
    Business Logic
    Database Layer
    Product
    Micro
    Service
    Product
    SE 8
    UI Layer
    WS
    BL
    DL
    Database
    Cart
    Order
    Customer
    Product
    UI Layer
    WS
    BL
    DL
    Database
    Cart
    Order
    Customer
    Product
    UI Layer
    WS
    BL
    DL
    Database
    Cart
    Order
    Customer
    Product
    Web Services
    Business Logic
    Database Layer
    Product
    Micro
    Service
    Product
    SE 8
    API Gateway / Proxy
    Step 1
    Identity the Module
    Step 2
    Move the Service
    Step 3
    Redirect the Calls to New Service
    Source: Monolith to Microservices By Sam Newman
    1. New Service
    (Code)
    2. Better Search
    Capabilities
    Product DB will be used
    by other modules in
    Monolithic App
    Monolith Monolith Monolith
    Only used for Search
    Capabilities and
    Scalability.
    8

    View Slide

  164. @arafkarsh arafkarsh
    Microservices Testing Strategies
    164
    E2E
    Testing
    Integration
    Testing
    Contract Testing
    Component Testing
    Unit Testing
    Number of Tests
    Speed
    Cost
    Time
    Mike Cohen’s Testing Pyramid
    Test Pyramid: https://martinfowler.com/bliki/TestPyramid.html
    70%
    20%
    10%
    Ubiquitous
    Language
    Domain
    Expert
    Analyst Developers
    QA
    Design
    Docs
    Test Cases
    Code
    Architect
    8

    View Slide

  165. @arafkarsh arafkarsh
    Microservices Testing Strategy
    165
    Unit Testing
    A unit test exercises the
    smallest piece of testable
    software in the application
    to determine whether it
    behaves as expected.
    Source: https://martinfowler.com/articles/microservice-testing/#agenda
    Component Testing
    A component test limits the
    scope of the exercised
    software to a portion of the
    system under test,
    manipulating the system
    through internal code
    interfaces and using test
    doubles to isolate the code
    under test from other
    components.
    Integration Testing
    An integration test verifies
    the communication paths
    and interactions between
    components to detect
    interface defects
    Integration Contract Testing
    An Integration Contract test is a
    test at the boundary of an
    external service verifying that it
    meets the contract expected by a
    consuming service.
    End 2 End Testing
    An end-to-end test verifies that a
    system meets external
    requirements and achieves its
    goals, testing the entire system,
    from end to end
    Say NO to End 2 End Tests - Mike
    Walker April 22, 2015. Google Test Blog
    8

    View Slide

  166. @arafkarsh arafkarsh
    Microservices Testing Scenarios / Tools
    166
    Testing Tools
    Contract Testing Scope
    Integration Testing
    Verifies the communication
    paths and interactions between
    components to detect interface
    defects
    Contract Testing
    It is a test at the boundary of an
    external service verifying that it
    meets the contract expected by a
    consuming service.
    Payment Mock
    Integration Contract Testing Scope
    Test Double
    Montebank
    Cart
    Component Testing
    Unit
    Testing
    Integration Testing Scope
    Order
    REST / HTTP or
    Events / Kafka
    Item ID,
    Quantity,
    Address..
    Mock Order
    Component Testing
    A component test limits the
    scope of the exercised
    software to a portion of the
    system under test.
    Order
    Payment
    Unit
    Testing
    Firewall
    Integration Testing Scope
    REST / HTTP
    Payment
    Sandbox
    Component
    Testing
    U
    8

    View Slide

  167. @arafkarsh arafkarsh
    Chaos Engineering – Load / Stress / Performance
    167
    Chaos Monkey Randomly disables production instances
    Chaos Kong
    Similar to Chaos Monkey, simulates an outage of an
    entire Amazon availability zone.
    Doctor Monkey
    Checks CPU load, Memory usage and removes it
    from network if the health is bad.
    Janitor Monkey Search for unused resources and disposes them.
    Compliance Monkey
    Finds instances that don’t adhere to best-practices
    and shuts them down.
    Latency Monkey Induces Artificial delays
    Security Monkey
    Is an extension of Compliance Monkey. Find security
    vulnerabilities and terminates offending instances.
    Source: https://github.com/Netflix/SimianArmy/wiki
    Source: http://principlesofchaos.org/
    8

    View Slide

  168. @arafkarsh arafkarsh
    SANS Cloud Security Architecture Principles
    168
    Source: RSA Conference 2019 – A Cloud Security Architecture workshop. Dave Shackleford Sr. Instructor SANS Institute
    Think
    Components
    Design for
    Failure
    Always
    Think of
    Feedback Loops
    Use Different
    Storages
    Options
    Built-In
    Security
    at every Layer
    CENTRALIZATION
    Focus on
    Centralization
    Standards & Automation
    Design for
    Elasticity
    8

    View Slide

  169. @arafkarsh arafkarsh
    Solution Maintenance
    o SDLC: Agile / DevOps
    o Shift Left
    o CALMS Framework and SRE
    o DevSecOps Playbook (US Dept of Defense)
    169
    9

    View Slide

  170. @arafkarsh arafkarsh
    SDLC: Agile & DevOps
    170
    Build
    Design Develop Test Deploy Ops
    Specs
    Agile
    DevOps
    Go Live Support
    Specs / Design / Development
    CI/CD and Tests Automation
    Operations
    9

    View Slide

  171. @arafkarsh arafkarsh
    Production Environment
    Continuous Monitoring
    Fully
    Automated
    Continuous Deployment
    Shift Left – Operational Concerns
    171
    • Operations Concerns move earlier in software delivery life cycle, towards development.
    • The Goal is to enable Developers and QC Team to Develop and Test the software that
    behave like Production System in fully automated way.
    Development Environment
    Build
    Build
    Build
    Test Environment
    Continuous Integration
    Unit
    Testing
    Component
    Testing
    Contract
    Testing
    Integration
    Testing
    Continuous Testing
    Shift Left moves operations earlier in development cycle.
    Stage Environment
    Acceptance Testing
    Pull Request / Merge
    Continuous Delivery
    GitOps – CD/CD
    9

    View Slide

  172. @arafkarsh arafkarsh
    DevOps
    172
    Source: https://www.atlassian.com/devops/what-is-devops
    9

    View Slide

  173. @arafkarsh arafkarsh
    5 DevOps Principles – CALMS Framework
    173
    Source: https://www.atlassian.com/devops/frameworks/calms-framework
    DevOps isn’t a process,
    or a different approach
    to development.
    It’s a culture change.
    DevOps culture is
    collaboration.
    Build, Test, Deploy, and Provisioning automation
    are typical starting points for teams.
    Another major contribution of DevOps is
    “configuration as code.” Developers strive to
    create modular, composable applications
    because they are more reliable and maintainable.
    CULTURE AUTOMATION
    LEAN MEASUREMENT SHARING
    Continuous
    Improvement
    with Canary
    Releases and A/B
    Testing
    Continuous
    Improvement
    requires Data to
    measure the
    changes
    Sharing responsibility,
    success, failure goes a
    long way toward
    bridging that divide
    between Dev and Ops.
    You built it, You run it.
    9

    View Slide

  174. @arafkarsh arafkarsh
    Implementing CALMS – DevOps Principles
    174
    Capability Centric Design
    Reduce
    Organization Silos
    CULTURE
    Leverage
    Tooling &
    Automation
    Tests, CI/CD Pipeline & Container Orchestration
    AUTOMATION
    Implement
    Gradual
    Change
    Microservices Architecture
    & Agile: Kanban
    LEAN
    Measure
    Everything
    Service Mesh: Observability
    MEASUREMENT
    Accept
    Failure as
    Normal
    Design for Failure
    SHARING
    Source: IBM DevOps Vs. SRE https://www.youtube.com/watch?v=KCzNd3StIoU Google: https://www.youtube.com/watch?v=uTEL8Ff1Zvk
    9

    View Slide

  175. @arafkarsh arafkarsh
    class SRE implements DevOps – CALMS
    175
    Capability Centric Design
    Reduce
    Organization Silos
    CULTURE
    Leverage
    Tooling &
    Automation
    Tests, CI/CD Pipeline & Container Orchestration
    AUTOMATION
    Implement
    Gradual
    Change
    Microservices Architecture
    & Agile: Kanban
    LEAN
    Measure
    Everything
    Service Mesh: Observability
    MEASUREMENT
    Accept
    Failure as
    Normal
    Design for Failure
    SHARING
    ü Share Ownership
    ü SLOs & Blameless PM
    ü Canary Deployment, A/B Testing
    ü Automate this years Job
    ü Measure toil & reliability
    9
    SRE – Site Reliability Engineering

    View Slide

  176. @arafkarsh arafkarsh
    DevSecOps
    176
    Recommended by US DoD (Dept of Defense) DevSecOps Best Practices
    Source:
    Page 17
    US DoD
    Enterprise
    DevSecOps
    Fundamentals
    9

    View Slide

  177. @arafkarsh arafkarsh
    6
    DevSecOps Playbook
    177
    1 Adopt a DevSecOps Culture
    2 Adopt Infrastructure as Code
    3 Adopt Containerized
    Microservices
    4 Adopt a Capability Model, not a
    Maturity Model
    5 Drive Continuous Improvement
    through Key Capabilities
    Establish a Software Factory
    7 Define a meaningful
    DevSecOps pipeline
    8 Adapt an Agile Acquisition
    Policy for Software
    9 Tirelessly Pursue Cyber
    Resilience
    10 Shift Left: Operational Test &
    Eval
    Source: US DoD DevSecOps Fundamentals Playbook
    9

    View Slide

  178. @arafkarsh arafkarsh 178
    DREAM | AUTOMATE | EMPOWER
    Araf Karsh Hamid :
    India: +91.999.545.8627
    https://speakerdeck.com/arafkarsh
    http://www.slideshare.net/arafkarsh
    https://www.linkedin.com/in/arafkarsh/
    https://www.youtube.com/user/arafkarsh/playlists
    http://www.arafkarsh.com/
    @arafkarsh
    arafkarsh

    View Slide