สถาปัตยกรรมองค์กร ตอนที่ 2: ธุรกิจและแอปพลิเคชัน เลือกแอปให้ตรงกับหน้างาน

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

ชั้นธุรกิจ: แยก "ทำอะไร" ออกจาก "ทำอย่างไร"

สถาปัตยกรรมธุรกิจคือพิมพ์เขียวที่เป็นทางการขององค์กร แสดงสองเรื่องที่ต้องแยกกันให้ออก

• ความสามารถ (capability) คือสิ่งที่องค์กรทำ เช่น วางแผนการผลิต ควบคุมคุณภาพ
• กระบวนการ (process) คือวิธีที่องค์กรใช้ความสามารถนั้น เช่น รับแผนที่หน้าเครื่อง สแกนล็อต บันทึกผล

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

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

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

ชั้นแอปพลิเคชัน: ห้ากิจกรรมของการออกแบบ

ตำราใช้แนวทางของ Microsoft Application Architecture Guide ซึ่งแบ่งการออกแบบเป็นห้ากิจกรรม และวนซ้ำได้

1. ตั้งเป้าหมาย ว่าออกแบบรอบนี้เพื่ออะไร จะเสร็จเมื่อไร
2. เลือกสถานการณ์ใช้งานสำคัญ ที่ถ้าทำไม่ได้ระบบนี้ถือว่าล้มเหลว
3. วาดภาพรวมของแอป ว่าเป็นแอปประเภทไหน ใช้สไตล์สถาปัตยกรรมแบบใด
4. หาจุดที่มักผิดพลาด (hot spots) เช่น การยืนยันตัวตน การจัดการข้อผิดพลาด การเชื่อมต่อ
5. เสนอทางเลือก แล้วทดสอบกับสถานการณ์ในข้อ 2

ในโรงงาน สถานการณ์แบบที่ใช้เป็นข้อ 2 ได้ดี เช่น "พนักงานยืนหน้าเครื่อง ถุงมือเปื้อน สัญญาณ WiFi หาย แต่ยังต้องบันทึกผลให้เสร็จ" สถานการณ์เดียวนี้ก็ตัดทางเลือกที่ใช้ไม่ได้ออกไปเกือบหมด

ผู้ใช้ ธุรกิจ ระบบ: หาจุดสมดุล

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

ตัวอย่างในตำราคือความเร็วในการตอบสนอง ผู้ใช้อยากได้เต็ม 100% แต่การลงทุนฮาร์ดแวร์ให้ได้ขนาดนั้นอาจไม่คุ้ม จุดสมดุลอาจอยู่ที่ 80% ในโรงงานก็มักเจอเรื่องคล้ายกัน หัวหน้าอยากเห็นทุกฟิลด์ ส่วนคนหน้าเครื่องต้องการแค่ไม่กี่ปุ่ม ทางออกที่ใช้ได้ดีคือแยกหน้าจอตามกลุ่มคน

เลือกประเภทแอปให้ตรงกับหน้างาน

ตำราแบ่งแอปเป็นห้าประเภท ผมเพิ่มคอลัมน์สุดท้ายเป็นงานในโรงงานที่ผมเลือกใช้แต่ละแบบ

ประเภท	จุดเด่น	ใช้ในโรงงานกับงาน
แอปมือถือ	ทำงานได้แม้เน็ตหลุดเป็นช่วง ๆ ใช้กับอุปกรณ์ทรัพยากรน้อยได้	บันทึกผลหน้าเครื่อง ตรวจนับคลัง พิมพ์ฉลาก
แอปบนเครื่อง (rich client)	ใช้ทรัพยากรของเครื่องเอง ไม่ต้องต่อเน็ตตลอด	สถานีที่ต่อกับเครื่องจักรหรือเครื่องชั่งโดยตรง
แอปบนอินเทอร์เน็ตแบบสื่อมาก (rich internet)	กราฟิกและสื่อเยอะ รันใน browser	หน้าจอแสดงสถานะสายการผลิตบนทีวี
แอปบริการ (service)	ให้ระบบอื่นเรียกใช้ ชิ้นส่วนแยกกันได้	API กลางของข้อมูลหลัก ตัววางแผนการผลิต
เว็บแอป	ใช้ได้ทุก browser ทำงานบนเซิร์ฟเวอร์ ต้องต่อเน็ต	งานสำนักงาน อนุมัติ รายงาน

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

สไตล์สถาปัตยกรรมที่ใช้บ่อย

ตำราสรุปไว้เก้าสไตล์ ในงานจริงผมใช้ไม่กี่แบบที่ผสมกัน

• แบบหลายชั้น (layered) แยกหน้าจอ ตรรกะ และข้อมูลออกจากกัน แก้ชั้นหนึ่งไม่กระทบอีกชั้น
• แบบเน้นบริการ (SOA) แต่ละงานเป็นบริการที่ระบบอื่นเรียกผ่าน API เช่น บริการข้อมูลเครื่องจักร
• บัสข้อความ (message bus) ใช้ส่งข้อมูลจากอุปกรณ์ เช่น MQTT ในฟาร์มของผม ผู้ส่งไม่ต้องรู้ว่าใครรับ

ประเมินก่อนลงมือ

ก่อนลงมือสร้าง ให้ทดสอบการออกแบบด้วยกรณีใช้งานที่สำคัญต่อความสำเร็จ และด้วยสถานการณ์ที่เน้นคุณภาพ เช่น "ถ้ามีคนใช้พร้อมกัน 200 คน" ตำรายกวิธีที่มีชื่อเรียกไว้ เช่น ATAM และ SAAM ในโรงงานขนาดกลาง ผมใช้แบบง่ายกว่านั้น คือเขียนสถานการณ์ 5–10 ข้อลงกระดาษ แล้วถามว่าแบบที่วางไว้รับมือได้ทุกข้อไหม

สรุปสำหรับคนที่จะเริ่ม

1. เขียนความสามารถของโรงงานก่อน ไม่เกิน 10–15 ข้อ แล้วค่อยลงกระบวนการ
2. เลือกสถานการณ์ที่ยากที่สุดของหน้างานมาเป็นตัวทดสอบการออกแบบ
3. เลือกประเภทแอปตามสถานที่และเครือข่ายที่ใช้งานจริง ไม่ใช่ตามความถนัดของทีมพัฒนา
4. แยกหน้าจอตามกลุ่มคน อย่าใส่ทุกอย่างให้ทุกคน

ตอนที่ 3 จะเป็นเรื่องที่ผมคิดว่าสำคัญที่สุดของทั้งชุด คือสถาปัตยกรรมข้อมูล ทำไมโรงงานต้องมีข้อมูลหลักชุดเดียว และต้องมีเจ้าของจากฝั่งธุรกิจ

อ้างอิง

ดนัยรัฐ ธนบดีธรรมจารี และ วรัญญา ปุณณวัฒน์. (2565). การออกแบบสถาปัตยกรรมองค์กร. ใน ประมวลสาระชุดวิชาการจัดการเทคโนโลยีดิจิทัลเชิงกลยุทธ์. สำนักพิมพ์มหาวิทยาลัยสุโขทัยธรรมาธิราช. ISBN 978-616-16-2818-5

Meier, J. D., et al. (2008). Application Architecture Guide 2.0: Designing Applications on the .NET Platform. Microsoft Patterns & Practices. (อ้างถึงในเอกสารข้างต้น)

บทความนี้เป็นการสรุปและตีความของผมจากการนำไปใช้จริง ภาพประกอบวาดขึ้นใหม่