Solution Architecture

@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

BPB
Building Cloud
Native Apps
2

View Slide

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

View Slide

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

View Slide

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

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

View Slide

Enterprise Architecture
7
Business Architecture:
Describes the organization's
business processes, functions,
and capabilities.
Data Architecture:
data structures, data flows,
and data storage.
Application Architecture:
Describes the organization's software
applications and their
interconnections.
Technology Architecture:
software applications and
their interconnections.
Security Architecture:
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

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

@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

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

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

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

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

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

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

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

View Slide

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

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

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

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

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

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

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

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

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

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

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

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

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

View Slide

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

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
ISO/IEC/IEEE
42010-2011
Standard
Source: https://www.iso.org/standard/50508.html
Only for Architecture Descriptions of
Software & Systems

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

37
ISO/IEC/IEEE
42010-2022
Standard
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

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
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
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
ISO/IEC/IEEE
42010-2011
Standard
ISO/IEC/IEEE
42010-2022
Standard

View Slide

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

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

Perspectives
44
• 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
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
Viewpoints are connected to Software Design
Source: Nick Rozanski. Software Systems Architecture: With Stakeholders Using Viewpoints and Perspectives. Pearson Education India.

View Slide

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

View Slide

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.
The issues addressed by perspectives are often referred to as cross-
cutting concerns or nonfunctional requirements of the architecture.

View Slide

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

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

View Slide

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.

View Slide

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.

View Slide

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

View Slide

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

View Slide

55
Source: Nick Rozanski. Software Systems Architecture: With
Stakeholders Using Viewpoints and Perspectives.
Architects
Role

View Slide

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

View Slide

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

View Slide

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
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

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

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

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

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

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

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

7. Operational Viewpoint: Monitoring & Management
65
Type Details
Diagrams Used Dashboard Mockups, Graphs, Visualizations
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

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

View Slide

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.
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
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

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

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

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

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

6. Deployment Viewpoint
72
Type Details
Diagrams Used Deployment Diagram
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

7. Operational Viewpoint: Infrastructure and Platform
73
Type Details
Diagrams Used Network Topology Diagram, Infrastructure Diagram
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

7. Operational Viewpoint: Monitoring & Management
74
Type Details
Diagrams Used Dashboard Mockups, Graphs, Visualizations
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

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

View Slide

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

2. Performance Perspective
77
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

3. Availability Perspective
78
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

4. Usability Perspective
79
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

5. Accessibility Perspective
80
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

6. Evolution Perspective
81
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

7. Internationalization Perspective
82
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

8. Regulation Perspective
83
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

9. Location Perspective
84
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

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

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

1 2 3 4 5 6 7 8 9
Let us dive into these sections

View Slide

Requirements
o Non-Functional Requirements
o Functional Requirements
88
1 2

View Slide

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

View Slide

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

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

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

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

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

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

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

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

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

Analytics: Apache Flink Architecture
99
3

View Slide

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

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

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

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

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

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

Product / Team
o Delivery Model
o Process
o Timelines
106
4 5

View Slide

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

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

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

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

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

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

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

View Slide

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

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

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

FHIR Data Models: Patient, Observation
117
6

View Slide

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

FHIR Data Models: Medication, Device
119
6

View Slide

FHIR Data Models: Practitioner
120
6

View Slide

Technology Selection
o Technology Selection
o Backend Tech Stack
o Frontend Tech Stack
121
7

View Slide

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

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

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

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

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

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
7

View Slide

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
7

View Slide

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

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

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.
• 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

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

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

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

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

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.
• SQL Injection and XSS protection
• Rate-based rules to mitigate DDoS
attacks
Source: AWS WAF: https://aws.amazon.com/waf/
7

View Slide

AWS Shield
137
Key Components:
• Shield Standard:
Network and transport
layer protections.
• Shield Advanced:
Additional protections
against more significant
attacks.
• 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

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.
• Anomaly detection
• Unauthorized access monitoring
Source: AWS Guard Duty: https://aws.amazon.com/guardduty/
7

View Slide

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.
• Vulnerability assessment
• Security best practice checks
Source: AWS Inspector: https://aws.amazon.com/inspector/
7

View Slide

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

View Slide

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

View Slide

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

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
& 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

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
& 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

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

View Slide

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

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

Solution Architecture

Solution Architecture

Araf Karsh Hamid

More Decks by Araf Karsh Hamid

Other Decks in Technology

Featured

Transcript