Enterprise Architecture: EA4

สัปดาห์แรกได้กล่าวไว้แล้วว่าการออกแบบสถาปัตยกรรมสารสนเทศ (Enterprise Architect-EA) ต้องคำนึงถึง 5 มิติหลัก ในสัปดาห์นี้เราจะกล่าวถึงอีกมิติหนึ่งคือระบบงาน หรือที่เราคุ้นเคยกันในชื่อ “Application” มิตินี้มีความสำคัญโดยตรงต่อผู้ใช้งานเพราะเป็นมิติที่ต้องตอบสนองความต้องการธุรกิจ (Requirements)โดยนำความต้องการเหล่านั้นมาออกแบบ

ลักษณะขบวนการทำงานของ Application มี 2 ลักษณะ

1. Batch Processing เป็นลักษณะรูปแบบการทำงานที่ใช้คนมีส่วนร่วมน้อย สามารถกำหนดตั้งเวลาดำเนินการ (job Scheduling) เมื่อมี resource เพียงพอ เช่น ขบวนการ run report, ขบวนการ run transaction ที่ซ้ำๆเป็นจำนวนมาก ตัวอย่างเช่นการออกใบเรียกเก็บเงินค่าใช้ไฟ เป็นต้น

2. On-Line หรือ Transaction Processing เป็นลักษณะรูปแบบการทำงานที่ต้องใช้คนมีส่วนร่วม (Interactive) ผ่านการเชื่อมต่อ network และได้รับผลตอบสนองจากระบบในทันที

โครงสร้างของ Application ในการออกแบบ Application Architecture มี 3 ส่วนหลัก คือ

1. Program – ชุดคำสั่งเพื่อตอบสนอง ฟังก์ชันงานตาม requirements ดังนั้นจึงต้องรู้เสมอว่ากำลังออกแบบเพื่อตอบโจทย์งานอะไร

2. Data ข้อมูล – เป็นส่วนที่ผู้ใช้นำมา process โปรแกรม ในการออกแบบโปรแกรม จึงต้องเข้าใจรูปแบบ-ข้อจำกัดของข้อมูล ออกแบบการจัดเก็บควรอยู่ในรูปแบบไหน จะนำข้อมูลมาใช้ได้อย่างไร

3. Front - การออกแบบหน้าจอ เมื่อต้องเริ่มมีผู้ใช้มาเกี่ยวข้อง (user interface-UI) ก็จะมีเรื่องเกี่ยวกับการออกแบบหน้าจอ ปัจจุบันการออกแบบหน้าจอก็เปลี่ยนไปมาก จากเมื่อก่อนที่เราเคยเห็นหน้าจอเป็นจอเขียวที่เป็นตัวอักษร (Dumb Terminal) เทคโนโลยีก็มีการพัฒนาเป็น PC เป็น Windows เปลี่ยนเป็น GUI (Graphic User Interface) ต่อมาก็มีโปรแกรมเป็น Browser เกิดขึ้นมาจึงมีการใช้งานผ่าน Browser base ปัจจุบันนี้ mobile technology มีการพัฒนา UI ใหม่ให้สามารถปรับขนาดจอได้เองเพื่อรองรับกับขนาดของอุปกรณ์ที่ขนาดต่างกัน จะเห็นได้ว่ารูปแบบ Front ที่เข้าถึงเริ่มมีความหลากหลาย

วิวัฒนาการทางสถาปัตยกรรม Application

วิวัฒนาการทางสถาปัตยกรรม Application ได้พัฒนาจากอดีตที่เป็น Terminal Based หน้าจอเขียว (Dumb terminal) ลักษณะการประมวนผลทุกขั้นตอนในสมัยนั้นจะเกิดขึ้นที่คอมพิวเตอร์ที่เดียว มาว่าจะเป็นขั้นตอนพิสูจน์ตัวตน การประมวนผลโดยโปรแกรม หรือการเข้าถึงข้อมูล

เมื่อมีการพัฒนา Personal Computer (PC) เกิดขึ้น PC จึงถูกนำมาใช้เป็น Desktop ส่วนหน้า (front end) ในขณะที่ส่วนของ Program และ Data ยังคงนำขึ้นไปประมวลผลบนคอมพิวเตอร์แม่ข่ายหลังบ้าน (Back end) แนวคิดที่ split workload แบ่งกระจายไปทำงานนั้นเป็นยุคของ Client Server Application. สถาปัตยกรรมของ Client Server Application ถูกออกแบบให้แยกการประมวนผลเป็นฝั่ง client ที่เป็น desktop และฝั่ง server ซึ่งเป็นคอมพิวเตอร์แม่ข่ายด้านหลัง

ต่อมาเมื่อถึงยุคที่มีการใช้งานอินเตอร์เน็ตอย่างแพร่หลาย มีการใช้อินเทอร์เน็ตในการทำธุรกิจ (eBusiness) โดยใช้งานผ่าน browser เพื่อให้เข้าถึงข้อมูลที่อยู่ใน world wide web (www) จึงเกิด Web Application ขึ้น รูปแบบของ front จึงมีการเปลี่ยนแปลงไปอย่างมากเพื่อสนับสนุนการใช้งานผ่าน browser ที่อยู่บน PC, Notebook หรือบนไอแพดในปัจจุบัน

สถาปัตยกรรม application เองก็ได้มีการพัฒนาเพิ่มขึ้น โดยมีการแยกส่วนให้เป็น multi-tier คือ แยกส่วน front เป็น web server ที่แสดงหน้าจอเป็นแบบ HTML, website ส่วน logic โปรแกรมหรือ application Server และ ส่วนที่บริหารจัดการข้อมูลหรือ data Server กรณีเช่นนี้เราเรียกว่า 3 tiers architecture แต่ในบางครั้ง web server อาจจะมีมากกว่า 1 เครื่อง หรือ application server อาจจะมีการ scale มากกว่า 1 เครื่อง จึงเรียกว่า Multi Tier Architecture อย่างไรก็ตามสถาปัตยกรรมแบบนี้มักมีข้อจำกัด เนื่องจากหนึ่งระบบมีหลายฟังก์ชั่นงานที่ต้องอาศัยข้อมูลซึ่งกันและกัน เมื่อมีเพียงหนึ่งฟังก์ชั่นไม่สามารถใช้งานได้ จะส่งผลให้ระบบล่มทั้งระบบ

จึงเป็นที่มาของการออกแบบสถาปัตยกรรมใหม่ที่เรียกว่า Micro Services ที่เน้นการออกแบบให้ฟังก์ชั่นให้เป็นอิสระออกจากกัน (no-dependency) ส่วนงานฟังก์ชั่นไหนที่มีปัญหาระบบก็จะงดให้บริการเฉพาะส่วนนั้น ไม่ได้ล่มทั้งระบบเหมือน multi-tier application จากการที่ฟังก์ชั่นเป็นอิสระต่อกันจึงทำให้ microservice application สามารถ scale เฉพาะในแต่ฟังก์ชั่นของตัวเองได้ รองรับการเปลี่ยน (change) ที่เกิดขึ้นโดยไม่ต้องการ downtime ทำให้ผู้ใช้งานสามารถใช้บริการได้ตลอด ช่วยขบวนการพัฒนาระบบให้รวดเร็วขึ้น

Micro Services Architecture เป็นพื้นฐานที่สำคัญของ application ที่ใช้ Cloud Native ซึ่งไม่เพียงแต่รองรับ virtual machine แต่ยังต้องใช้กับ Container ซึ่งเป็นเทคโนโลยีใหม่ที่ใช้ทรัพยากรของเครื่องน้อยลงและรองรับการ Scaling ได้เร็วขึ้นและมีประสิทธิภาพมากกว่าเดิม

จะเห็นได้ว่ารูปของสถาปัตยกรรมสารสนเทศมีการพัฒนาเปลี่ยนแเวลา ระบบ application ณ วันนี้ไม่สามารถคำนึงถึงการให้บริการด้าน function แต่อย่างเดียวอีกต่อไปแล้ว ดังนั้นการออกแบบสถาปัตยกรรม application ต้องคำนึงถึงส่วนที่เรียกว่า non-functional ด้วย Non-Functional Requirement เป็นปัจจัยรองที่ทำให้ function ที่ออกแบบถูกใช้งานได้อย่างมีประสิทธิภาพ เช่น ปริมาณของคนที่เข้าใช้ระบบ อัตราการเพิ่มขึ้นของผู้ใช้งาน ความปลอดภัยของระบบ ความต่อเนื่องของระบบ เช่นใช้งาน แบบ 24x7 แบบไม่มี downtime

สัปดาห์หน้าจะกล่าวถึงกระบวนการการพัฒนาระบบงาน (Software Development Life Cycle) ซึ่งก็มีวิวัฒนาการเพื่อให้เราสามารถพัฒนาระบบให้ออกสู่ตลาดได้เร็ว (Agile)

แล้วพบกันครั้งหน้า กับหัวข้อ Software Development Life Cycle

โปรดติดตามตอนต่อไป...