Architecture Business Cycle

วัฏจักรสถาปัตยกรรมกับธุรกิจ (Architecture Business Cycle)

ระบบต่างๆ ที่ถูกพัฒนาขึ้นมีวัตถุประสงค์หลัก คือ เพื่อสนับสนุนกิจกรรมทางธุรกิจ ดังนั้นจึงควรทราบเสียก่อนพัฒนาระบบว่าภาคธุรกิจคาดหวังอะไรจากระบบบ้าง? ระบบต้องไปสนับสนุนกิจกรรม (operation) หรือกระบวนการทางธุรกิจ (business process) อะไรบ้าง? ใครคือผู้ที่มีส่วนได้เสียหรือมีผลต่อความสำเร็จหรือล้มเหลวของโครงการ (stakeholder) บ้าง? ระบบจะไปทำงานในสภาพแวดล้อมแบบใด? สถาปนิกผู้ออกแบบมีประสบการณ์และแบ๊กกราวด์ด้านใดมาบ้าง? สิ่งเหล่านี้เป็นดังแรงกดดัน (influence) ต่อการออกแบบสถาปัตยกรรมซอฟต์แวร์ ซึ่งจะกลายเป็นต้นแบบต่อการพัฒนาระบบ (รวมถึงการเขียนโปรแกรม) ต่อไป จนกระทั่งระบบพัฒนาเสร็จ โดยการทำงานและคุณภาพของระบบที่พัฒนาเสร็จสิ้นจะต้องสะท้อนกลับไปยังปัจจัยต่างๆ ก่อนหน้านี้ได้ว่า…ระบบตอบสนองต่อภาคธุรกิจได้ตามที่คาดหวังไว้หรือไม่?

การพัฒนาระบบแต่ไหนแต่ไรมาคนจำนวนมากคุ้นเคยแต่การสร้างซอร์สโค้ด แล้วก็คอมไพล์ ระบบสมัยก่อนมักเป็นระบบที่ไม่ใหญ่และไม่ซับซ้อนมากนัก เมื่อกาลเวลาผ่านไปเทคโนโลยีทวีความซับซ้อนยิ่งขึ้น ฮาร์ดแวร์และโครงสร้างพื้นฐานโดยเฉพาะความเร็วในการสื่อสารต่างเจริญรุดหน้าไปมาก ผลักดันให้ระบบเองเริ่มซับซ้อนยิ่งขึ้น เพื่อให้รองรับการใช้งานหลากหลายฟังก์ชั่น และผู้ใช้ที่หลากหลายยิ่งขึ้น สมัยก่อนไม่มีใครรู้จักและใส่ใจกับสถาปัตยกรรมซอฟต์แวร์กันนัก ส่วนหนึ่งเพราะยังเป็นศาสตร์ใหม่ และอีกส่วนหนึ่งที่น่าจะเป็นเหตุผลหลักคือ การที่ผู้คนยังคงสนใจแต่ซอร์สโค้ดเป็นหลัก ได้ requirement มาก็โซโล่โค้ดกันเลย ออกแบบในหัวแล้วปลดปล่อยจินตนาการออกมาเป็นซอร์สโค้ด มีงานออกแบบที่มักทำกันบ้างเช่น Data Flow, Entity-Relationship Data Model (หรือ ER Diagram), หน้าจอโปรโตไทป์ ที่เหลือก็เป็น ‘สเป๊ก’ (Specification) บรรยายฟังก์ชั่นและหน้าจอต่างๆ ซึ่งก็เป็นเพียงรายละเอียดคร่าวๆ และออกไปทางนามธรรม! งานออกแบบจึงยังไม่ค่อยมีใครให้ความสำคัญนักในสมัยก่อน (แต่สมัยนี้องค์กรจำนวนมากก็ยังคงปฏิบัติกับการพัฒนาระบบไม่ต่างกันนัก)

ในความเป็นจริงแล้วไม่ว่าระบบจะเล็กจะใหญ่ จะเก่าจะใหม่ต่างมีสถาปัตยกรรมด้วยกันทั้งนั้น เพียงแค่ว่าได้อธิบายมันออกมาเป็นกิจลักษณะหรือไม่เท่านั้นเอง สมัยนี้การพัฒนาระบบหนึ่งๆ ต่างอุดมด้วยเทคโนโลยีอันหลากหลาย ภาษาโปรแกรมภาษาสคริปต์หลายภาษาในระบบเดียว เลเยอร์ (layer) ซับซ้อนขึ้น เทียร์ (tier) เริ่มมีหลายชั้นมากขึ้น แพลตฟอร์มในสภาพแวดล้อมระบบก็มีหลากหลาย เฟรมเวิร์กและไลบรารี่จำนวนมากถูกขยำรวมกันในระบบหนึ่งๆ แบบไม่บันยะบันยัง ผู้ใช้งานที่ทวีจำนวนมากและหลากหลายขึ้นทั้งพฤติกรรมการใช้งานและอุปกรณ์ที่ใช้ ไม่ว่าจะเป็นพีซี โทรศัพท์มือถือ แท็บเล็ต รวมไปถึงการทำงานเชื่อมต่อกันข้ามระบบก็มีมากยิ่งขึ้น resource system ก็มีมากขึ้นๆ อาทิ database server (ที่มียี่ห้อที่นิยมใช้งานกันเยอะขึ้นๆ), message queue server, mail server, directory server, data warehouse ฯลฯ เหล่านี้เองที่ผลักดันให้ระบบจำต้องซับซ้อนมากขึ้นกว่าสมัยก่อนไปโดยปริยาย กลายเป็นในสภาพแวดล้อมระบบมี ‘อะไรต่อมิอะไร’ มากมาย ซึ่งต่างเป็นปัจจัยที่ส่งผลต่อระบบทั้งนั้น ดังนั้นการสร้างสถาปัตยกรรม เพื่อใช้เป็นต้นแบบ ใช้สื่อสาร ใช้ควบคุม จึงถูกให้ความสำคัญมากยิ่งขึ้น

มุมมองเชิงสถาปัตยกรรม (Architectural View) ที่อธิบายออกมาจากงานออกแบบสถาปัตยกรรม มักเป็นนามธรรม ไม่จำเป็นต้องอธิบายส่วนต่างๆ (system element) ในระบบให้ละเอียดมากนัก แต่ต้องอธิบายให้เห็นภาพรวม และประเด็นสำคัญต่างๆ ในระบบ โดยมุ่งเน้นอธิบายพฤติกรรมและปฏิสัมพันธ์ (interaction) ของอิลิเม้นต์ต่างๆ ในระบบเป็นหลัก

อิลิเม้นต์ในระบบมีอะไรบ้าง อาทิ โมดูล คอมโพเน้นต์ ไฟล์คอนฟิกุเรชั่น หน้าจอ ไลบรารี่ที่ใช้ ข้อมูล เลเยอร์ เทียร์ เป็นต้น ส่วน ‘อิลิเม้นต์ที่สำคัญในระบบ’ (architectural elements) จะพิจารณาเกณฑ์ง่ายๆ ว่าอิลิเม้นต์นั้นๆ  1) ต้องส่งผลต่อภาพรวมของระบบ (เช่น database driver ถ้าคอนฟิกค่าผิดระบบทั้งระบบอาจติดต่อกับ database server ไม่ได้ก็ได้) 2) ต้องสัมพันธ์กับสิ่งที่ stakeholder สนใจ (หรือ concern) (เช่น stakeholder กังวลเรื่องการจัดการกับ business logic ที่เป็นความลับขององค์กร ดังนั้นสถาปัตยกรรมก็ควรเน้นตรงนี้มากหน่อย)

BlackBoxElements

รูปที่ 1 : สถาปัตยกรรมซอฟต์แวร์โฟกัสที่ปฏิสัมพันธ์และพฤติกรรมระหว่าง ‘black box elements’

จากรูปที่ 1 เราจะพิจารณา ‘อิลิเม้นต์ที่สำคัญในระบบ’ เป็นเสมือนกล่องดำ โดยไม่สนใจโครงสร้าง (structure) และพฤติกรรม (behavior) ภายในแต่ละอิลิเม้นต์มากนัก แต่จะมุ่งเน้นที่พฤติกรรมและปฏิสัมพันธ์ระหว่างอิลิเม้นต์เป็นหลัก จากรูปที่ 1 อิลิเม้นต์ ‘A’ มี dependency กับอิลิเม้นต์ ‘E’ (เช่น โมดูล A มีการเรียกใช้เซอร์วิสของโมดูล E) เราจะไม่สนใจกับรายละเอียดภายในของ ‘A’ และ ‘E’ นัก แต่สนใจที่ความสัมพันธ์ระหว่าง ‘A’ กับ ‘E’ ซึ่งมีประเด็นที่ต้องพิจารณากันหลายเรื่องทีเดียว อาทิ ฟังก์ชั่นการทำงาน (functionality) และคุณภาพด้านต่างๆ (performance, reliability,…, scalability) (มีอธิบายอย่างละเอียดในหัวข้อ Quality Attribute)

Architectural Concerns

ArchitectureInfluences

รูปที่ 2 : ความสนใจที่แตกต่างกันของ Stakeholder ที่ Architect ต้อง Balance Concern เหล่านี้ให้ได้

จากรูปที่ 2 ระบบจะออกมาหน้าตาอย่างไรขึ้นกับสถาปัตยกรรม ซึ่งสถาปัตยกรรมจะมีหน้าตาอย่างไรก็ขึ้นกับความสนใจของ stakeholder โดยสิ่งที่ architect จะต้องรับผิดชอบคือการ ‘balance concern’ เหล่านี้ให้ได้ สำหรับ ‘balance concern’ คือ การสร้างสมดุลในความต้องการของแต่ละ stakeholder ให้ได้ นั่นคือการทำให้ stakeholder ทุกคนต้อง ‘win-win’ โดย architect ต้องเข้าใจเหตุผล ที่มาที่ไป ว่าทำไม stakeholder ถึงสนใจสิ่งเหล่านั้น ว่ามีประโยชน์ต่องานของตน สวัสดิภาพการทำงานของตน ธุรกิจของตน อย่างไร? ‘concern’ เหล่านี้อยู่ในรูปของ requirement ที่จะถูกจำแนกเป็นประเภทต่างๆ อีกที แต่อยู่ๆ stakeholder ให้ความต้องการมา architect จะตอบเลยว่าทำได้หรือไม่ทันทีนั้นก็กระไรอยู่ ดังนั้นจึงต้องออกแบบสถาปัตยกรรมและใช้สถาปัตยกรรมมาประกอบการสื่อสารและวิเคราะห์ และอาจต้องมีการประนีประนอมกับ stakeholder เพื่อปรับ concern เหล่านั้นให้อยู่ภายในกรอบของสถาปัตยกรรมที่ สามารถนำไปสร้างได้จริง ภายใต้เงื่อนไข เช่น งบประมาณ กำลังคน ระยะเวลา และความเสี่ยงทางธุรกิจ ไม่ใช่ว่า stakeholder อยากได้อย่างไร ก็ต้องตามใจ หรือ architect จะออกแบบสถาปัตยกรรมตามอำเภอใจโดยไม่ใส่ใจ stakeholder เลยก็ไม่ได้

Attitude

รูปที่ 3 : ทัศนคติและมุมมองที่มีต่อระบบเดียวกัน

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

ABC

รูปที่ 4 : วัฏจักรสถาปัตยกรรมกับธุรกิจ

 

ขั้นตอนของวัฏจักร

จากรูปที่ 4 Architecture’s Influences คือ ปัจจัยหลักที่ถาโถมสู่ architect ประกอบด้วยความต้องการของ stakeholder ต่างๆ และ Developing Organization (ซึ่งความต้องการที่ว่านี้เรียกว่า ‘Architectural Concern’ นั่นเอง), สภาพแวดล้อมเชิงเทคนิค และประสบการณ์ของ architect เอง เหล่านี้ถือเป็นอินพุตหลักสู่ตัว architect เอง เพื่อนำไปใช้ออกแบบสถาปัตยกรรม จากนั้นจึงนำสถาปัตยกรรมไปเป็นต้นแบบในการสร้างระบบ เมื่อระบบสร้างเสร็จแล้วก็ ‘ควร’ ตอบสนองต่อ Architecture’s Influences โดยเฉพาะความต้องการของ stakeholder ต่างๆ และ Developing Organization และเมื่อเวลาผ่านไปหลังจากเริ่มใช้งานระบบ atakeholder อาจมีความต้องการเพิ่มเติม อันเป็นผลสืบเนื่องจาก concern ด้านธุรกิจและเทคโนโลยีที่มีการเปลี่ยนแปลง เช่น แผนธุรกิจ, แผลกลยุทธ์, business rule, business process, เทคโนโลยี, ไลบรารี่ เป็นต้น ทำให้สถาปัตยกรรมและตัวระบบเองต้องปรับตาม วัฏจักรของสถาปัตยกรรมกับธุรกิจก็จะกลับมาหมุนวนรอบใหม่อีกครั้ง เป็นวัฏจัรกเช่นนี้สืบเนื่องกันไป ซึ่งการบริหารสถาปัตยกรรมให้รองรับการเปลี่ยนแปลงและมีความทันสมัยอยู่เสมอเรียกว่า ‘Architecture Change Management’ หรือบางทีเรียกว่า ‘Architecture Evolution Management’

Stakeholder หมายถึง ผู้มีส่วนได้เสียในระบบ หรือ ผู้มีผลต่อความสำเร็จหรือล้มเหลวของระบบ เช่น acquirer (ผู้ถือลิขสิทธิ์ของระบบ), developer/developing organization (ทีมพัฒนาระบบ), maintainer (ผู้ดูแลระบบหลังเริ่มใช้งาน ช่วงแรกอาจเป็นทีมพัฒนาหรือเวนเดอร์ดูแลตามระยะเวลารับประกันผลงาน ช่วงต่อมาฝ่ายไอทีฝั่งผู้ใช้อาจดูแลต่อเอง) และ end user (ผู้ใช้ระบบ)

Developing Organization หมายถึง หน่วยงานหรือทีมพัฒนาระบบ สามารถรวมถึงที่ปรึกษาได้ด้วย

Technical Environment หมายถึง สภาพแวดล้อมเชิงเทคนิคที่ระบบจะต้องไปทำงานอยู่ภายใน เช่น ไคลเอ็นต์/เซิฟเวอร์, เว็บแอพพลิเคชั่น, เว็บเซอร์วิส, เมนเฟรม, distributed computing, cloud computing ซึ่งยังสามารถลงรายละเอียดไปได้ถึงฮาร์ดแวร์ เน็ตเวิร์ก และ resource system ต่างๆ เช่น database server, message queue server, directory server และระบบอื่นๆ ที่ระบบที่กำลังออกแบบต้องไปทำงานร่วมด้วย

Architect’s Experience หมายถึง ประสบการณ์ ความรู้ และทักษะ ของ architect เอง ว่ามีพื้นด้านไหนมาบ้างก่อนที่จะมาออกแบบสถาปัตยกรรมระบบนี้ เช่น ถ้ามีพื้นฐานที่เกี่ยวข้องกับระบบที่กำลังจะทำก็ถือว่าดี แต่ถ้าไม่มีก็ควรจัดเวลาเพื่อศึกษาและค้นคว้าเพื่อเตรียมตัวก่อน

สำหรับ Requirements (Qualities) หมายถึง ความต้องการหลักที่สะท้อนถึง concern ของ stakeholder ซึ่งเป็นความต้องการในเชิงคุณภาพเป็นหลัก เพราะงานสถาปัตยกรรมต้องให้ความสำคัญกับคุณภาพ ความต้องการประเภทใดตัวใดก็ตามที่ส่งผลต่อคุณภาพหลักของระบบ ก็จะถูกรวมอยู่ในกลุ่มนี้ (สำหรับ Architectural Concern จะกล่าวถึงอย่างละเอียดในบทคุณสมบัติทางคุณภาพ (Quality Attribute)’)

 

คำว่าธุรกิจ

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

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

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

ขอยกตัวอย่างจากประสบการณ์ที่เคยพบมา มีผู้บริหารองค์กรรายหนึ่งมอบหมายให้ฝ่ายไอทีศึกษา SOA (Service-Oriented Architecture) เพื่ออยากให้นำมาแก้ปัญหาการเชื่อมต่อระหว่างระบบจำนวนมากที่ซับซ้อนยุ่งเหยิง แล้วก็ลงทุนไปมากมายหลายร้อยล้านบาท ทำทั้ง BPM (Business Process Management), ESB (Enterprise Service Bus), Portal Web, Web Services แล้วก็ลงไปปรับรื้อระบบขนาดใหญ่มากมาย อันไหนปรับไม่ได้ก็แก้ด้วยการเพิ่มประสิทธิภาพฮาร์ดแวร์ ผู้บริหารให้เวลามาอย่างจำกัด ทีมพัฒนาจึงต้องรีบทำ แต่ก็ไม่ได้ทำกันเองทั้งหมด โดยส่วนใหญ่จ้างเวนเดอร์ทำ และจ้างหลายเจ้า พอระบบเริ่มใช้งานจริง เชื้อที่สะสมไว้ก็แผลงฤทธิ์ ระบบต่างๆ ทำงานช้า โอเวอร์เฮดสูงมาก เน็ตเวิร์กมีการจราจรหนาแน่นคับคั่งสาหัส ทางออกสุดท้ายที่ง่ายที่สุดและประหยัดเวลาที่สุดคือ ขยายประสิทธิภาพฮาร์ดแวร์และเน็ตเวิร์ก…(ต้องใช้เงินเพิ่ม) ทั้งที่เมื่อย้อนกลับมาดูความตั้งใจตอนต้นคือ ผู้บริหารต้องการแก้ปัญหาการเชื่อมต่อระหว่างระบบจำนวนมากด้วย SOA ซึ่งในความเป็นจริงแล้วการแก้ไขปัญหานี้ไม่จำเป็นต้องใช้ SOA ก็ได้ และการอิมพลีเม้นต์ SOA ก็ไม่จำเป็นต้องทำ BPM, ESB, Portal Web และ Web Services เสมอไป การแก้ปัญจึงไถลเลยเถิดออกไปไกล และผลาญงบฯ องค์กรไปมหาศาล แต่หากเพียงเข้าใจสักนิดว่าผู้บริหารเพียงแค่ต้องการแก้ปัญหาการเชื่อมต่อระหว่างระบบจำนวนมากเท่านั้น ผู้ที่เป็น architect จะต้องสามารถเข้าถึงความต้องการแท้จริงตรงนี้ให้ได้ เพราะนี่คือ ‘ธุรกิจ’ ถึงแม้ถ้อยคำจะเป็นในเชิงเทคนิค และ architect ต้องสามารถช่วยผู้บริหารปรับวัตถุประสงค์ กลยุทธ์ ความต้องการ ฯลฯ ให้อยู่ในกรอบและแนวทางที่จะสามารถทำได้จริงและแก้ปัญหาได้ตรงจุด! ซึ่งต้องคุ้มค่าทั้งเงิน เวลา คน และธุรกิจ…

เสียดายที่วงการการพัฒนาระบบไอทีในประเทศไทยยังไม่มีกฏหมายควบคุม และไม่มีองค์กรอิสระทำหน้าที่ตรวจสอบและให้ความช่วยเหลือชัดเจนเหมือนในอุตสาหกรรมอื่นๆ อาทิ ในงานก่อสร้าง ที่แบบก่อสร้างก็มีกฏหมายควบคุม ออกแบบแล้วพอเอาแบบไปเริ่มก่อสร้างก็ต้องมีการตรวจสอบว่าสร้างตรงตามแบบหรือไม่ บ้านสร้างเสร็จแล้วก็ยังต้องมีการตรวจสอบอีก ต้องเซ็นต์รับทราบร่วมกันหลายฝ่าย พอวันหนึ่งบ้านพังก็ไล่ตรวจสอบเอาผิดกันได้ ในวงการพัฒนาระบบไอทีก็เริ่มบ้าง แต่เป็นในเชิงแนวปฏิบัติ เช่น การทำ ‘Conformance Test’ เพื่อทดสอบว่าระบบสร้างตรงตามแบบหรือไม่ และตอบสนองต่อความต้องการของ stakeholder หรือไม่

 

ปัจจัยที่ส่งผลต่องานด้านสถาปัตยกรรม

กระบวนการพัฒนาซอฟต์แวร์ยังมีความสำคัญต่องานด้านสถาปัตยกรรมอย่างมาก โดยปัจจัยสำคัญได้แก่ องค์กร, ประเพณีปฏิบัติ และการบริหารจัดการ

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

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

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

สถาปัตยกรรมที่ดีขึ้นกับอะไร?

การสร้างสถาปัตยกรรมที่ดีควรมีข้อแนะนำหรือไกด์ไลน์ด้าน Process และ Product ที่ดี เพื่อให้กระบวนการสร้างสถาปัตยกรรมอยู่ในกรอบที่ถูกต้องและปรับให้เข้ากับสถานการณ์ได้

ข้อแนะนำด้าน Process การทำงาน อาทิเช่น

  • สถาปัตยกรรมควรถูกสร้างโดย architect เพียงคนเดียวหรือกลุ่มเล็กๆ เพียงกลุ่มเดียว โดยควรมีการกำหนดผู้นำทีมที่ชัดเจน
  • architect หรือทีม architect ควรมี requirement ที่ดีเป็นอินพุต ซึ่งควรประกอบด้วย Functional Requirements ของระบบ ซึ่งควรเชื่อมโยง (Traceability) กับความต้องการเชิงคุณภาพ (Quality Attribute หรือที่หลายคนคุ้นในชื่อ Non-Functional Requirements) และต้องมีการจัดลำดับความสำคัญของความต้องการ เพื่อให้ออกแบบสถาปัตยกรรมได้ตรงกับ concern มากที่สุด
  • สถาปัตยกรรมควรอธิบาย (เป็นเอกสาร) ให้ดีให้กระจ่าง ควรมีอย่างน้อย 1 static view และ 1 dynamic view โดยใช้สัญลักษณ์ที่ stakeholder ทุกคนสามารถเข้าใจได้ง่าย
  • ควรเวียนสถาปัตยกรรมให้ stakeholder ของระบบได้รับทราบและทำความเข้าใจ เพื่อประกอบการตรวจทาน
  • สถาปัตยกรรมเมื่อออกแบบแล้วควรถูกวิเคราะห์และตรวจทานก่อน โดยวิเคราะห์ในเชิงปริมาณว่าโซลูชั่นที่ใช้มีความคุ้มค่าเพียงใด และควรถูกวิเคราะห์ในเชิงคุณภาพ โดยพิจารณาจากการจัดการกับ Quality Attribute ซึ่งการวิเคราะห์ควรทำแต่เนิ่นๆ ก่อนที่จะสายเกินกว่าที่จะย้อนกลับไปแก้ไขได้ (การวิเคราะห์นี้เป็นเชิงการประเมิน ไม่ใช่การทดสอบระบบ ซึ่งต้องทำก่อนเริ่มสร้างระบบนั่นเอง)
  • ไม่จำเป็นต้องออกแบบสถาปัตยกรรมจนเสร็จสมบูรณ์แล้วค่อยเริ่มอิมพลีเม้นต์ (เพราะอาจใช้เวลานาน) แต่ให้ออกแบบสถาปัตยกรรมในระดับ ‘Skeletal System’ ซึ่งเป็นโครงสร้างหลักให้ได้ก่อน แล้วจึงค่อยทะยอยอิมพลีเม้นต์ไปเรื่อยๆ ในขณะที่สถาปัตยกรรมอาจยังมีการปรับเปลี่ยนรายละเอียดเล็กๆ น้อยๆ ได้อยู่ โดยให้ยึดเอา เส้นทางการสื่อสารหรือการ call กันภายในระบบ หรือเรียกว่า ‘Communication Path’ ของระบบเป็นแนวทาง (มีลักษณะคล้าย process ของการ call กันระหว่างโมดูลต่างๆ ภายในสถาปัตยกรรม) ซึ่งจะช่วยให้ง่ายต่อการอิมพลีเม้นต์ การทดสอบ และการเชื่อมต่อระบบ ตัวอย่างเช่น ออกแบบสถาปัตยกรรมอาคารสูง 5 ชั้น แต่ 2 ปีแรกลูกค้าต้องการใช้งานแค่ 3 ชั้นแรก ก็ออกแบบโครงสร้างรองรับ 5 ชั้นไว้ก่อน แต่ออกแบบอย่างละเอียดเฉพาะ 3 ชั้นแรก และอิมพลีเม้นต์ (ก่อสร้าง) จริงเฉพาะ 3 ชั้นแรกก่อน อีก 2 ชั้นก็จะสามารถต่อเติมได้ง่ายต่อไปโดยไม่กระทบโครงสร้าง
  • สถาปัตยกรรมควรมุ่งเน้นแก้ปัญหาในจุดที่สำคัญที่มีผลต่อคุณภาพและฟังก์ชั่นการทำงานของระบบ ซึ่งเป็นจุดที่เกี่ยวข้องกับ concern ของ stakeholder เช่น จุดที่ส่งผลต่อรายได้ กำไร ประโยชน์ ธุรกิจ ความเสี่ยง กิจกรรม ของ stakeholder เป็นต้น

ข้อแนะนำด้าน Product หรือโครงสร้างระบบ อาทิเช่น

  • ควรจัดวางโครงสร้างการทำงานระหว่างโมดูลให้ชัดเจน ควรยึดหลักการออกแบบด้าน Information Hiding และ Separation of Concerns เพื่อให้แต่ละโมดูลมี Coupling ต่อกันให้น้อยที่สุด และ Encapsulate สิ่งที่ไม่จำเป็นเอาไว้ โดยแบ่งการทำงานของแต่ละโมดูลให้ชัดเจน ไม่ซ้ำซ้อนกัน
  • แต่ละโมดูลควรมีอินเตอร์เฟสที่ดี รองรับการเกิดผลกระทบข้างเคียงได้ กรณีมีการเปลี่ยนแปลงเกิดขึ้นกับโมดูลอื่น (อินเตอร์เฟสมีหลายระดับ ในที่นี้หมายถึงอินเตอร์เฟสระดับสถาปัตยกรรม หรือ Architectural Interfaces ให้นึกถึงเสาและคานในอาคารซึ่งเปลี่ยนแปลงยาก แต่ผนังและฉากกั้นห้องเปรียบเสมือนอินเตอร์เฟสภายในโมดูล ที่สามารถเปลี่ยนแปลงง่ายกว่า และไม่กระทบต่ออาคาร)
  • Quality Attribute ต่างๆ ของระบบควรใช้โซลูชั่น (Architectural Tactic และ Architectural Pattern) ที่ดีและเป็นที่รู้จักกันเป็นอย่างดีมาแก้ปัญหา (ที่ต้องเป็นที่รู้จักกันดี เพราะจะช่วยให้สื่อสารง่าย ไม่ใช่รู้จักอยู่คนเดียว หรือเป็นโซลูชั่นที่คิดเองเออเอง ไม่มีที่อ้างอิง)
  • โมดูลที่สร้าง (produce) ข้อมูล กับโมดูลที่ใช้ (consume) ข้อมูล ควรแยกออกจากกันให้ชัดเจน เพื่อลดปัญหาเวลาต้องปรับปรุงแก้ไข และยังช่วยในการจัดการ performance ของระบบ
  • ในสภาพแวดล้อมระบบที่มีการประมวลผลแบบ Parallel หรือเป็นระบบที่มี multi-process หรือ multi-thread จำนวนมากและซับซ้อน ซึ่งมักเป็นระบบที่มี concurrent access สูงๆ ควรอธิบาย process view ให้ชัดเจน เพื่อใช้วิเคราะห์ process และ thread ของการทำงาน
  • task หรือ process ควรระบุภาระหน้าที่ที่ชัดเจนว่ามีการใช้ processor ใดบ้าง เพื่อให้ง่ายต่อการเปลี่ยนแปลง เช่น ในช่วง Runtime กรณีนี้มักพบกับระบบที่ออกแบบให้ทำงานกับฮาร์ดแวร์ที่มีหลาย processor
  • ควรอธิบาย process หลักของการทำงานของระบบด้วยแบบจำลองง่ายๆ สัก 1 รูปก็พอ เพื่อให้เห็นกระบวนการทำงานหลักของระบบว่า flow อย่างไร โดยใช้เป็น pattern หลักของระบบ โดยมีสมมติฐานคืองานในส่วนต่างๆ ก็จะมีขั้นตอนไม่ต่างกันมากนัก มีประโยชน์เพื่อช่วยให้เห็นภาพรวมของ flow การทำงานของระบบในภาพรวม
Advertisements

ใส่ความเห็น

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