Perspective Positioning

เคยได้ยินมาว่า
โลกยิ่งมีความเจริญก้าวหน้ามากเท่าไร
ศีลธรรมและจริยธรรมในสังคมก็ยิ่งตกต่ำลงมากยิ่งขึ้น

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

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

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

คนกลุ่มที่สอง… เพ่งมองไม่เห็นอะไร… กึ่งเดินกึ่งวิ่งไร้ทิศทาง ภาพเบื้องหน้าพร่าเลือน เสพกลืนแต่ผลการค้นพบโดยคนกลุ่มที่หนึ่งอย่างไร้สติและจำยอม

คนกลุ่มที่สาม… เพ่งมองไปรอบทิศ วิ่งไล่อย่างมุ่มมั่น เห็นแต่คนกลุ่มที่หนึ่ง… แต่ไม่ครบทุกคน บ้างพยายามวิ่งให้ทันเพื่อแทรกกายไปผสมรวมกับคนกลุ่มที่หนึ่ง บ้างพยายามวิ่งแซง แต่วิ่งทันเพียงบางคน และแซงได้เพียงบางคน

คนกลุ่มที่สี่… เพ่งมองเห็นคนทั้งสามกลุ่ม ก้าวเดินอย่างสงบ เห็นทั้งซากอดีตสิ่งที่เคยถูกค้นพบ สิ่งที่กำลังถูกค้นพบ และสิ่งที่คนกลุ่มที่หนึ่งยังค้นไม่พบ….

…….

Continue reading

อีกด้านหนึ่งของ ‘SOA’ ที่ไม่มีใครพูดถึง

เกริ่นนำ
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 รวมถึงต้องอัพเกรดระบบเน็ตเวิร์กและอุปกรณ์เน็ตเวิร์ก ฯลฯ
  • ฯลฯ

Continue reading

วิกฤตแฮมเบอร์เกอร์กับไอทียุคโพสต์โมเดิร์น

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

==================================================

จากการล่มสลายของบริษัทยักษ์ใหญ่ที่มีผลต่อเศรษฐกิจของสหรัฐฯ และลามต่อไปยังอุตสาหกรรมต่าง ๆ ทำให้นึกถึงสำนวนไทย ๆ อย่าง “หมองูตายเพราะงู” ได้เป็นอย่างดี ลัทธิทุนนิยมเสรี และรวมไปถึง ‘อะไร ๆ’ ที่เสรีทั้งหลาย ที่ประเทศที่พยายามทำให้ชาวโลกประจักษ์ถึงความเป็น ‘เจ้าโลก’ ของตน โดยการเข้าไปก้าวก่ายชาวบ้านแทบทุกเรื่อง ไม่เว้นแม้แต่ระบอบการปกครอง แต่ตนเองกลับหลงลืมอะไรบางอย่างไปว่า รากเหง้าอารยธรรมและวัฒนธรรมของตนนั้นมีอายุน้อยนิดกว่าหลายประเทศ ที่ ‘เหมือน’ จะดูด้อยกว่าตนเองในสายตาของตนเอง หนำซ้ำยังมีความหลากหลายทางชาติพันธุ์ที่มาหลอมรวม ‘การแสวงหาความฝัน’ ก่อเกิดสิ่งดีงามและสิ่งเลวทรามต่าง ๆ มากมาย หากความสำเร็จของสหรัฐฯ ส่วนหนึ่งที่ผ่านมา เกิดขึ้นจากความชาญฉลาดในการเผยแพร่วัฒนธรรมใหม่ของตน ไปยังประเทศที่เหมือนจะด้อยพัฒนาต่าง ๆ ผ่านการแอบแฝงไปกับสื่อที่เป็นรูปธรรมจับต้องได้และเข้าถึงได้สูง ผู้เชี่ยวชาญด้านนี้ประเทศอื่นเช่น ญี่ปุ่น และที่กำลังตามจี้ติดมาคือเกาหลี หรือแม้แต่พี่ไทยเราก็กำลังทำอยู่เช่นกัน โดยผ่านอาหารและแหล่งท่องเที่ยว เป็นต้น

การเคลื่อนที่ด้วยความเร็วสูงของเทคโนโลยีและการสื่อสาร ทิ้งห่างวัฒนธรรมและศีลธรรมที่ค่อย ๆ วิวัฒน์ไปอย่างช้า ๆ แทนที่จะวิ่งเคียงไปด้วยกันอย่างกายกับเงา ไลฟ์สไตล์ของมนุษย์ในสังคมทุนนิยมเสรีที่ทวีความเป็นปัจเจกหรือความต้องการความเป็นส่วนตัว (identity) สูงขึ้น การผลิตสินค้าต่าง ๆ จึงเปลี่ยนจากการผลิตสินค้าเหมือน ๆ กันคราวละมาก ๆ (mass production) เป็นการผลิตสินค้าที่มีความหลากหลาย เข้าถึงผู้บริโภคที่เฉพาะเจาะจงมากขึ้น (mass customization) สินค้าชิ้นหนึ่งมีความหลากหลายทั้งด้านฟังก์ชั่นและรูปลักษณ์ (convergent product) ภูมิศาสตร์การตลาดก็เริ่มกว้าง ลึก มีมิติมากขึ้น ทำให้เซกเม้นต์เล็กแคบแต่มีจำนวนมากขึ้น (niche market) การตลาดจึงกลายเป็นเครื่องมืออันทรงพลัง เป็นศาสตราวุธที่มีแสนยานุภาพสูงเสียยิ่งกว่าระเบิดนิวเคลียร์ เพราะมีอำนาจครอบงำ (ทำลายล้าง) กินพื้นที่และระยะเวลากว้างไกลยาวนานกว่า เช่น แคมเปญโฆษณาเพียงชิ้นเดียวสามารถยิงไปครอบงำชาติพันธุ์ต่าง ๆ ได้แทบทั่วโลก

Continue reading

Standard and Guideline for Developer

เป็น guideline คร่าว ๆ เอาไว้ค่อยปรับปรุงให้ละเอียดและชัดเจนขึ้นอีกที เพราะมีคนถามผมเยอะว่าการทำงานระหว่างฝั่งเจ้าของงานกับฝั่งผู้พัฒนาระบบฯ ควรมี ‘อะไร’ บ้างนอกเหนือจากสิ่งที่ทั่ว ๆ ไปคุ้นเคยกัน เพื่อให้การทำงาน งาน และการว่าจ้างมีคุณภาพและประสิทธิภาพ โดยโมเมนตัมโฟกัสไปที่ด้าน development / programming และการจัดการ มากหน่อย ไม่ได้เน้นด้านออกแบบหรือสถาปัตยกรรมฯ นัก และไม่ได้อิงกับหลักการด้าน outsourcing / subcontract management อะไรครับ เอาจากประสบการณ์ล้วน ๆ โดยมานั่งคิดเล่น ๆ ว่าควรมีอะไรบ้างแล้วก็ลิสต์ออกมาครับ

ดังนั้นหากใครมีไอเดียอะไรเชิญเสนอเต็มที่เลยนะครับ ผิด-ถูกอย่างไรตรงไหนหรือมีอะไรเพิ่มจะได้ปรับและเสริม ๆ กันไปครับ :)

หากการว่าจ้างพัฒนาระบบฯ สามารถมีครบ 20 ข้อนี้ก็…สุดยอดไปเลย :lol: แฮปปี้กันถ้วนหน้า

และขอแจ้งอีกนิดว่าผมเขียนบทความนี้โดยมีทัศนคติเอนเอียงเข้าข้าง ‘เจ้าของงาน’ มากกว่า ‘ผู้พัฒนาระบบฯ’ นะครับ ^_^ และระหว่างเขียนก็นึกถึงงานที่เจอบ่อย ๆ คือด้าน enterprise architecture / application ดังนั้นบางประเด็นอาจดูขาด ๆ ปริ่ม ๆ และ ล้น ๆ ได้ :)

Standard And Guideline For Developer

1. Naming
มาตรฐานและแนวทางสำหรับการตั้งชื่อและระเบียบการตั้งชื่อ เช่น ชื่อคอลัมน์ ตาราง ตัวแปร เมธอด ฟังก์ชั่น คลาส อินเตอร์เฟส ไดเร็กทอรี่ แพ็กเกจ ฯลฯ ซึ่งรวมถึงชนิดตัวแปร นอกจากนี้ควรทำ mapping เช่น ระหว่างชื่อคอลัมน์กับชื่อแอททริบิวต์ เป็นต้น และควรมีเอกสารหรือเว็บเพจอธิบายตัวย่อ ศัพท์เฉพาะ แปลคำไทยเป็นอังกฤษ แปลคำอังกฤษเป็นไทย เป็นต้น

2. Business Logic Separation
มาตรฐานและแนวทางสำหรับการแยกเอกสาร, โค้ด, subsystem, คอมโพเน้นต์ ฯ ในส่วน business logic ให้เป็นอิสระจากซอฟต์แวร์และสภาพแวดล้อมของซอฟต์แวร์ให้มากที่สุด และควรเป็นอิสระจากสภาพแวดล้อมอื่น เช่น ของแอพพลิเคชั่น ทรานแซกชั่นเซิร์ฟเวอร์ และควรแยกส่วนอิมพลีเม้นต์ด้าน business logic ให้เป็นอิสระหรือให้อยู่คนละที่กับอินเตอร์เฟส

Continue reading