วันนี้ได้รับคำถามเกี่ยวกับ Enterprise Architecture ในโลกของ Agile
ว่ามันอยู่ร่วมกันได้ไหม
ถ้าอยู่ได้ มันจะอยู่ร่วมกันอย่างไร พร้อมยกตัวอย่าง
ส่วนตัวผมก็ไม่ได้มีประสบการณ์ในเรื่องนี้เลย
แต่ก็ลองหาข้อมูลเพิ่มเติม รวมกับเอาเรื่องของ
manifesto และ principle ของ Agile เป็นตัวตั้งก็แล้วกัน
เริ่มต้นหาข้อมูล
เอกสารที่น่าอ่านคือ Who need architect ? ของคุณ Martin Fowler
และข้อมูลที่น่าสนใจก็คือ บทความเรื่อง Agile Architecture Applied จาก InfoQ
ได้พูดถึงเรื่องการประยุกต์เรื่อง Architecture เข้ากับโลกของ Agile
ซึ่งผมทำการสรุปแบบคร่าวๆ ได้ดังนี้
Agile นั้นเน้นเรื่องการปรับตัวเข้ากับบริบทต่างๆ ได้รวดเร็วและการพูดคุยกัน
โดยแนวคิดของ Agile มาจากปัญหาในเรื่องของ Planing Driven Development คือ
ก่อนที่จะทำอะไรก็ตาม จะต้องทำการวางแผนให้ครบและเรียบร้อยเสมอ
ซึ่งมันคือการแยกการวางแผนงาน และ การลงมือทำงาน ออกจากกัน
พูดง่ายๆ ก็คือ ต้องมี specification ของ requirement ทั้งหมดที่ชัดเจนและไม่มีการเปลี่ยนแปลง
นั่นก็หมายถึง Architecture ต่างๆ ของระบบงานนั้นก็มีการวางแผน และออกแบบ ไว้พร้อมแล้ว
แต่ยังไม่ลงมือทำนะ …
ลองคิดดูว่า ถ้าวางแผนงานไว้เป็นปีๆ
ระหว่างนั้น ความต้องการของลูกค้าจะไม่มีการเปลี่ยนเลยหรือ ?
ระหว่างนั้น ทีมพัฒนาหาวิธีการสร้างมันขึ้นมา คิดว่ามันจะเปลี่ยนไหม ?
คิดไหมว่าโลกรอบๆ ตัวมันมีการเปลี่ยนแปลงไปไหม ?
ถ้าตอบว่า ไม่มีการเปลี่ยนแปลง … ก็ปิดบทความนี้ไปได้เลย !!!
ก่อนอื่น เข้าใจกันก่อนว่า Architecture นั้นไม่ใช้เครื่องมือ หรือ framework อะไร แต่มันคือ
การทำงานร่วมกันของทีมต่างๆ
การทำงานร่วมกันของ component ต่างๆ
โดย Architecture ที่ดี จะกำหนด role และหน้าที่ความรับผิดชอบของแต่ละ component ไว้เสมอ
แต่ Architecture ที่ดีกว่านั้น คือ การออกแบบให้แต่ละ component สามารถเปลี่ยนได้ง่าย ด้วยค่าใช้จ่ายที่ต่ำ
แน่นอนว่าเรื่อง technical practice ต่างๆ ย่อมมีความจำเป็น แต่มักถูกมองข้ามไป
แล้วในโลกของ Agile มันแตกต่างไปอย่างไร ?
แนวคิดของ Agile นั้นจะไม่ทำการออกแบบ หรือ วางโครงสร้าง แบบใหญ่ๆ หรือ ทั้งหมด ในครั้งเดียว ( Big Design Up Front )
แต่ไม่ได้หมายความว่า Architcture ไม่มีความสำคัญนะ
มันยังสำคัญอยู่เสมอ เนื่องจากในอนาคตระบบยังต้องการความเสถียร
เพื่อรองรับสิ่งต่างๆ ที่จะเข้ามาเสมอ
แล้วเราจะออกแบบ Architecture ไว้เท่าไรดี ถึงจะไม่เรียกว่า ใหญ่ไป หรือ up-front เกินไป
คำตอบคือ แล้วแต่ระบบ ซึ่งมันต้องเพียงพอสำหรับสิ่งที่กำลังทำอยู่หรือไม่
คำว่าเพียงพอนั้นมันอธิบายยาก เนื่องจากในแต่ละบริบทมันแตกต่างกัน
ลองมองย้อนกลับไปว่า ลูกค้าของคุณต้องการการวางแผนที่สมบูรณ์แบบ
หรือว่าต้องการ working software ที่ช่วยทำให้ธุรกิจขับเคลื่อนไปได้
ถ้าตอบว่า ต้องการการวางแผนที่สมบูรณ์แบบ … ก็ปิดบทความนี้ไปได้เลย !!!
ในโลกของการพัฒนา Software ประกอบด้วย 2 ส่วน คือ
1. Build the right thing
คือ การสร้าง software ที่ใช่ ตรงกับสิ่งที่ลูกค้าต้องการ อาจจะรู้หรือไม่รู้ก็ตาม
ซึ่งในปัจจุบันมีวิธีการมากมาย เพื่อหาสิ่งที่ใช่ เช่น Product discovery, Story mapping เป็นต้น
2. Build the thing right
คือ การสรา้ง software ด้วยวิธีการที่ถูกต้อง ซึ่งแน่นอนว่า การวางและออกแบบ Architecture
ให้กับ software จะช่วยทำให้เราสร้างมันขึ้นมาได้อย่างถูกต้อง
แต่เราจะรู้ได้อย่างไรว่า Architecture ที่ออกแบบมานั้นมันใช่หรือไม่
คำตอบเดียวก็คือ ลงมือทำ แล้วให้ code มันบอกเองว่าใช่หรือไม่
Architecture มันจะมาจากไหนได้บ้าง ?
Test-Driven Development (TDD)
ในปัจจุบันเริ่มนิยมนำเอาแนวคิด TDD มาใช้ประโยชน์ สำหรับการออกแบบ code ที่จะเขียน
และจะมีประโยชน์มากถ้าคิดแบบ outside-in
การทดสอบต่างๆ มันช่วยทำให้เรา refactoring code ได้อย่างมั่นใจ
นั่นคือแสดงว่า code ที่เราเขียนขึ้นมา มันพร้อมรับต่อการเปลี่ยนแปลงต่างๆ
ถ้า code เขียนมาดีแล้ว เข้าใจง่าย อ่านได้ เรียนรู้ง่าย
ซึ่งแต่ละคนในทีมมีความเข้าใจเป็นอย่างดีเริ่มเกี่ยวกับ code ของระบบ
คำถาม แล้วภาพใหญ่หรือภาพรวมของระบบงานล่ะ ไม่จำเป็นต้องรู้หรือไง ?
คำตอบ ต้องมีสิ
คำถาม ดังนั้นเราต้องเขียนเอกสารเพื่ออธิบายภาพรวมของระบบนะสิ ?
คำตอบ ใช่แล้ว แต่ …
การเขียนเอกสาร คือ การอธิบายโครงสร้างการทำงานจริงๆ ของระบบ
ดังนั้นควรต้องลงในรายละเอียดระดับ code เลยว่าเขียนมาอย่างไร และทำงานอย่างไร
โดยรูปแบบทีมจะต้องตกลงกันเองว่าให้อยู่รูปแบบไหน
เพื่อให้ทุกคนในทีม เข้าใจเหมือนๆ กัน
ไม่เช่นนั้นเอกสารที่สร้างขึ้นมาจะไม่มีประโยชน์ใดๆ เลย
วิธีการที่ในบทความเข้าแนะนำ และ ผมก็ใช้ประจำ ก็คือ
การวาดภาพลองใน whiteboard ซึ่งทุกคนในทีมสามารถเขียนและแก้ไขได้
ตามความเหมาะสมตามสิ่งที่ทำและเทคโนโลยีที่ใช้
ดังนั้น TDD มันเป็นแนวคิดที่ช่วยกำหนดกรอบในการออกแบบในแต่ละส่วน
แต่ Architecture นั้นช่วยให้เราเห็นว่าสุขภาพของระบบเป็นอย่างไร
ดังนั้นมันจะต้องไปด้วยกันเสมอ โดย code ที่เกิดขึ้นมา มันจะบอกเองว่า
Architecture ที่ออกแบบมานั้นมันเหมาะสมหรือไม่
Simplicity
จาก Agile principle ข้อ 10
Simplicity–the art of maximizing the amount of work not done–is essential.
คำว่า Simplicity หรือว่า ความเรียบง่าย มันหมายถึง
ในทุกๆ ส่วน มันสามารถทำความเข้าใจได้ง่าย
ตั้งแต่การออกแบบ Architecture ไปจนถึงการเขียน code
Software ที่เรียบง่าย คือ Software ที่พร้อมรับต่อการเปลี่ยนแปลง
Emergence
เป็นแนวปฏิบัติใน Agile ที่มักก่อให้เกิดความเข้าใจผิดว่า
ไม่ต้องการ Architecture อีกต่อไป
Agile principle ข้อ 11
The best architectures, requirements, and designs emerge from self-organizing teams.
คำว่า Emergence นั้นสามารถอธิบายแบบง่ายได้ดังนี้
การทำงานเป็นทีม
ซึ่ง Architecture คือ กิจกรรมหนึ่งของทีม เพื่อแบ่งปันความรู้ซึ่งกันและในภายในทีม
มันไม่ใช่เอกสารที่ส่งมาจากทีมที่ถูกเรียกว่า อยู่บนหอคอยงาช้าง …
คุณลักษณะของ Emergent ที่สำคัญก็คือ มันไม่สามารถระบุได้ว่าจะเกิดตรงไหน
แต่ว่ามันจะส่งผลกระทบต่อทุกๆ ส่วนของระบบ
ยกตัวอย่างเช่น
น้ำ มันจะไม่ใช่ของเหลว ถ้าเอาโมเลกุลออกไป
โดยแต่ละโมเลกุล มันไม่ใช่ของเหลว
แต่เมื่อรวมกันเป็นน้ำ มันคือของเหลวซะงั้น
ดังนั้น Emergent architecture จะเกิดขึ้นไม่ได้ถ้าไม่ทำงานเป็นทีม
จะไม่มีเพียง architect หน่วยงานเดียวที่ตัดสินใจเรื่องของ Architecture
Architect จะเป็นส่วนที่สนับสนุนการทำงานของทีมให้เป็นไปอย่างดี
ไม่ใช่เป็นส่วนที่กำหนด Architecture เพื่อให้ทีมทำตามนั้น
ดังนั้นไม่จำเป็นต้องออกแบบมาให้ perfect เนื่องจากมันจะดีหรือไม่นั้น
จำเป็นต้องให้ทีมเป็นคนพิสูจน์ ดังนั้นลงมือทำซะเถอะ ( ทั้งทีมและ Architect มา coding เพื่อดูว่ามันดีไหมและเขียนอย่างไรกัน )
ดังนั้น Agile มันเข้ามาพร้อมกับแนวคิดของคนที่ต้องเปลี่ยนไป
เน้นเรื่องของการทำงานร่วมกันของคน
สุดท้ายสิ่งที่สำคัญมากๆ คือ การลงมือทำ และการเรียนรู้จากสิ่งที่ทำ
จากบทความ ดังกล่าว ยก Convey law มาอธิบาย คือ
โครงสร้างของระบบที่ถูกออกแบบมานั้น
มันสะท้อนถึงโครงสร้างขององค์กร และ ข้อจำกัดต่างๆ ที่คุณเผชิญอยู่
ซึ่งทำให้เกิด principle ต่างๆ ในการออกแบบระบบ เพื่อแก้ไขปัญหาข้างต้น เช่น
Separation of concern, cohesion และ loose coupling เป็นต้น
เมื่อมีแนวคิด Agile เข้ามาได้เพิ่มเรื่อง ต่างเหล่านี้เข้ามา
- ทัศนคติเรื่องของการเปลี่ยนแปลง มันเป็นเรื่องธรรมชาติ แต่เราจะรับมืออย่างไร นั่นสำคัญกว่า
- ฝั่ง business และ ลูกค้า สามารถเข้ามาทดลองใช้งานก่อนได้
- การทำงานเป็นทีม ไม่แยกเป็น silo
- Emergence design
- Simplicity
- Working Software
ดังนั้น ลองเปลี่ยนแนวคิดในการเริ่มต้นให้ง่ายๆ เข้าไว้
เริ่มจากการมองในมุมของ developer ไม่ใช่ architect
แล้วลงมือทำจริงๆ และเรียนรู้จากสิ่งที่ทำ ว่าดีหรือไม่ดีอย่างไร
แล้วปรับเปลี่ยนไปเรื่อยๆ เพื่อทำให้ดีขึ้นอยู่เสมอ
Agile นั้นต้องการให้เปิดทางเลือกต่างๆ ไว้เสมอ ไม่ใช่ทำการระบุเส้นทางไว้เพียง 1 หรือ 2 เส้นทางเท่านั้น
สุดท้ายสิ่งที่สำคัญ คือ การพร้อมรับกับการเปลี่ยนแปลงอยู่เสมอ และ การพูดคุยกันของทีมนะครับ …
