BusinessArchitectNote#7: Data Quality, key success of SOA

สวัสดีปีใหม่ครับทุกท่าน ^^
ก็กลับมาคุยๆกันเรื่อง Business มองมุม IT กันอีกครั้งในปีใหม่นี้นะครับ
วันนี้ ผมอยากคุยเรื่อง SOA อีกแล้ว!!
-
เจ้า SOA นี่มันแปลกนะครับ ยังไม่มีใครเช็คบิลมันได้เลย
บางคนทำไปแล้ว อยากโล๊ะทิ้ง
บางคนทำไป แก้ไป
ทำไมไม่มีใครพิชิตมันได้อย่างหน้าชื่นตาบานซักที
-

สมัยก่อน ผมเป็น IT ผมก็มองแค่มุมเทคโนโลยีว่า
ทำไงให้เทคโนโลยีพร้อมสำหรับ SOA จะใช้ Web Service, REST บลาๆ อะไรก็ว่าไป
แต่พวกนั้น มันไม่ใช่ประเด็นครับ
-
หลังจากย้ายมาอยู่มุม Business แล้ว จึงเข้าใจมากขึ้น
ตอนนี้ผมทำงานเป็น Project Manager ควบ Business Analyst ให้ธนาคารหนึ่ง
ซึ่ง IT ธนาคารนี้ ก็ “บ้า” (ไม่ได้หยาบนะครับ แต่เค้าอยากได้มากๆจนขั้นคลั่ง)
คลั่ง SOA มากๆ และอยากทำให้ทุกอย่างเป็น Service
-
ตั้งแต่ผมเรียนปริญญาตรี เมื่อ 5ปีที่แล้วแล้ว
มีคำคมของอาจารย์ผมที่มหาลัยผู้หนึ่ง ตอนผมทำ Senior Project เรื่อง SOA ว่า
“มันยากตรงที่ จะ define อะไรให้เป็น Service”
คำอาจารย์วันนั้น ถึงวันนี้ ผมยังจำได้
แต่ก็ยังทำให้มันเป็นจริงไม่ได้…
เสียดาย IT หลายๆคนไม่เข้าใจ ไปบ้าอยู่แต่เทคโนโลยี SOA
-
แต่ที่น่าตกใจมากกว่า เกิดจากบทสนทนาที่ขุนพลสะท้านภพบอกผม
“แชมป์ SOA มันยังไม่เริ่มหรอก ยังมี space ให้เราสำรวจอีกเยอะ”
คำพูดนี้ เกิดขึ้นเมื่อต้นปีนี้เองครับ (ไม่กี่วันที่ผ่านมา)
-
เราคุยกันเรื่อง Intelligence Service ซึ่งมันควรเป็นรากฐานของ SOA
แต่ตอนนี้เรายังไม่เห็นแม้นแต่เงาของมัน
ดังนั้น เราจึงพูดกันว่า จริงๆแล้ว SOA นั้นยังไม่เริ่ม!!!
-
(
เรื่อง Intelligence Service ไว้ติดตามต่อใน Software Architect Note นะครับ
มันเป็น Personal Cloud ของยุค Post-PC ที่จะมาใน 3-5ปีนี้
)
-
วันนี้ก็เลยจะมาพูดว่า “จะเริ่ม SOA ยังไง”
ตัดไอ้ตัว Intelligence Service ทิ้งนะครับ เอา SOA แบบบ้านๆก่อน
-
เริ่มโดย…
-
+ อะไรควรจะเป็น Service บ้าง?
คำถามประจำ ที่อาจารย์มหาลัยผู้นั้นถามผม
เพราะอะไร…
เพราะว่า ถ้าเป็น Service แล้วมันก็คือข้อต่อ
ซึ่งข้อต่อนี้เปลี่ยนแปลงได้ยาก
เพราะทุก Application ใน Enterprise นั้น
จะมีชีวิตและต้องพึ่งพาข้อต่อนี้
ดังนั้นข้อต่อนี้ อย่างหยาบก็คือมี Data ที่ Provide ให้เพียงพอ
แต่อย่างละเอียดคือ ต้องเป็น Data ที่เกิดจาก Object หนึ่งใน Enterprise Domain นั้นๆ
เรื่อง Data ใน Enterprise Domain นั้น
ผมจะพยายาม update ใน Software Architect Note ต่อไปครับ
-
+ แล้วจะจัดการ Data Quality ได้อย่างไร?
เพราะเมื่อเรา define service ที่เป็นข้อต่อได้แล้ว
ในแต่ละข้อต่อเวลารับส่ง Data กัน ก็ต้อง validate data ที่รับส่งระหว่างกัน
เพื่อให้มั่นใจว่า Data ที่ส่งกันนั้นจะได้ไม่เป็นขยะ
ดังนั้น Data พวกนั้น ต้องมาจาก Data Dict เดียวกัน
พูดง่ายๆว่า Based on data model ใน Data Warehouse เดียวกัน
-
มี Case Study ครับเรื่อง Data Quality นี้
พอดี ผมดันไปได้ Project อุจจาระ ที่ชาวบ้านทำทิ้งไว้
ซึ่งถ้าไม่ยากจริง หน้าที่ตามล้างตามเช็ดก็คงไม่ต้องพึ่งผมหรอก
แต่พอมาตามล้างตามเช็ดแล้ว พบปัญหาเรื่อง Service ว่า
คนเดิมที่เค้าทำไว้ เค้ามีวิธีคิดที่ดีครับ
วิธีคิดคือ ส่ง รหัสไปรษณีย์ และตำบล อำเภอ จังหวัด ระหว่างกัน
โดยเค้า map รหัสไปรษณีย์ กับ รหัสตำบล อำเภอ จังหวัด
ซึ่ง รหัสของ อำเภอ ตำบล จังหวัด แต่ละอันจะมี 2 digit
แต่…
มีรหัสตำบลบางอันมี 1 digit
ทำให้เกิดปัญหาครับ
สุดท้าย ผมคงเตรียมปรับ service ฝั่ง consumer ให้รองรับ 1 digit
แต่ผมก็พูดกับ IT ใน Project ว่า
ถ้าปล่อยแบบนี้ต่อไป
ระบบอื่นๆ ที่จะ interface กับ ระบบนี้
จะต้องรองรับตำบล 1 และ 2 digit
ซึ่งแน่นอนครับ มีปัญหาในอนาคตแน่
Logic การเขียนโปรแกรม มันไม่ควรจะยืดหยุ่นตรงนี้
มันควรจะ fix ให้ fit พอดี คือ 2 digit เท่านั้น
พอให้ data ได้ quality
แต่ถ้า เป็น 1digit หรือ 2 digit ก็ได้
จะ handle ยังไง เวลา data ส่งมาแล้ว lose ใน digit สุดท้าย
อันนี้คือ case study ของที่นี่ครับ
ว่าถ้าเริ่มต้น service ไม่ดีแล้ว จะมีปัญหาระยะยาวเรื่อง data quality
เช่น 1 กับ 2 digit แบบไหนก็ได้
ระยะยาวมีปัญหา แน่ๆ
-
นอกจากคุณจะ define Standard Service แล้ว
คุณยังต้อง define Standard Data Dict และ
methodology หรือ rules ใน Data Dict นั้นๆ
ซึ่งถ้าทำแบบนี้ได้ คุณก็จะได้ “SOA แบบบ้านๆ” แล้ว
-
แต่ SOA ที่สวยงามจริง จะเกิดจาก
การ define Object ใน Enterprise Domain
และการ define behavior ของ Object นั้น
ซึ่งถ้าเราได้ Object แล้ว เราจะรู้ว่า อะไรควรเป็น Service ด้วย
เช่นถ้าคุณเป็นแบงค์ คุณต้องมี Object Domain ของลูกค้า
ซึ่งลูกค้า มี domain ในการ เปิดเงินกู็ เปิดเงินฝาก บลาๆ
แล้วค่อย sub จาก behavior นั้นเป็น function ย่อย
ซึ่ง data ที่ใช้ใน behavior นั้น มาจาก
data dict ใน data model ของ data warehouse เดียวกัน
อย่างงี้ก็จะแก้ปัญหาได้ทั้งหมดครับ
แต่มันก็ยากกับการ design
-
แต่การยากในการ design ยังไม่ยากเท่า implement
เพราะเรามี legacy มากมายนักที่ต้อง phasing ออกไป
ซึ่งถ้าทำเสร็จจริงๆ อย่างต่ำก็ 10ปีครับ กว่าจะ obsolete legacy ได้หมด
แล้ว…
มันจะคุ้มเหรอ กับ Business ที่เปลี่ยนเร็ว
-
ขอบคุณครับ
-