เกริ่นนำ
SOA หรือ Service-Oriented Architecture เป็น ‘แนวคิด’ ทางสถาปัตยกรรมซอฟต์แวร์เชิงบริการ โดยมีพื้นฐานอยู่บนสถาปัตยกรรมซอฟต์แวร์ (จากนี้จะขอเรียกสั้น ๆ ว่า ‘architecture’) แบบ Enterprise Architecture ที่มีการประมวลผลลักษณะ Distributed Computing
SOA ก็คือการสร้างเลเยอร์ (architectural layer) มาครอบระบบฯ และทรัพยากรไอทีขององค์กรที่มีอยู่ และที่จะเกิดขึ้นในอนาคต… ทั้งหมดหรือเกือบทั้งหมด โดยเลเยอร์นี้เรียกว่าชั้นบริการ (service layer) ด้วยเหตุผลเพื่อให้เกิดการเชื่อมโยงติดต่อ (integrate) กับระบบฯ และทรัพยากรไอทีต่าง ๆ ที่ชั้นบริการนี้ ลดความซับซ้อนยุ่งเหยิงที่มีมาในอดีต การจัดการ transaction, security, การแปลง (adapt) ของการ call ระหว่างระบบที่ต่างแพลตฟอร์มกัน, การทำ data exchange, การจัดการเครือข่าย ฯลฯ เหล่านี้จะได้รับ ‘การปรับปรุง’
แต่หากมองอีกด้านหนึ่งของประเด็นข้างต้น นี่หมายถึงอะไร? มีนัยสำคัญใดซ่อนอยู่? ลองมองข้ามประเด็นด้านเทคโนโลยีและคุณประโยชน์ของ SOA ออกไปก่อน… นี่อาจเป็นช่องทางที่ก่อให้เกิดการผูกขาดทางการค้าใช่หรือไม่? หากโซลูชั่นของผู้ค้ารายใดได้ถูกนำมาใช้ในองค์กรนั้น และมีการใช้กลยุทธ์ ‘Vendor Lock-In’ ขึ้นอย่างแยบยล หรือจะเปิดเผยโฉ่งฉ่างก็ตาม โดยมีการออกแบบอินเตอร์เฟซที่สลับซับซ้อน ซ่อนเงื่อน มี ‘API เปิดเผย’ จำนวนหนึ่ง นี่อาจเข้าข่ายการเป็น ‘มาตรฐานปิด’ ก็ได้ แม้ผู้ค้าจะออกแถลงว่าตนใช้มาตรฐานเปิด เช่น พัฒนาต่อยอดมาจากโอเพ่นซอร์ส ใช้ Java ใช้เว็บเซอร์วิส เป็นต้น แต่ในฐานะ architect และคนในวงการ architect ต่างก็รู้ ๆ กันอยู่ ว่าเราสามารถทำให้ ‘ปิดในส่วนที่อยากปิด และเปิดในส่วนที่อยากเปิด’ ได้
องค์กรอาจถูกแนะนำ (บังคับทางอ้อม) ให้ปรับปรุง:
- ระบบ security เช่นอนาคตจะได้รองรับ single sign-on, digital certificate และติดตั้งระบบ intrusion detection system (IDS) จะได้ปัองกับแฮกเกอร์และการโจรกรรมข้อมูล (หว่านล้อมโดยพูดให้ฟังดูน่ากลัว) ฯลฯ
- การจัดการ transaction เช่น เมื่อดึงการจัดการ transaction ขึ้นมาที่เลเยอร์บนแล้ว เพื่อจะได้ติดตาม (monitor) การทำงานของ transaction ได้สะดวกต้องมี transaction monitor server ฯลฯ
- การจัดการ business process เช่น เพื่อให้เห็นภาพโดยง่าย ทำ model ได้ง่าย ติดตาม (monitor) และจัดการได้ง่ายต้องมีเครื่องมือด้าน business process modeling, business process management ฯลฯ
- การติดต่อกับ service ต่าง ๆ เช่น เพื่อให้พัฒนาส่วนแสดงผล (presentation) ได้ง่าย ยืดหยุ่น ปรับปรุงง่าย ไม่ต้องเขียนโค้ดมาก เพิ่มเติมต่อยอดได้ง่าย และรองรับ WEB 2.0 โดยต้องใช้ portal ฯลฯ
- การ map ระหว่าง service กับระบบฯ ต่าง ๆ ที่มีหลายแพตฟอร์มทำได้ง่ายขึ้นด้วยการใช้ adapter และต้องมี Enterprise Service Bus (ESB) และมี adapter ที่มีความสามารถและ ‘แปลง’ ให้ทำงานร่วมกับแพลตฟอร์มต่าง ๆ ได้มากมาย
- การจัดการ service registry เช่น เพื่อประสิทธิภาพและความปลอดภัย ต้องเก็บไว้ใน directory server โดยทำงานบนโปรโตคอล LDAP ฯลฯ
- การจัดการ messaging เช่น เพื่อให้มีความน่าเชื่อถือ (reliability) สูงสำหรับการ call โดยเฉพาะการ call แบบ asynchronous ต้องใช้ message queue server ฯลฯ
- การโฮสต์แอพพลิเคชั่น (พวกพ่อค้าคงลืมไปว่า SOA ไม่มีแนวคิดด้านแอพพลิเคชั่นแล้ว) เช่น การติดตั้ง (deploy) แอพพลิเคชั่น และการจัดการต่าง ๆ ต้องใช้ application server และหากต้องการให้รองรับ scalability ต้องมี web server แยกต่างหาก ฯลฯ
- การจัดการ fault tolerance เช่น งานมีความสำคัญ มี transaction สำคัญและไม่ต้องการให้เกิดความเสียหาย ผิดพลาด หรือหากเกิดขึ้นก็สามารถกู้คืนได้ และต้องการรองรับ load สูง ๆ ได้ ต้องทำ load balance, clustering, hot swap, cold swap, active redundancy, passive redundancy, shadow processing, state resychronization, backup and recovery (พูดหว่านล้อมใช้ศัพท์ให้ดูยาก ๆ ไว้) ดังนั้นต้องมีเครื่องเซิร์ฟเวอร์เพิ่มเติม และมีอุปกรณ์ด้าน cluster และ mass storage รวมถึงต้องอัพเกรดระบบเน็ตเวิร์กและอุปกรณ์เน็ตเวิร์ก ฯลฯ
- ฯลฯ
แล้วใครอยู่เบื้องหลังหรือเป็นผู้ผลักดัน SOA ให้เกิดเป็นกระแสที่รุนแรงอยู่ในปัจจุบันนี้? องค์กรที่มีการบริโภคไอทีจำเป็นต้องใช้ SOA จริงหรือไม่? การทำ Enterprise Application Integration (EAI) ยังมีวิธีอื่นอีกหรือไม่? เมื่อโลกเข้าสู่ยุคบริการแล้วระบบไอทีจำเป็นต้องร่วมวงด้วยหรือไม่?
ซอฟต์แวร์มีวันเสื่อมหรือไม่? คำตอบคือ ไม่!… ถ้าไม่มีใครไปทำหรือพยายามทำให้มันเสื่อม! เพราะซอฟต์แวร์มันห่อหุ้ม (encapsulate) ลอจิกต่าง ๆ เอาไว้ ถ้าเราออกแบบและพัฒนาโดยแบ่งแยกลอจิก (partitioning logic) ให้ดี โดยออกแบบและพัฒนาให้ลอจิก เทคโนโลยี และฮาร์ดแวร์แยกขาดจากกันให้มากที่สุด ซอฟต์แวร์ก็จะไม่มีวันเสื่อม!
สำหรับรายละเอียดความหมายของ SOA คืออะไร บทความนี้คงไม่จำเป็นต้องกล่าวถึงอีก เพราะมี ‘สื่อ’ มากมายให้สืบค้นเพื่อศึกษาได้อยู่แล้ว แต่ขอแนะนำว่าการจะสืบค้นเพื่อศึกษาจากสื่อต่าง ๆ ต้องกระทำอย่างมีสติ มิฉะนั้นอาจพลาดติดกับดักนายพรานได้
โลกแห่งการประมวลผลทางคอมพิวเตอร์เราได้ผ่านช่วงยุค (generation) ต่าง ๆ มาแล้วมากมาย แต่มิได้หมายความว่า ‘สังคมแห่งการพัฒนาไอที’ เราโตจนมีวุฒิภาวะที่ดีแล้ว เพราะอุตสาหกรรมหรือธุรกิจซอฟต์แวร์เพิ่งอุบัติขึ้นมาบนโลกนี้ไม่กี่สิบปีเท่านั้น (บิลล์ เกตส์ ตอนนี้ยังมีชีวิตอยู่เลย และคงอยู่ไปอีกหลายปี) เราผ่านยุคเมนเฟรม ไคลเอ็นต์-เซิร์ฟเวอร์ อ็อบเจ็คต์ช่วงต้น เว็บ ฯลฯ และตอนนี้พวกกูรู หรือพวก ‘กูรู้’ ต่างออกมาบอกว่า “เรากำลังจะเข้าสู่ยุค service” และพวก ‘กูรู้’ เหล่านี้ก็คิดค้นดัดแปลงเล่นแร่แปรธาตุกันสนุกมือได้นวัตกรรมใหม่ออกมาเรียกว่า ‘Service-Oriented Architecture’ บริษัทวิจัยด้านไอทีมากมายต่างก็ออกมาประโคมว่ามันมาแน่ เราจะเข้าสู่ยุคทุกข์เข็ญ เอ้ยไม่ใช่! เข้าสู่ยุค service กันจริง ๆ แต่กระแสเศรษฐกิจและการค้าโลก ที่จะเน้นเชิงบริการมากยิ่งขึ้น ดังนั้นแอพพลิเคชั่นซอฟต์แวร์ต่าง ๆ ก็เช่นกัน ก็จะเข้าสู่ยุคบริการเช่นกัน
“ใช่” ผมก็เห็นด้วยว่ายุคแห่ง ’service’ มาแน่ ๆ และตอนนี้ก็เข้ามาจอดเทียบหัวหาดแล้วด้วยซ้ำ เพียงแต่ว่าเราต้องรีบหักหัวเรือเข้าร่วมด้วยทันทีหรือไม่?
- การใช้ชีวิตตามยุคสมัย นั้นต่างจากการใช้ชีวิตร่วมสมัย -
เหล่ากูรู้และผู้ผลักดัน
พวกกูรู้เหล่านั้นเป็นใครกันบ้าง แน่นอนส่วนหนึ่งคือนักวิชาการ นักวิจัย ผู้เชี่ยวชาญที่อยู่ในอุตสาหกรรมซอฟต์แวร์ และรวมถึง ‘ผู้ค้า’ ที่ไม่ได้เป็นเพียงพ่อค้าอย่างเดียว แต่ผู้ค้าเหล่านี้ส่วนใหญ่เป็นผู้พัฒนาเทคโนโลยีและเครื่องมือด้วย และบางรายก็ ‘ค้า’ ระบบฮาร์ดแวร์และเน็ตเวิร์กด้วย กูรู้ที่อยู่ในคราบพ่อค้ารายใหญ่เช่นใครบ้าง? โลกนี้มีไม่กี่เจ้า ไม่บอกก็รู้ว่าใครบ้าง แล้วกูรู้ที่อยู่ในคราบนักวิชาการล่ะ ก็เช่น พวกผู้บริหารที่มีวิญญาณนักวิชาการที่ทำงานอยู่บนหอคอยงาช้าง ดูแลงานไอที บ้างสิงสู่อยู่ตามหน่วยงานภาครัฐ ภาคเอกชน ภาคการศึกษา มีหัวใจนักวิชาการแต่อาจไม่ได้เป็นนักปฏิบัติ (practitioner) ก็ได้ คือ ‘คิดเก่ง ไม่ใช่ อาชญากร… ทำไม่เป็น ไม่ใช่อาชญากรรม’ หลายรายมีพวกพ่อค้าหนุนหลังสนับสนุน หลายรายมีหุ้นอยู่ในบริษัทเอกชน แต่อย่าถามว่าใคร เพราะชี้ชัดยาก ก็เพราะเขาใช้ ‘นอมินี’ กัน
ในขณะที่ SOA เป็นแนวคิดที่เพิ่งอุบัติขึ้นมาไม่นาน ยังไม่มีมาตรฐานที่ชัดเจน กลับมีเครื่องไม้เครื่องมือวางขายเกลื่อนกลาดตามตลาดเสียแล้ว พ่อค้าแม่ค้าออกมาเร่ขายสินค้า (โซลูชั่น) กันเป็นแถว เราประชาชนตาำดำ ๆ เป็นนักพัฒนาระดับรากหญ้าที่ทำมาหากินอยู่บริเวณโคนต้นหญ้า เหยียบดินเหยียบโคลนอยู่ทุกวัน และพวกกูรู้ที่อยู่บนหอคอยงาช้างอาจไม่เคยมองเห็นพวกเราจริง ๆ สักครั้งเลยก็ได้ แล้วเราจะทำอย่างไรกันดี? ใช้ชีวิตอย่างจำนน จำยอมให้พ่อค้าแม่ค้าเอาหมากมาล้อม ราวกับว่าพวกเขาคือผู้เล่นเกมหมากล้อมกันเอง ส่วนพวกเราเป็นเพียงหมาก หรือจะใช้ชีวิตแบบปิดหูข้างหนึ่ง ปิดตาข้างหนึ่ง อ้าปากคุยกันเอง แต่ปิดปากกับคนภายนอก แล้วฝืนยิ้มร่าบอกโลกว่าแค่นี้ฉันก็สุขใจ หรือจะแค่มานั่งวิพากษ์ SOA กันไปวัน ๆ แต่ไม่ทำอะไร เหมือนถ่มน้ำลายขึ้นฟ้ากระนั้นหรือ? แล้วสุดท้ายก็ต้องก้มหน้าทำ SOA ทั้งที่มีคำถามในใจมากมาย เช่น ทำไปเพื่ออะไร? ทำไมต้องทำ? ทำไมต้องใช้? มันจำเป็นจริงหรือ? คนทำต้องมีความรู้และทักษะแท้จริงอะไรบ้าง? สิ่งที่พวกกูรู้เหล่านั้นออกมาบอก มันมีแค่นั้นจริง ๆ หรือ? หรือว่าแท้จริงเขาเหล่านั้นก็ยังไม่รู้จริงเลยด้วยซ้ำ? ทำไมโครงการ SOA ถึงมีมูลค่าเป็นร้อย ๆ ล้าน? ใช้โอเพ่นซอร์สไม่ได้หรือ? ไม่มีหรือ? ก็ในเมื่อมันเป็นแนวคิด แล้วเราพัฒนาเครื่องมือหรือสร้างเอ็นจิ้นขึ้นมาใช้เองไม่ได้หรือ? เอ… หรือว่าพวกเราจะเป็นอย่างผลสำรวจการศึกษาโดยภาครัฐ ที่บอกว่าประชาชนไทยอ่านหนังสือเฉลี่ยปีละ 7 บรรทัด? นี่เรากำลังถูกพวกกูรู้ดูถูกอยู่ใช่ไหม? ประมาณว่ามึงไม่ต้องคิด มึงไม่ต้องศึกษา กูหาของไปให้ใช้ หาคนไปทำให้ มึงอยู่เฉย ๆ? พอกูรับเงินเสร็จ ขายฮาร์ดแวร์เสร็จ ขายซอฟต์แวร์เสร็จ กูก็จะ ‘สับ’ งานให้บริษัทอื่นหรือพาร์ทเนอร์เอาไปทำต่อ แล้วกูก็จะชิ่ง ถ้างานล้มเหลวมึงก็ไปโทษพาร์ทเนอร์หรือคนที่เขาไปทำให้มึงแล้วกัน? เพราะกำไรของกูมาจาก ‘ของ’ ของกู ไม่ใช่ ‘ของ’ ของมึง ฯลฯ
ใครมีส่วนได้-เสียในโครงการ SOA
เหล่านักพัฒนาตาดำ ๆ ใช้ชีวิตอยู่แถวโคนต้นหญ้า ก้มหน้าก้มตารับวิบากกรรม ส่วนมากก็รู้อยู่แก่ใจว่ามิใช่ใครถ้าไม่ใช่ผู้บริหารของเรานี่เอง
การขาดวิสัยทัศน์ด้านไอทีและสถาปัตยกรรมซอฟต์แวร์ (technological and architectural visions) อย่างรุนแรงในเหล่าผู้บริหารไอที และอาจลามไปถึงผู้บริหารองค์กรด้วย คือหายนะสำคัญ ยิ่งหากเป็นพวกที่มีหัวคิดเชิงทุนนิยมและบริโภคนิยมด้วยแล้วยิ่งอันตราย
การพึ่งพาและเชื่อใจบุคคลภายนอกมากกว่าคนภายในขององค์กร, การจัดซื้อ/จัดจ้างแบบมีเงื่อนงำ, การไม่ปรึกษาหรือประเมินความพร้อมขององค์กรหรือโดยเฉพาะของทีมไอทีของตนเองก่อน, การชื่นชมชื่นชอบการจับจ่ายซื้อหาสิ่งของ มากกว่านำเพียงเศษสตางค์มาสร้างฐานความรู้ให้องค์กรและให้ทีมงานตน, การพยายามวิ่งให้ทันเทคโนโลยีแต่ตนเองกลับไม่เข้าใจแท้จริงสักอย่างว่าวิ่งไปเพื่ออะ
ไร แล้วไอ้เทคโนโลยีที่วิ่งตามมันคืออะไร,
การติดยึดในศักดิ์ศรีและการชิงดีชิงเด่นทางการแข่งขันระหว่างองค์กรหรือธุรกิจ, การติดยึดกับชื่อเสียงของบริษัทพ่อค้าแม่ค้าระดับโลก แต่ไม่ดูด้านลึกว่าบริษัทเหล่านั้นในประเทศเราเขาเป็นอย่างไร บางรายมีธุรกิจหลักคือฮาร์ดแวร์ ซอฟต์แวร์และเทคโนโลยีเป็นเพียงของแถมและเครื่องมือสร้างภาพลักษณ์ บางรายก็ใหญ่โต (เกินพอดี) เล่นเกมการเมืองเข้มข้น บางรายเพิ่งถูกซื้อ เพราะเหตุผล ‘เธอดีเกินไป’ ของฉันสู้ของเธอไม่ได้ งั้นฉันขอซื้อเธอละกัน จึงไม่รู้ว่าถูกซื้อไปทิ้งหรือเอาไปเลี้ยงแต่ไม่ให้โต บางรายก็เคี่ยวลากดิน แต่ใหญ่โตคับโลก บางรายก็เก่งเฉพาะด้าน แต่เผอิญไม่เก่ง SOA ฯลฯ
(ในงานบรรยายล่าสุด ผมบอกผู้ฟังว่า เป็นผมผมจะเลือกเจ้าที่เคี่ยวลากดิน แต่ใหญ่คับโลก เพราะมีความพร้อมด้านฝึกอบรม และเชี่ยวชาญทั้งเทคโนโลยีและงานบริหาร มากที่สุด แต่มีข้อแม้ว่า ผมต้องสร้างภูมิคุ้มกันป้องกันความเคี่ยวของเขาให้ดีเสียก่อน! ส่วนเจ้าที่เหลือ ใช้เทคโนโลยีที่ผมมีความชำนาญมาร่วมสิบปี จึงเห็นด้านมืดที่ซ่อนอยู่หลายอย่าง ซึ่งเมื่อก่อนมันก็ไม่ได้มืดทึมอย่างนี้ แต่เดี๋ยวนี้มันมืดทะมึนเพราะพวกกูรู้ในคราบพ่อค้า)
ประเด็นเหล่านี้เป็นเพียงเศษเสี้ยวของวิสัยทัศน์ที่สุ่มเสี่ยงต่อหายนะด้านไอทีขององ
ค์กร เพราะหากความผิดพลาดหรือการมีวิสัยทัศน์ที่แย่ ๆ ในระดับบริหารแล้ว การถ่ายทอดและแปลงวิสัยทัศน์สู่การปฏิบัติ (transform vision to operations) ตามชั้นลำดับหน้าที่การงาน จนถึงระดับคนทำงานจริงจะเป็นอย่างไร ในเมื่อความผิดพลาดและเป็นตัวการอาจก่อให้เกิดความล้มเหลวกลับอยู่ที่ระดับสูงสุด (หรือเกือบสุด) กลายเป็นผลกระทบแบบ ‘Ripple Effect’ แล้วตัวเองก็มักหาทางหนีทีไล่ด้วยการใช้ (เล่น) การเมืองภายในองค์กร จนเอาตัวรอดได้แทบทุกครั้ง ปัญหาการเมืองภายในองค์กร และทุจริต คอร์รัปชั่นมันถึงไม่มีวันหมดไปง่าย ๆ จากเมืองไทย ในเมื่อผู้บริหารยังคงยึดถือเป็นส่วนหนึ่งใน ‘job description’
ไม่กี่วันมานี้มีผลสำรวจเด็กวัยรุ่นว่าโตขึ้นอยากทำอะไรมากที่สุด… “อยากคอร์รัปชั่นแบบนักการเมืองครับ/ค่ะ” !!!
และนอกจากนี้การเข้ามาล็อบบี้ของพวกกูรู้ที่เป็นพ่อค้าแม่ค้า โดยเข้ามา ‘ล็อกสเป๊กฯ’ บ้าง เข้ามาโฆษณาชวนเชื่อบ้าง เข้ามาให้ ‘สินน้ำใจ’ บ้าง หากเป็นธรรมเนียมปฏิบัติเพียงเล็กน้อย แค่พอเป็น ‘ค่าผ่านทาง’ หรือ ‘น้ำใจ’ เล็กน้อย ก็พอไหว เพราะถึงอย่างไรแล้วประเด็นทุจริตคอร์รัปชั่นก็คงหมดจากโลกนี้ไปได้ยาก แต่ทำไมประเทศที่เจริญแล้วเขาไม่ค่อยมี (ไม่ใช่ไม่มี แต่มีแบบไม่โฉ่งฉ่าง) ก็เพราะเขายังคำนึงถึงผลประโยชน์ต่อองค์กรที่เขารับใช้เป็นสำคัญอยู่ ไม่ใช่คำนึงถึงผลประโยชน์ต่อตนเองเป็นสำคัญหลัก
และสุดท้ายก็เป็นพวกกูรู้ในคราบนักวิชาการตามสถาบันเสริมสร้างปัญญา และตามหน่วยงานภาครัฐ หลายคนมีวิสัยทัศน์ และมุมมองที่ดี แต่ดีเกินไป คือเป็นพวกถวิลหาความสมบูรณ์แบบ (perfectionism) และมักเผยแผ่แต่ปัญญาที่เป็นอุดมคติ (idealism) เกินไป ไม่มองถึงความจริง หรืออาจมองไม่เห็นว่าโลกแห่งความเป็นจริงคืออะไร เพราะใช้ชีวิตอยู่ในอุดมคติมากเกินไป จนแยกแยะไม่ออกว่าอะไรจริง อะไรไม่จริง คิดสร้างหรือเผยแพร่แต่โครงการขี่ช้างจับตั๊กแตน โครงการตำน้ำพริกละลายแม่น้ำ โครงการขายผ้าเอาหน้ารอด โครงการลูบหน้าปะจมูก โครงการขายฝัน (เพ้อเจ้อ) และโครงการสร้างภาพ
คราวนี้ท้ายสุด ผู้มีส่วนได้-เสียที่มักเสียมากกว่าได้ เพราะเป็นกลุ่มบุคคลหลักที่จำเป็นต่อการทำงาน หรือเรียกได้ว่าเป็นกำลังหลักในโครงการ SOA เลยทีเดียว นั่นคือ นักวิเคราะห์ธุรกิจ (business analyst) และ สถาปนิกซอฟต์แวร์ (software architect) เพราะสองส่วนนี้คือกำลังสำคัญ ดังนั้นองค์กรต้องถามตนเองว่าในองค์กรมีใครไหมที่เป็น business analyst และ architect เพราะสองกลุ่มนี้ต้องเป็นคนขององค์กร ไม่ใช่คนที่ไปจ้างมา หรือเป็นคนที่พวกกูรู้จัดหามาให้ เพราะไม่มีใครที่จะวิเคราะห์และเข้าใจระบบงานหรือธุรกิจขององค์กรได้ดีไปกว่าคนภายใน
องค์กรเอง และไม่มีใครที่จะสร้าง architecture ที่จะใช้ในองค์กรได้ดีไปกว่าคนภายในองค์กรเอง ดังนั้น business analyst และ architect จึงต้องเป็นคนภายในองค์กร หากองค์กรยังไม่มี หรือไม่มีความพร้อมก็ต้องสร้างเขาเหล่านี้ขึ้นมาให้มีความพร้อม… ก่อนที่จะเริ่มทำ SOA!
ทำ SOA องค์กรต้องมีความพร้อมอะไรบ้าง
- ผู้บริหารต้องมีวิสัยทัศน์ด้านเทคโนโลยีและสถาปัตยกรรมซอฟต์แวร์ (technological and architectural visions) ที่ดี
- ตรวจสอบและติดตามกระบวนการจัดซื้อ/จัดจ้างอย่างใกล้ชิด เพื่อให้เกิดการทุจริต คอร์รัปชั่นน้อยที่สุดหรือไม่ให้มีเกิดขึ้นถ้าเป็นไปได้
- มีทีมที่ติดตามพฤติกรรมของผู้บริหารที่อาจมีการสุ่มเสี่ยงต่อการทุจริต คอร์รัปชั่น และต้องมีการดำเนินการโดยปราศจากเกมการเมืองภายในองค์กร หรือการเอื้อประโยชน์ซึ่งกันและกัน
- ฝ่ายไอทีขององค์กรต้องมีทีมพัฒนาซอฟต์แวร์ (software development team) ที่มีความรู้ ทักษะ และมีมาตรฐาน เพื่อจะได้รู้เท่าทันพวกกูรู้ต่าง ๆ
- มีการจัดการองค์ความรู้ (knowledge management) ที่ดี และสร้างฐานความรู้ (knowledge base) ที่ดีพร้อม ไม่ใช่ให้ความรู้อยู่กับคน แต่ความรู้ต้องอยู่กับองค์กร
- การทำงานระหว่างหน่วยงานภายใต้องค์กร เช่น แผนก ฝ่าย ต้องมีประสิทธิภาพ เพราะ SOA จำเป็นต้องทำร่วมกันโดยหลายฝ่าย มิใช่เพียงฝ่ายไอทีฝ่ายเดียว
- วัฒนธรรมองค์กรและวัฒนธรรมการทำงาน ที่ปราศจากการเมืองภายใน หรือมีให้น้อยที่สุด เพราะ SOA ไม่ใช่เป็นกิจกรรมของฝ่ายไอทีเพียงฝ่ายเดียว แต่เป็นกิจกรรมที่ต้องทำร่วมกันของหลายฝ่ายในองค์กร วัฒนธรรมองค์กรถือเป็นตัวชี้วัด (KPI) สำคัญต่อความสำเร็จหรือล้มเหลวของโครงการ SOA เลยทีเดียว หากวัฒนธรรมองค์กรอ่อนแอ ผุกร่อน หรือไม่พร้อม ก็ยังไม่ควรเริ่มกับ SOA
- ต้องมี (ทำ) Business Modeling หรือแบบจำลองธุรกิจหรือระบบงานขององค์กรที่ละเอียด ทำโดยคนขององค์กรเอง ไม่ใช่คนภายนอก หรือหากมีคนภายนอกด้วย คนภายนอกสามารถเป็นเพียงที่ปรึกษาได้เท่านั้น และไม่ใช่ทำแต่ Business Process เพราะเป็นเพียงศัพท์การตลาด และเป็นเพียงส่วนหนึ่งของการทำ Business Modeling เท่านั้น การวิเคราะห์และทำความเข้าใจกับ Business Process จึงถือว่าไม่เพียงพอ และมีรายละเอียดถือเป็นสัดส่วนน้อย เมื่อเทียบกับการทำ Business Modeling ที่มีความละเอียดและชัดเจนกว่า
- ต้องมี (ทำ) architecture ที่ดีและละเอียด ทำโดยคนขององค์กรเอง ไม่ใช่คนภายนอก หรือหากมีคนภายนอกด้วย คนภายนอกสามารถเป็นเพียงที่ปรึกษาได้เท่านั้น และต้องมีทีม architect ที่ดี มีความรู้และทักษะที่เพียบพร้อม ถ้าไม่มีต้องสร้างขึ้นมา อย่าหวังรับสมัครหรือหาจากคนภายนอก เพราะไม่มีทางหาได้ เพราะองค์กรต้องมี architect ที่มีความจงรักภักดี (loyalty) ต่อองค์กรที่ดี ดังนั้นจึงควรคัดเลือกและสร้างจากคนที่มีอยู่มากกว่าหาจากคนนอก
- มี Domain Expert หลาย ๆ ด้าน เช่น ด้านธุรกิจหรือระบบงานขององค์กร ด้านเทคนิค เป็นต้น
- กระบวนการพัฒนาซอฟต์แวร์ (software development process) ต้องมีวุฒิภาวะที่ดี แต่ไม่จำเป็นต้องมีใบประกาศนียบัตรรองรับ เช่น CMMi เพราะใบกระดาษพวกนี้ไม่ได้ยืนยันแท้จริงเสมอไป เพราะจำเป็นต้องสร้างวุฒิภาวะให้กับคนและองค์กรมากกว่า ไม่ใช่ไปมุ่งโฟกัสที่กระบวนการพัฒนาซอฟต์แวร์
- มีผู้นำหรือผู้ผลักดัน (motivator / champion) โดยมีความสามารถในการผลักดัน ชี้นำ กระตุ้น สนับสนุน ให้กำลังใจ มีทักษะด้านจิตวิทยามวลชนที่ดี เพื่อให้โครงการรุดหน้า สมาชิกทุกคนในทีมมีกำลังใจ ทำงานด้วยความสุข สนุก และมุ่งมั่น แต่ผู้นำไม่ใช่ทำตัวเป็นเพียงผู้ประสานงานเท่านั้น
- สร้างทีมเพื่อติดตามการทำงานของพวกกูรู้หรือกลุ่มบุคคลหรือบริษัทภายนอกที่จ้างให้เข
้ามาช่วยงาน เช่น ติดตั้งระบบซอฟต์แวร์ ฮาร์ดแวร์ หรือเข้ามาพัฒนางานบางส่วน หรือเข้ามาอบรมการใช้งานซอฟต์แวร์และฮาร์ดแวร์ ทีมนี้ต้องทำ ‘cross check’ โดยมีลักษณะเป็นทีมเงา (shadow team / shadow process) โดยห้ามมิให้พวกกูรู้หรือกลุ่มบุคคลหรือบริษัทภายนอกที่จ้างให้เข้ามาช่วยงานทราบได้ ว่าในองค์กรมีการจัดตั้งทีมนี้ขึ้นมาเพื่อตรวจสอบและติดตาม (monitor) การทำงานอยู่อย่างลับ ๆ เพื่อดูว่าพวกนั้นเขามีความรู้ ทักษะ และทำงาน ‘เป็น’ จริงหรือไม่ มีการหลบ ๆ เลี่ยง ๆ ลัด ๆ อ้อม ๆ มั่ว ๆ ตรงไหนบ้าง นอกจากนี้ทีมนี้ยังสามารถเป็น ‘architecture evaluator’ หรือผู้ประเมินผลการออกแบบและสร้าง architecture ได้อีกด้วย ซึ่งมีลักษณะเป็น quality assurance หรือ quality control นั่นเอง - ต้องมีทีมวิจัยและพัฒนา (R&D) ที่แข็ง เพื่อจะได้รู้เท่าทันเทคโนโลยี และสามารถวิจัยพัฒนาเทคโนโลยีต่อยอด เพื่อความเหมาะสมต่อองค์กรได้ โดยไม่ต้องพึ่งพาพวกกูรู้หรือกลุ่มบุคคลหรือบริษัทภายนอกมากเกินไป และโดยเฉพาะหากองค์กรมีการใช้โอเพ่นซอร์สด้วย ยิ่งจำเป็นต้องมีทีมวิจัยและพัฒนาที่แข็งแกร่ง
- มีทีมทดสอบ (testing) ที่แข็งแกร่งและมีความเชี่ยวชาญสูง เพราะ SOA เป็น architecture แบบ distributed computing ดังนั้น transaction ส่วนมากจึงเป็นแบบ distributed transaction จึงต้องออกแบบการทดสอบและทดสอบให้มีประสิทธิภาพ นอกจากนี้ยังมีประเด็นอื่นมากมายที่ต้องทดสอบเช่น security, performance, availability, usability, reliability, integrability, interoperability, scalability เป็นต้น
- งานในส่วนตรรกะธุรกิจหรือระบบงานที่สำคัญ (business rule) ต้องทำโดยคนภายในองค์กรเอง หรือหากจำเป็นต้องให้คนภายนอกทำ เช่น กรณีมีการ outsource ต้องห้ามเปิดเผย implementation หรือเนื้อในวิธีคิดและการทำงานจริงให้คนภายนอกเห็นเด็ดขาด แต่ให้เปิดเผย API แทน ดังนั้นหมายความว่า business rule ต้องออกแบบและสร้าง (เขียนโปรแกรม) โดยคนภายในองค์กรเอง และควรมีการกำหนดทีมเฉพาะขึ้นมาทำในส่วนนี้ โดยมีเอกสาร ‘ห้ามเปิดเผยความลับ’ (non disclosure agreement) ให้สมาชิกในทีมทุกคนเซ็นรับทราบ
- ทำการแกะระบบฯ (ซอฟต์แวร์และแอพพลิเคชั่น) เก่าที่มีอยู่ (architecture reconstruction) เพื่อสร้าง portfolio หรือประวัติศาสตร์ (history) ของระบบฯ ทุกตัวที่มีอยู่ ซึ่งบางระบบฯ อาจจำเป็นต้องมีการทำเอกสารขึ้นมาใหม่ หากของเดิมไม่มีคุณภาพพอ และเพื่อศึกษา architecture ของระบบฯ ที่มีอยู่ในองค์กร เพื่อประเมินว่าจะต้องมีการปรับแก้ (re-architecting) ระบบฯ ใดบ้าง เพื่อให้สามารถ integrate กันได้ตามแนวคิด SOA และเพื่อประเมินว่ามีส่วนใดที่สามารถ reuse ได้ และไม่สามารถ reuse ได้ เช่นจำเป็นต้องพัฒนาใหม่หรือโละทิ้ง ทั้งนี้ใน portfolio ก็คือ asset หรือทรัพย์สินนั่นเอง เพราะระบบฯ ที่มีอยู่ต้องมองว่าเป็นทรัพย์สิน และจากนี้ต่อไปหากมีการทำ architecture และ SOA อย่างหนักหน่วงจริงจัง ทุกสิ่งจึงควรแปลงเป็นทรัพย์สินได้ และดังนั้นจึงต้องสามารถจัดเก็บได้ โดยอาจจัดเก็บ portfolio ไว้ในระบบ configuration management หรือหากจะให้เกิดประโยชน์สูงสุด ควรเก็บไว้ใน data warehouse และควรมีการทำ mining และ knowledge base เพื่อสนับสนุนการตัดสินใจ การบริหารไอทีในองค์กร การบริหารโครงการ การ estimate ราคา (งบประมาณ), คน ฯ เป็นต้น
- ทำ Software Product Lines (SPL) ซึ่งประเด็น SPL นี้จำเป็นอย่างมาก องค์กรจำเป็นต้องทำ SPL เพราะสิ่งที่อยู่ใน SPL คือ core asset base หรือ core architecture นั่นเอง เพราะ SOA เป็น architecture ที่เน้นการ integrate ระบบฯ ต่าง ๆ ดังนั้น เมื่อ SOA เข้ามาครอบคลุมระบบฯ และทรัพยากรไอทีของทั้งองค์กร องค์กรจึงต้องมี core architecture ที่ดีและมีประสิทธิภาพรองรับระบบฯ ต่าง ๆ ที่มีอยู่ และ solution logic และ service ต่าง ๆ ที่จะเกิดขึ้นในอนาคต ดังนั้นการทำ SPL ที่ดีจึงต้องมองไปยังอนาคตข้างหน้า พิจารณาและทำร่วมกันโดยฝ่ายบริหาร ฝ่ายไอที และถ้าองค์มีฝ่ายการตลาดก็ต้องให้ฝ่ายการตลาดร่วมทำด้วย
ลองสำรวจดูว่าองค์กรคุณมีข้อไหนบ้าง และไม่มีข้อไหนบ้าง และที่สำคัญการทำ SOA จะขาดข้อใดข้อหนึ่งไปไม่ได้ ดังนั้นกิจกรรมแรกก่อนหรือช่วงเพิ่งเริ่มทำ SOA ที่ต้องทำคือ ‘ประเมินสถานะองค์กร’ (assess organizational status) เพื่อประเมินความพร้อมขององค์กร และใช้เป็นข้อมูลเพื่อการตัดสินใจ
ทำ SOA ต้องรู้อะไรบ้าง?
จะขอกล่าวถึงเพียงสั้น ๆ โดยไม่อธิบายรายละเอียดในแต่ละประเด็น เพราะเกรงจะเป็น่การสร้างความท้อแท้ใจให้แก่ผู้อ่านและผู้สนใจ และผู้ที่กำลังทำหรือกำลังจะทำ SOA อยู่ โดยจะขอกล่าวถึงความรู้และทักษะของ architect หรืออาจเรียกว่าเป็น Service-Oriented Architect เท่านั้น เพราะเป็นหัวใจหลักของโครงการ SOA
ความรู้และทักษะที่จำเป็นที่ architect ต้องมีเพื่อทำ SOA คือ
- มีความจงรักภักดี (loyalty) ต่อองค์กร และคำนึงถึงผลประโยชน์ขององค์กรเป็นที่ตั้ง
- เข้าใจความหมายที่แท้จริงของคำว่า ‘งานบริการ’ และ ‘หัวใจของงานบริการ’
- Understanding Social and Political Issues เช่น เล่นการเมืองเป็น อ่านเกมการเมืองออก
- Consulting เช่น เป็นที่ปรึกษาที่ดีแก่ทุกคนในองค์กร มีทักษะการเป็นนักวิเคราะห์ที่ดี และมีทักษะในการลดข้อขัดแย้งระหว่างการสนทนาหรือการทำงาน
- Communication เช่น สื่อสารกับทุกคนได้ วิ่งได้ทั่วผังองค์กร จะขึ้นข้างบน ลงข้างล่าง ไปซ้ายข้ามแผนก ไปขวาข้ามฝ่าย ฯ และมีจิตวิทยาและศิลปะการสื่อสารที่ดี และมีทักษะภาษาที่ดี ทั้งพูด ฟัง อ่าน เขียน โดยเฉพาะภาษาไทย
- Strategy เป็นนักกลยุทธ์และมีความคิดเชิงกลยุทธ์ที่ดี
- Lateral Thinking รู้จักคิดนอกกรอบ มองโลกในแง่ดี และแง่ร้ายเป็น เข้าใจทั้งสภาวะภายในและภายนอก
- Integrated Thinking คิด วิเคราะห์ ออกแบบ และปฏิบัติเชิงบูรณาการ
- Marketing เข้าใจหลักการประชาสัมพันธ์ การสื่อสารองค์กร มองเกมการตลาดออก และรู้จักใช้การตลาดเป็นเครื่องมือ
- Knowledge Transfer สามารถถ่ายทอดองค์ความรู้ให้ผู้อื่นได้ เช่น สมาชิกภายในทีม และต้องพัฒนาความรู้และทักษะของตัวเองอย่างต่อเนื่อง โดยสามารถกระตุ้นและบังคับตัวเองได้ โดยไม่ต้องรอให้ใครมาบังคับ
- มีภาวะผู้นำสูง
- Object-Orientation
- Object-Oriented Analysis and Design
- UML
- Aspect-Oriented Programming (AOP)
- Agile Philosophy เปรียบเทียบอีกอย่างนั่นคือ เข้าใจหลักปรัชญาเศรษฐกิจพอเพียง และดำเนินกิจกรรมทุกอย่างอยู่บนหลักแห่งความพอเพียง
- Business Modeling
- Software Engineering
- Software Development Process โดยเฉพาะต้องเป็น development life cycle แบบ Iterative and Incremental Development (IID) เท่านั้น
- Design Patterns and Architectural Patterns
- Software Architecture
- Enterprise Architecture
- Domain Modeling, Domain Specific Language and Domain Driven Architecture
- Event-Based Architecture
- Component-Based Architecture
- Enterprise Application Integration (EAI)
- Software Product Lines
- Distributed Computing
- Distributed Transaction Design and Management
- Security
- Architecture Reconstruction
- Architecture Evaluation
- Components Off-The-Shelf (COTS) Decision
- Software Testing ควรเป็นแบบ Test Driven Development
- มี Perspective Positioning ด้านเทคโนโลยีที่ดี
- Requirements Management โดยเฉพาะด้าน Business Goals และ Non-Functional Requirements
- Configuration and Change Management
- Principle Design for High Available and Interoperable Architecture
- Internet Protocol, Architecture and Web Services
- BPEL (Business Process Execution Language) and Enterprise Service Bus (ESB)
แล้วลองถามองค์กรดูว่ามีใครที่มีความรู้และทักษะเหล่านี้ไหม ไม่จำเป็นต้องมีทั้งหมดในตัวคนคนหนึ่ง เพราะ SOA ต้องมี ‘Domain Expert’ หลาย ๆ ด้านมาช่วยกันทำ แต่ที่แน่ ๆ สำหรับ architect ในโครงการ SOA ควรมีทักษะเหล่านี้!
บางคนที่เห็นแล้วอาจหัวเราะ เช่นพวกกูรู้หลายคนที่ผมเคยเล่าให้ฟัง “ว่ามันจะเป็นไปได้อย่างไร” “จะไปหามาจากไหน” “จะสร้างขึ้นมาอย่างไร” ฯลฯ ก็จะไม่ให้หัวเราะได้อย่างไร ซึ่งผมก็เข้าใจ เพราะคนเหล่านั้นชอบดูถูกลูกค้าและนักพัฒนาตาดำ ๆ เป็นปกติอยู่แล้วนี่ ก็เลยชอบหาอะไรมายัดเยียดให้เขาใช้ ให้เขาเรียน แล้วก็ดูถูกผ่านข้ออ้างว่า “เพราะคนไทยไม่รักการศึกษา” “สังคมมันแย่” “สร้างยาก” “จะได้ให้เขาได้ทำในส่วนสำคัญจริง ๆ” “เพื่อให้เขาไปต่อยอดได้” “ต้องลงทุนสูง” “เป็นปัญหาเรื่องคน มันแก้ยาก” ฯลฯ
แต่ผมขอยืนยันว่า… คนที่มีความรู้และทักษะเหล่านี้สามารถสร้างได้! ถ้าคิดจะสร้าง เพราะกิจกรรมที่สำคัญที่สุดของโครงการ SOA คือ สร้างความพร้อม! และ output ที่สำคัญที่สุดของการสร้างความพร้อมคือ Service Inventory Blueprint ซึ่งรวบรวม policy, standard, service design ฯลฯ มากมาย และเครื่องมือที่สำคัญที่สุดที่ใช้สร้างคือ คน และเครื่องมือที่สำคัญที่สุดที่คนต้องใช้คือ กระดาษและปากกา หรือจะใช้โปรแกรม word processing ก็ได้
องค์กรต้องสร้าง Service Inventory Blueprint ขึ้นมาก่อน เพราะเปรียบเสมือนพิมพ์เขียวของ ‘คลังบริการ’ ขององค์กร อธิบายโครงสร้าง การทำงานของ service ระเบียบการเข้าใช้ การจัดเก็บ สิทธิ รายละเอียดของ service ทุกตัว รวมถึง service level agreement ของ service ทุกตัว การจัดทีม แบ่งทีม การกำหนดและเลือกใช้เทคโนโลยี ฯลฯ นอกจากนี้ยังรวมถึงแผนการใช้เงิน (งบประมาณ) เหล่านี้ไม่จำเป็นต้องง้อเครื่องมือราคาแพงใด ๆ เลย!
เมื่อสร้าง Service Inventory Blueprint เสร็จแล้ว ถึงช่วงที่จะต้องอิมพลีเม้นต์ จึงค่อยมาดูเรื่องเครื่องไม้เครื่องมือ อุปกรณ์ซอฟต์แวร์ ฮาร์ดแวร์ การลงทุนการตั้งงบฯ การวางแผนงาน ถึงตอนนี้จะซื้อเครื่องมือราคาแพงใด ๆ หรือจะเลือกพัฒนาเอง หรือจะใช้โอเพ่นซอร์ส ก็ได้ เพราะเมื่อเหนื่อยกับการทำ Service Inventory Blueprint จนเสร็จและสมบูรณ์ได้เมื่อไร ถือว่าองค์กร… มีความพร้อมแล้ว!
ทิ้งท้าย
สุดท้าย… SOA จะมีประโยชน์และคุ้มค่าหรือไม่ องค์กรต้องมีความพร้อมและใจเย็น ๆ เพื่อสร้างภูมิคุ้มกันไม่ให้บกพร่องเสียก่อน และเพื่อให้ปลอดภัยจากโฆษณาขายฝันและการเข้ามากอบโกยจากพวกกูรู้ทั้งหลาย แล้วเมื่อองค์กรพร้อมก็สามารถเรียกตนเองได้ว่าได้เป็นพวก ‘กูรู้กว่า’ จะหยิบใช้พวกกูรู้นอกองค์กรได้อย่างเกิดผลยิ่ง ราวกับวาทยากร (service orchestrator!) แล้วท้ายสุดคนที่เดินเกมและกุมอำนาจแท้จริงก็คือ ‘ลูกค้า’!
แล้ว… architect จะหาอย่างไร? จากใครในองค์กร? ต้องเก่งแค่ไหน? จบอะไรมา? อายุเท่าไร? ประสบการณ์แค่ไหน? ฯลฯ
ขอตอบสั้น ๆ ว่า architect วัดกันที่ วิสัยทัศน์ ทัศนคติ และการพลิกแพลงกลยุทธ์!
- ความรู้และความสามารถสร้างและปรับกันได้ แต่วิสัยทัศน์และทัศนคติสร้างและปรับได้ยากกว่า -
และ
- คนเราหากอยากเป็นอะไร ตัวเขาเท่านั้นที่รู้ตัวเองดี ไม่ต้องรอให้ใครมาจับไปปั้นแต่ง
หากไม่ท้อถอย กัดไม่ปล่อย เขาก็จะได้เป็นในสิ่งที่อยากเป็น ด้วยตัวของเขาเอง -
………………………………………………
หลงเอยหลงไขว่คว้า ฟายฝัน
หลงผิดคิดว่าจันทร์ แค่เอื้อม
หลับใหลมิรู้วัน วายวิ่น
เพียงแผ่นน้ำกระเพื่อม เสื่อมสิ้น เงาสลาย
………………………………………………
“หนึ่งหยดน้ำหลับใหลในสายน้ำ”, ชนะ คำมงคง
minimalist (ณรงค์ จันทร์สร้อย ๑ พฤษภาคม พ.ศ. ๒๕๕๑)
ความเห็นล่าสุด