กรณีศึกษาทางธุรกิจ

1แปดรูปแบบการใช้งาน Big Data ในธุรกิจ

Use Case เดียวอาจต้องใช้หลาย Pattern

Fraud Detection ต้องมี Behavioral Analytics เพื่อสร้าง Baseline, Streaming เพื่อให้คะแนนเร็ว, Graph เพื่อเห็น Ring, ML เพื่อรวมสัญญาณ และ Case Management เพื่อให้มนุษย์ตัดสินใจ ส่วน Customer Segmentation อาจเป็น Batch SQL กับ k-means รายเดือนโดยไม่ต้อง Streaming เลย การใช้เทคโนโลยีมากไม่เท่ากับออกแบบดี

กรอบวิเคราะห์กรณีศึกษาเจ็ดขั้น

1. Problem: ปัญหาที่มีผลจริงคืออะไร
2. Decision: ใครจะทำอะไรจากผลลัพธ์
3. Data: ข้อมูลใดทราบก่อนเวลาตัดสินใจและเชื่อถือได้แค่ไหน
4. Architecture: Batch, Streaming, Graph หรือ ML ส่วนใดจำเป็น
5. Evaluation: วัดทั้ง Technical Metric และ Business Outcome
6. Failure: ระบบ/ข้อมูล/โมเดลผิดอย่างไรได้บ้าง
7. Governance: สิทธิ์ ความเป็นส่วนตัว ความเป็นธรรม และเจ้าของความรับผิดชอบ

Metric สามชั้นที่ไม่ควรปนกัน

2กรณีศึกษาเจาะลึก: Behavioral Analytics และ Customer Segmentation

จาก Segment ไปสู่ Action

Cluster 0, 1, 2 ไม่มีคุณค่าจนกว่าจะอธิบายได้ว่ากลุ่มต่างกันตรงไหน ทีมธุรกิจทำอะไรต่างกัน และจะวัดผลอย่างไร Segment ที่ดีต้องมีขนาดพอเหมาะ เสถียรตามเวลา เข้าถึงได้ผ่านช่องทางจริง และตอบสนองต่อ Action ต่างกัน

RFM เป็น Baseline ที่ควรมี

ก่อนใช้ Embedding หรือ Clustering ซับซ้อน ลอง Recency, Frequency, Monetary และกฎธุรกิจง่าย ๆ ก่อน Baseline อธิบายง่ายและช่วยรู้ว่าโมเดลซับซ้อนเพิ่ม Lift จริงหรือเพียงตั้งชื่อกลุ่มใหม่ให้สิ่งที่รู้อยู่แล้ว

Behavioral Event ต้องมี Taxonomy

Event click อย่างเดียวไม่พอ ต้องรู้ object, screen, campaign, session, event time, user state และ schema version ถ้าทีม Mobile กับ Web ตั้งชื่อคนละแบบ Funnel จะขาด การจัด Event Contract และ Data Quality สำคัญกว่า Algorithm ปลายทางในหลายโครงการ

Segmentation เปลี่ยนเมื่อพฤติกรรมเปลี่ยน

Centroid ที่สร้างปีที่แล้วอาจไม่อธิบายลูกค้าปีนี้ ต้องติดตามขนาดกลุ่ม, Feature Distribution, Transition ระหว่าง Segment และ Business Response การ Refit ทำให้ Segment ID สลับความหมายได้ จึงต้องมี Version และ Mapping ก่อนส่งให้ระบบ CRM

ทดลอง Action ด้วย Control Group

ลูกค้าที่ได้รับข้อเสนอแล้วซื้อ ไม่ได้พิสูจน์ว่าข้อเสนอทำให้ซื้อ เพราะอาจซื้ออยู่แล้ว A/B Test หรือ Holdout ช่วยวัด Incremental Lift ส่วน Uplift Modeling พยายามหา Treatment Effect รายบุคคล ซึ่งตอบ Action ได้ตรงกว่า Propensity อย่างเดียว

3กรณีศึกษา: Fraud Detection แบบเรียลไทม์

Fraud เป็นโจทย์ที่ False Positive และ False Negative แพงคนละแบบ ปล่อยธุรกรรมเสี่ยงทำให้สูญเงิน แต่ระงับธุรกรรมดีทำให้ลูกค้าเดือดร้อน ระบบจึงต้องออกแบบ Decision หลายระดับ เช่น Allow, Step-up Authentication, Review และ Block แทน Binary Prediction อย่างเดียว

สถาปัตยกรรม

Class Imbalance และ Delayed Label

Fraud อาจมีสัดส่วนน้อยมาก Accuracy จึงไร้ประโยชน์ ต้องดู Precision/Recall, PR-AUC, Recall ที่ Review Capacity และ Cost-weighted Metric Label บางส่วนมาหลัง Chargeback หลายสัปดาห์ และธุรกรรมที่ Block ไม่มีทางรู้ว่า Fraud จะสำเร็จหรือไม่ เกิด Selective Label

Feature Leakage

เหตุผล Chargeback, ผล Investigation หรือยอดรวมหลังธุรกรรมเป้าหมายเป็นข้อมูลอนาคต ห้ามใช้ตอน Scoring แม้จะ Join ได้ง่าย Feature Store ต้องรองรับ Point-in-time Correctness

Adversarial Drift

Fraudster เปลี่ยนพฤติกรรมเมื่อรู้กฎ โมเดลจึงเผชิญคู่แข่งที่ปรับตัว ไม่ใช่ Drift ตามธรรมชาติอย่างเดียว ต้องมี Rule Update, Exploration, Analyst Feedback และ Red-team Scenario

4กรณีศึกษา: Predictive Maintenance

เป้าหมายไม่ใช่ทำนายว่าเครื่องจะเสียอย่างแม่นที่สุด แต่ลด Downtime และ Maintenance Cost โดยไม่เปลี่ยนอะไหล่เร็วเกินไป การตัดสินใจขึ้นกับ Lead Time ของอะไหล่ ความปลอดภัย ตารางผลิต และความสามารถทีมซ่อม

ข้อมูลหลายอัตราและหลายเวลา

Sensor บางตัวส่งทุก millisecond บางตัวทุกนาที Maintenance Log เขียนทีหลังและ Failure Time อาจเป็นช่วง ไม่ใช่จุดเดียว เราต้อง Synchronize, Resample และป้องกันไม่ให้ข้อมูลหลัง Technician เปิดเครื่องรั่วเข้า Feature

Signal Pipeline

1. รับ Sensor Stream และตรวจหน่วย/Calibration
2. สร้าง Window Feature เช่น Mean, RMS, Kurtosis, Frequency Band
3. Join Operating Context เช่น Load, Product Type, Ambient Temperature
4. ให้คะแนน Anomaly/Failure Risk หรือ Remaining Useful Life
5. รวมกับ Maintenance Policy และ Spare-part Inventory

Rare Failure และ Censoring

เครื่องจำนวนมากยังไม่เสียก่อนสิ้นช่วงเก็บข้อมูล ไม่ได้แปลว่าอายุเท่ากับวันสุดท้าย นี่คือ Right Censoring ซึ่ง Survival Analysis จัดการตรงกว่า Regression ธรรมดา Failure ใหม่อาจไม่มีตัวอย่างพอ จึงใช้ Anomaly Detection หรือ Physics-informed Feature ร่วม

Business Metric

5กรณีศึกษา: Funnel Analytics และ Recommendation

Funnel วัดเส้นทางจาก Impression → Click → Add to Cart → Purchase แต่ผู้ใช้ข้ามขั้น เปลี่ยนอุปกรณ์ กลับมาหลายวันหลังเห็นโฆษณา และถูกหลาย Campaign แตะ Attribution จึงเป็น Model/Rule ที่ต้องประกาศ ไม่ใช่ข้อเท็จจริงจาก Log โดยตรง

Identity Resolution

Anonymous Cookie, Login ID, Device ID และ Household อาจเป็นคนเดียวกันหรือไม่ การรวม Identity เพิ่มความครบของ Journey แต่เพิ่ม Privacy Risk และ False Merge ระบบควรเก็บ Confidence/Provenance และไม่รวมเกิน Consent

Attribution

Recommendation Pipeline

ระบบแนะนำมักแยก Candidate Generation จาก Ranking Candidate อาจมาจาก Popularity, Co-occurrence, Graph/Embedding และ Business Rule แล้ว Rank จาก User, Item, Context สุดท้าย Re-rank เพื่อ Diversity, Freshness, Stock และ Safety

Offline Metric กับ Online Outcome

Precision@K หรือ NDCG ดีขึ้นไม่ได้รับประกัน Conversion/Retention ดีขึ้น เพราะ Offline Data มี Exposure Bias การ A/B Test ต้องดู Novelty, Diversity, Revenue, Return Rate และ Long-term Satisfaction ไม่ใช่ CTR อย่างเดียว

Cold Start

User ใหม่ไม่มีประวัติ Item ใหม่ไม่มี Interaction ใช้ Content Feature, Context, Popularity ตาม Segment และ Exploration ช่วยเริ่มต้น แต่ต้องยอมรับความไม่แน่นอน ไม่ควรแสร้งว่าคะแนนทุกตัวแม่นเท่ากัน

6กรณีศึกษา: Market Basket และการวางแผนสินค้า

Association Rule ใช้ Support, Confidence และ Lift เพื่อดูสินค้าที่เกิดร่วม แต่ Rule ที่น่าสนใจทางสถิติอาจไม่มี Action เพราะสินค้าอยู่คนละช่องทาง Margin ต่ำ หรือเกิดร่วมจาก Promotion เดียวกัน

เวลาและลำดับ

การซื้อพร้อมกันต่างจากซื้อ A แล้ว B ใน 30 วัน Sequence Mining ตอบ Journey ได้ดีกว่า Basket Static ในบางโจทย์ ส่วน Graph Item–Item ใช้น้ำหนัก Co-occurrence และ Personalized PageRank หา Candidate แต่ต้องแก้ Popularity Bias

จาก Rule สู่การทดลอง

พบกาแฟซื้อร่วมขนมไม่ได้พิสูจน์ว่าการวางใกล้กันเพิ่มยอด อาจซื้อร่วมอยู่แล้ว การเปลี่ยน Layout/Bundle ต้อง A/B Test และดูยอดรวม Margin Cannibalization และ Inventory Constraint

7กรณีศึกษา: Cybersecurity และ Log Analytics

Security Operations รับ Log จาก Endpoint, Network, Identity, Cloud และ Application ปริมาณสูง เป้าหมายไม่ใช่เก็บทุกอย่างให้นานที่สุด แต่ตรวจ Signal สำคัญให้ทันและมีหลักฐานพอ Investigate

Schema และเวลา

Log ต่างระบบใช้ชื่อ User/IP/Action คนละแบบ ต้อง Normalize แต่ยังเก็บ Raw Event และ Provenance เพื่อย้อนตรวจ Event Time ต่างจาก Ingestion Time และผู้โจมตีอาจแก้นาฬิกาหรือ Log บางส่วน จึงต้องระวังการเรียง Sequence

Rule, CEP, Anomaly และ Graph

Alert Fatigue

Recall สูงแต่ส่ง Alert แสนรายการต่อวันไม่มีประโยชน์ ต้องวัด Precision at Analyst Capacity, Mean Time to Detect/Respond และ Investigation Yield รวม Alert ที่เกี่ยวข้องเป็น Incident เดียวแทนการนับ Event แยก

Retention ตามความเสี่ยง

Raw Packet แพงกว่าสรุป Flow เราอาจเก็บ Hot Data รายละเอียดสูงช่วงสั้น, Aggregate ระยะกลาง และ Archive ตามกฎหมาย/ความเสี่ยง Smart Summary ช่วย Query แต่ต้องรู้ว่าสูญข้อมูลใดจนใช้ Forensics ไม่ได้

8กรณีศึกษา: เกษตรแม่นยำและระบบสิ่งแวดล้อม

Sensor ดิน อากาศ ภาพดาวเทียม โดรน และบันทึกเกษตรกรมี Space–Time Resolution ต่างกัน การทำนายผลผลิตหรือให้น้ำจึงต้องรวมข้อมูลเชิงพื้นที่ เวลา และความรู้โดเมน ไม่ใช่เพียงโยนทุกคอลัมน์เข้าโมเดล

Connectivity และ Edge Computing

แปลงเกษตรอาจสัญญาณไม่สม่ำเสมอ Device ต้อง Buffer, ตรวจค่า และตัดสินใจบางส่วนที่ Edge ข้อมูลจึงมาช้า/ซ้ำเมื่อเชื่อมต่อกลับ ระบบ Streaming ต้องใช้ Event Time, Deduplication และ Reconciliation

Spatial Leakage

ถ้าสุ่ม Pixel ใกล้กันไปทั้ง Train/Test โมเดลเห็นพื้นที่เกือบเดียวกันและคะแนนสูง ควรแบ่งตามแปลง พื้นที่ หรือฤดูกาลเพื่อทดสอบการใช้ในพื้นที่/ปีใหม่

Decision ไม่ได้จบที่ Prediction

ทำนายความชื้นแล้วต้องแปลงเป็นตารางให้น้ำภายใต้ Water Quota, Pump Capacity, Weather Forecast และ Crop Stage นี่เป็น Optimization หลัง ML บางกรณีโมเดลง่ายแต่ Policy ดีให้ผลมากกว่าโมเดลแม่นขึ้นเล็กน้อย

ผลกระทบและความเป็นธรรม

ระบบที่ต้องใช้ Sensor แพงอาจให้ประโยชน์เฉพาะฟาร์มใหญ่ การออกแบบควรดู Cost of Adoption, Offline Operation, Explainability และช่องทางให้เกษตรกรแก้ข้อมูล ไม่ใช่รายงานเฉพาะ RMSE

9กรณีศึกษา: Healthcare และ Clinical Decision Support

ข้อมูลสุขภาพมีทั้งเวชระเบียน Lab ภาพทางการแพทย์ สัญญาณชีพ ยา และข้อความ Clinical Note ความท้าทายไม่ใช่เพียง Variety แต่คือผลของความผิดพลาดสูง Label เกิดจากกระบวนการรักษา และข้อมูลที่บันทึกสะท้อนว่าแพทย์สงสัยอะไร ไม่ใช่สภาวะคนไข้อย่างเป็นกลางทั้งหมด

Prediction Target ต้องผูกกับ Workflow

การทำนาย Sepsis ภายใน 6 ชั่วโมงต้องระบุว่าเวลาเริ่มคือเมื่อใด ใครรับ Alert และทำอะไรได้ทัน ถ้า Alert มาถึงหลังแพทย์เริ่มรักษาแล้ว ระบบอาจดูแม่นเพราะใช้สัญญาณที่เกิดหลัง Clinical Recognition แต่ไม่ได้ช่วยตัดสินใจเร็วขึ้น

Label Leakage จากการรักษา

การสั่งตรวจเฉพาะทาง ยาบางชนิด หรือย้าย ICU อาจเป็น Proxy ว่าแพทย์รู้ผลแล้ว Feature เหล่านี้ทำให้โมเดลทำนาย Diagnosis ได้สูงแต่เป็นการอ่านการตัดสินใจของแพทย์ย้อนหลัง ต้องกำหนด Prediction Time และ Feature Availability อย่างเข้มงวด

Missing Not at Random

ค่า Lab หายไม่ได้เกิดสุ่ม แพทย์สั่งตรวจเมื่อมีเหตุผล การเติม Mean อาจลบสัญญาณจาก “เหตุใดจึงไม่ได้ตรวจ” เราอาจเพิ่ม Missing Indicator และวิเคราะห์ Workflow แต่ต้องระวังโมเดลเรียน Hospital Practice แทน Biology

Generalization ข้ามโรงพยาบาล

เครื่องมือ Protocol ประชากรและ Code ต่างกัน Random Split ในโรงพยาบาลเดียวไม่ตอบว่าจะใช้ที่อื่นได้หรือไม่ ควรมี Temporal/External Validation และ Calibration ต่อ Site การ Update ต้องผ่าน Governance เพราะ Model Drift กระทบความปลอดภัย

Metric ทางคลินิก

Human Oversight และ Automation Bias

การให้แพทย์อยู่ใน Loop ไม่ได้แก้ทุกอย่าง หาก UI แสดงคะแนนโดยไม่มีบริบท คนอาจเชื่อตามอัตโนมัติหรือเกิด Alert Fatigue ต้องออกแบบ Explanation, Override, Escalation และติดตามว่ากลุ่มใดถูก Override บ่อย

10จาก Use Case ไปสู่สถาปัตยกรรมที่พอดี

ไม่ใช่ทุกโครงการต้องมี Data Lake, Kafka, Spark, Graph และ GPU พร้อมกัน เราเริ่มจาก SLA และ Decision แล้วเลือกส่วนประกอบน้อยที่สุดที่ตอบโจทย์ได้ เพราะทุก Component เพิ่ม Failure Mode, Skill และค่าใช้จ่ายดูแล

Lambda, Kappa และสิ่งที่ควรถามจริง

แทนจำชื่อ Architecture ควรถามว่า Fast Result กับ Corrected Result มาจากเส้นเดียวหรือสองเส้น จะ Replay อย่างไร State อยู่ที่ไหน และ Business ยอมให้ผลย้อนหลังเปลี่ยนหรือไม่ การมี Batch กับ Streaming สองชุดอาจเพิ่ม Logic ซ้ำ แต่เส้นเดียวอาจซับซ้อนเกินถ้าต้องรองรับทั้ง Low Latency กับ Backfill

Build กับ Buy

บริการสำเร็จลดเวลาเริ่มและงานปฏิบัติการ แต่มี Cost Model, Lock-in และข้อจำกัด Customization การสร้างเองให้ควบคุมแต่ต้องมีทีม On-call การตัดสินใจควรรวม Total Cost of Ownership หลายปี ไม่ใช่ราคา Compute ต่อชั่วโมงอย่างเดียว

Data Product และ Ownership

ตาราง Feature หรือ Customer 360 ต้องมี Owner, SLA, Schema Contract, Quality Test, Lineage และช่องทาง Incident ไม่เช่นนั้นทีมปลายทางทุกทีมสร้างความหมาย “ลูกค้าที่ Active” คนละแบบ แล้ว Model ต่าง ๆ เทียบกันไม่ได้

11ทดลอง วัดผล และหยุดโครงการอย่างมีเหตุผล

โครงการ Data จำนวนมากผ่าน Proof of Concept เพราะเลือกข้อมูลสะอาดและ Metric ที่เอื้อ แต่ไม่ผ่าน Production เพราะ Feedback ช้า Integration แพง หรือไม่มีใครเปลี่ยนการตัดสินใจตามผลโมเดล เราควรกำหนด Stage Gate ตั้งแต่ต้น

Kill Criteria

กำหนดก่อนทดลองว่าเมื่อใดควรหยุด เช่น Data Coverage ต่ำกว่าเกณฑ์, Lift ไม่คุ้ม Integration, False Positive เกิน Capacity หรือไม่มี Feedback เพื่อปรับโมเดล การหยุดโครงการที่ไม่คุ้มคือผลลัพธ์ทางวิศวกรรม ไม่ใช่ความล้มเหลวที่ต้องซ่อน

Shadow Mode และ Human-in-the-loop

ระบบใหม่ควรรันเงียบเพื่อเปรียบเทียบกับ Decision เดิม ก่อนให้อำนาจ Action อัตโนมัติ กรณีความเสี่ยงสูงให้ Model จัดลำดับและมนุษย์ตัดสิน พร้อมเก็บ Reason/Override เป็น Feedback แต่ต้องระวัง Automation Bias ที่คนเชื่อตามคะแนนโดยไม่ตรวจ

Monitoring หลัง Deployment

• System: Latency, Error, Queue, Cost
• Data: Freshness, Null, Schema, Distribution
• Model: Score/Calibration/Drift และ Metric เมื่อ Label มาถึง
• Decision: Action Rate, Override, Capacity
• Business: Incremental Outcome และ Harm

Incident Response

ต้องมี Owner, Runbook, Rollback, Safe Default และ Audit Trail ถ้า Feature Store ขาดข้อมูล ระบบควรหยุด Block ธุรกรรมทั้งหมด หรือกลับ Rule เดิม? Safe Failure ขึ้นกับความเสียหายของแต่ละ Use Case

12Governance, Privacy และความรับผิดชอบ

คำว่า “ข้อมูลสาธารณะ” ไม่ได้แปลว่าใช้รวม Profile ได้ทุกวัตถุประสงค์ การรวม Dataset ทำให้ข้อมูลที่แต่ละชุดดูไม่อ่อนไหวเปิดเผยสิ่งใหม่ได้ Governance จึงต้องดู Purpose, Consent, Retention และ Harm ของการเชื่อมโยง

Data Minimization

เก็บเท่าที่ต้องใช้และนานเท่าที่มีเหตุผล การเก็บทุก Log ตลอดไปเผื่ออนาคตเพิ่ม Attack Surface และ Cost Feature ที่ไม่เพิ่มคุณค่าแต่มี Sensitive Attribute สูงควรถูกตัด ไม่ใช่เก็บเพราะ Storage ถูก

Fairness เป็นคำถามหลายแบบ

Equal Error Rate, Equal Opportunity, Calibration และ Individual Fairness อาจขัดกัน ต้องเลือกตามบริบทและกฎหมาย ไม่ควรประกาศว่าโมเดล “Fair” จาก Metric เดียว Proxy เช่น Postcode หรือ Device อาจนำ Sensitive Attribute กลับมาแม้ลบคอลัมน์ตรง ๆ

Explainability ตามผู้รับ

Right to Correct และ Right to Forget

ข้อมูลถูกแก้หรือลบแล้ว Downstream Feature, Cache, Training Set และ Model ทำอย่างไรเป็นคำถามระบบกระจายเต็มรูปแบบ การลบจาก Table ต้นทางไม่ได้ทำให้สำเนาและโมเดลลืมเอง ต้องมี Lineage, Retention และกระบวนการ Retrain/Unlearning ตามความเสี่ยง

13สรุปภาพรวมทั้งวิชา: ทุกอย่างประกอบกันอย่างไร

ระบบหนึ่งประกอบบทเรียนหลายบทอย่างไร

Fraud Detection ตัวอย่างเดียวใช้ HDFS/Object Storage เก็บประวัติ, Spark SQL สร้าง Feature, Streaming รักษา Window State, Graph หา Ring, ML ให้คะแนน, NoSQL/Online Store ให้บริการ และ Distributed Systems ดูแล Failure/Consistency การแบ่งเป็นบทช่วยเรียน แต่ระบบจริงนำทุกบทกลับมาประกอบกัน

Technology Stack ไม่ใช่ Architecture

รายชื่อ Kafka + Spark + Cassandra + Kubernetes บอกผลิตภัณฑ์ แต่ยังไม่บอก Data Contract, State Ownership, Consistency, Replay, Failure หรือ Decision Flow Architecture ต้องอธิบายความสัมพันธ์และเหตุผล ไม่ใช่เพียงโลโก้เรียงบนสไลด์

ความรู้ที่ควรติดตัวหลังเรียนจบ

1. เริ่มจาก Decision และ Constraint ก่อนเลือกเทคโนโลยี
2. เคลื่อน Code ไปหา Data และลดข้อมูลก่อนข้าม Network
3. ใช้ Algebra, Associativity และ Summary เพื่อจัดรูปการคำนวณ
4. มอง Failure, Retry, Duplicate และ Late Data เป็นเรื่องปกติ
5. วัด System, Model และ Business แยกกัน
6. ระบุ Error Budget, Latency Budget และ Cost Budget
7. เก็บ Lineage/Version เพื่อทำซ้ำ แก้ไข และรับผิดชอบ
8. รู้ว่าเมื่อใดระบบง่ายกว่าคือคำตอบที่ดีกว่า

14สรุปและขั้นตอนถัดไป

ตลอดวิชา เราเริ่มจากคำว่า Big Data แล้วค่อยพบว่าขนาดไม่ใช่แก่นเดียว ปัญหาจริงอยู่ที่การเคลื่อนข้อมูล การแบ่งงาน ความไม่สอดคล้องชั่วคราว เวลา State ความสัมพันธ์ และการเรียนรู้จากข้อมูล เมื่อมาถึงกรณีศึกษา ทุกแนวคิดกลับมารวมกันภายใต้คำถามเดียวว่า “ระบบช่วยให้เกิดการตัดสินใจที่ดีขึ้นจริงหรือไม่”

กรณีศึกษาไม่ได้ให้สูตรสำเร็จ แต่ให้โครงถาม Problem → Decision → Data → Architecture → Evaluation → Failure → Governance หากตอบครบ เรามักเห็นเองว่าอะไรจำเป็น อะไรเกิน และจุดใดต้องทดลองก่อนลงทุนขยายขนาด

ขั้นตอนถัดไป ไม่ใช่บทที่ 14 แต่คือภาคปฏิบัติ เริ่มจาก Lab ที่เล็กพอให้เห็นข้อมูลไหลจริง แล้วค่อยประกอบ Capstone หนึ่งระบบโดยต้องอธิบายทั้งการตัดสินใจ สถาปัตยกรรม Metric, Failure และ Governance เป้าหมายไม่ใช่ใช้เครื่องมือให้ครบ แต่เลือกเครื่องมือเท่าที่จำเป็นและพิสูจน์เหตุผลได้