Solution Architecture

@arafkarsh arafkarsh Architecting & Building Apps a tech presentorial Combination
of presentation & tutorial AI / ML Generative AI LLMs, RAG 6+ Years Microservices Blockchain 8 Years Cloud Computing 8 Years Network & Security 8 Years Distributed Computing 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 Capability Centric Design System Context Design, DFD L0,L1, & L2 4+1 Architecture Views / UML 2.5 Zachman Framework C4 Diagrams (Context to Code) ISO/IEC/IEEE 42010:2011 & 42010:2022 View, Viewpoints & Perspectives

@arafkarsh arafkarsh Topics 2 ➢ Understanding the Context 1. Capability
Centric Design 2. System Context Design, DFD L0,L1, & L2 3. 4+1 Architecture View / UML 2.5 Diagrams 4. C4 Diagrams (Context to Code) 5. Zachman Framework 6. ISO/IEC/IEEE 42010:2011 & 42010:2022 7. View, Viewpoints & Perspectives 8. Solutions Architect

@arafkarsh arafkarsh 3 Source: https://arafkarsh.medium.com/embracing-cloud-native-a-roadmap-to-innovation-a6b06fe3a9fb Cloud-Native Architecture

@arafkarsh arafkarsh 4 Source: https://arafkarsh.medium.com/embracing-cloud-native-a-roadmap-to-innovation-a6b06fe3a9fb

@arafkarsh arafkarsh 0 Refreshing the basic o Deterministic Systems o
Non-Deterministic Systems o Idempotent Systems o Non-Idempotent Systems 5

@arafkarsh arafkarsh 1 Deterministic System o Concept of Deterministic System
o Decision Models and Notations (DMN) o Case Study: Visa and Mastercard 6

@arafkarsh arafkarsh Deterministic System 7 1. Input facts arrive in
real time (amount, merchant MCC, device ID, geolocation, velocity counters, watch-list flags). 2. A rule engine (Drools, IBM ODM, FICO Blaze) evaluates a fixed, version- controlled knowledge base: IF amount > ₹50 000 AND firstTimeMerchant AND MCC = 7995 THEN ACTION = CHALLENGE 3. The first rule that matches fires; priority order is deterministic >> identical facts always trigger the same action (ALLOW, DECLINE, CHALLENGE). 4. The decision, rule ID and timestamp are logged for audit and post-event analytics.

@arafkarsh arafkarsh Decision Model & Notation (DMN) 8 Aspect Key
points What it is An ISO/OMG standard (ISO/IEC 21305) for authoring, visualising and executing business decisions. Core artefacts o Decision Requirements Diagram (DRD) – boxes and arrows showing which input data and sub-decisions feed a top-level decision. o Decision Tables – spreadsheets where each row is an “IF … THEN …” rule. o Boxed Expressions & FEEL – the Friendly Enough Expression Language used inside cells. Why it matters Separates decision logic from application code, so domain experts can update policy without redeploying software. Execution DMN runtime engines (e.g., Camunda, Red Hat Decision Manager, Drools) evaluate the tables at run-time, returning deterministic results plus the “hit policy” (e.g., FIRST, COLLECT, ANY). Typical uses Loan-eligibility checks, insurance underwriting, pricing calculators, workflow routing—any place a spreadsheet of rules already exists.

@arafkarsh arafkarsh Case Study: Visa and Mastercard 9 o Visa
Advanced Authorization and Mastercard Decision Intelligence both expose “static rule sets” that issuer banks can tailor. A bank might codify: o “Block any e-commerce spend above ₹1 lakh if the card has never been used online and is travelling internationally.” o Major Indian issuers (HDFC, SBI) layer their own rules on top of the network- supplied ones to satisfy RBI’s step-up authentication mandates. o Outcome: regulators like deterministic engines because they can trace every decline back to an explicit policy line; operations teams can A/B test a rule on yesterday’s transactions and know exactly how many approvals would have flipped.

@arafkarsh arafkarsh Key Takeaways 10 o Same input >> same
output every time; behavior is fully predictable and repeatable. o Logic is explicitly encoded (rules, decision tables, finite-state machines) rather than learned from data. o Easy to test and audit—each outcome can be traced to a specific rule or line of code. o Regulatory-friendly: supports clear explainability and version control; changes only happen when a rule is intentionally updated. o Limited adaptability: can’t handle novel situations without new rules, so coverage depends on how exhaustively the rule set is maintained.

@arafkarsh arafkarsh 2 Non-Deterministic System o Concept of Non-Deterministic System
o Case Study: Retail Banking Apps o Deterministic Vs. Non-Deterministic Systems o Compare DMN, RNN, & Transformers 11

@arafkarsh arafkarsh Non-Deterministic System 12 Machine-Learning Chatbot (Conversational AI for
Banking Support) How it works 1. A user types “I lost my card—what do I do?” 2. The input is tokenized and passed through a large-language model (LLM). 3. The model predicts probabilities for the next token; sampling (temperature, top-p) injects randomness so the same sentence can be completed in multiple valid ways. 4. Post-processors apply guardrails (e.g., no account numbers in the response) and route the answer back to chat.

@arafkarsh arafkarsh Case Study: Retail banking Apps 13 o EVA
(HDFC Bank) now runs on an LLM fine-tuned for Indian banking vocabulary. Two identical queries can yield stylistically different guidance, even though both are correct. o ChatGPT, Gemini, or Alexa skills integrated into retail-banking apps behave similarly—answers vary with model version, conversation history and sampling settings. o Risk controls: banks wrap the model with a deterministic policy layer (no confidential data leakage; escalate to human after three fallback intents), but the core language generation remains probabilistic

@arafkarsh arafkarsh Why Distinction Matters? 14 Practical concern Deterministic Fraud
Engine ML Chatbot Regulatory audit Straightforward—show rule, show match Must log prompts, completions, and safety filters Updating behaviour Change a rule, redeploy; effect is predictable Re-train or fine-tune >> side- effects possible elsewhere Dealing with novel patterns Needs a new rule—may lag Can generalise to unseen phrasing or fraud pattern (after retraining) User trust “Your txn was declined because Rule #214 triggered.” “The bot usually answers, but may rephrase or refuse.”

@arafkarsh arafkarsh Deterministic Vs. Non-Deterministic Systems 15 Deterministic System Non-Deterministic
System Key trait Same input >> always the same output Same input >> may yield different outputs (stochastic or context- dependent) Governance Fully scripted, easy to audit & unit-test Harder to predict, relies on statistical confidence & guardrails Typical tech Rule engines, decision tables, DMN Deep-learning models (transformers, RNNs), probabilistic inference Primary risk “Rule explosion” & coverage gaps Bias, hallucination, drift, loss of traceability DMN = Decision Model & Notation RNN = Recurrent Neural Networks

@arafkarsh arafkarsh Recurrent Neural Networks (RNN) 16 Aspect Key points
What they are A family of neural nets that maintain a hidden state and loop it back into the model, making them naturally suited for sequential data. Math sketch h_t = f(W_{xh}x_t + W_{hh}h_{t-1} + b_h) — the same weights are reused at every time step. Training uses Back-Propagation Through Time (BPTT). Variants o LSTM (Long Short-Term Memory) and GRU (Gated Recurrent Unit) add gates to combat vanishing gradients. o Bidirectional RNNs look both forward and backward in the sequence. Strengths Good for moderate-length sequences (speech frames, sensor streams), compact parameter count. Limitations Hard to parallelise, struggle with very long-range dependencies (> ~200 tokens); prone to vanishing/exploding gradients. Classic uses Early language models, speech recognition, time-series forecasting, anomaly detection on IoT streams.

@arafkarsh arafkarsh Transformers 17 Aspect Key points Innovation Replace recurrence
with self-attention, letting the model weigh how every token relates to every other token in parallel (“Attention Is All You Need”, 2017). Core building block A Multi-Head Attention layer + position-wise feed-forward network; stacked N times with residual connections and layer norm. Scalability Parallelisable on GPUs/TPUs; performance scales almost linearly with data and parameters (scaling laws). Variants o Encoder-only (BERT, RoBERTa) for understanding tasks. o Decoder-only (GPT, Llama) for text generation. o Encoder-decoder (T5, PaLM-2) for seq-to-seq tasks like translation. Strengths Captures very long-range dependencies, supports billion-scale parameter counts, state-of-the-art in NLP, vision (ViT), protein folding, etc. Trade-offs O(N²) memory in vanilla form (mitigated by sparse, linear or sliding-window attention); needs large datasets and compute.

@arafkarsh arafkarsh Compare: DMN, RNN, Transformers 18 Feature DMN RNN
Transformer Paradigm Rule-based, deterministic Sequential neural net Self-attention neural net Determinism Yes (same inputs >> same output) No (probabilistic weights; may vary with sampling) No (probabilistic) Best for Business decisions, compliance logic Streaming data, modest sequences Long sequences, large-scale language & vision Explainability High (tables) Medium (some attribution) Lower (needs attention maps, SHAP, etc.) Compute style CPU-friendly, low latency Serial; limited parallelism Highly parallel on GPU/TPU

@arafkarsh arafkarsh Summary: DMN / RNN / Transformers 19 1.
DMN externalizes human-readable decision tables—perfect for transparent, auditable business logic. 2. RNNs model sequences by looping hidden state, but struggle with very long contexts and parallelism. 3. Transformers use self-attention to see the whole sequence at once, enabling today’s most capable language and vision models. 4. Pick the tool that matches the problem: deterministic rules for clear-cut policies; RNNs or Transformers for pattern-rich, data- driven tasks where flexibility trumps hard-coding.

@arafkarsh arafkarsh Key Takeaways 20 o Variable outputs: identical inputs
can yield different responses because the system relies on probabilistic sampling or context-dependent state. o Data-driven logic: decision patterns are learned from historical data via machine-learning models rather than hard-coded rules. o High adaptability: can generalize to novel scenarios and language variations without manual rule updates, making it powerful for open-ended tasks. o Explainability challenges: reasoning is statistical, so audits require techniques like feature attribution, confidence scoring, and guardrails to manage risk. o Continuous tuning needed: retraining or fine-tuning improves performance but can introduce unpredictable side effects, demanding rigorous validation and monitoring for drift or bias.

@arafkarsh arafkarsh 3 Idempotent System o Concept of Idempotent System
o Case Study 1: Updating Phone Number o Case Study 2: Cancelling Order o How to enforce Idempotency o Why should your Architecture care? 21

@arafkarsh arafkarsh Idempotent Concept 22 Term Plain-English meaning Why it
matters in software Idempotent action You can perform the same action once or 100 times and the end-state is identical—no duplicates, no incremental side-effects. Guarantees safety under retries, network glitches, or impatient users pressing a button repeatedly.

@arafkarsh arafkarsh Case Study 1: Updating Phone Number 23 #
1 Client sends PUT /users/123/phone with body { "phone": "+91-9876543210" } and an Idempotency-Key header abc-123. 2 o Server checks key abc-123 in a deduplication table. o Not found? Process the change, write “+91-9876543210” into the phone column, store the key with a 24 h TTL. o Found? Skip the update and simply return the first response again. 3 Whether the client retries once or ten times (same body, same key), the phone column still contains the same value; audit log shows only one logical change. Why it must be idempotent o Mobile apps often auto-retry on spotty 4G connections. o Ensures billing/SMS gateways don’t get duplicate “number change” events. Bank App: Editing your mobile number in your bank’s profile page.

@arafkarsh arafkarsh Case Study 2: Cancelling Order 24 E-Commerce App:
Hitting “Cancel Order” twice on Amazon because the page seemed to hang. Event sequence Desired final state o API call POST /orders/987/cancel with idempotency key can-987. o User clicks again; browser re-sends the same request (same key) or the backend job retries after a timeout. o Order status should be CANCELLED exactly once; o refund issued once; o inventory restored once; single email confirmation sent. Typical safeguards 1. Order state machine – only allow transition from NEW >> CANCELLED; further cancels are no- ops. 2. Idempotency key – logged with the order so duplicate requests short-circuit. 3. Database uniqueness – refund row keyed by order_id to block double credits.

@arafkarsh arafkarsh How to enforce Idempotency? 25 Technique How it
enforces idempotency HTTP verbs (PUT, DELETE) Spec define them as idempotent: “Replace resource with this exact representation” or “Remove it.” Idempotency-Key header Client generates a UUID per logical operation; server caches result keyed by that UUID for a window (Stripe, Razorpay APIs). State-transition guards Finite-state machine in DB ensures illegal or repeat transitions are ignored. Database constraints Unique index on (order_id, action) prevents double inserts (e.g., duplicate refunds). Retry logic in message queues Consumers treat duplicate messages as harmless because they re-check the authoritative record before acting.

@arafkarsh arafkarsh Why Should Your Architecture Care? 26 1. Network
reliability: Retries from load balancers, SDKs, or message queues are inevitable. 2. User experience: Double-clicks or back-button resubmits shouldn’t create duplicate side-effects. 3. Financial correctness: Prevents double billing, double refunds, or inconsistent inventory. 4. Regulatory/audit clarity: Single auditable event instead of a chain of partial duplicates. 5. Simpler recovery: If a service crashes mid-flow, replaying the same command is safe.

@arafkarsh arafkarsh Key Takeaways 27 o Same effect, no matter
how many times an operation is executed; retries or double-clicks leave state unchanged. o Achieved through design patterns such as PUT/DELETE verbs, Idempotency- Key headers, state-machine guards, and DB uniqueness constraints. o Real-world examples: editing a user’s phone number or cancelling an order— one logical change, even if the API call is repeated. o Protects against network retries, user impatience, and system crashes, preventing duplicate charges, refunds, or inventory errors. o Boosts auditability and resilience, ensuring critical workflows stay correct without complex rollback logic Treat critical state-changing operations—like profile edits or order cancellations—as idempotent commands. You’ll gain robustness against retries, better auditability, and a smoother user experience.

@arafkarsh arafkarsh 4 Non-Idempotent System o Concept of Non-Idempotent System
o Case Study 1: Banking Transaction (Credit/Debit) o Case Study 2: Stock Purchases 28

@arafkarsh arafkarsh Non-Idempotent Concept 29 Term Plain-English meaning Key property
Non- idempotent action Doing it twice amplifies the effect— each invocation changes state further. Same request ≠ same result

@arafkarsh arafkarsh Case Study 1: Banking Transactions (Credit/Debit) 30 Scenario
What happens Why it’s non-idempotent NEFT/IMPS transfer: You instruct the bank to credit ₹10,000 to a friend. A network glitch makes the mobile app resend the request. Two separate postings hit the core ledger; friend’s balance +₹20,000, your balance –₹20,000. Each message is treated as a new monetary event; ledgers must preserve an exact audit trail— replaying the instruction legitimately moves real money again. Safeguards in the real world 1. Unique transaction reference (UTR/IMPS ID): Front-end generates a UUID so duplicates can be spotted before they reach the payment switch. 2. Ledger immutability: Even if a duplicate slips through, the correction is a reversal entry, never a silent edit, to keep the audit complete. 3. User-visible status: Mobile apps show “Processing / Completed” to deter repeated taps.

@arafkarsh arafkarsh Case Study 2: Stock Purchases (Equities or Mutual
Funds) 31 Scenario What happens Why it’s non-idempotent You place an order to buy 100 shares of TCS at market price. Unsure it went through, you click “Submit” again. Two separate orders are routed to the exchange; you now own 200 shares and owe double the cash plus brokerage. Each order ID represents a legally binding trade; exchanges can’t “merge” or ignore the second order. Broker & Exchange controls o Client Order ID: The trading front-end tags each submission; back-office reconciliations flag duplicates after execution so the trader can decide to manually offset (sell back) if unintended. o Throttling / Confirm dialogs: Many broker apps block repeat clicks within a few seconds or require a slide-to-confirm gesture to reduce accidents—but they do not treat duplicates as the same order.

@arafkarsh arafkarsh Key Takeaways 32 o Non-idempotent actions are intentional;
business rules require every invocation to leave a new, immutable trail (money moved, shares bought). o Systems rely on strong identifiers, audit entries, and user confirmations to mitigate accidental repeats rather than ignoring them. o Developers must decide early which API endpoints are safe to retry (idempotent) and which must be guarded carefully (non- idempotent) because each call has financial or legal consequences.

@arafkarsh arafkarsh 5 Rule based Architecture o Concept of Rule
based Architecture o Case Study 1: Rental Loan Approval, Why Rules? o Case Study 2: Fraud Detection, Why Rules? o Case Study 3: Network Security Policies o Best Practices 33

@arafkarsh arafkarsh Rule Based Architecture 34 A software style where
declarative rules o IF conditions o THEN actions drive decisions. Instead of hard-coding logic in many services, you externalize it into a rules/decision service so that policies can be changed quickly and audited. Core parts o Knowledge base: the rules (often in a DSL, decision tables, or DMN). o Working memory / facts: input data (e.g., an application, a transaction, a request). o Inference engine: evaluates rules (forward chaining is common; Rete/Phreak algorithms are typical). o Decision service API: stateless HTTP/gRPC endpoint; integrates with apps, queues, streams. o Authoring & governance: versioning, testing/simulation, approvals, and audit. Where it shines o Stable, compliance/policy-heavy domains. o Clear, explainable decisions with auditable trails. o Frequent rule changes by non-developers (product, risk, compliance).

@arafkarsh arafkarsh Case Study 1: Retail Loan Approvals 35 Context:
A lender wants rapid, consistent decisions and easy policy updates. Architecture (typical) 1. Origination app (web/mobile) submits an application event to Kafka (or calls synchronously). 2. Decision service (rules engine) pulls the application facts (KYC, credit score, income, bureau hits). 3. Rule sets compute an outcome (APPROVE, REFER, DECLINE) + reasons and a risk grade. 4. Downstream workflows (document collection, underwriting queue) branch on that decision. Credit score DTI Income Flags (KYC, Fraud) Decision Max Amount ≥ 780 ≤ 35% ≥ ₹8L none APPROVE ₹20L 700–779 ≤ 40% ≥ ₹6L none APPROVE ₹12L 650–699 ≤ 45% ≥ ₹4L none REFER ₹6L < 650 any any any DECLINE 0 Decision Table DTI = Debt-to-Income ratio

@arafkarsh arafkarsh Why rules? 36 o Risk & compliance can
change thresholds (e.g., RBI policy updates) without code releases. o Every decision returns explainability: “Declined because DTI > 45% and score < 650.” o Versioned policies by effective date for audit. Common add-ons o ML hybrid: a model provides a risk score; rules set policy guardrails (e.g., “never approve if suspected identity theft”). o Simulation: run new rules on last 90 days of applications to check approval/PNR impact before go-live.

@arafkarsh arafkarsh Case Study 2: Fraud Detection (rule-centric baseline) 37
Context: Real-time card payments or UPI/P2M transfers. Typical flow 1. Transaction stream (Kafka/Kinesis) >> Stream processor (Flink/Spark Streaming) >> Rules service. 2. Enrich with geolocation, device fingerprint, merchant category, historical velocity. 3. Rules compute risk score & actions: ALLOW, CHALLENGE (OTP/step-up), or DECLINE; plus reasons. Concrete rules o Velocity: “More than 5 transactions > ₹10,000 in 10 minutes >> CHALLENGE.” o Impossible travel: “Login at 10:00 from Kochi and at 10:45 from Paris >> DECLINE.” o MCC block: “New device + first-time merchant in MCC 7995 (high-risk) + amount > ₹50,000 >> CHALLENGE.” o List checks: “If PAN or device on watchlist >> DECLINE.” MCC = Merchant Category Code MCC 7995 = Gambling and Betting • Gambling sites have elevated charge-back and money-laundering risk.

@arafkarsh arafkarsh Why Rules? 38 o Immediate, deterministic controls for
regulatory compliance and known patterns. o Easy to explain to customers and auditors (“declined due to velocity rule X”). o Often combined with ML anomaly scores; rules set thresholds and block certain categories outright. Operational tips o Maintain salience/priority to resolve rule conflicts. o Use feature stores or fast caches for recent history (velocity windows). o Provide reason codes back to channels to reduce support calls.

@arafkarsh arafkarsh Case Study 3: Network Security Rules 39 Firewalls
and Access Controls – ACL Context: Enforcing traffic policy in data centers, cloud VPCs, and microservices. Firewall ACL examples o Perimeter firewall (stateful): 1. Allow outbound TCP 443 to sanctioned update repos. 2. Allow inbound 443 to public LB from India IP ranges. 3. Deny all (implicit/explicit). o East-west policy (Zero-Trust, service mesh): 1. “payment-svc may call tax-svc on TCP 8443 only if request has sub=invoice- processor and env=prod.”

@arafkarsh arafkarsh Best Practices 40 Data & performance o Cache
reference data (rate cards, watchlists). o Pre-compute sliding windows for velocity rules. o Partition by key (customer, card, device) to keep state local in stream processors. Governance o Treat rules like code: version control, pull requests, unit tests, regression suites. o Simulation on historical data before deployment. o A/B or canary to measure business impact. o Maintain effective-date windows and jurisdictional variants (e.g., EU vs. India). Observability o Emit decision traces: input hash, matched rules, outcome, latency. o KPIs: approval rate, false positives/negatives, manual review load, SLA adherence.

@arafkarsh arafkarsh Key Takeaways 41 o Externalizes “IF … THEN
…” logic from application code o Evaluates rules against incoming facts to return deterministic decisions. o Agility: non-developers (risk, ops, compliance) can change policies without redeploying code o Transparency: every decision is explainable, testable, and audit-ready o Governance: version control, simulation, and effective-date scheduling keep policy changes safe When to prefer rules vs. ML o Rules: policy/eligibility, regulatory “must/never” constraints, stable heuristics, explainability required. o ML (with rules guardrails): fuzzy patterns (fraud rings), personalization, anomaly detection. A Business Rule Engine lets you separate rapidly-changing business logic from slow-changing application code, enabling faster iteration, stronger governance, and fully explainable decisions.

@arafkarsh arafkarsh 6 Simulation based Architecture o Concept of Simulation
Based Architecture o Simulation Building Blocks o Case Study 1: Weather and Climate Monitoring o Case Study 2: Traffic Simulation o Case Study 3: Financial Market Predictions o Best Practices 42

@arafkarsh arafkarsh Simulation based Architecture 43 A simulation-based architecture reproduces
the behaviour of a real- world system inside a computational twin. The pattern is cyclical: o ingest >> o simulate >> o analyze >> o act >> o learn. Simulate Analyze Act Learn Ingest

@arafkarsh arafkarsh Simulation: Building Blocks 44 Layer Purpose Typical Tech
Model library Mathematical / agent-based representation of the system PDE solvers, agent frameworks, DMN, FMU Scenario generator Creates “what-if” inputs (weather fronts, traffic incidents, market shocks) Monte-Carlo samplers, synthetic data tools Simulation engine Runs models at scale (often HPC or GPU) MPI clusters, Kubernetes batch, CUDA Data assimilation / replay Feeds real telemetry back into the model for accuracy 4D-Var, Kalman filters, Kafka, time-series Database Results store & analytics Dashboards, alerting, AI post- processing Parquet/Lakehouse + BI, Grafana Decision hook Sends insights back to planners or autonomous controllers APIs, event buses, control loops PDE = Partial Differential Equation DMN = Decision Model & Notation HPC = High Performance Computing FMU = Functional Mock-up Unit GPU = Graphical Processing Unit MPI = Message Passing Interface CUDA = Compute Unified Device Architecture

@arafkarsh arafkarsh Case Study 1: Weather & Climate Modelling 45
Real-world example – ECMWF Integrated Forecasting System (IFS) o Runs a 51-member ensemble twice daily at ≈9 km global resolution. o Assimilates 50 + million satellite & in-situ observations each cycle (4D-Var). o Produces hour-by-hour forecasts up to 15 days and seasonal outlooks. o An AI-assisted variant (AIFS) now outperforms physics-only runs by ~20 % and will shift to diffusion-model ensembles next year (2026). ECMWF = European Centre for Medium-Range Weather Forecasts AIFS – Artificial Intelligence Forecasting System The ensemble design plus continuous assimilation makes the system both probabilistic and self-correcting.

@arafkarsh arafkarsh Case Study 2: Traffic Simulation 46 Real-world example
– Singapore’s island-wide digital twin (Aimsun Live) o Lane-level model of 9000 km of roads, updated every 60s with loop-detector and camera data. o Operators test signal-timing or road-closure scenarios virtually before applying them on the street. o Achieved 23 % reduction in average congestion minutes during a 2024 port- access pilot. Architecture highlights Edge IoT >> Kafka | Stateful agent-based sim on Kubernetes | Control-centre API The sim can be rewound to replay yesterday’s rush hour or fast-forward to evaluate a future event.

@arafkarsh arafkarsh Case Study 3: Financial Market Predictions 47 Real-world
example – BlackRock Aladdin Scenario Engine & central-bank stress tests o Ingests live Bloomberg feeds and order books. o Generates tens of thousands of Monte-Carlo paths for rates, FX, credit spreads, plus agent-based liquidity models. o Aggregates VaR, Expected Shortfall, climate-risk metrics for 11,000 + portfolios (≈ US $25 tn AUM) overnight. o Outputs drive margining, hedging, and board-level capital planning. VaR = Value-at-Risk AUM = Assets Under Management VaR quantifies potential loss, while AUM tells you how big the pile of invested money is. Why simulation? Real markets only deliver one price path; simulations expose the tail-risk management cares about.

@arafkarsh arafkarsh Best Practices 48 o Treat the simulation as
a first-class microservice, not a side tool. o Automate scenario generation, execution, and result scoring in CI/CD pipelines. o Couple with real-world telemetry to keep the twin in sync and improve forecasting skill. o Provide traceability: each run is versioned (code + data + seed) for audit and reproducibility. Simulation-based architectures let organizations explore “what if?” safely and at scale—saving years, rupees, or lives before acting in the physical world.

@arafkarsh arafkarsh Key Takeaways 49 o Build a computational twin
of the real world >> run “what-if” experiments safely, cheaply, and fast. o Cycle: ingest data >> simulate >> analyze >> act >> learn. Why It Matters o Reveals outcomes you can’t observe in reality (extremes, future years, rare events). o Cuts physical-testing costs (wind tunnels, road miles, crisis drills). o Provides probabilistic insight and decision support under uncertainty. Common Layers o Model Library – physics, stochastic, or agent- based equations o Scenario Generator – Monte-Carlo shocks / synthetic events o Simulation Engine – HPC / GPU grid, scalable batch on Kubernetes o Data Assimilation / Replay – keeps the twin in sync with real telemetry o Results Store & Analytics – LakeHouse + BI, notebooks, alerting o Decision Hooks – APIs or event buses that feed planners, traders, AV stacks

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

@arafkarsh arafkarsh Management Pipeline Automation Architecture SpecOps Workflow – Secure
SDLC 51 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

@arafkarsh arafkarsh Requirements & Specifications 52 Requirements Focus on “What”
What the System should do o High Level Abstract o Written in Plain Language o Themes, Initiatives, Epics o User Stories, Acceptance Criteria o User Story Maps o Minimum Viable Product Specifications Focus on “How” How the System solves the problem o Detailed and Precise o Technical Language o System Architecture o Application Architecture o Data Architecture o Security Architecture Non-Functional Requirements o Observability (Logs, Trace, Metrics) o Scalability & Performance o Availability & Fault Tolerance o Security & Compliance o User Experience & Accessibility o Internationalization

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

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

@arafkarsh arafkarsh Business Architecture 55 A structural view of how
the organization creates value: capabilities, value streams, policies, org units, and the business processes that stitch them together. It’s technology-agnostic and describes what the business must be able to do to hit strategy. Scope o Vision >> goals >> value streams >> capabilities >> policies/risks >> metrics. o Stakeholders, RACI, and operating model. Typical artifacts o Capability map (L1–L3), value-stream maps, customer journey maps. o Policy catalogs and business rules, KPI trees/OKRs. o Process models (BPMN) at “just enough” detail.

@arafkarsh arafkarsh Business Architecture 56 Key decisions o Target capabilities
to invest in; sourcing (build/buy/partner); operating model changes. o Prioritized outcomes and measurable acceptance criteria. Interfaces o Feeds Application Architecture via capability >> application/service mapping. o Drives Data Architecture with information concepts and KPIs. o Informs Security Architecture with risk appetite and control objectives. Common pitfalls o Mistaking “org chart” for capabilities. o Jumping to solutions before agreeing on target capabilities and measures.

@arafkarsh arafkarsh Application Architecture 57 A logical blueprint of applications
and services that realize business capabilities, plus their interactions and integration styles. Scope o Application portfolio (systems of record/engagement/insight), service boundaries, APIs/events, integration patterns. o Non-functional needs at the app level (latency, resilience, compliance). Typical artifacts o Application landscape map; context and container views (C4 L1–L2). o API and event catalogs; integration contracts; sequence/communication diagrams. o Decomposition docs (domain maps, DDD bounded contexts).

@arafkarsh arafkarsh Application Architecture 58 Key decisions o Service boundaries
(by domain), integration styles (sync REST/gRPC vs async events), strangler-fig migration pathways from monoliths. o Buy vs build; SaaS fit and exit strategy. Interfaces o Realizes business capabilities; consumes/produces Data through well-defined contracts; runs atop Technology; must satisfy Security controls. Common pitfalls o “Entity-driven” microservices (CRUD-by-table) instead of domain-driven boundaries. o Point-to-point integration sprawl (tight coupling, change amplification).

@arafkarsh arafkarsh Technology Architecture 59 The computing and platform foundation:
runtime, networks, storage, platform services, observability, and delivery tooling needed to host the applications. Scope o Infrastructure (on-prem/cloud/edge), networking, platform services (Kubernetes, service mesh, messaging, caches, DB engines), CI/CD and SRE practices. Typical artifacts o Reference architectures (landing zone, VPC/VNet/peering), environment topologies (dev/stage/prod), capacity & SLO models, platform service catalog, IaC baselines. Key decisions o Platform stack selection (e.g., K8s + Istio, Kafka, Redis); multi-AZ/region strategy; resilience and failover patterns; golden paths and paved roads for teams.

@arafkarsh arafkarsh Technology Architecture 60 Interfaces o Provides runtime and
platform guarantees for Applications; hosts Data platforms; enforces Security controls (networking, secrets, policy-as-code). Common pitfalls o Over-customizing the platform (snowflake clusters). o Ignoring operability: weak logging/metrics/tracing and no error budgets.

@arafkarsh arafkarsh Database Architecture 61 The model of the enterprise’s
information: data domains, flows, storage / processing patterns, quality / governance, and lifecycle. Scope o Conceptual >> logical >> physical models; master/reference data; lineage and metadata; data platform choices (OLTP/OLAP/lakehouse/streaming). Typical artifacts o Enterprise data model and domain maps; canonical event definitions; data catalog & glossary; retention/classification matrix; lineage diagrams. Key decisions o Domain ownership (data mesh vs centralized), storage/processing patterns (OLTP vs OLAP vs streaming), SCD approach, CDC strategy, privacy & retention rules.

@arafkarsh arafkarsh Database Architecture 62 Interfaces o Supplies information to
Business KPIs; contracts with Applications (schemas/events/APIs); relies on Technology for platforms; bound by Security policies. Common pitfalls o Treating the warehouse as the integration layer for operational needs. o Schema drift and “Excel as a service” shadow systems.

@arafkarsh arafkarsh Security Architecture 63 Risk-driven design of controls across
identity, data, application, and infrastructure—threat models, policies, and the technical patterns that enforce them. Scope o IAM (authn/authz, federation, least privilege), network segmentation/zero trust, secrets management, cryptography, app-sec patterns, data protection, detection/response. Typical artifacts o Threat models (STRIDE, attack trees), control catalogs mapped to frameworks (e.g., NIST 800-53/ISO 27001), reference designs (mTLS, token flows), SBOM/SLSA supply-chain posture, incident response playbooks. Key decisions o Trust boundaries and posture (zero trust tiers), key management (HSM/KMS), token strategy (OAuth2/OIDC/JWT, token exchange), encryption at rest/in transit, data classification & DLP, vulnerability management & SCA.

@arafkarsh arafkarsh Security Architecture 64 Interfaces o Derives objectives from
Business risk appetite; constrains Application designs (e.g., token scopes, mTLS); depends on Technology enforcement (policy-as-code, WAF); guards Data (classification, masking, retention). Common pitfalls o Paper controls without runtime enforcement or monitoring. o “Encrypt everything” without key lifecycle or performance modeling.

@arafkarsh arafkarsh Putting it together 65 1. Strategy >> Business
Architecture defines target capabilities and measurable outcomes. 2. Application Architecture maps those capabilities to domains/services and integration patterns. 3. Data Architecture defines the information contracts, ownership, and pipelines those services use. 4. Technology Architecture provides the platform and SLOs to run the lot. 5. Security Architecture overlays risk-driven controls across all layers, verified in code and telemetry.

@arafkarsh arafkarsh Case Study: Health Care App 66 o Business:
Capability “Manage Appointment Lifecycle” with KPIs: booking lead time, no-show rate, patient NPS. o Application: Patient App, Scheduling Service (bounded context), Provider App; async events AppointmentBooked, AppointmentCancelled; API for slot search. o Technology: K8s with a service mesh for mTLS, Kafka for events, Redis for slot cache, Postgres for scheduling. o Data: Domains “Patient”, “Provider”, “Appointment”; immutable event log for audit; retention 7 years for PHI with masking on analytics views. o Security: OIDC flows (confidential PKCE), token scopes per operation, FHIR-aligned data classification, envelope encryption using KMS, DLP on analytics exports, anomaly alerts for mass-access.

@arafkarsh arafkarsh Deliverables by Domain 67 Domain Questions it answers
Core deliverables “Done means…” checks Business What value, for whom, measured how? Capability map, value streams, KPIs, process models Capabilities prioritized with OKRs; owners named Application Which services/apps and how they talk? App landscape, C4 L1–L2, API/event catalog, sequences Clear service boundaries; integration style chosen Technology Where does it run and how it’s operated? Reference platform, env topology, SLO/error budgets, IaC baselines Repeatable “paved road” with golden templates Data What data, who owns it, how it moves? Conceptual/logical models, glossary, lineage, retention/classification Contracts versioned; lineage & quality monitored Security What can go wrong and how is it controlled? Threat models, control catalog, ref designs, incident runbooks Controls enforced by policy-as-code & observability

@arafkarsh arafkarsh Key Takeaways 68 o Business Architecture: capabilities, value
streams, policies, KPIs, and operating model decisions that drive everything downstream. o Application Architecture: domains/bounded contexts, service boundaries, APIs/events, and integration styles (sync vs async) to realize capabilities. o Technology Architecture: platforms, networks, runtimes, SRE/CI-CD, resilience and SLOs—the paved road for teams. o Data/Database Architecture: domains, models, lineage, retention/classification, and ownership (e.g., mesh) powering KPIs and contracts. o Security Architecture: risk-driven controls across identity, app, data, and infra (OIDC, mTLS, KMS, DLP, supply-chain posture). o Integration: strategy >> business >> application >> data >> technology with security overlay; validated via a healthcare case study and domain deliverable checklists.

@arafkarsh arafkarsh Solutions Architecture 69 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

@arafkarsh arafkarsh 70 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

@arafkarsh arafkarsh 71 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?

@arafkarsh arafkarsh 1 Capability Centric Design o From Object Modeling
to Process Modeling o Business Solution and Business Process & Data Flow Diagrams o Compare Activity Oriented to Outcome Oriented o Core Principles of Capability Centric Design 72

@arafkarsh arafkarsh From Object Modeling to Process Modeling 73 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

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

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

@arafkarsh arafkarsh System Context Diagram / Data Flow Diagram –
L0 76 • 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.

@arafkarsh arafkarsh Business Solution & Business Process / Capabilities 77
User Journey with Story Map Payment Registration Doctors Diagnosis Pharmacy Ward Patient Microservices Business Solution: Patient Hospital Experience Core Domain Sub Domain Sub Domain Sub Domain Sub Domain Generic Domain Sub Domain Business Solution: User Shopping Experience Browse Products Add to Shopping Cart Select Shipping Address Confirm Order Make Payment Catalogue Shopping Cart Order Payment Customer View Product Search Core Domain Sub Domain Sub Domain Sub Domain Generic Domain Sub Domain Domain Driven Design: Core Domain, Sub-Domain, Generic Domain

@arafkarsh arafkarsh Business Solution & Business Process / Capabilities 78
User Journey with Story Map Core Domain Sub Domain Sub Domain Generic Domain Core Domain Sub Domain Generic Domain Order Management Production Scheduling Inventory Management Procurement Management Quality Control Warehouse Management Shipping & Logistics Customer Service Generic Domain Business Solution: Manufacturing – Order Processing Experience Business Solution: Customer Dining Experience Order Payment Food Menu Kitchen Dining Browse Menu Order Dinner Dinner Served Get Bill Make Payment Core Domain Sub Domain Sub Domain Sub Domain Generic Domain Domain Driven Design: Core Domain, Sub-Domain, Generic Domain

@arafkarsh arafkarsh From Project Based Activity Oriented To Product Based
Outcome Oriented Source: Sriram Narayan– https://martinfowler.com/bliki/BusinessCapabilityCentric.html 79 Traditional corporate IT organizations operate in an activity-oriented manner where they fund projects with set time-spans. Organizations that are outcome-oriented align better with business outcomes, but project-based funding undermines long- term effectiveness. Basing funding on products centered around long-term business capabilities creates stable teams that are aligned with business needs. Outcome-oriented thinking compels business capability centered organizations to consider more than just delivering the scope, which is where we want to be. Project based Product based Activity Oriented Outcome Oriented Business Capability Centric

@arafkarsh arafkarsh Business Capability Centric Design 80 Business Centric Development
• Focus on Business Capabilities • 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, leading to bottlenecks and a 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

@arafkarsh arafkarsh Core Principles of CCD 81 o Business-Outcome Orientation:
Capabilities align directly to strategic objectives and outcomes, not just operational tasks. o Stable but Evolving Building Blocks: Capabilities are relatively stable over time (e.g., "customer relationship management") even as processes, tools, or structures change around them. o Cross-Functional Integration: CCD encourages breaking down silos, since most capabilities require collaboration across different domains (business, technology, data, operations). o Technology as an Enabler, Not the Starting Point: Systems and platforms are designed to support capabilities, rather than adopting technology first and then finding where to apply it. o Prioritization via Value and Maturity: Capabilities are assessed for current maturity, business criticality, and potential value to guide investment decisions. o Reusable Patterns of Design: By focusing on capabilities, organizations create modular, reusable designs that can be adapted across products, services, or market units.

@arafkarsh arafkarsh Key elements of CCD 82 1. Capability map
(levels 1-3). A visual, hierarchical map of what the enterprise does. Use it to find overlaps, gaps, and priority areas. 2. Value streams capabilities. Link capabilities to the value streams (end-to-end flows that produce outcomes). This shows where a capability contributes to customer value and where to invest. 3. Capability fitness (maturity/health). Assess each capability’s people, process, tech, data, controls, SLOs, and cost. Target weak but critical capabilities for uplift. 4. Capability applications/services mapping. Trace which apps, APIs, and data products implement each capability. This reveals duplication and coupling and guides modernization.

@arafkarsh arafkarsh Key elements of CCD 83 5. Bounded contexts
(DDD). For each important capability, define a bounded context—a coherent language, model, and data boundary. Keep models clean; integrate contexts via explicit contracts/events. 6. Policies & SLOs by capability. Own security controls, compliance requirements, performance SLOs, and cost guardrails per capability (e.g., “KYC must meet X regulation; Onboarding SLO p99 < 800 ms”). 7. Roadmaps & funding via capability-based planning. Plan initiatives as capability uplifts (build, fix, retire). This keeps strategy and spend tied to outcomes rather than projects.

@arafkarsh arafkarsh Key Elements – Expected Outcomes 84 # Artifact
Purpose “Done right” signals 1 Capability Map (L1– L3) Common language for what we do Stable for years; used in portfolio reviews and team design. 2 Value-Stream Capability Matrix Shows where value is created Clear hotspots for investment; fewer hand-offs. 3 Capability Health Scores Prioritize uplift Evidence-based maturity + SLO/Cost/Risk metrics. 4 Capability Services/APIs Map Reduce duplication/coupling One team clearly owns each capability API surface. 5 Bounded Contexts Protect domain models Ubiquitous language per context; explicit contracts/events.

@arafkarsh arafkarsh Key Takeaways 85 o Organize around business capabilities—the
stable what we do, not the volatile how we do it—to anchor strategy, architecture, and teams. o Create a Capability Map (L1–L3) and link it to value streams/KPIs to expose overlaps, gaps, and high-leverage investment areas. o For each priority capability, define a DDD bounded context with a clear domain language, explicit contracts (APIs/events), and a map of apps/services/data that implement it. o Assign single ownership: one stream-aligned team per capability, supported by platform, enabling, and complicated-subsystem teams to manage cognitive load and speed flow. o Treat policies as part of the contract: SLOs, security/compliance controls, data ownership/versioning, and cost guardrails are owned per capability. o Plan and fund as capability uplifts (build, fix, retire) and track capability fitness (maturity, SLO attainment, unit cost, risk) rather than feature/output counts. o Avoid traps: mirroring org charts, fuzzy boundaries, shared databases across capabilities, and project slices that cut across many capabilities; prefer events + versioned APIs for integration.

@arafkarsh arafkarsh 2 Capability Centric Design - Implementation o How
to implement CCD o Building a Team for CCD o Team Structure & Operating Model o Case Study o Pitfall to Dodge 86

@arafkarsh arafkarsh How to Implement CCD 87 1. Discover &
map. Start with an L1 capability map from strategy docs and customer journeys; decompose top priorities to L2/L3. 2. Connect to value. Attach capabilities to value streams and KPIs. Mark “critical, weak, high-risk” hotspots for uplift. 3. Carve boundaries. For each high-value capability, define its bounded context, core entities, events, and external contracts (APIs/queues). 4. Assign ownership. One team owns one capability API/data product. Avoid shared ownership of core paths. 5. Set SLOs & policies. Security, compliance, and performance SLOs become part of the capability contract. 6. Plan by capability. Create a capability-uplift roadmap (foundational enablers, target state, dependencies), not a feature list.

@arafkarsh arafkarsh Building a Team for CCD 88 CCD pairs
beautifully with Team Topologies. Use these four team types to match capability boundaries and flow of change: o Stream-aligned teams own a capability end-to-end (“you build it, you run it”). o Platform teams offer reusable infrastructure and internal products that accelerate stream teams. o Enabling teams coach on gaps (e.g., data, SRE, security). o Complicated-subsystem teams take on gnarly internals to reduce cognitive load for everyone else.

@arafkarsh arafkarsh Team Structure 89 Typical stream-aligned (capability) team makeup
o Product Manager/Owner (value & roadmap tied to capability KPIs) o Lead/Staff Engineer (tech strategy & contracts) o Backend/API & Frontend engineers (if capability is user-facing) o Data engineer/analyst (events, data product, quality) o SRE/Platform liaison (SLOs, reliability, cost) o Security/Compliance liaison (policy as code, audits)

@arafkarsh arafkarsh Engineering Pod (Team) Size 90 5 Manager Architect
Sr. Engineer Engineers 7 Manager Architect Sr. Engineer Engineers Engineering Pods are created based on Various Team Size Configurations As per Business Capability Requirement • 5 Members • 7 Members • 9 Members

@arafkarsh arafkarsh Roles & Responsibilities and Tech Stack 91 Category
Role Type Responsibilities Tech Stack 1 Customer Product Owner External • Complete Product Vision • Specifications (User Stories, Acceptance Criteria) • User Stories • BDD – Acceptance Criteria 2 Engineering Pod Cloud Manager / Analyst Internal • Analyst & Specifications (User Stories, Acceptance Criteria) • Feature Management in Production & Focused on Outcome • Scrum Master & Team Management • Design Thinking • Lean Startup • Agile (Kanban) 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) • Mentoring the team • Code Reviews (Functional / Infra Codes) • Deeper Understanding of Infra Stack • Event-Driven Architecture • Domain Driven Design • Data Flow Diagrams • Microservices Architecture • Data Mesh, Polyglot DB / Lang • Terraform, K8s, Service Mesh 4 Engineering Pod Cloud Sr. Engineer Internal • Mentor / Guiding Team on Technology • Product Development / Testing / Deployment • All the above • DevSecOps 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 • All the above • DevSecOps 6 Engineering Pod Cloud Network / Security Lead External • Define Network Policies • Define Security Policies • Review Infra Code for Network & Security Policies • Terraform / Kubernetes • Zero Trust / Service Mesh • DevSecOps 7 Engineering Pod Cloud User Experience Lead External • Usability Guidelines • Data Flow Guidelines • Human-Computer Interface • Material Design Guidelines

@arafkarsh arafkarsh Operating Model 92 o One team one capability
(or tightly related sub- capabilities). o Team has clear inbound/outbound contracts: APIs, events, SLAs, and change policies. o Cross-capability dependencies handled with published events and versioned APIs; never hidden DB joins. o Funding and goals measured as capability fitness improvements (SLOs, cycle time, risk posture, unit cost).

@arafkarsh arafkarsh RACI Sketch 93 o Responsible: Stream-aligned team o
Accountable: Capability Product Owner o Consulted: Platform, Security, Data Governance, Risk/Compliance o Informed: Adjacent capability owners, Portfolio/PMO

@arafkarsh arafkarsh Case Study: Payment Settlement 94 o Bounded context:
Payment (Authorize, Capture, Refund, Reconcile) with events like PaymentAuthorized, PaymentCaptured, RefundIssued. o Contracts: REST/GraphQL for sync ops; Kafka topics payments.events.* for async. o SLOs: p99 ≤ 300 ms for authorization; availability ≥ 99.95%; ledger integrity guarantees. o Team: Stream-aligned “Payments” squad; Platform provides secrets, observability, PCI tooling; Enabling team helps with risk modeling. o Roadmap: “Improve authorization success rate by 1.5%” and “Cut reconciliation time by 80%”—both are capability outcomes, not features.

@arafkarsh arafkarsh Pitfalls to Dodge 95 o Treating “capability” as
a synonym for department— breaks when org charts shift. o Mapping processes before capabilities—start with what, then how. o Owning the same entity in multiple capabilities—use clear bounded contexts and contracts. o Project funding that slices across many capabilities— return to capability-based planning and invest where outcomes live.

@arafkarsh arafkarsh Playbook to run with your teams. 96 1.
Draft the L1-L3 capability map and validate with business leads. 2. Link to value streams and KPIs; score capability health. 3. Draw bounded contexts and contracts for top capabilities. 4. Stand up stream-aligned teams per capability; support with platform/enabling teams. 5. Fund and roadmap by capability uplift, measure via SLOs/fitness KPIs.

@arafkarsh arafkarsh Key Takeaways 97 o Implement: Draft an L1–L3
capability map and link it to value streams/KPIs to surface overlaps, gaps, and hotspots to fix first. o Design: For priority capabilities, carve DDD bounded contexts with clear domain language and explicit contracts (APIs/events); map apps/services/data ownership to each. o Govern: Make SLOs, security/compliance controls, and cost guardrails part of each capability’s contract; plan & fund via capability-uplift roadmaps tied to measurable outcomes. o Team structure: Stand up one stream-aligned team per capability, supported by platform, enabling, and complicated-subsystem teams; staff with PO/PM, lead engineer, FE/BE, data, and SRE/security liaisons. o Operating model: Enforce single ownership and inbound/outbound contracts; handle dependencies via events + versioned APIs (never shared DB joins); measure capability fitness (SLO attainment, cycle time, risk, unit cost). o RACI sketch: Responsible: stream-aligned team; Accountable: capability Product Owner; Consulted: platform, security, data governance, risk/compliance; Informed: adjacent capability owners and portfolio/PMO. o Pitfalls to dodge: Mirroring org charts, fuzzy boundaries, shared databases, process-before-capability mapping, project funding that slices across many capabilities, and tight coupling that bypasses contracts.

@arafkarsh arafkarsh 3 System Context Diagrams Data Flow Diagrams o
Data Flow Diagrams L0, L1, L2 Diagrams o Compare Data Flow Diagrams and Flow Charts 98

@arafkarsh arafkarsh Components of Data Flow Diagram 99 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

@arafkarsh arafkarsh 5 Main methods of Notations used in DFD
100 External Entity Process Store Data Flow Yourdon + De Marco SSADM Chris Gane & Trish Sarson <<process>> Unified <<entity>> 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

@arafkarsh arafkarsh Levels of Data Flow Diagram 101 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 / Capability 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

@arafkarsh arafkarsh Data Flow Diagram – Rules 102 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.

@arafkarsh arafkarsh Data Flow Diagram Rules 103 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.

@arafkarsh arafkarsh How to create a System Context Diagram 104
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.

@arafkarsh arafkarsh Data Flow Diagram – L1 106 • 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.

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.

@arafkarsh arafkarsh Drawbacks of Data Flow Diagrams 108 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.

@arafkarsh arafkarsh Benefits of Data Flow Diagrams 109 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.

@arafkarsh arafkarsh Best Practices 110 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.

@arafkarsh arafkarsh Key Takeaways 111 o DFD basics: entities, processes,
data stores, and flows—plus common notations (Yourdon/DeMarco, Gane–Sarson, SSADM, Unified). o Leveling: L0 (system context), L1 (main processes), L2 (sub-process detail) to progressively refine scope. o Canonical rules: no entity <> entity, no store <> store, no direct entity <> store; processes/stores require at least one in/out flow; avoid crossing lines. o How to build a context diagram: define boundary and internal roles, list external entities, identify bidirectional flows, review for gaps. o Tradeoffs: clarifies boundaries and dependencies but can oversimplify dynamics and omit UI/hardware/error paths. o Practice tips: consistent names, keep it simple, group related processes, label clearly, and validate with stakeholders.

@arafkarsh arafkarsh Software Architecture o 4+1 Architecture View Model o
Zachman Framework o C4 Model o ISO/IEC/IEEE 42010:2011 & 2022 o Views, Viewpoints & Perspectives 112

@arafkarsh arafkarsh 4 4+1 Architecture View Model o Logical View
o Process View o Development View o Deployment View 113 o Use Cases

@arafkarsh arafkarsh 4+1 Architecture View Model in Software 114 Logical
View Process View Development View Physical View Use Cases Software Philippe Kruchten: Inventor of the 4+1 Architectural View Model Class, Object, State & Package Systems Functionality Systems Runtime Behavior Sequence, Communication, Activity, Interaction Overview & Timing Component, Composite, & Package 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

@arafkarsh arafkarsh 4+1 Views – Logical / Process / Development
115 Logical View What the system must do o Represents: the system’s functional design: key abstractions, responsibilities, and relationships. It’s essentially the object model seen by end- users and analysts. o Audience: domain experts, product owners/BAs, application architects. o UML 2.5 diagrams (typical): Class, Object, State Machine, Package (for grouping). Mapping is conventional rather than mandated by the model. Development View How the code is organized o Represents: the static organization of the software in the development environment: modules, layers, libraries, ownership. o Audience: developers, build/release engineers, software leads. o UML 2.5 diagrams (typical): Component, Package, Composite Structure (to open up a component). Process View How it behaves at runtime o Represents: concurrency, distribution, inter-process communication, performance and scalability concerns. o Audience: system/solution architects, performance engineers, integrators. o UML 2.5 diagrams (typical): Sequence, Communication, Activity, State Machine, Timing, and Interaction Overview for higher-level orchestration.

@arafkarsh arafkarsh 4+1 Views – Physical View / Use Cases
116 Physical View Where it runs and how it’s wired o Represents: deployment topology—nodes (servers/VMs/containers), networks, and the mapping of artifacts to hardware/infra. o Audience: infrastructure/DevOps/SRE, network & security engineers. o UML 2.5 diagrams (typical): Deployment (optionally annotated with components/artifacts). “+1” Scenarios (Use-Case View) Why all this exists o Represents: a set of use cases or scenarios that illustrate and validate the architecture; they knit the four views together. o Audience: everyone—from stakeholders and testers to architects—because scenarios are the shared reference point. o UML 2.5 diagrams (typical): Use Case (primary), plus Sequence (to realize scenarios).

@arafkarsh arafkarsh 4+1 Architecture View Model in Software 117 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 Chart Object Package Sequence Communication Activity Timing Component Composite Package Deployment Use Case IEEE, November 1995: Architectural Blueprints – The 4+1 View Model of Software Architecture

@arafkarsh arafkarsh Unified Modelling Language 118 The Unified Modeling Language
(UML) is owned, standardized, and maintained by the Object Management Group (OMG), a non-profit standards consortium. OMG publishes and revises the UML specification and related standards. Structure diagrams 1. Class 2. Component 3. Composite Structure 4. Deployment 5. Object 6. Package 7. Profile Behavior diagrams 1. Use Case 2. Activity 3. State Machine. Interaction diagrams (behavioral subset) 1. Sequence 2. Communication (a.k.a. Collaboration) 3. Interaction Overview 4. Timing. Source: OMG – UML 2.5 Specs

@arafkarsh arafkarsh Key Takeaways 119 o Kruchten’s 4+1 model connects
Logical, Process, Development, and Physical views with scenario-driven Use Cases (“+1”). o Logical: what the system must do (classes/objects/states); audience includes domain experts and app architects. o Process: runtime behavior—concurrency, distribution, performance; uses sequence/activity/state/timing diagrams. o Development: code organization—components, packages, ownership and layering for build/release teams. o Physical: deployment topology—nodes, networks, artifact mapping; consumed by SRE/DevOps/security. o Use-case scenarios knit the four views and validate the architecture end-to-end for all stakeholders.

@arafkarsh arafkarsh Setting up the App Context o Health Care
App o System Context Diagram (DFD L0) o Data Flow Diagram L1 o Data Flow Diagram L2 120

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.

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.

@arafkarsh arafkarsh Behaviour Diagrams 1. Use Case 2. Activity 3.
State Machine 124

@arafkarsh arafkarsh 1. Use Case Diagrams 125 Created using PlantUML:
https://plantuml.com/use-case-diagram o Purpose: Capture external goals (user- or system-initiated) and the interactions needed to achieve them. Great for scoping features and aligning stakeholders on outcomes without design details. o Shows: Actors, use cases, associations, and relationships such as «include»/«extend». o Use when: You’re eliciting or communicating functional requirements; you need a high-level contract between business and engineering What does the system do for whom? | These diagrams are illustrative and may not represent production architectures.

@arafkarsh arafkarsh 2. Activity Diagram 126 Created using PlantUML: https://plantuml.com/activity-diagram-beta
o Purpose: Capture flows of control and data (branch/merge, parallelism with fork/join). Great for business processes, algorithms, or use-case realizations. o Shows: Actions, control nodes (initial, decision, merge, fork, join, finals), object flows, and partitions (swim lanes). What is the workflow? | These diagrams are illustrative and may not represent production architectures.

@arafkarsh arafkarsh 3. State Chart Diagram 127 Created using PlantUML:
https://plantuml.com/state-diagram o Purpose: Model the lifecycle of a thing (order, appointment, account), focusing on states and event- driven transitions, with guards and actions. Ideal when behavior depends on history. o Shows: Initial/final states, transitions, guards, entry/exit/do actions; can be behavioral or protocol state machines. How does an object change over time? | These diagrams are illustrative and may not represent production architectures.

@arafkarsh arafkarsh Interaction Diagrams 1. Sequence 2. Communication (a.k.a. Collaboration)
3. Interaction Overview 4. Timing. 128

@arafkarsh arafkarsh 1. Sequence Diagram 129 Created using PlantUML: https://plantuml.com/sequence-diagram
o Purpose: Detail a scenario’s time-ordered interactions across lifelines (services/objects), clarifying APIs, sync/async calls, and error paths. Excellent for contract-first service design. o Shows: Lifelines, messages (sync/async/return), frames (alt/loop/opt) for control logic. Who calls whom, and in what order? | These diagrams are illustrative and may not represent production architectures.

@arafkarsh arafkarsh 2. Communication Diagram 130 o Purpose: Show the
same interaction as a sequence diagram but emphasize the network of links between participants; messages are numbered rather than laid out on a timeline. Handy to visualize runtime topology of a collaboration. o Shows: Objects/parts and their links, with numbered messages indicating order. Which elements collaborate, and how are messages routed? | These diagrams are illustrative and may not represent production architectures. Created using PlantUML: Emulated Diagram

@arafkarsh arafkarsh 3. Interaction Overview 131 | These diagrams are
illustrative and may not represent production architectures. Created using PlantUML: Emulated Diagram How do multiple interactions compose? o Purpose: Provide a high-level control- flow of a scenario where each node is an interaction (or an interaction use), so you can stitch together smaller sequences into one coherent story (great for complex use cases with branches/parallelism). o Shows: Initial/Final nodes, decisions/merges, forks/joins and nodes that represent interactions (or references to them). It’s like an activity diagram whose actions are interactions.

@arafkarsh arafkarsh 4. Timing 132 Created using PlantUML: https://plantuml.com/timing-diagram When
do states/values change, and under what constraints? o Purpose. A timing diagram is a UML interaction diagram specialized for reasoning about time: how lifelines change state/value as time increases left >> right. It complements sequence diagrams by making durations, delays, and deadlines first-class citizens (axes are effectively “flipped” compared to sequences). o Shows. Parallel lifelines stacked vertically with states or values plotted along a time axis; state changes at marked times; optional message/constraint annotations. It’s used to verify latency/ordering requirements and to spot races or SLA violations. | These diagrams are illustrative and may not represent production architectures.

@arafkarsh arafkarsh Key Takeaways 133 o Use Case diagrams capture
goals and actor–system interactions for scoping functional requirements. o Activity diagrams model workflows with branching, merging, and parallelism (swim lanes for roles). o State machine diagrams show lifecycle states and event-driven transitions with guards/actions. o Sequence diagrams detail time-ordered interactions across lifelines; great for API and contract design. o Communication diagrams emphasize collaboration links and numbered message ordering. o Interaction overview diagrams compose multiple interactions into one control flow; o Timing diagrams make durations/deadlines explicit.

@arafkarsh arafkarsh Structural Diagrams 1. Class 2. Component 3. Composite
Structure 4. Object 134 5. Deployment 6. Package 7. Profile

@arafkarsh arafkarsh 1. Class Diagram 135 Created using PlantUML: https://plantuml.com/class-diagram
o Purpose: Describe the static model—classes, attributes, operations, and relationships (associations, compositions, generalizations). Useful from domain modeling through detailed design and even data modeling. o Shows: Types and their multiplicities/constraints; the backbone from which code and schemas are derived. What are the static structures? | These diagrams are illustrative and may not represent production architectures.

@arafkarsh arafkarsh 2. Component Diagram 136 Created using PlantUML: https://plantuml.com/component-diagram
o Purpose: Describe deployable/replaceable software units (components) and their provided/required interfaces— useful for service boundaries, ownership, and dependency analysis. o Shows: Components, interfaces (lollipops/sockets), ports, and dependencies across subsystems. How is the codebase organized into replaceable parts? | These diagrams are illustrative and may not represent production architectures.

@arafkarsh arafkarsh 2. Component Diagram 137 Created using PlantUML: https://plantuml.com/component-diagram
How is the codebase organized into replaceable parts? | These diagrams are illustrative and may not represent production architectures.

@arafkarsh arafkarsh 3. Composite Diagram 138 Created using PlantUML: Emulated
Diagram What’s inside this thing, and how do its parts talk? o Purpose. Show the internal structure of a classifier (a class or component treated as a container) and the collaboration of its parts—including the ports through which they interact and the connectors that wire them together. It’s the right tool when you need to open the box and explain how a “whole” (e.g., an Encounter) is realized by cooperating parts (Pre-Checkup, History accessor, Diagnostic engine, etc.). o Shows (core elements). Structured classifier (the “whole” you’re opening). Parts (roles/instances that make up the whole). Ports (interaction points exposing required/provided interfaces). Connectors (wiring): assembly connects parts to parts; delegation routes through the boundary port to an internal part. Collaborations (optional) describing roles the parts play together | These diagrams are illustrative and may not represent production architectures.

@arafkarsh arafkarsh 4. Object Diagram 139 Created using PlantUML: https://plantuml.com/object-diagram
o Purpose. An object diagram shows instances at a specific moment in time and the links between them (e.g., a particular Patient p1 linked to Appointment a1, Encounter e1, Prescription rx1, LabOrder lo1). It’s the class diagram’s “polaroid”—used to validate that the static model actually supports a real scenario. o Shows. Concrete objects (with attribute values), links/association instances, and sometimes composition “parts” expanded for a single example configuration. That’s ideal when possible connections are complex and you want to be sure the cardinalities and navigability make sense in practice. Snapshot of runtime instances | These diagrams are illustrative and may not represent production architectures.

@arafkarsh arafkarsh 5. Deployment Diagram 140 Created using PlantUML: https://plantuml.com/deployment-diagram
o Purpose: Map software artifacts to execution environments (nodes: servers, VMs, containers), revealing runtime topology, networks, and hardware/infra constraints. Core for “Physical View.” o Shows: Nodes and communication paths; artifacts/components deployed to those nodes. Where does it run, and what’s connected to what? | These diagrams are illustrative and may not represent production architectures.

@arafkarsh arafkarsh 6. Package Diagram 141 | These diagrams are
illustrative and may not represent production architectures. How is the model organized, and who depends on whom? o Purpose: Group related model elements into packages (namespaces) and show dependencies between those packages to communicate module boundaries, layering, and coupling. This helps structure large systems and manage change impact. o Shows: Packages (optionally with contents), and dependency relationships (e.g., access/import) among packages that indicate allowed references and usage across subsystems Created using PlantUML: Emulated Diagram

@arafkarsh arafkarsh 7. Profile Diagram 142 | These diagrams are
illustrative and may not represent production architectures. Created using PlantUML: Emulated Diagram How do we extend UML with a domain-specific vocabulary? o Purpose: Define a Profile that tailors UML to a platform/domain using stereotypes, tagged values, and constraints. Each stereotype extends a UML metaclass (e.g., Component, Node) to add domain-specific semantics— without changing UML’s core. Profiles let teams standardize names, colors/icons, tags, and rules for a whole project. o Shows: The Profile, its stereotypes, the metaclasses they extend (drawn as the extension relationship), plus any tag definitions and constraints. Optionally, you can show example model elements with those stereotypes applied.

@arafkarsh arafkarsh Key Takeaways 143 o Class diagrams define static
structure: types, relationships, multiplicities— foundation for code and schemas. o Component diagrams capture deployable units, provided/required interfaces, and inter-component dependencies. o Composite structure diagrams “open the box” to show parts, ports, and connectors inside a classifier. o Object diagrams snapshot concrete instances/links at a moment in time to validate the model. o Deployment diagrams map artifacts to nodes and networks—your physical view in UML clothing. o Package diagrams explain module organization and dependencies; o Profile diagrams extend UML via stereotypes/tags/constraints.

@arafkarsh arafkarsh 5 Zachman Framework o RACI Matrix o Zachman
Framework o How Zachman Framework fit with other Enterprise Architectures 144

@arafkarsh arafkarsh RACI matrix - the “who-does-what” 145 RACI is
a lightweight responsibility-assignment matrix that maps every task or deliverable (rows) against project roles or names (columns) and labels each intersection with one of four codes: Code Stands for One-line meaning How many per task?* R Responsible Hands on – actually does the work ≥ 1 A Accountable The buck stops here – approves/signs-off and owns the outcome exactly 1 C Consulted Give input – provides expertise; two- way communication 0 … many I Informed Kept in the loop – receives progress or result; one-way communication 0 … many

@arafkarsh arafkarsh Zachman Framework 146 John Zachman Zachman Framework is
a 6 × 6 matrix that acts as an ontology for describing every facet of an enterprise. o Rows capture six stakeholder perspectives from “big-picture” Planner to running-system instances) o while columns capture the six fundamental interrogatives (What, How, Where, Who, When, Why). Filling the 36 cells yields a complete, non-redundant architectural knowledge base. 1. Why it exists o Communication & alignment – gives business and IT a common grid to map requirements, designs, and implementations. o Completeness check – empty cells reveal blind spots (e.g., “We defined processes How but never linked them to roles Who”). o Change impact – tracing a change in one cell shows ripple effects (e.g., new goal in Why → new KPIs in When → new data in What)

@arafkarsh arafkarsh 2. The 6 columns: interrogatives 5W1H 147 John
Zachman Interrogative Alias (EA shorthand) Typical artefacts What Data / Inventory entity lists, conceptual ER models, canonical message schemas How Function / Process BPMN models, service-function catalogues, value-stream maps Where Network / Location data-centre map, cloud-region diagram, CDN topology Who People / Responsibility org charts, RACI matrices, IAM role models When Time / Events release calendars, SLAs, workflow timers, event-storming timelines Why Motivation / Goals OKRs, business rules, policies, balanced-scorecard, decision tables

@arafkarsh arafkarsh 3. The 6 rows (perspectives / reification levels)
148 # Row EA perspective Key question answered Output granularity 1 Planner (Scope) “Why do we exist?” Context lists high-level bullets 2 Owner (Business Conceptual) “What does the business need?” Conceptual models rich business language 3 Designer (System Logical) “How will it work logically?” Logical models tech-agnostic detail 4 Builder (Technology Physical) “Which tech implements it?” Physical specs platform-specific design 5 Sub-contractor (Detailed) “How is it built?” Code, DDLs, configs implementation detail 6 Functioning Enterprise “How is it running now?” Monitoring dashboards, runtime logs live instances John Zachman

@arafkarsh arafkarsh 3. The 6 rows (perspectives / reification levels)
149 # Role What How Where Who When Why 1 2 3 4 5 6 1 Planner Scope 2 Owner Business Conceptual 3 Designer System Logical 4 Builder Technology Physical 5 Sub-contractor Detailed 6 Functioning Enterprise John Zachman Reification is the process of treating an abstract concept or an intangible idea as if it were a concrete, tangible thing with its own independent reality

@arafkarsh arafkarsh 4. Case Study – E-commerce order-to-cash 150 #
Cell (row × col) Deliverable (illustrative) 1 What Conceptual Product, Customer, Order entities and their relationships 2 How BPMN diagram of Browse → Add-to-Cart → Pay → Fulfil 3 Where Logical deployment map: Web UI, API gateway, microservices, payment gateway 4 Who IAM roles: Buyer, CS Agent, Warehouse Bot mapped to micro-service RBAC 5 When Cron-based inventory sync jobs + Kafka event schedule definitions 6 Why Live dashboards tracking KPI “Order-to-Ship < 2 h” tied to SLA alerts John Zachman

@arafkarsh arafkarsh How Zachman fits with other EA approaches 151
Zachman TOGAF C4 / 4 + 1 View Model Taxonomy / ontology – tells you what to document Process (ADM) – tells you how to develop & govern EA Viewpoints / diagrams – show how to visualise selected cells Stable 6×6 grid (never add rows/cols) Iterative phases (Prelim → A–H) Context, Container, Component, Code views or logical/physical views John Zachman

@arafkarsh arafkarsh Pros and Cons 152 Pros Cons Crystal-clear taxonomy;
easy to spot gaps Steep learning curve for non- architects Framework-agnostic – complements TOGAF, SAFe, ArchiMate No guidance on how to fill cells (needs a method such as TOGAF ADM) Works for any scale – from department to multi-national Can become “documentation for documentation’s sake” if not tied to governance & value

@arafkarsh arafkarsh Key Takeaways 153 o A 6×6 ontology: rows
are perspectives (Planner >> Functioning Enterprise), columns are interrogatives (What/How/Where/Who/When/Why). o Columns map to typical artifacts: data (ER, schemas), function (BPMN), location (topologies), people (RACI/IAM), time (SLAs/calendars), motivation (OKRs/policies). o Rows refine granularity from scope lists to live instances, aligning business intent to running systems. o Benefits: shared vocabulary, completeness checks, and clear change- impact tracing across cells. o Fits with other methods: complements TOGAF’s ADM (process) and C4/4+1 (viewpoints/diagrams).

@arafkarsh arafkarsh 6 C4 Diagrams o Context o Container o
Component o Code 154

@arafkarsh arafkarsh What is C4 Model? 155 Source: C4 Model

@arafkarsh arafkarsh What is the C4 Model? 156 The C4
Model is a lightweight way to visualize software architecture at four zoom levels—Context, Container, Component, and Code—so different audiences can see just the right amount of detail. It is like a Google Maps for your system: zoom out for the big picture, zoom in for the details. The four core diagrams (the “C4”) o Level 1 – Context: Your system, its users (people/roles), and external systems; shows responsibilities and high-level relationships. o Level 2 – Container: The major deployable/runtime pieces (apps, services, UIs, databases, queues, serverless functions) inside your system and how they talk. o Level 3 – Component: For one container, the main components/modules and their interactions plus external calls. o Level 4 – Code: Class-level (or equivalent) detail; usually done with UML/ERD/IDE-generated diagrams if needed. Source: C4 Model Simon Brown

@arafkarsh arafkarsh How they differ: C4 – L1 vs DFD
L0 157 Aspect C4 Level-1 (System Context) DFD Level-0 (Context Diagram) Primary purpose Structural context: your system, its users, and external systems Data movement: what data enters/leaves the (single-process) system Elements Person, Software System, External System; labeled relationships External entities, single system process, data flows (and sometimes data stores) Typical labels Interaction intent (e.g., “places order”, “fetches profile”) Data names (e.g., “Order JSON”, “Payment Auth Token”) Scope People + systems; static view Process boundary + data in/out; functional/data view If you must adapt DFD L0 to stand in for C4 L1, adjust semantics: o Treat “external entities” as People or External Systems. o Keep the system as a single box, but rename arrows from data names to interaction labels. o Remove data stores/process details (not part of C4 L1). o Add short responsibilities on each neighbor

@arafkarsh arafkarsh Context Diagram – C4 Level 1 158 Created
using PlantUML: Emulated Diagram Level 1 – Context: Your system, its users (people/roles), and external systems; shows responsibilities and high-level relationships.

@arafkarsh arafkarsh Container Diagram – C4 L2 159 Created using
PlantUML: Emulated Diagram Level 2 – Container: The major deployable/runtime pieces (apps, services, UIs, databases, queues, serverless functions) inside your system and how they talk.

@arafkarsh arafkarsh Component Diagram – C4 L3 160 Created using
PlantUML: Emulated Diagram Level 3 – Component: For one container, the main components/mod ules and their interactions plus external calls.

@arafkarsh arafkarsh Code Diagram – C4 L4 161 Created using
PlantUML: Emulated Diagram Level 4 – Code: Class-level (or equivalent) detail; usually done with UML/ERD/IDE-generated diagrams if needed.

@arafkarsh arafkarsh Key Takeaways 162 o C4 gives four zoom
levels—Context, Container, Component, Code—to tell the right story to the right audience. o L1 Context: people/roles and external systems and how they interact with “our system.” L2 Container: major deployable pieces and their connections. o L3 Component: internal building blocks of a container and their interactions; L4 Code: class-level detail when warranted. o C4 vs DFD-L0: C4 is structural context (people/systems), DFD-L0 is data movement for a single process; labels and scope differ. o Practical guidance: adapt a DFD-L0 to a C4 L1 by reinterpreting entities as people/systems and focusing on interaction intent, not data payload names.

@arafkarsh arafkarsh 7 ISO/IEC/IEEE 42010:2011 & 2022 o ISO/IEC/IEEE 42010-2011
Standard o ISO/IEC/IEEE 42010-2022 Standard o View and Viewpoints o Perspectives 163

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

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

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

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

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

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

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

@arafkarsh arafkarsh ISO/IEC/IEEE 42010-2022 Standard 171 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.

@arafkarsh arafkarsh ISO/IEC/IEEE 42010-2022 Standard 172 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

@arafkarsh arafkarsh 173 ISO/IEC/IEEE 42010-2011 Standard ISO/IEC/IEEE 42010-2022 Standard

@arafkarsh arafkarsh View 174 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).

@arafkarsh arafkarsh Viewpoints 175 • 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.

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

@arafkarsh arafkarsh 177 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

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

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

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

@arafkarsh arafkarsh 181 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 Architecture: Viewpoints & different NFR Perspectives

@arafkarsh arafkarsh 182 Functional Viewpoint Information Viewpoint Concurrency Viewpoint Development
Viewpoint Deployment Viewpoint Operational Viewpoint Context Viewpoint Business Perspective Security Perspective Architect Perspective Engineering Perspective Compliance Perspective Operations Perspective Architecture: Viewpoints & Stakeholder Perspectives

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

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

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

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

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

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

@arafkarsh arafkarsh Key Takeaways 189 o 2011 scope: architecture descriptions
for software & systems; defines architecture, AD, stakeholders, concerns, viewpoints, views, model kinds, and correspondences. o 2022 broadened scope: architecture descriptions for any “entity of interest” (systems, products, enterprises, lines, technologies). o Terminology shift: introduces stakeholder perspectives, architecture aspects, and view components; contrasts view components (2022) with architecture models (2011). o Traceability: correspondence rules and correspondences link requirements (e.g., use cases) to structural elements (e.g., components) for consistency. o Views, viewpoints, and perspectives (per Rozanski & Woods) provide methodical ways to shape and evaluate architectural concerns and quality attributes.

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

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

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

@arafkarsh arafkarsh 2. Functional Viewpoint 193 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.

@arafkarsh arafkarsh 3. Information Viewpoint 194 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.

@arafkarsh arafkarsh 4. Concurrency Viewpoint 195 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.

@arafkarsh arafkarsh 5. Development Viewpoint 196 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.

@arafkarsh arafkarsh 6. Deployment Viewpoint 197 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.

@arafkarsh arafkarsh 7. Operational Viewpoint: Infrastructure and Platform 198 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.

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

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

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

@arafkarsh arafkarsh 2. Functional Viewpoint 202 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.

@arafkarsh arafkarsh 3. Information Viewpoint 203 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.

@arafkarsh arafkarsh 4. Concurrency Viewpoint 204 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.

@arafkarsh arafkarsh 5. Development Viewpoint 205 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.

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

@arafkarsh arafkarsh 7. Operational Viewpoint: Infrastructure and Platform 207 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.

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

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

@arafkarsh arafkarsh 1. Security Perspective 210 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.

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

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

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

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

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

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

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

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

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

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

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

@arafkarsh arafkarsh Budget o Costing Categories o Cloud Native Cost
BOM o Kubernetes & Microservices o 8 Step Costing Playbook o Guard Rails that saves Money 222 0

@arafkarsh arafkarsh Costing Categories 223 o Build cost (one-time-ish): people
(dev, QA, SRE, PM), tooling (IDEs, scanners, CI/CD), design/prototyping, migration, training, compliance onboarding. o Run cost (recurring): cloud bill (compute, storage, network, DB, managed services), platform (Kubernetes control plane, service mesh, observability), support/SRE, incident response, backups/DR, security & governance. o Change cost (recurring): the “gravity” of microservice sprawl, schema evolution, refactors, upgrades, and feature experiments. o Governance loop: FinOps (engineering + finance + product) keeps these in check by turning cost into a first-class metric tied to business value.

@arafkarsh arafkarsh A cloud-native cost BOM (bill of materials) 224
Area What you actually pay for Cloud-native gotchas Compute VM/Node hours, autoscaling headroom, GPU time Sidecars/daemonsets add CPU/RAM overhead; HPA/queue backlogs can surprise you Containers/K8s Control plane or per-pod fee (provider- specific), node pools Overage from per-namespace isolation; noisy neighbors; bin-packing inefficiency; cost allocation by namespace/label needed Data Managed DB hours/IOPS/storage, snapshots Cross-AZ replication, read replicas, PITR, multi-region DR add steady cost Storage Object, block, file; retrieval and lifecycle tiers Cold storage is cheap, retrieval isn’t; logs/metrics/cardinality explode without limits Network Egress to Internet, cross-region, NAT gateways, load balancers, CDN Ingress is often free; egress is not; inter-region and Internet egress drive TCO Observability Metrics, logs, traces, APM, synthetics High-cardinality labels and long retention cost real ₹ Security & Compliance Scanners, KMS/HSM, secrets mgmt, WAF, CSPM, SIEM Audit trails + long retention; encrypt-everywhere has CPU/latency tradeoffs Platform Registries, artifact stores, package repos, IaC state Image sprawl; retention policies; cross-account pulls Team/Ops SRE rotations, runbooks, incident tooling, training 24×7 coverage vs. SLO ambition is a real budget lever

@arafkarsh arafkarsh Special to Kubernetes & microservices 225 o Cost
drivers = CPU, memory, storage, and network per workload; service mesh/sidecars add overhead; platform components (ingress, controllers) also consume nodes. Treat them as line items. o Cost allocation needs consistent labels/annotations (service, team, env, app, cost-center). Use OpenCost/OpenCost-based tools for showback/chargeback to namespaces/workloads. o Containers ≠ free: you still pay the underlying nodes, disks, LB IPs, NAT, and egress. The FinOps Foundation has a solid “Calculating container costs” guide.

@arafkarsh arafkarsh The 8-step costing playbook 226 1. Define SLOs
& regions/AZs (availability drives duplication). Align with provider well-architected guidance. 2. Forecast load: peak RPS, concurrency, data volume, growth curve. 3. Choose topology: managed vs self-managed DB, multi-AZ, caching, CDN, queueing. 4. Translate into resources: pods per service, node types, DB instance class/IOPS, storage tiers/retention, LB counts, NAT, VPC endpoints. 5. Price the BOM with calculators/billing exports; include control-plane/per-pod fees if applicable, and platform add-ons (mesh, registry, observability). 6. Model network explicitly: inter-AZ, inter-region, and Internet egress (ingress is typically free; egress is metered). 7. Apply FinOps levers: commitments (CUD/Reservations/Savings Plans), spot/preemptible where safe, rightsizing, autoscaling policies, storage lifecycle, demand-shaping. 8. Close the loop: tagging/labeling, showback/chargeback, budgets/alerts, monthly reviews. Consider adopting FOCUS to normalize billing data across vendors.

@arafkarsh arafkarsh Guardrails that save real money 227 o Allocate
by label (service/team/env) and review monthly; you can standardize with OpenCost and push showback to teams. o Right-size and de-zombie: kill idle nodes, volumes, IPs, snapshots, test clusters. (FinOps principle: stop spending on undifferentiated heavy lifting.) o Commitments + Spot/Preemptible for stateless and batch work; keep critical paths on regular capacity. o Design for egress: push content to CDN, keep chatty services co-located, avoid cross-region chatter; remember that egress is metered while ingress often isn’t. o Observability discipline: cap log levels, drop high-cardinality labels, set retention per signal.

@arafkarsh arafkarsh Key Takeaways 228 o Three buckets of cost:
Build (people & tooling), Run (cloud bill, platform, support), and Change (upgrades, refactors, experiments). o SLOs drive spend: Availability/latency targets, regions/AZs, and “managed vs. self-managed” choices multiply or trim cost. o Kubernetes ≠ free: Pay for nodes, control planes, sidecars/mesh overhead, and platform add- ons; allocate costs by labels/namespaces (showback/chargeback). o Network is the sneaky one: Internet and cross-region egress dominate surprises—co-locate chatty services, cache, and push static traffic to a CDN. o Observability & security have price tags: Control log/metric/trace retention and cardinality; add scanners, KMS, WAF, backups/DR as explicit line items. o Forecast → BOM → price: Translate traffic and data into pods/node pools, DB class/IOPS, storage tiers/snapshots, LB/NAT/CDN—then compute unit economics (₹ per user / per 1k requests). o FinOps feedback loop: Tag everything, set budgets/alerts, review monthly; right-size and kill zombies; use commitments & spot/preemptible where safe to bend the curve.

@arafkarsh arafkarsh Requirements o Functional Requirements o Non-Functional Requirements 229
1 2

@arafkarsh arafkarsh Functional Requirements – Epics / Stories 230 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

@arafkarsh arafkarsh Functional Requirements: User Story 231 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

@arafkarsh arafkarsh Functional Requirement: Acceptance Criteria / BDD 232 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

@arafkarsh arafkarsh End User Requirements 233 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

@arafkarsh arafkarsh Non-Functional Requirements 234 Disaster Recovery Business Continuity Security
& Compliances Application Performance Load & Scalability High Availability 1 2 3 4 5 6 1

@arafkarsh arafkarsh Non-Functional Requirements 235 As a system administrator, I
want the system to automatically switch to a backup data centre in the event of a failure, So that services are restored quickly and data loss is minimised. Role-Feature-Reason Matrix User Story - 1: Disaster Recovery BDD Acceptance Criteria – 1: Failure Given a major data centre failure When the system detects the failure Then it must automatically failover to a secondary data centre with minimal service disruption. BDD Acceptance Criteria – 2 : RPO / RTO Given the system has failed over to a secondary data centre, When recovery processes are initiated, Then The Recovery Point Objective (RPO) must not exceed 5 minutes AND the Recovery Time Objective (RTO) must not exceed 30 minutes. BDD Acceptance Criteria – 3 : Resend Mail Given a data recovery process, When data is restored, Then data loss must not exceed the last 5 minutes of data prior to the disruption. 1 More NFR Examples: https://speakerdeck.com/arafkarsh/agile-user-stories-domain-driven-design

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

@arafkarsh arafkarsh Infrastructure: Servers / Virtual Machines / Containers 237
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

@arafkarsh arafkarsh Compare Type 1 and Type 2 Hypervisor 238
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

@arafkarsh arafkarsh Deployment – Updates and rollbacks, Canary Release D
ReplicaSet – Self Healing, Scalability, Desired State R Worker Node 1 Master Node (Control Plane) Kubernetes Architecture 239 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

@arafkarsh arafkarsh Infrastructure Specs 240 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

@arafkarsh arafkarsh Infrastructure: Distributed Cloud / Multi Cloud 241 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

@arafkarsh arafkarsh Analytics: Apache Flink Architecture 242 3

@arafkarsh arafkarsh SDN Architecture Software Defined Network 243 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

@arafkarsh arafkarsh 244 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

@arafkarsh arafkarsh Perimeter Security Vs. Zero Trust 245 Zero Trust
Security Model Classic Security Model Perimeter Security • Location Based (External / Internal) • Anyone inside the network is always trusted. • Based on Layered Security Never Trust, Always Verify 1 Implement Least Privilege 2 (Always) Assume Breach 3 Forrester's John Kindervag 2010: No More Chewy Centers: Introducing The Zero Trust Model Of Information Security Inspired from Jericho Forum Commandments v1.2 May 2007 Source: Microsoft: Jericho & Modern Security Restrict everything to a secure Network Zero Trust Protect Assets anywhere with Central Policy 3

@arafkarsh arafkarsh NIST 800-207: Zero Trust Architecture 246 Source: NIST
SP 800-207:Zero Trust Architecture https://csrc.nist.gov/publications/detail/sp/800-207/final A User, An Application, or a Device – Operating on (or with) a Computer System which has access to an Enterprise Resource Subject Is an Application, Document, Data, Database, Workload that’s under the Enterprise Control protected by the Zero Trust System Resource Policy Enforcement Point Policy Engine Policy Administrator Policy Decision Point Control Plane Data Plane Resource Subject User App Device UnTrusted Trusted CDM System GRC System Threat Intelligence Activity Logs Data Access Policy PKI IAM SIEM 1 2 3 3

@arafkarsh arafkarsh Traditional VPN Vs. Zero Trust 247 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

@arafkarsh arafkarsh Cisco SD-Access 248 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

@arafkarsh arafkarsh Infrastructure: Service Mesh: Istio Security 249 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

@arafkarsh arafkarsh Service Mesh: Istio – Security Architecture 250 Source:
https://istio.io/docs/concepts/security/ 3

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

@arafkarsh arafkarsh Product Discovery 252 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

@arafkarsh arafkarsh Project Timelines 253 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

@arafkarsh arafkarsh Project Timelines: Kanban Board 254 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

@arafkarsh arafkarsh Global Teams: Business Capability Centric Design 255 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

@arafkarsh arafkarsh Management Pipeline Automation Architecture Global Teams: Engineering Pods
256 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

@arafkarsh arafkarsh Roles & Responsibilities and Tech Stack 257 Category
Role Type Responsibilities Tech Stack 1 Customer Product Owner External • Complete Product Vision • Specifications (User Stories, Acceptance Criteria) • User Stories • BDD – Acceptance Criteria 2 Engineering Pod Cloud Manager / Analyst Internal • Analyst & Specifications (User Stories, Acceptance Criteria) • Feature Management in Production & Focused on Outcome • Scrum Master & Team Management • Design Thinking • Lean Startup • Agile (Kanban) 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) • Mentoring the team • Code Reviews (Functional / Infra Codes) • Deeper Understanding of Infra Stack • Event-Driven Architecture • Domain Driven Design • Data Flow Diagrams • Microservices Architecture • Data Mesh, Polyglot DB / Lang • Terraform, K8s, Service Mesh 4 Engineering Pod Cloud Sr. Engineer Internal • Mentor / Guiding Team on Technology • Product Development / Testing / Deployment • All the above • DevSecOps 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 • All the above • DevSecOps 6 Engineering Pod Cloud Network / Security Lead External • Define Network Policies • Define Security Policies • Review Infra Code for Network & Security Policies • Terraform / Kubernetes • Zero Trust / Service Mesh • DevSecOps 7 Engineering Pod Cloud User Experience Lead External • Usability Guidelines • Data Flow Guidelines • Human-Computer Interface • Material Design Guidelines 5

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

@arafkarsh arafkarsh Global Compliance 259 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.

@arafkarsh arafkarsh FHIR – Fast Healthcare Interoperability Resources 260 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

@arafkarsh arafkarsh FHIR Global Adoption 261 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

@arafkarsh arafkarsh FHIR Data Models: Patient, Observation 262 6

@arafkarsh arafkarsh FHIR Data Models: Condition 263 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.

@arafkarsh arafkarsh FHIR Data Models: Medication, Device 264 6

@arafkarsh arafkarsh FHIR Data Models: Practitioner 265 6

@arafkarsh arafkarsh Technology Selection o Technology Selection o Backend Tech
Stack o Frontend Tech Stack 266 7

@arafkarsh arafkarsh Technology Selection 267 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

@arafkarsh arafkarsh Technology Selection: Backend 268 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

@arafkarsh arafkarsh Technology Selection: Front End 269 # 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

@arafkarsh arafkarsh What is Apache Flink 270 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

@arafkarsh arafkarsh Use Case: Periodic ETL vs Streaming CTL 271
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

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

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

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

@arafkarsh arafkarsh AWS IAM – Identity & Access Management 275
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/

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

@arafkarsh arafkarsh AWS Route 53: DNS Service 277 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.

@arafkarsh arafkarsh AWS EC2 – Elastic Compute Cloud 278 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

@arafkarsh arafkarsh AWS S3: Simple Storage Service 279 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

@arafkarsh arafkarsh AWS RDS 280 • 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

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

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

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

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

@arafkarsh arafkarsh Analytics: AWS Kinesis – Architecture (Flink) 285 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

@arafkarsh arafkarsh AWS DevOps 286 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

@arafkarsh arafkarsh AWS Build Process 287 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

@arafkarsh arafkarsh AWS Stack for Deployment: Containers 288 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

@arafkarsh arafkarsh Monitoring & Management 289 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

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

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

@arafkarsh arafkarsh 292 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

@arafkarsh arafkarsh 293 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

@arafkarsh arafkarsh API Architecture Maturity Levels 294 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

@arafkarsh arafkarsh Composable Enterprise Architecture 295 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

@arafkarsh arafkarsh Architecture Styles, Patterns & Design Patterns 296 •
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

@arafkarsh arafkarsh Event Driven & Pub Sub Architectures 297 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

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

@arafkarsh arafkarsh Event Sourcing Intro 299 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 Event store Single Source of Truth Greg Young 8

@arafkarsh arafkarsh Event Sourcing: Case Study: Shopping Site – Event
Sourcing / CQRS 300 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

@arafkarsh arafkarsh Event Sourcing: Case Study: Patient Diagnosis and Treatment
301 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

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

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

@arafkarsh arafkarsh Product Model in Different Bounded Context 304 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

@arafkarsh arafkarsh Cloud-Native Architecture 305 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 Layered Architecture Domain Driven Design Capability Centric Design Kafka Messaging / Streams / Connect Epics / User Stories / MVP / DDD / ES & CQRS Data Mesh / K8s/Kafka Clusters / Infra Patterns Containers / Kubernetes / Mesh Terraform Bulkhead, Circuit Breaker, Green / Blue Deployment Microservices Characteristics 8

@arafkarsh arafkarsh Microservices Architecture 306 /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

@arafkarsh arafkarsh Design Pattern 1 Decomposition Identify the Modules and
Boundaries 2 Strangler Fig Product Service (Query Only with Apache Solr) 3 Branch By Abstraction Shopping Cart as Service using Monolithic DB 4 Decorating Collaborator New Shipping Service with Database 5 Change Data Capture Enhance Loyalty Module as a new Service 6 Aggregate API Expose Customer API on Monolith 7 Split Table Product Split into 2 Services as Product Management and Warehouse 8 Change Data Ownership Order Service using Monolithic DB 9 Move Foreign Key to Code Foreign Key in Order (item) with Product Table moved to Order Service Code 10 Strangler Fig Move out Customer Module and decommission the Monolith Legacy Migration Design Patterns 307 • 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

@arafkarsh arafkarsh Migration Design Patterns: Strangler Fig Pattern 308 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

@arafkarsh arafkarsh Microservices Testing Strategies 309 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

@arafkarsh arafkarsh Microservices Testing Strategy 310 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

@arafkarsh arafkarsh Microservices Testing Scenarios / Tools 311 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

@arafkarsh arafkarsh Chaos Engineering – Load / Stress / Performance
312 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

@arafkarsh arafkarsh SANS Cloud Security Architecture Principles 313 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

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

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

@arafkarsh arafkarsh Production Environment Continuous Monitoring Fully Automated Continuous Deployment
Shift Left – Operational Concerns 316 • 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

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

@arafkarsh arafkarsh 5 DevOps Principles – CALMS Framework 318 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

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

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

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

@arafkarsh arafkarsh 6 DevSecOps Playbook 322 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

@arafkarsh arafkarsh 323 Thank you DREAM EMPOWER AUTOMATE MOTIVATE India:
+91.999.545.8627 https://arafkarsh.medium.com/ https://speakerdeck.com/arafkarsh https://www.linkedin.com/in/arafkarsh/ https://www.youtube.com/user/arafkarsh/playlists http://www.slideshare.net/arafkarsh http://www.arafkarsh.com/ @arafkarsh arafkarsh LinkedIn arafkarsh.com Medium.com Speakerdeck.com

@arafkarsh arafkarsh 324 Slides: https://speakerdeck.com/arafkarsh Blogs https://arafkarsh.medium.com/ Web: https://arafkarsh.com/ Source:
https://github.com/arafkarsh

Solution Architecture

Solution Architecture

More Decks by Araf Karsh Hamid

Other Decks in Technology

Featured

Transcript