Software Architecture คือ ?

สถาปัตยกรรมซอฟต์แวร์ (Software Architecture) คือ ?

งานด้านสถาปัตยกรรมเป็นงานที่ต้องมองภาพรวม เข้าใจองค์ประกอบสำคัญและความสัมพันธ์ระหว่างองค์ประกอบเหล่านั้น มุ่งเน้นที่จุดสำคัญที่ส่งผลต่อภาพรวมของทั้งระบบ ทั้งในเชิงฟังก์ชั่นและคุณภาพ โดยต้องสอดคล้องกับ concern ของ stakeholder (จุดที่ stakeholder สนใจเป็นพิเศษ) architect จะใช้สถาปัตยกรรมที่ออกแบบขึ้นเพื่อสื่อสารกับ stakeholder ต่างๆ เพื่อให้ stakeholder เข้าใจภาพรวมและแนวทาง (โซลูชั่น) ที่ architect ใช้เพื่อจัดการกับ concern ต่างๆ เพื่อร่วมวิเคราะห์ ประเมิน และตรวจทาน ซึ่งอาจมีการปรับแก้ไขบ้าง เพื่อให้อยู่ในกรอบ concern และข้อจำกัด (constraint) ต่างๆ จากนั้นจึงนำสถาปัตยกรรมไปเป็นต้นแบบในการอิมพลีเม้นต์ต่อไป สถาปัตยกรรมยังมีประโยชน์ต่อกิจกรรมอื่นอีก อาทิ การทดสอบระบบ การดูแลระบบ การปรับปรุงระบบ เป็นต้น

เปรียบเทียบงานสถาปัตยกรรมก่อสร้าง

เฉกเช่นกับสถาปัตยกรรมสิ่งก่อสร้างที่ architect ต้องมองภาพรวม ออกแบบภาพรวม เพื่อเชื่อมโยงองค์ประกอบสำคัญเข้าด้วยกัน มุ่งเน้นในจุดสำคัญทั้งในเชิงธุรกิจที่ stakeholder concern และในเชิงเทคนิคที่ทีมก่อสร้าง concern สิ่งที่ architect ต้องพิจารณาและอธิบายออกมามีอะไรบ้าง อาทิ โครงสร้างอาคาร, ความสวยงามเชิงสถาปัตยกรรม, ทิศทางแสงและลมในฤดูต่างๆ, ต้นไม้ที่จะปลูกภายในและภายนอกอาคาร, ตำแหน่งบันได ลิฟต์ หน้าต่าง ประตู ท่อประปา ท่อทางเดินอากาศ ทางเดินสายไฟ, รูปแบบหลังคา, การป้องกันแรงสั่นสะเทือนเช่นจากแผ่นดินไหว เป็นต้น architect ต้องจัดวางองค์ประกอบเหล่านนี้และเชื่อมโยงกัน เพื่อจัดการความสัมพันธ์ระหว่างองค์ประกอบต่างๆ เช่น การจัดวางตำแหน่งลิฟต์และบันไดไม่ให้ซ้อนทับกัน, การเชื่อมต่อระหว่างระบบฉีดน้ำอัตโนมัติเวลาไฟไหม้กับระบบประปา

งานออกแบบสถาปัตยกรรม architect เน้นการออกแบบภาพรวม ไม่เน้นรายละเอียดมากนัก (ไม่ลงลึกถึงการทำ detailed design) และไม่เน้นรูปแบบการอิมพลีเม้นต์มากนัก (เป็นหน้าที่ของคนอิมพลีเม้นต์ว่าจะใช้แนวทางหรืออัลกอริธึมใด) อาจจะกล่าวได้ว่างานสถาปัตยกรรมเน้นการ ‘คุมภาพรวม’ เช่น โครงการพัฒนาระบบ ERP (Enterprise Resource Planning) ที่ประกอบด้วยระบบย่อยจำนวนมาก เช่น ระบบบัญชี ระบบการเงิน ฯ architect จะต้องคุมภาพรวมการทำงานระหว่างระบบต่างๆ หรือแม้แต่การพัฒนาระบบเพียงระบบเดียว architect ก็ต้องคุมภาพรวมของการทำงานระหว่างฟังก์ชั่นและกลไกต่างๆ

UfaCinema1

รูปที่ 1 ภาพร่าง (เครดิตภาพจากเว็บ thinkinginsomniac.wordpress.com)

UfaCinema2

รูปที่ 2 ภาพแบบแปลน (เครดิตภาพจากเว็บ adesignideas.blogspot.com)

UfaCinema3

รูปที่ 3 ภาพเมื่อก่อสร้างเสร็จแล้ว (เครดิตภาพจากเว็บ adesignideas.blogspot.com)

ในงานก่อสร้าง architect จะเป็นฝ่ายเริ่มต้นการทำงานก่อน ด้วยการออกแบบสถาปัตยกรรมที่อธิบายภาพรวมออกมา ผ่านการวาดพิมพ์เขียว (blueprint) หรือแบบแปลน ซึ่งเอาไว้ใช้กับเฉพาะวิศวกรและทีมผู้รับเหมาก่อสร้าง แต่ก่อนที่พิมพ์เขียวจะออก architect ก็ต้องวาดรูปแบบอาคารด้วยภาพวาด (วาดด้วยมือหรือใช้โปรแกรมสร้าง) เพื่อให้ลูกค้าดูและเข้าใจได้ง่าย ทั้งพิมพ์เขียวที่เอาไว้ใช้งานและรูปที่เอาไว้สื่อกับลูกค้า อาจมีหลายรูปได้ขึ้นกับจำนวนองค์ประกอบของอาคาร เช่น จำนวนชั้น จำนวนห้อง จากนั้นก็จะมาถึงงานของวิศวกรที่จะเอาพิมพ์เขียวไปใช้ต่อ เพื่อดูรายการองค์ประกอบต่างๆ ที่จะต้องสร้าง โดยงานของวิศวกรจะคำนึงถึงแนวทางในการก่อสร้างเป็นหลัก เช่น architect ระบุตำแหน่งเสาและคานของอาคาร ส่วนวิศวกรก็จะพิจารณาในแง่วัสดุ เช่น เหล็ก ปูน การลงเสาเข็ม เป็นต้น จากนั้นวิศวกรจะปรึกษากับผู้รับเหมาก่อสร้าง (ทีมก่อสร้าง) ถึงการวางลำดับการก่อสร้าง และประเด็นสำคัญในการก่อสร้าง รวมถึงเรื่องวัสดุด้วย ในขณะที่ architect ก็ยังอยู่ไม่ได้ไปไหน เพียงแต่งานเบาลง โดยยังคอยให้คำปรึกษาและติดตาม เพื่อให้อาคารสร้างตรงตามแบบที่ออกแบบไว้

ArchStructure

รูปที่ 4 โครงสร้างอาคารที่กำลังก่อสร้าง (เครดิตภาพจากเว็บ ideocondo.com)

จากรูปที่ 4 ลองสังเกตอาคารที่เพิ่งก่อสร้าง จะเห็นว่าสิ่งแรกๆ ที่ต้องทำคือการปรับพื้น ทำฐานรากและเสาเข็ม จากนั้นก็เชื่อมโยงเสาด้วยคาน ในขณะที่เสาก็ยังสร้างต่อเติมให้สูงขึ้นเรื่อยๆ โดยมีการสร้างคานเพิ่มขึ้นเรื่อยๆ เช่นกัน โครงสร้างอาคารก็มีอยู่เพียงเท่านี้ จากนั้นพื้น บันได จึงค่อยตามมา แล้วต่อด้วยผนังภายใน การก่อสร้างมีลำดับขั้นตอน เช่น จะสร้างห้องน้ำจนเสร็จแล้วค่อยมาวางท่อประปาและท่อน้ำทิ้งไม่ได้ ต้องวางท่อประปาและท่อน้ำทิ้งก่อน หรือจะสร้างหลังคาก่อนตอกเสาเข็มก็ไม่ได้ แต่อาจสร้างห้องครัวก่อนห้องนอน หรือสร้างห้องน้ำก่อนห้องนั่งเล่นได้ สร้างอาคารจนเกือบเสร็จจึงถึงคราวของงานตกแต่งภายในหรือ ‘Interior Design’ ที่จะมาออกแบบรายละเอียด อาทิ สี ฝ้าเพดาน พื้น ผนัง ประตู โคมไฟ ตู้ โต๊ะ ระเบียง ฯลฯ ซึ่งงานตกแต่งภายในอาจเริ่มตั้งแต่ช่วงก่อนหรือช่วงต้นของการก่อสร้างก็ได้ เพื่อกำหนดแนวทางในบั้นปลายก่อน เพื่อให้งานก่อสร้างสอดคล้องกับแนวทางการตกแต่งในตอนท้าย

จากตัวอย่างงานก่อสร้างข้างต้น เสาและคานเปรียบเสมือน ‘อินเตอร์เฟส’ ระดับสถาปัตยกรรม หรือ ‘Architectural Interface’ เพื่อใช้เชื่อมชั้นและห้องต่างๆ และยึดโครงสร้างอาคารให้แข็งแรง จึงไม่แปลกที่งานออกแบบสถาปัตยกรรมระบบจึงให้ความสำคัญกับการออกแบบอินเตอร์เฟสเป็นอย่างมาก และมองห้องต่างๆ เป็นดั่ง ‘กล่องดำ’ งานตกแต่งภายในก็เหมือนงาน ‘Detailed Design’ ส่วนงานของวิศวกรและทีมก่อสร้างก็เปรียบดังงานของทีมอิมพลีเม้นต์ที่มุ่งเน้นการสร้างระบบ (เช่น เขียนโปรแกรม) แต่ทั้งนี้ทั้งนั้นงานก่อสร้างกับงานพัฒนาระบบไม่ได้เหมือนกันแบบแนบสนิทจริงๆ มีส่วนแตกต่างกันบ้าง เช่น งานก่อสร้างเน้นความสวยงามด้วย ขณะที่งานพัฒนาระบบเน้นฟังก์ชั่นการทำงานมากกว่า นอกจากนี้ในงานพัฒนาระบบเองยังมีความซ้อนเหลื่อมกันของกระบวนการทางสถาปัตยกรรม (Architectural Process) และกระบวนการทางวิศวกรรมซอฟต์แวร์ (Software Engineering Process) ที่คล้ายและต่างกันไปตามแต่ละวิธีการทางกระบวนการ (Software Process Methodology) ต่างๆ สำหรับมาตรฐานเองก็มีหลายมาตรฐาน

นิยามของสถาปัตยกรรมซอฟต์แวร์

ความหมายของ ‘สถาปัตยกรรมซอฟต์แวร์’ (Software Architecture) ยังไม่มีนิยามสั้นๆ กระชับๆ ที่จะอธิบายให้เข้าใจได้ง่ายในเวลาอันสั้นนัก บ้างก็ว่าคือ High Level Design, บ้างก็ว่าคือการอธิบายโครงสร้างของระบบ, บ้างก็ว่าคือภาพรวมของระบบ, บ้างก็ว่าคือการอธิบายการเชื่อมต่อระหว่างคอมโพเน้นต์สำคัญๆ ในระบบ… ซึ่งไม่ถูกสักเหตุผล แต่ต้องนำเหตุผลทั้งหมดมารวมกัน แต่ก็ยังไม่ชัดเจนอยู่ดี ดังนั้นจึงขอให้นิยมกับความหมายของสถาปัตยกรรมซอฟต์แวร์ไว้ง่ายๆ ดังนี้

สถาปัตยกรรมซอฟต์แวร์ คือ การอธิบายภาพรวมของระบบซึ่งมีโครงสร้างที่เชื่อมโยงองค์ประกอบสำคัญ ที่มีผลต่อภาพรวมของทั้งระบบ ทั้งในด้านฟังก์ชั่นและคุณภาพ ซึ่งแสดงให้เห็นถึงผลกระทบ, ผลสะท้อน, คุณสมบัติ และคุณลักษณะ ของการเชื่อมกันระหว่างองค์ประกอบเหล่านั้น โดยมุ่งเน้นจัดการและอธิบายในจุดสำคัญที่มีผลต่อความสนใจด้านธุรกิจและด้านเทคนิค และมุ่งเน้นวางกรอบแนวคิดพื้นฐานกำกับให้ผู้รับผิดชอบในส่วนต่างๆ ยึดปฏิบัติและต่อยอดเพื่อให้ระบบมีเอกภาพ ตอบโจทย์ภาพรวมเดียวกัน

องค์ประกอบของระบบ (system element) หมายถึง ทุกๆ โมดูล, คอมโพเน้นต์, ไฟล์คอนฟิกุเรชั่น, หน้าจอ, ไลบรารี่, ข้อมูล, เลเยอร์, เทียร์ เป็นต้น แต่องค์ประกอบสำคัญของสถาปัตยกรรม (architectural element) นั้นหมายถึงองค์ประกอบของระบบเฉพาะบางส่วนที่มีผลเท่านั้น ซึ่งเป็นส่วนที่มีผลต่อภาพรวมของทั้งระบบในเชิงฟังก์ชั่นและคุณภาพ เช่น ไม่ใช่ทุกโมดูลที่จะอยู่ในส่วนสถาปัตยกรรม อาจเป็นเฉพาะบางโมดูลเท่านั้น เช่น เป็นกลไกสำคัญของระบบ มีผลต่อคุณภาพหลักของระบบ สนับสนุนฟังก์ชั่นสำคัญของระบบ และมีผลต่อธุรกิจหรือ concern ของ stakeholder สูง

ความสัมพันธ์ระหว่างองค์ประกอบสำคัญ หมายถึง ความสัมพันธ์ทั้งในเชิงไดนามิก และเชิงโครงสร้าง เช่น โมดูล ‘A’ เรียกใช้โมดูล ‘E’ แสดงว่า ‘A’ มี coupling กับ ‘E’ หาก ‘E’ มีการเปลี่ยนแปลงจะส่งผลกระทบต่อ ‘A’ การทำงานของโมดูล ‘E’ สะท้อนถึงคุณภาพของโมดูล ‘A’ ด้วย คุณสมบัติและบริการของโมดูล ‘E’ ที่ ‘A’ เรียกใช้ได้อาจเป็นเพียงบางส่วนที่ ‘E’ เปิดให้ ‘A’ เห็นและเข้าถึงได้ การทำงานร่วมกันในเชิงไดนามิหรือการเชื่อมโยงกันในเชิงโครงสร้างระหว่างองค์ประกอบเหล่านั้น ส่วนใดที่มีผลต่อ concern ในเชิงธุรกิจและเชิงเทคนิคมากๆ ยิ่งต้องมุ่งเน้นจัดการและอธิบายให้ชัดเจน เช่น หากโมดูล ‘E’ ทำงานช้าผิดปกติ จะทำให้โมดูล ‘A’ ทำงานช้าตามเพราะต้องรอ และจะทำให้ระบบโดยรวมเกิดปัญหาคอขวด รองรับ Request ที่เข้ามาปริมาณมากไม่ไหวจนอาจทำให้ระบบหยุดทำงาน หรืออาจทำให้มีทรานแซกชั่นถูกยกเลิกจำนวนมาก สถาปัตยกรรมจึงต้องมุ่งเน้นที่โครงสร้างความสัมพันธ์ระหว่างองค์ประกอบสำคัญต่างๆ

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

ทุกวันนี้โลกไอทีมีอะไรต่อมิอะไรที่ขึ้นต้นด้วยคำว่า ‘สถาปัตยกรรม’ หรือลงท้ายด้วยคำว่า ‘Architecture’ อยู่เต็มไปหมด อาทิ Enterprise Architecture, IT Architecture, Business Architecture, Information Systems Architecture, Solution Architecture, Application Architecture, Technology Architecture, Infrastructure Architecture, Security Architecture, Network Architecture, Hardware Architecture, System Architecture, Data Architecture, Software Architecture,…

ความรู้สำคัญด้าน Software Architecture

  • วัฏจักรสถาปัตยกรรมกับธุรกิจ (Architecture Business Cycle)
    บริบทและเป้าหมายธุรกิจคือ input สำคัญต่องานสถาปัตยกรรมระบบ ดังนั้นสถาปัตยกรรมระบบต้องตอบโจทย์ธุรกิจให้ได้ รวมถึงระบบที่พัฒนาจากสถาปัตยกรรมที่ได้ออกแบบก็ต้องตอบโจทย์ธุรกิจให้ได้เช่นกัน ส่วน architect ก็ต้องเข้าใจบริบทและเป้าหมายธุรกิจของโครงการด้วยเช่นกัน จากนั้นเมื่อเวลาผ่านไปหากมีการเปลี่ยนแปลงใดๆ เกิดขึ้นกับธุรกิจหรือสถาปัตยกรรม ก็ต้องปรับทั้ง 2 ส่วนให้สอดคล้องกันเสมอ (อ่านรายละเอียดเพิ่มเติมเกี่ยวกับ Architecture Business Cycle คลิ้ก)
  • คุณสมบัติทางคุณภาพ (Quality Attribute)
    Quality Attribute คือ คุณสมบัติเชิงคุณภาพของหน่วย (architectural element) ต่างๆ ภายในระบบที่มีการทำงาน อาทิ สถาปัตยกรรมระบบ,ระบบย่อย,  โมดูล, อ็อบเจ็คต์, หน้าจอ เป็นต้น เนื่องจากหน่วยต่างๆ เหล่านี้ต้องมีการประมวลผล มี input และมี output เกิดขึ้น การจะให้ทำงานได้มีคุณภาพที่ดีจึงมีการกำหนดคุณสมบัติเชิงคุณภาพเอาไว้ โดยควรมีคุณภาพอะไรบ้างก็ขึ้นกับบริบทของระบบนั้นๆ ว่า stakeholder ต้องการระบบที่มีศักยภาพแค่ไหนการกำหนด Quality Attribute ได้มาจากการเก็บรวบรวมความต้องการประเภท Non-Functional Requirement โดยเจ้า Quality Attribute เองก็ยังแบ่งออกได้เป็น 3 ประเภท ได้แก่

    1. System Quality คือ คุณภาพระบบ มีหลักๆ อยู่แค่ 6 ตัว ได้แก่ Availability, Modifiability, Performance, Security, Testability และ Usability ซึ่งเจ้า System Quality นี่ล่ะที่เราๆ มักเรียกอีกอย่างว่า ‘Non-Functional Requirement’ นั่นเอง ดังนั้นส่วนมากพอพูดถึง Non-Functional Requirement ก็มักหมายถึง System Quality เหล่านี้นั่นเอง
    2. Business Quality คือ คุณภาพในเชิงธุรกิจที่ระบบได้สนองต่อธุรกิจของ stakeholder มีหลายตัว มักเป็นศัพท์ธุรกิจ อาทิ Increase Net Profit, Increase Competitiveness, Short Time to Market, Reduce Paper Work เป็นต้น ถ้าสังเกตให้ดี ก็จะร้องอ๋อ…ว่ามันก็คือ Business Goal นั่นเอง แต่ต่างๆ เล็กน้อยที่ขอบเขตและ Level of Abstraction เพราะ Business Goal เป็นการมองภาพรวมของทั้งระบบหรือทั้งโครงการ แต่ Business Quality สามารถใช้มองในระดับที่ลึกในรายละเอียดกว่าได้ เช่น Business Quality ของ Domain Layer, ของโมดูล Report Manager, ของกลไก Transaction Management, ของสถาปัตยกรรมระบบ เป็นต้น
    3. Architecture Quality คือ คุณภาพของสถาปัตยกรรมระบบ ที่ไม่ได้มองที่การทำงานของระบบแบบ System Quality แต่มองที่ประโยชน์และการนำสถาปัตยกรรมไปใช้ มีไม่กี่ตัวนัก อาทิ Conceptual Integrity, Buildability, Correctness and Completeness เป็นต้น

    (อ่านรายละเอียดเพิ่มเติมเกี่ยวกับ Quality Attribute คลิ้ก)

  • การอธิบายและสื่อสารสถาปัตยกรรม (Architecture Description & Communication)
    สถาปัตยกรรมที่ออกแบบและสร้างขึ้นจำเป็นต้องสื่อสารให้ stakeholder ได้ทำความเข้าใจ ซึ่งยังใช้เพื่อรับฟีดแบ็กแล้วนำมาปรับปรุงสถาปัตยกรรม ดังนั้นการอธิบายรายละเอียดของสถาปัตยกรรมออกมาจึงมีความสำคัญมาก หาก stakeholder เข้าใจคลาดเคลื่อนไปจากความตั้งใจของ architect แล้วอาจให้ดำเนินการผิดพลาด หรือไม่ได้ตามเป้าหมายที่ต้องการในโครงการปกติมักมี stakeholder ที่หลากหลาย ทั้งตำแหน่งหน้าที่, ประสบการณ์, ความรู้, ความสามารถทางภาษา

    การอธิบายจึงต้องสามารถโน้มน้าวให้ stakeholder ทุกคนเข้าใจตรงกัน ดังนั้น architect จำเป็นต้องเข้าใจแนวคิด ‘Level of Abstraction’ เป็นอย่างดี เข้าใจความแตกต่างของ stakeholder แต่ละกลุ่ม เข้าใจประเด็นสำคัญในสถาปัตยกรรมที่จะนำเสนอ โดยเลือกใช้ชุดภาษา , สัญลักษณ์รูปภาพ และรูปแบบการนำเสนอ ให้เหมาะสม และแบ่งระดับรายละเอียดของเนื้อหาให้เหมาะสม เหมือนการทำหนังสือ, หนังสือพิมพ์, นิตยสาร อาทิเช่น หัวข้อหนึ่งอาจมีผู้อ่านที่หลากหลายมีวัตถุประสงค์ในการรับรู้สาระแตกต่างกันการอธิบายสถาปัตยกรรมจะแบ่งรายละเอียดออกเป็นส่วนต่างๆ เรียกว่า ‘Architectural view’ หมายถึงมุมมองของสถาปัตยกรรม ที่เป็นประเด็นสำคัญที่ต้องการนำเสนอหรืออธิบายออกมา โดยสอดคล้องกับประเด็น stakeholder สนใจ (concern) อาทิ architectural process view, architectural layer view, transaction management view, integration view เป็นต้น

    ในการอธิบายสถาปัตยกรรมมีมาตรฐานและข้อกำหนดด้วยเช่นกัน คือ ISO/IEC/IEEE 42010 ซึ่งปรับปรุ่งต่อจาก IEEE 1471-2000

    ISO42010
    รูปที่ 5 ISO/IEC/IEEE 42010 – Architecture Description

    ArchAccs-cms
    รูปที่ 6 ตัวอย่างมุมมอง ‘Architecture Overview’

    TXView
    รูปที่ 7 ตัวอย่างมุมมอง ‘Transaction Overview’

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

  • การออกแบบสถาปัตยกรรม (Architecture Design)
    การออกแบบสถาปัตยกรรมก็คือการหา solution ที่ตอบโจทย์ความต้องการหลัก โดยเฉพาะ Business Goal, Architectural Concern, Quality Attribute, Functionalityจากความต้องการด้านต่างๆ โดยเฉพาะความต้องการตัวที่มีผลต่อระบบและสถาปัตยกรรมมากๆ (Architecture Requirement) ซึ่งอยู่ในโซนปัญหา (problem area) ก็จะไหลผ่านกระบวนการพัฒนาไปสู่ระบบที่พัฒนาเสร็จสิ้น (concrete system) ความต้องการเหล่านั้นต้องไหลผ่านการแก้ปัญหาที่อยู่ในโซนแนวทางแก้ไข (solution area) เสียก่อน

    solution ที่ใช้แก้ปัญหาทางสถาปัตยกรรมอาทิเช่น Architectural Tactic (ยุทธวิธีทางสถาปัตยกรรม), Architectural Pattern (รูปแบบสามัญทางสถาปัตยกรรม), Architectural Framework (กรอบแนวคิดทางสถาปัตยกรรม) การออกแบบสถาปัตยกรรมก็คือการเลือก solution ที่มีอยู่มาปรับใช้ หรือสร้าง solution ขึ้นใหม่ ที่ต้องตอบโจทย์ความต้องการที่มีผลต่อระบบและสถาปัตยกรรมให้ได้การออกแบบสถาปัตยกรรมเป็นกระบวนการแบบวนซ้ำ (iterative) โดยเริ่มจากคิด solution คร่าวๆ ระดับไอเดียก่อน (คล้ายเริ่มจากการสเก็ตช์ภาพก่อน แล้วค่อยลงรายละเอียด) ซึ่งตลอดเวลาของการออกแบบจะต้องพิจารณาความต้องการหลัก (และโดยเฉพาะ Quality Attribute) ประกอบไปด้วยเสมอ

    สถาปัตยกรรมที่ออกแบบต้องนำเสนอภาพรวมและโฟกัสให้เห็นประเด็นสำคัญ แล้วสื่อสารกับ stakeholder ต่างๆ รวมถึงทีมงาน โดยมุ่งหมายให้สถาปัตยกรรมเป็นต้นแบบหรือพิมพ์เขียวสำหรับการทำงานในส่วนต่างๆ ต่อไป อาทิ detail design, เขียนโปรแกรม, testing, maintain ระบบ

    แนวทางที่ใช้ในการออกแบบสถาปัตยกรรมมีมากมาย อาทิ Attribute-Driven Design, Model-Driven Architecture, Domain-Driven Design เป็นต้น

  • การประเมินสถาปัตยกรรม (Architecture Evaluation)
    การที่ Architecture Requirement จะผ่าน solution มาอย่างราบรื่นตอบโจทย์ทางธุรกิจและเทคนิคหลักได้หรือไม่ขึ้นอยู่กับ solution ที่เลือกมาใช้ ดังนั้นจึงจำเป็นต้องมีการประเมิน solution เหล่านั้นอย่างรอบคอบนั่นเอง

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

    การประเมินจำเป็นต้องประเมินหลายมิติควบคู่กันไป อาทิ ประเมินทั้งด้านคุณภาพและความคุ้มค่าของ solution (ซึ่งอาจรวมถึงประเมินด้านกฏหมายและแผนฯ ด้วยในบางกรณี) ดังนั้น Architecture Evaluation จึงถือเป็นเครื่องมือสำคัญหนึ่งในการทำการศึกษาความเป็นไปได้ หรือ ‘Feasibility Study’

    นอกจากนี้ในการประเมิน solution ต่างๆ จึงต้องทำควบคู่กันไปกับการทำ Proof-of Concept หรือ POCสำหรับการประเมินสถาปัตยกรรมแตกต่างจากการทดสอบ (testing) เพราะเราควรประเมิน solution ให้ได้ก่อนนำไปอิมพลีเม้นต์ (ไม่ใช่สร้างตึกแล้วค่อยมาประเมิน อย่างนั้นเสี่ยงมากมาย) เพราะหากอิมพลีเม้นต์แล้วจะมาดูว่ามันเวิร์กไหม อย่างนี้เรียกว่า test แล้วล่ะ แต่…การประเมินอาจใช้ testing มาเป็นเครื่องมือช่วยก็ได้ ด้วยการนำ solution ไปสร้าง prototype (เขียนโค้ด mock up) แล้วสร้าง test case ขึ้นมาเพื่อทดสอบสมมติฐาน

  • การบูรณะสถาปัตยกรรม (Architecture Reconstruction)
    การรื้อ แกะ แคะ แงะ สถาปัตยกรรม เหมารวมไปถึงการทำซ้ำ/การลอกเลียนแบบ (ก๊อปปี้) หรือผมชอบเรียกว่า hacking architecture design ซึ่งส่วนตัวคิดว่าในอนาคตน่าจะเป็นอีกอาชีพที่น่าสนใจมากๆครับ เพราะคนไทย จีน ไต้หวัน ฮ่องกง มีพรสวรรค์ด้านนี้อยู่ใน DNA มาแต่ครั้งบรรพกาลแล้ว :)จุดประสงค์ของการทำ Architecture Reconstruction มีหลายเหตุผล อาทิ

    • เพื่อจัดทำเอกสารสถาปัตยกรรมของระบบขึ้นมาใหม่
    • เพื่อวิเคราะห์และเรียนรู้การทำงานของระบบ
    • เพื่อระบุองค์ประกอบของระบบว่าส่วนใดที่สามารถ re-use ได้บ้าง ส่วนใด re-use ไม่ได้
    • เพื่อระบุส่วนที่ต้องปรับปรุง
    • เพื่อการวิวัฒน์ (evolve) สถาปัตยกรรมให้ทันสมัย

    Architecture Reconstruction เป็นกระบวนการที่มีการดำเนินการในลักษณะวนซ้ำ (iterative) ทำไปเรื่อยๆ จนกว่าจะบรรลุเป้าหมาย มีกิจกรรมที่เกี่ยวข้องจำนวนมาก โดยมักไม่สามารถทำให้เป็นอัตโนมัติตั้งแต่ต้นจนจบได้ แต่กิจกรรมบางอย่างอาจทำให้เป็นอัตโนมัติได้บ้าง ซึ่งมักต้องใช้เครื่องมือ (tool) ช่วย อาทิการใช้เครื่องมือประเภท reverse engineering, de-compiler  เป็นต้น

    การจะเป็น architect ระดับสุดยอดได้ก็ต้องฝึก ‘รื้อ แกะ แคะ แงะ’ สถาปัตยกรรมของคนอื่นบ่อยๆ คล้ายกับ programmer ที่จะเขียนโปรแกรมเก่งๆ ก็ต้องแกะโค้ดโปรแกรมอื่นบ่อยๆ บางทีการแกะดีไซน์ของคนอื่นเป็นสิ่งที่เราๆ ก็คุ้นเคยอยู่แล้ว กรณีที่เรียบง่ายและใกล้ตัวที่สุด อาทิ การแต่งตัวตามแฟชั่น, การแต่งสวนตามคอลัมน์ในนิตยสาร, การดัดแปลงรถให้คล้ายกับรถแข่งของนักแข่งชื่อดัง, การซื้อหนังสือแบบบ้านสำเร็จรูปเพื่อเลือกแบบมาดัดแปลงแล้วออกแบบใหม่ให้ได้บ้านแบบที่ชอบ ฯลฯ เพียงแต่การจะแกะ software architecture นั้นผู้ปฏิบัติย่อมต้องมีพื้นฐานที่แข็งแกร่งพอควร เพราะสถาปัตยกรรมบางระบบที่ซับซ้อนมากๆ โดยเฉพาะระบบปิด (เช่น ซอฟต์แวร์เชิงพาณิชย์ที่ปิดโค้ด) อาจต้องใช้กำลังภายในมากพอควร ซึ่งนี่ก็คือความท้าทาย เพราะหาก ‘reconstruct’ สถาปัตยกรรมจนชำนาญแล้ว ก็จะก้าวไปสู่งานด้าน Architecture Evaluation เพื่อไปเป็นผู้ประเมินสถาปัตยกรรมได้ไวขึ้น

  • คอมโพเน้นต์สำเร็จรูป (Component-Off-The-Shelf)
    ในการพัฒนาระบบสมัยใหม่เป็นลักษณะการออกแบบคอมโพเน้นต์แล้วนำมาประกอบ (assemble) กันเป็นระบบที่เรียกว่า ‘Component-Based System’ หรือการออกแบบเซอร์วิสแบบในสถาปัตยกรรม  SOA และ Cloud Computing เมื่อทราบว่าระบบต้องมีคอมโพเน้นต์อะไรบ้างแล้ว ต้องวิเคราะห์เพื่อประเมินว่าคอมโพเน้นต์ใดจะพัฒนาเองคอมโพเน้นต์ไม่ควรพัฒนาเองโดยเลือกใช้ COTS (Commercial/Component Off-the-Shelf)

    การได้คอมโพเน้นต์มาใช้งาน (acquisition) มีหลายทางเลือก อาทิ ได้มาด้วยการ outsource ให้ผู้อื่นผลิตให้, ซื้อคอมโพเน้นต์สำเร็จรูปมาใช้, ดาวน์โหลดคอมโพเน้นต์ที่เป็นโอเพ่นซอร์สมาใช้ architect ต้องเป็นผู้ประเมินคอมโพเน้นต์ที่ออกแบบ โดยวิเคราะห์อินเตอร์เฟสและ Quality Attribute ของคอมโพเน้นต์ในสถาปัตยกรรม เพื่อระบุข้อกำหนด (specification) และเกณฑ์คัดเลือกคอมโพเน้นต์ (qualification) เพื่อป้องกันปัญหา ‘interface mismatch’ หรือ ความไม่เข้ากัน หรือเข้ากันได้แต่ไม่ครอบคลุม quality attribute และ functionality ที่กำหนดนอกจากนี้ architect ยังต้องประเมินเบื้องต้นเกี่ยวกับ ค่าใช้จ่าย, ระยะเวลา, องค์ความรู้ที่เกี่ยวกับคอมโพเน้นต์นั้นๆ และทักษะของผู้ที่จะมาอิมพลีเม้นต์คอมโพเน้นต์นั้นๆ รวมไปถึงความเสี่ยงในการอิมพลีเม้นต์ เพื่อเป็นข้อมูลตั้งต้นให้ project manager ประมาณการณ์และวางแผนโคงการต่อไป

    การสร้างระบบไอทีทุกวันนี้เราไม่ควรสร้างทุกชิ้นส่วนขึ้นมาเอง เสียทั้งเวลา, งบประมาณ และกำลังคน ให้นึกถึงกฏ 80/20 ของ Pareto เพราะงานสถาปัตยกรรมที่ดีควร ‘Do More with Less’ หรือ ‘Less is More’ นั่นเอง ความบ้าพลังของผู้บริหารและนักไอทีไม่น้อยที่มีค่านิยม ‘ชอบทำทุกชิ้นส่วน’ เอง นำมาซึ่งการสูญเสีย ให้นึกถึงอาคาร, ห้างสรรพสินค้า, เครื่องจักร สมัยนี้ที่ออกแบบ, วางแผน และผลิตเสร็จเร็วมาก อาคารใหญ่ๆ สมัยนี้เพียงไม่ถึงปีก็สร้างเสร็จแล้ว ขณะที่ระบบไอทีบางระบบที่ไม่ได้ใหญ่อะไรนักกลับใช้เวลากว่าปี! ผมพบผู้บริหารหลายรายมักมีทัศนคติว่าอะไรทำเองได้ก็น่าประหยัดกว่า… ซึ่งบางครั้งมันไม่ใช่! เช่น การเอาคนเงินเดือนเกือบแสนมานั่งวาดรูปโมเดล แทนที่จะเอาเด็กๆ เงินเดือนน้อยๆ มาวาดรูป แล้วเอาคนเงินเดือนแพงๆ มาตั้งโจทย์ให้เด็กๆ วาดรูปแล้วตัวเองมานั่งวิเคราะห์รูปนั้นแทน น่าจะคุ้มค่ากว่า

  • สายการผลิตซอฟต์แวร์ (Software Product Lines)
    Software Product Lines (SPL) คือ สายผลิตภัณฑ์ซอฟต์แวร์ในลักษณะ ‘กลุ่มผลิตภัณฑ์’ (product family) หมายถึง มีระบบหลายระบบที่มีการแชร์บาง architectural element ร่วมกัน ยกตัวอย่างเช่น Microsoft Office ที่ประกอบด้วย Word, Excel, PowerPoint, Access ฯ ที่มีการแชร์กลไกการทำงานบางอย่างร่วมกัน เป็นต้นกลุ่มผลิตภัณฑ์เหล่านี้ต้องมี ‘core asset base’ หรือสถาปัตยกรรมกลาง (Product Line Architecture) เพื่อแชร์องค์ประกอบบางอย่างระหว่างกันได้ อาทิ คอมโพเน้นต์, ไลบรารี่, คอนฟิกกุเรชั่น เป็นต้น

    SPL เป็นการมุ่งเน้นการ re-use ในเชิงกลยุทธ์ (strategic reuse) ซึ่งไม่ได้เน้นแค่ด้านเทคนิคเท่านั้น แต่เน้นธุรกิจและการวางแผนด้วย แนวทางการ re-use ของ SPL จึงแตกต่างจาก Object-Orientation อยู่มากในแง่ขอบเขตและวิธีปฏิบัติ

    SPL เป็นการหยิบยืมแนวคิด ‘สายการผลิต’ (Product Line) มาจากอุตสาหกรรมการผลิต ที่มีมายาวนาน ตัวอย่างผลิตภัณฑ์ที่มี Product Line อาทิ เครื่องยนต์, โทรศัพท์มือถือ, คอมพิวเตอร์, เครื่องใช้ไฟฟ้า, เฟอร์นิเจอร์, หรือแม้แต่แม็คโดนัลด์, เซเว่นอีเลฟเว่น

    SPL เน้นเรื่องการ re-use เพื่อลดต้นทุนและระยะเวลาการผลิตลง จึงมีประโยชน์มากกับการพัฒนาซอฟต์แวร์เชิงพาณิชย์, การพัฒนาระบบขนาดใหญ่อย่าง enterprise system ที่ประกอบด้วยระบบย่อยจำนวนมาก, การพัฒนาเซอร์วิสจำนวนมากอย่างในสถาปัตยกรรมแบบ SOA เป็นต้น แต่…เรามักพบว่าการจะใช้ SPL ให้สัมฤทธิ์ผลต้องอาศัยการวางแผนและ…มองการณ์ไกล ซึ่งขัดแย้งกับแนวทางการพัฒนาระบบไอทีในบ้านเรามาก ที่มักนึกถึงไอทีเมื่อเวลาเจอปัญหา แต่กลับไม่พยายามมองให้เห็นปัญหาในอนาคต (การจะอยู่กับปัจจุบันตามหลักพุทธ ก็ต้องรู้จักบริหารความเสี่ยงที่อาจเกิดขึ้นในอนาคตด้วย ซึ่งต้องรู้จักวางแผนรับมือนั่นเอง) จึงมักพบได้บ่อยทั้งองค์กรภาครัฐและเอกชนที่มักเอาไอทีมาแก้ปัญหาเฉพาะหน้าหรือแค่เพียงช่วงเวลาหนึ่ง (ซึ่งมักไม่ยาวพอ)

สรุป

สถาปัตยกรรมซอฟต์แวร์ ก็แค่… การเข้าใจความต้องการของ stakeholder แล้วหา solution ที่เหมาะสม ออกแบบภาพรวมระบบซึ่งมีโครงสร้างเชื่อมโยงองค์ประกอบสำคัญ มุ่งเน้นประเด็นสำคัญที่มีผลต่อภาพรวมโดยเฉพาะจุดที่ส่งผลต่อธุรกิจและทางเทคนิค แล้วอธิบาย solution เหล่านั้นให้ stakeholder เข้าใจ และให้สถาปัตยกรรมเป็นต้นแบบต่อการทำงานในส่วนที่เหลือต่อไป โดยบริหารจัดการความสัมพันธ์ระหว่างองค์ประกอบสำคัญต่างๆ ควบคู่กันไปเพื่อให้การทำงานและคุณภาพมีดุลยภาพและมีเอกภาพ

architect ที่ดีจึงจำเป็นต้องมองภาพรวมเก่งๆ จำแนกส่วนสำคัญมากน้อยออกจากกันได้ว่องไว ตีความความเสี่ยงได้รวดเร็วและจัดการบูรณาการกับ solution ต่างๆ ได้มีประสิทธิภาพ สื่อสารกับ stakeholder ที่หลากหลายได้ดีเยี่ยมเข้าถึงแก่นแท้ที่เขาเหล่านั้นต้องการ แล้วออกแบบ solution ที่ดี, คุ้มค่า และเป็นต้นแบบและกรอบให้ทีมงานได้ทำงานสอดคล้องม สะดวก และถูกต้องตามที่ควรจะเป็น ส่วน solution จะต้องมีรายละเอียดมากน้อยแค่ไหน ให้นึกถึงเรื่อง ‘Level of Abstraction’ นั่นคือต้องขึ้นกับความซับซ้อนของปัญหาและคุณภาพการสื่อสารกับ stakeholder ต่างๆ โดยเฉพาะทีมเวิร์คระหว่าง architect กับทีมงาน

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s