สรุปหลักการของ Data Architecture ที่ดี principle good data architecture

แวะมาทักทายกันได้

สรุปหลักการของ Data Architecture ที่ดี ตอนที่ 1 : Choose Common Components Wisely เลือกเครื่องมืออย่างฉลาด อ่านใน comment

1️⃣ Good data architecture

คำว่า Architecture เป็นเหมือนตัวแทน หรือ ตัวอย่าง ของการออกแบบที่จะเอาไว้ตัดสินใจเลือกว่าจะมีโครงสร้างของระบบแบบใด โดยมีเป้าหมายที่จะ สร้างความมั่นใจในการวางโครงสร้างตั้งแต่ยังไม่เริ่มวางระบบ

นิยามความหมายของคำว่า good data architecture คือการสร้างความ ยืดหยุ่นของระบบและง่ายต่อการบำรุงรักษาเพื่อสนับสนุนงานทางธุรกิจและเทคโนโลยีใหม่ๆ และ ในทางตรงกันข้าม Bad data architecture จะมักจะเป็นระบบที่ไม่สามารถเปลี่ยนแปลงได้ง่าย

2️⃣ หลักการของ Data Architecture ที่ดี

หลักการ (principle) เป็น key สำคัญที่เอาไว้ประเมินโครงสร้างของระบบเพื่อนำไปใช้งาน ซึ่ง หลักการนั้นในหลายๆ platform ก็มีหลักการที่เป็นของต้นเอง อย่างเช่น

AWS ก็มีหลักการทั้งหมด 6 ข้อ ประกอบไปด้วย

• Operational excellence
• Security
• Reliability
• Performance efficiency
• Cost optimization
• Sustainability

Google cloud ก็มีเช่นเดียวกัน ประกอบไปด้วย 5 ข้อ

• Design For automation
• Be smart with state
• Favor managed service
• Practice defense in depth
• Always be architecting

แต่โดยสรุปแล้ว ไม่ว่าจะ platform ไหนก็ตาม ควรจะประกอบไปด้วยหลักการทั้งหมด 9 ข้อ ดังนี้

• Choose common component wisely
• Plan for failure
• Architect for scalability
• Architecture is leadership
• Always be architecting
• Build loosly coupled system
• Make reversible decisions
• Prioritize security
• Embrace FinOps

3️⃣ สำหรับโพสนี้ จะเขียนสรุปในส่วนของ หลักการข้อแรกกันก่อน

Principle 1 : Choose Common Components Wisely

เลือกเครื่องมืออย่างฉลาด

ต้องบอกว่าเครื่องมือในปี 2023 นี้มีมากมายก่ายกองเต็มไปหมดดังภาพ

4️⃣หน้าที่หลักของ data engineer จะต้องเข้าใจเครื่องมือให้เหมาะกับปัญหาที่จะนำไปแก้ไข โดยยึดหลักใน ความถูกต้องของข้อมูล การทำงานร่วมกันในองค์กรเพื่อทลายการทำงานแบบ silo ร่วมถึงการแบ่งปันความรู้ โดยการแชร์ ความรู้อาจจะเป็นการเขียนบทความ หรือ ทำ video ส่งให้แก่กันในองค์กรก็ได้

5️⃣มารู้จักกับ Common component เป็นเหมือนกับเครื่องมือหลักที่จะต้องมีในระบบ ได้แก่

• Object Storage เป็นเครื่องมือ ที่เก็บข้อมูลแบบไม่มีโครงสร้าง อย่างเช่น google cloud storage เป็นต้น
• version-control เป็นเครื่องมือสำหรับการพัฒนาซอฟต์แวร์ จัดเก็บ source code ในแต่ละ version
• monitoring เป็นเครื่องมือสำหรับดูการเปลี่ยนแปลงของข้อมูล
• orchestration เครื่องมือที่ช่วยจัดการ task งานในระบบต่างๆ

6️⃣นอกจากนี้จะต้องควบคุมการเข้าถึงของข้อมูล โดยสามารถเข้าถึงได้ทุกคนตามความเหมาะสมภายใต้เงื่อนไขการใช้งานของแต่ use case รวมถึงการทำงานร่วมกันของทีม ให้เหมือนฟันเฟืองขับเคลื่อนระบบ

7️⃣ โดยสรุปแล้ว ต้องเข้าใจเครื่องมือให้เหมาะกับปัญหาที่จะนำไปแก้ไข โดยยึดหลักการเลือกใช้เครื่องมือให้เหมาะสม

สรุปหลักการของ Data Architecture ที่ดี ตอนที่ 2 : Plan for failure วางแผนให้รัดกุม ป้องกันระบบล่ม อ่านใน comment

1️⃣ แม้ว่ายุคนี้ cloud จะเป็นที่นิยมเป็นอย่างมาก ทั้งยังระบบยังแข็งแกร่งทนทาน ล่มได้ยาก แต่ไม่ว่าอย่างไรก็ตาม ระบบล่มก็อาจจะเกิดขึ้นได้ เพื่อป้องกันเหตุที่คาดไม่ถึง ควรเตรียมความพร้อมไว้ตั้งแต่เนิ่นๆ อย่างเรื่องการวางแผน

2️⃣ ความพร้อมใช้งาน (Availability)

data architecture ที่ดี ควรมีความพร้อมใช้งานที่สูง ผู้ใช้สามารถเข้าถึงข้อมูลได้ตลอดเวลาที่ต้องการ ความอัตราส่วนของเวลา ว่าระบบจะสามารถถูกกู้คึนกลับมาได้เป็นเวลาเท่าไร

3️⃣ ความน่าเชื่อถือ (Reliability) ****

ควรกำหนดมาตรฐาน ข้อปฏิบัติขั้นตอนเมื่อเกิดเหตุและระบุช่วงเวลาในการจัดการเอาไว้ เพื่อ การทำงานได้อย่างถูกต้องเพื่อให้สามารถให้บริการข้อมูลแก่ผู้ใช้ได้อย่างมีประสิทธิภาพและต่อเนื่อง

4️⃣ Recovery time objective (RTO) ****

ระยะเวลาที่ยอมรับได้ในการกู้คืนระบบ โดยปกติจะพิจารณาจากผลกระทบทางธุรกิจ โดยจะต้อง report ให้ภายในองค์กร มักจะกำหนดเป็นหน่วยเวลา เพื่อให้ความสำคัญกับระบบว่าสำคัญเพียงใด

5️⃣ Recovery point objective (RPO)

ระยะเวลาที่ยอมรับได้ในการกู้คืนข้อมูลกลับมายังระบบ เช่นเดียวกันกับ RTO ที่จะต้องกำหนดปริมาณข้อมูลที่สูญหาย ว่าปริมาณเท่าไรจึงยอมรับได้ ไม่ส่งผลกระทบต่อธุรกิจ โดยจะต้องคำนึงถึง ความสำคัญของข้อมูล ผลกระทบการสูญหาย ความพร้อมใช้งาน

6️⃣ จากหลักการข้างต้น เราสามารถวางแผนป้องกันระบบล่มได้ดังนี้

การสำรองข้อมูล (Data Backup)

เป็นการสำรองข้อมูลไว้ในรูปแบบต่างๆ เช่น สำรองข้อมูลแบบ hot backup, cold backup, หรือ cloud backup เพื่อให้สามารถกู้คืนข้อมูลได้อย่างรวดเร็วในกรณีที่ระบบล่ม

การกระจายข้อมูล (Data Distribution)

เป็นการกระจายข้อมูลไปยังระบบต่างๆ หลายแห่ง เพื่อให้ระบบล่มเพียงแห่งเดียวจะไม่ส่งผลกระทบต่อระบบทั้งหมด

การติดตามและแจ้งเตือน (Monitoring and Alerting**)**

เป็นการติดตามสถานะของระบบและแจ้งเตือนเมื่อเกิดปัญหา เพื่อให้สามารถแก้ไขปัญหาได้อย่างรวดเร็ว

การทดสอบและปรับปรุง (Testing and Improvement)

เป็นการทดสอบสถาปัตยกรรมข้อมูลอย่างสม่ำเสมอ และทำการปรับปรุงเพื่อแก้ไขจุดอ่อนต่างๆ

1️⃣0️⃣0️⃣ นับว่าเป็นสิ่งที่สำคัญยิ่งต่อการดูแลระบบ ควรจะวางแผนเอาไว้และเตรียมความพร้อมเสมอ

สรุปหลักการของ Data Architecture ที่ดี ตอนที่ 3 : Architect for Scalability ความสำคัญของการขยายระบบอ่านใน comment

1️⃣การขยายระบบเป็นเรื่องที่สำคัญอีกเรื่องหนึ่งที่ต้องพิจารณาหลายอย่าง ไม่ว่าจะเรื่อง ค่าใช้จ่ายที่จะต้องจัดซื้อคอมพิวเตอร์ การวางแผนคำนวนการใช้งานต่างๆในระบบ การออกแบบโครงสร้างที่ดี และ เรื่องการทดสอบระบบ ซึ่งในยุคนี้ มีความสะดวกสบายมากขึ้น มีเทคโนโลยีอย่างเรื่อง cloud solution ต่างๆมาช่วยตอบโจทย์ ให้ทำงานได้ง่ายขึ้น ซึ่ง ทุกเรื่องที่กล่าวมาเกี่ยวข้องกับ การสเกลระบบ (Scaling System)

2️⃣การสเกลระบบ มีอยู่ 2 ส่วนหลักๆ

อย่างแรก การ scale up หรือ การขยายระบบให้เพิ่มขึ้นโดยจัดการระบบให้เพิ่มขึ้นตามปริมาณที่ data เพิ่มขึ้น ไม่ว่าจะเป็น Data transfer บน Network Computer หรือ Storage ยกตัวอย่าง เช่น เราอาจจะมองในเรื่องของการทำ cluster ที่ใหญ่ขึ้น เพื่อรองรับการ train model ในระดับ petabyte

3️⃣การที่คอมพิวเตอร์จะทำงานได้ในประสิทธิภาพที่สูงนั้น จะต้องนำคอมพิวเตอร์มาต่อๆกันหลายๆ เครื่อง เรียกว่าการ cluster จะทำให้ cpu, ram, storage รองรับปริมาณการใช้งานได้มากขึ้น ซึ่ง ประสิทธิภาพที่มากขึ้น ราคาที่ต้องจ่ายให้กับการทำ cluster นั้นก็จะสูงขึ้นตามไปด้วย

4️⃣ยก use case การใช้งาน สักหนึ่งตัวอย่าง แอปพลิเคชันธนาคารแห่งหนึ่ง จะมีช่วง peak การใช้งานก็ช่วงเวลาต่างๆ เช่น เงินเดือนออก หรือ ต้องสมัครสมาชิกเมื่อมีสวัสดิการพิเศษและมีโค้วต้า เป็นต้นซึ่งความสามารถในการ scale up นั้นจะต้องรองรับการ load data ขนาดใหญ่ได้ จากวิธีที่กล่าวมาข้างต้น

5️⃣อย่างที่สอง การ scale down หรือ การลดขนาดลง เมื่อการเพิ่มขึ้นไม่ได้คงอยู่ตลอดไป จากที่ยกตัวอย่างมาเรื่องธนาคาร ไม่ได้มีการใช้งานปริมาณมากอยู่ตลอดเวลา ก็จำเป็นต้องลดขนาดลง จากที่ได้กล่าวไปข้างต้นว่า การทำ cluster จะมีค่าใช้จ่ายที่สูงขึ้นตามการใช้งาน เมื่อไม่มีการใช้งาน ก็ลดขนาดของ cluster ลงทำให้ลดค่าใช้จ่ายลงได้

6️⃣เมื่อระบบสามารถ Scale ได้อย่างยืดหยุ่น ก็สามารถเข้าสู่ความเป็น Automation ได้อย่างสมบูรณ์

ถึงแม้ว่าจะสะดวกขึ้นก็ยังต้องคำนึงถึงการออกแบบที่ดี และ เหมาะสมกับการใช้งาน การวางกลยุทธ์ในการวางระบบ ถ้าสามารถทำระบบให้ยืดหยุ่นได้แล้วแต่ระบบซับซ้อน ก็ไม่ตอบโจทย์ทั้งยังทำให้ราคาค่าใช้จ่ายสูงตามไปด้วย

7️⃣สิ่งที่สำคัญอีกหนึ่งเรื่อง คือ การทดสอบ load test เพื่อดูว่าระบบโครงสร้างเหมาะสมและรองรับการใช้งานเท่าไร พร้อมใช้งานตลอดเวลาหรือไม่ ตัวอย่างต่างๆ ในการทำ scale architect มีอยู่หลายรูปแบบตามความต้องการ และ ความเหมาะสมในการออกแบบ มีดังต่อไปนี้

• สถาปัตยกรรมแบบกระจาย (Distributed Architecture)

  การกระจายงานหรือข้อมูลไปยังเซิร์ฟเวอร์หลายเครื่อง ช่วยให้สามารถรองรับการเพิ่มจำนวนผู้ใช้หรือปริมาณงานได้โดยไม่ต้องเพิ่มขีดความสามารถของเซิร์ฟเวอร์แต่ละเครื่อง

• สถาปัตยกรรมแบบคลาวด์ (Cloud Architecture)

  ทรัพยากรคอมพิวเตอร์จากผู้ให้บริการคลาวด์ ปรับขนาดได้ตามความต้องการใช้งาน อย่าง google cloud, microsoft azure, AWS amazon

• สถาปัตยกรรมแบบไมโครเซอร์วิส (Microservices Architecture)

  แบ่งระบบออกเป็นบริการย่อยๆ ที่สามารถทำงานร่วมกันได้ ช่วยให้สามารถปรับขนาดบริการแต่ละตัวได้อย่างอิสระ

• สถาปัตยกรรมแบบไร้เซิร์ฟเวอร์ (Serverless Architecture)

  บริการคลาวด์ที่ให้บริการประมวลผลและจัดเก็บข้อมูลแบบอัตโนมัติ

8️⃣ปัจจัยสำคัญที่ต้องพิจารณาในการเลือกสถาปัตยกรรมสำหรับความสามารถในการปรับขนาด ได้แก่:

• ประเภทของงานที่ต้องการประมวลผล : งานที่ต้องใช้ Resource คอมพิวเตอร์มาก เช่น การประมวลผลภาพหรือวิดีโอ จำเป็นต้องใช้สถาปัตยกรรมที่สามารถรองรับการประมวลผลแบบขนานได้
• ปริมาณข้อมูลที่ต้องจัดเก็บ : ข้อมูลที่ต้องใช้พื้นที่จัดเก็บมาก เช่น ข้อมูลลูกค้าหรือข้อมูลทางธุรกิจ จำเป็นต้องใช้สถาปัตยกรรมที่สามารถรองรับการขยายพื้นที่จัดเก็บได้
• ข้อจำกัดด้านงบประมาณและเวลา : สถาปัตยกรรมที่มีความซับซ้อนอาจต้องใช้งบประมาณและเวลาในการพัฒนามากกว่าสถาปัตยกรรมที่เรียบง่าย

9️⃣รวมถึงวิธีการทดสอบ และ ทดลองต่างๆ เพื่อให้ได้ข้อมูลมาวางแผนและเตรียมความพร้อม

• การทดสอบโหลด (Load Testing) เป็นการทดสอบระบบเพื่อดูปริมาณการใช้งานจริง ช่วยให้สามารถทดสอบประสิทธิภาพของระบบเงื่อนไขต่างๆ เช่น การใช้งานระบบจำนวนมากพร้อมกัน เช่นการเข้าแอปพลิเคชันพร้อมกัน

1️⃣0️⃣ นับว่าเป็นความสะดวกสบายที่เพิ่มมากขึ้นต่อการออกแบบและการวางระบบ ควรเลือก architect ให้เหมาะกับธุรกิจ และ ค่าใช้จ่ายที่มี

สรุปหลักการของ Data Architecture ที่ดี ตอนที่ 4 : Architect Is Leadership ความสัมพันธ์ระหว่างการบริหารและเทคฯ อ่านใน comment

1️⃣ Architecture for leadership เป็นหลักการของการบริหารจัดการข้อมูล และ นำข้อมูลเข้าสู่ระบบธุรกิจ เพื่อให้การบริการตัดสินใจไปในทางที่ดีสำหรับธุรกิจในระยะยาว นี้เป็นเรื่องสำคัญเรื่องหนึ่งของ Data Architecture และ Data Management ซึ่งมีองค์ประกอบหลายอย่าง ได้แก่

• การวางแผนและกลยุทธ์ข้อมูล เช่น แผนการดำเนินงาน ตามวัตถุประสงค์ขององค์กร
• โครงสร้างข้อมูล เช่น การกำหนดโครงสร้างข้อมูล การจัดเก็บ การจัดการการเข้าถึงข้อมูล
• ความรับผิดชอบ เช่น บทบาทและความรับผิดชอบในการบริหารข้อมูล
• ความสอดคล้อง เช่น ข้อมูลที่สอดคล้อง ตามมาตรฐานที่กำหนดเอาไว้
• การควบคุมอยู่ตามกฎระเบียบ เช่น มีมาตรฐาน การดำเนินงานตามกฎ ปฏิบัติตามหลักการของธุรกิจ เช่น ISO

2️⃣ การบริหารที่ดี นั้นจะประกอบไปด้วย ทักษะต่างๆ เช่น

• ทักษะทางเทคโนโลยี หมายถึง การมีความรู้และความสามารถในงานที่ทำ
• ทักษะมนุษย์สัมพันธ์ หมายถึง ความสามารถที่จะทำงานได้อย่างมีประสิทธิภาพร่วมกับผู้อื่น
• ทักษะวางแผน หมายถึง มีกลยุทธ์ในการวางแผนและมองภาพใหญ่ของธุรกิจออก
• ทักษะการตัดสินใจ หมายถึง ความสามารถในการประเมินและตัดสินใจในตัวเลือกต่างๆจากข้อมูลที่มี
• ทักษะการแก้ปัญหา หมายถึง ความสามารถที่จะปิดจบปัญหาได้อย่างมีประสิทธิภาพ

3️⃣ Data architecture เป็นเหมือนต้นแบบของเทคโนโลยี มีความสำคัญต่อการตัดสินใจและอธิบายโครงสร้างของข้อมูล เพื่อประสิทธิภาพต่อการบริหารที่ดีและถ่ายทอดความรู้การใช้งานระบบ

4️⃣ สิ่งเหล่านี้ล้วนเป็นทักษะที่จะช่วยให้เป็นผู้นำที่ดี ซึ่งในเรื่องที่จะกล่าวถึง

5️⃣ การบริหารที่ดีและแข็งแกร่งเกิดจากการที่มีทักษะทางเทคโนโลยีและความเชี่ยวชาญที่สูงและสร้างคุณค่าให้กับธุรกิจได้ โดย Data architecture ที่ดีควรจะส่งเสริมเรื่องเหล่านี้อย่างจริงจัง

6️⃣ การบริหารที่แข็งแกร่งที่กล่าวเอาไว้ข้างต้น ไม่ได้หมายความว่า บริหารโดยการควบคุมและสั่งการให้เข้าถึงเทคโนโลยีแบบบังคับ ซึ่งวิธีการบริหารแบบนี้ มันล้าสมัยไปแล้ว เพราะ ไม่มีใครชอบถูกบังคับอย่างแน่นอน

7️⃣ ในยุคการทำงานที่จะต้องรวดเร็ว หนีไม่พ้นการทำงานแบบ agile process หากกล่าวถึง เรื่องของการบริหารด้วย agile process จะมีเรื่องของ self-organize เข้ามาเกี่ยวซึ่งทุกคนในทีมจะสามารถทำงานด้วยตัวเองได้ วางแผนงาน แก้ปัญหาเองได้ เป็นต้น

8️⃣ การจะทำให้เกิดระบบที่ดีได้ ต้องเกิดจากทั้งสองส่วน ทั้งการบริหารและระบบการทำงาน

9️⃣ คำถามถัดไป คือ จะทำอย่างไรให้ทั้งสองส่วนทำงานได้อย่างสัมพันธ์กัน และ การทำอย่างไรในการนำ data architecture มาช่วยให้ทักษะที่ดีเหล่านี้เกิดขึ้นด้วยเทคโนโลยี

1️⃣0️⃣การทำให้เกิด data architecture ที่ดี จะช่วยตอบโจทย์กับคำถามข้างต้น ที่จะช่วยพลักดันสิ่งเหล่านี้ให้เกิดขึ้นมาได้ด้วย คือ platform ที่เหมาะสม ซึ่ง platform ที่เหมาะสม จะเกิดจากการเลือก เครื่องมือใช้งานที่เหมาะสม อย่างเช่น การเลือกใช้งาน Cloud Platform ที่จะมีช่วยหลายๆอย่างเช่น

ในทางระบบ ได้แก่

• ฐานข้อมูล (Database)
• การประมวลผลข้อมูล (Data Processing)
• การจัดเก็บข้อมูล (Data Storage)
• การนำทางข้อมูล (Data Governance)
• การควบคุมคุณภาพข้อมูล (Data Quality Control)
• การมอนิเตอร์ (Monitoring and Alert)

ในทางบริหาร ได้แก่

• การตัดสินใจด้วยข้อมูล (Data Decision)
• การเข้าถึงข้อมูลตาม use case แต่ละผู้ใช้งานที่เกี่ยวข้อง (Data Access)
• ความปลอดภัยในข้อมูล (privacy and security)

ซึ่งได้กล่าวเอาไว้ในบทก่อนๆแล้ว

สรุปหลักการของ Data Architecture ที่ดี ตอนที่ 5 : Always Be Architecting เพื่อความต่อเนื่องที่ยั่งยืน อ่านใน comment

1️⃣ Always Be Architecting ถ้าแปลตรงตัว ความหมายคือ การวางระบบหรือการพัฒนาระบบอย่างต่อเนื่อง โดยหลักการนี้ เป็นหลักการของการทำ architecture ของ google cloud ที่จะอ้างถึงในตอนที่ 5 นี้

2️⃣ สำหรับโพสต์ที่แล้ว ตอนที่ 4 เขียนถึงหลักการของการบริหารจัดการข้อมูล (Architect Is Leadership) มีความเกี่ยวข้องกับในบทนี้เป็นอย่างมาก และ เกี่ยวข้องกับบทถัดไปอีกด้วย

3️⃣ ในการพัฒนาระบบนั้นเป็นเหมือนกับการพัฒนาความรู้ไปในตัวทั้งยังต้องค้นหาข้อมูลเชิงลึก เพื่อรู้ปัญหาของระบบอย่างแท้จริง เหมือนการวางหลักฐานที่ดีของระบบ เพื่อนำไปสู่การพัฒนาโครงสร้างเป็นไปตามเป้าหมายโดยมีการวางแผนอย่างต่อเนื่อง และพิจารณาตามความสำคัญของงาน ตามความเร่งด่วน หรือ ปริมาณงาน เป็นต้น

4️⃣ อย่างที่ได้กล่าวไปในตอนที่ 4 นั้น เมื่อเข้าสู่ยุค digital ที่ให้ความสำคัญกับ self-organize มากขึ้น จะไม่มีการทำงานแบบสั่งการ (command-and-control) หรือ waterfall อีกต่อไป โดยเข้าสู่ยุค modern architecture หรือก็คือการทำงานร่วมกันแบบ process agile

5️⃣ โดยมีหลักการทำงานโดยการวางแผนอย่างเป็นลำดับ อาจจะใช้เครื่องมือมาช่วยบริหารจัดการอย่าง Jira หรือ trello เพื่อตอบสนองความต้องการของธุรกิจที่เปลี่ยนแปลงอย่างรวดเร็ว โดยพิจารณาการทำงานตามลำดับความสำคัญของงานในการทำ เพื่อทำให้ส่งมอบได้ทันที

6️⃣ หลักการที่สนับสนุนความคิดในการพัฒนาระบบหรือซอฟต์แวร์อย่างต่อเนื่อง โดยพิจารณาว่าสามารถ

• ปรับปรุงสิ่งเหล่านี้ได้อย่างมีประสิทธิภาพอย่างไร
• ทำงานแบบเชิงรุก ระบุปัญหาและวิธีแก้ไขที่เกิดขึ้น
• ปรับตัวให้เข้ากับเทคโนโลยีใหม่
• การปรับขนาด ความยืดหยุ่น และความปลอดภัยมากขึ้น

7️⃣ มีหลายเหตุผลที่ นำหลักการของ agile process มาใช้งาน

• ความต้องการที่เปลี่ยนแปลงอย่างรวดเร็ว
• ความต้องการใหม่เกิดขึ้น
• ความต้องการเก่าเปลี่ยนแปลง
• มีเทคโนโลยีใหม่มาทดแทน
• ระบบมีความซับซ้อนเพิ่มขึ้นตามกาลเวลา เมื่อระบบโตขึ้นและพัฒนาขึ้น จะทำให้ทำความเข้าใจและจัดการได้ยากขึ้น

8️⃣ แนวทางที่ดีและจำเป็นของการเป็น Data Architecture ที่ดีนั้น อาจจะต้องประกอบไปด้วยหลายเรื่อง เพื่อแนวทางปฏิบัติที่ดีและถูกต้อง เช่น

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

สรุปหลักการของ Data Architecture ที่ดี ตอนที่ 6 : Build Loosely Coupled Systems แยกระบบเพิ่มความยืดหยุ่น อ่านใน comment

1️⃣ คำว่า Loosely Coupled ถูกนำไปใช้ในหลายๆงาน ถ้าในงานของการเขียนโปรแกรม ก็เกี่ยวข้องกับการออกแบบ โครงสร้างของโปรแกรมหรือการออกแบบโปรแกรมเชิงวัตถุ OOP ให้มีการเรียกใช้งาน Class หรือ inheritance Class กันอย่างหลวมๆ ออกแบบให้มีความเกี่ยวข้องกันระหว่าง Class น้อยที่สุดเพื่อไม่ให้กระทบต่อการเรียกใช้งาน หมายความว่า เวลาที่เกิดปัญหา หรือเกิด bug software เวลาที่แก้ไข จะไม่กระทบต่อส่วนอื่นๆในโปรแกรมที่เรียกใช้งาน Class ร่วมกัน

2️⃣ นอกจากงานทางการเขียนโปรแกรมแล้ว ยังนำไปใช้กับการออกแบบสถาปัตยกรรมต่างๆ ขนาดใหญ่ อย่างเช่นวิธีการทำงาน พูดง่ายๆ เลยคือ มันเป็นแนวคิดในการออกแบบให้สามารถทำงานได้อย่างยืดหยุ่น

3️⃣ อย่างที่เกริ่นไป เป็นการยกตัวอย่างจากประสบการณ์เดิมกับคำว่า Loosely Coupled ที่นำไปใช้กับการออกแบบ Software Application แต่สำหรับโพสต์นี้ สรุปหลักการของ Data Architecture ที่ดี ตอนที่ 6 : Build Loosely Coupled Systems ยังคงเกี่ยวข้องกับเรื่องของ Data ซึ่งแนวคิดนี้ เกี่ยวข้องกับ DataOps

5️⃣ dataops เป็นแนวทางการทำงานของทีม data ที่มุ่งเน้นผสมผสาน ประสานงานระหว่างกระบวนการที่เกี่ยวข้องกับการพัฒนา data product ตั้งแต่การรวบรวมข้อมูล การทำความสะอาดข้อมูล การวิเคราะห์ข้อมูล ไปจนถึงการเผยแพร่ข้อมูล ซึ่ง การนำ หลักการของ Loosely Coupled มาใช้โดยการแยกกระบวนการต่างๆ ออกเป็นส่วนๆ แยกออกจากกัน เพื่อให้ยืดหยุ่นให้มากที่สุด วิธีการนั้นคือ การสร้าง API

• ———————————— *

• 1️⃣0️⃣0️⃣ หากใครไม่อยากพลาด

• โพสต์เรื่องเกี่ยวกับ *

• data analyst, data science, *

• data engineer และ programming *

• ในโพสต์ถัดๆไป ฝากแชร์ กดติดตาม *

• profile กันไว้ด้วยนะครับ *

• *———————————— **

6️⃣ นอกจากนี้ การออกแบบระบบแบบ loosely coupled ยังหมายถึง การช่วยให้ทีมต่างๆ สามารถทำงานได้โดยใช้เครื่องมือ ทำให้ช่วยแยกหน้าที่ของแต่ละงาน ออกจากันได้ โดยไม่จำเป็นต้องนัดประชุมกันตลอดเวลาเมื่อเกิดปัญหา หรือ ต้องแก้ไขระบบต่างๆ

7️⃣ สามารถใช้เครื่องมือต่างๆ มาช่วย ซึ่งเครื่องมือเหล่านี้ เป็นสิ่งที่สำคัญมาก สำหรับ dataops และ devops เนื่องจากทั้งสองวิธีทำงานนี้ต้องเผชิญกับความเปลี่ยนแปลงอย่างรวดเร็วของเทคโนโลยีและข้อมูล เช่น

• การใช้เทคโนโลยีอัตโนมัติ (automation) เพื่อลดภาระงานซ้ำซาก อย่าง CICD บน Gitlab หรือ Jenkin เป็นต้น
• การจัดการข้อมูล (data management technology) และ ความปลอดภัย (security technology) เพื่อปกป้องข้อมูล ถ้าใช้ระบบ Cloud จะมีเมนูจัดการ access การเข้าถึงข้อมูลต่างๆได้ โดยที่ไม่ต้องยุ่งยากเรื่อง Server เท่าไรนัก อาจจะมีเกี่ยวข้องบ้างแต่น้อยลง

8️⃣ ซึ่งจริงๆ แล้ว software product หรือ data product ก็ตามส่วนประกอบของทีม มีทั้ง นักพัฒนา devloper นักทดสอบระบบ tester ผู้ประสานงาน PM PO ทุกคนล้วนมีหน้าที่ของตนเองที่ต้องทำงานร่วมกันอย่างเป็นระบบ โดยการทำงานนั้นจะตกลง Policy ของทีมร่วมกัน โดยการใช้ Tool Management อย่างการทำงานโดยใช้ Backlog หรือ ชิ้นงานมาหั่น และ ประเมินเวลาในการทำงานร่วมกัน (scrum)

9️⃣ นอกจากนี้ สถาปัตยกรรมต่างที่ เหมาะกับการนำหลักการ loosely coupled มาใช้ เช่น

• การใช้สถาปัตยกรรมแบบไมโครเซอร์วิส (microservices architecture) กับ data architecture ซึ่งช่วยให้สามารถพัฒนาและบำรุงรักษาระบบข้อมูลที่ซับซ้อนได้ง่ายขึ้น
• การใช้เทคโนโลยีคลาวด์คอมพิวติ้ง (cloud computing) กับ data architecture ซึ่งช่วยให้สามารถจัดเก็บและประมวลผลข้อมูลได้แบบกระจายและยืดหยุ่น

1️⃣0️⃣0️⃣ โดยสรุปแล้วหลักการ Build Loosely Coupled Systems เป็นแนวคิดในการจัดการทีมงาน ที่มีอยู่หลายๆทีม หรือ ระบบที่มีอยู่หลายๆระบบ โดยใช้เครื่องมือต่างๆ อย่างการทำ API แยกระบบออกจากกัน เพื่อความยืดหยุ่นช่วยการทำงานลื่นไหล และ ไม่ผูกติดกัน จนไม่สามารถทำงานอื่นได้และมีประสิทธิภาพมากขึ้น

สรุปหลักการของ Data Architecture ที่ดี ตอนที่ 7 : Make Reversible Decision การตัดสินใจที่ย้อนกลับได้

1️⃣  หากยังจำกันได้ ภาพของเครื่องมือต่างๆที่ในงาน data engineer ที่เรียกว่า Data Landscape มีเครื่องมือต่างๆมากมายที่ในงาน dataops หากใครจำไม่ได้ ย้อนขึ้นไปดูภาพส่วนที่ 1 ของ Principle 1 : Choose Common Components Wisely

2️⃣ ประเด็นสำหรับโพสต์นี้คือ ด้วยเทคโนโลยีที่เปลี่ยนแปลงไปอย่างรวดเร็ว มีเครื่องมือมายมายให้เลือกสรร สามารถใช้งานให้ตอบโจทย์ กับ ปัญหาที่พบเจอได้ ซึ่งในการออกแบบ data architecture ก็ได้แนะนำเอาไว้ว่า ควรจะตัดสินใจทันที ถ้าต้องเปลี่ยนแปลงระบบย้อนกลับ make reversible decision ซึ่งถ้าแปลตรงตัว ก็หมายความว่า “การตัดสินใจที่ย้อนกลับได้”

3️⃣ ในบริบทของสถาปัตยกรรมข้อมูล หรือ data architecture นั้น หมายถึงการตัดสินใจเกี่ยวกับการออกแบบหรือการใช้งานสถาปัตยกรรมข้อมูลที่สามารถเปลี่ยนแปลงได้ภายหลัง หากผลลัพธ์ไม่เป็นที่น่าพอใจ

4️⃣ ในการตัดสินใจที่ย้อนกลับได้ ถ้าเป็นการตัดสินใจที่ส่งผลไม่รุนแรง หรือ มีค่าใช้จ่ายที่ไม่สูงมาก เช่น การตัดสินใจเลือกเทคโนโลยีฐานข้อมูล (database) การตัดสินใจเลือกเครื่องมือวิเคราะห์ข้อมูล (data warehouse) การตัดสินใจเลือกโครงสร้างข้อมูล (data pipeline) เป็นต้น

5️⃣ ในกระบวนการต่างๆ เพื่อที่จะรู้ได้ว่า สิ่งที่สร้างหรือออกแบบมานั้น ไม่ได้ผล คือ การทดลอง และ การทดสอบ เปรียบเทียบผลลัพท์ที่เกิดขึ้น ด้วยวิธีการจำลองต่างๆ โดยใช้ต้นทุนให้น้อยที่สุด หรือ เรียกสั้นๆว่า Research process ให้ทำการศึกษา หรือ อ่าน document ก่อนที่เริ่มลงมือจะได้ไม่เสียเวลาในภายหลัง

6️⃣ ดังนั้นเวลาที่ออกแบบระบบ ควรจะคำนึงถึง การออกแบบตามหลักการ data architecture ที่ผ่านๆมาด้วย อย่างเช่น loosly couple ควรจะออกแบบให้แยกส่วน เพื่อที่จะเปลี่ยนแปลงได้ง่าย และ เราควรจะวาง solution เอาไว้หลายๆ แบบ หรือ 2 แผนเป็นอย่างน้อยเสมอ เพื่อเป็นตัวเลือกในการเปลี่ยนแปลง ถ้าไม่สามารถทำได้ เพราะติดปัญหาต่างๆ เช่น งบประมาณในการใช้งาน เป็นต้น

• ———————————— *

• 1️⃣0️⃣0️⃣ หากใครไม่อยากพลาด

• โพสต์เรื่องเกี่ยวกับ *

• data analyst, data science, *

• data engineer และ programming *

• ในโพสต์ถัดๆไป ฝากแชร์ กดติดตาม *

• profile กันไว้ด้วยนะครับ *

• *———————————— **

  
  

1️⃣0️⃣0️⃣ โดยสรุปแล้ว ในการตัดสินใจที่ย้อนกลับได้ ถ้าเป็นการตัดสินใจที่ส่งผลไม่รุนแรง หรือ มีค่าใช้จ่ายที่ไม่สูงมาก หากตัดสินใจไปแล้วผิดพลาด ก็ไม่ต้องเสียใจ ให้เริ่มต้นใหม่ ให้วางแผนเอาไว้ 2 แผนเป็นอย่างน้อยเสมอ

แวะมาทักทายกันได้