Screen Shot 2557-11-11 at 5.50.23 PM
บทความที่น่าสนใจซึ่งพี่ @roofimon ทำการ share มาที่ facebook
[fb_embed_post href=”https://www.facebook.com/roofimon.class/posts/10152385785767047/” width=”550″/]

ดังนั้นในฐานะที่เป็น developer คนหนึ่ง จึงต้องทำการศึกษาหน่อยว่า มันคืออะไร
มีความน่าสนใจอย่างไร เพื่อจะได้ไม่ตกกระแส
และทำให้เข้าใจว่ามันเกิดขึ้นมาเพื่อแก้ไข หรือ ช่วยอะไรเราบ้าง

ทำความรู้จัก

คำที่มักได้ยินก็คือ MVP (Minimum Viable Product)
ช่วยให้สามารถเลือกได้ว่า จะต้องทำอะไรที่สำคัญและมีคุณค่าก่อน
เพื่อส่งมอบให้ลูกค้าหรือผู้ใช้งานให้รวดเร็วที่สุด
ทำให้ลดทั้งเวลาในการพัฒนา และ ค่าใช้จ่ายที่ต้องลงทุนไป

แต่สิ่งหนึ่งที่ต้องให้ความสนใจไม่น้อยกว่า MVP
นั่นคือเรื่องของ Architecture ที่จะต้องมีเท่าที่จำเป็นเท่านั้น
ซึ่งถูกเรียกว่า Minimal Viable Architecture (MVA)

เนื่องจากจะพัฒนา MVP ได้รวดเร็วได้อย่างไร
ถ้า architecture มันซับซ้อนตั้งแต่เริ่มต้น !!

แล้วทำไมต้องให้ความสำคัญด้วยล่ะ ?

เนื่องจากปัญหาที่มักพบเจอมากๆ สำหรับการพัฒนา product ที่เลือกมาจาก MVP นั้น
คือ การเลือก architecture ที่ไม่เหมาะสม

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

ดังนั้น เราต้องสร้างความสมดุลระหว่าง speed to market และ architecture ของระบบงาน
นั่นคือเราต้องการ Minimal Viable Architecture (MVA) นั่นเอง

จาก blog เรื่อง Minimum Viable Architecture ได้ทำการแนะนำคำถาม
เพื่อใช้สอบถามเจ้าของ requirement หรือ Product Owner
เพื่อช่วยทีม และ architect  เตรียม MVA ได้ง่ายขึ้น มีดังต่อไปนี้

  • เมื่อระบบเปิดใช้งาน คาดว่าจะมีผู้ใช้งานเท่าไร
  • เมื่อเปิดระบบไป 6 เดือน คาดว่าจะมีผู้ใช้งานเท่าไร
  • เมื่อเปิดระบบไป 1 ปี คาดว่าจะมีผู้ใช้งานเท่าไร
  • คาดว่าจำนวน transaction ต่อ วินาที จะเป็นเท่าไร เมื่อทำการเปิดตัว ภายใน 6 เดือน หรือ 1 ปี
  • ระดับของความปลอดภัยที่ต้องการของระบบ

คำถามเหล่านี้เพื่อช่วยให้ทีมพัฒนาไม่ต้องไปทำอะไรมัน over เกินไป
หรืออาจจะเรียกว่า Over-engineering ตั้งแต่แรก
เนื่องจากการสร้างระบบที่มัน perfect ตั้งแต่แรกก็ไม่ใช่ทางที่ดีนัก !!

ตัวอย่างเช่น
เมื่อทำการพูดคุยรายละเอียดเรื่องจำนวนผู้ใช้งานแล้ว อาจจะได้ว่า
ในช่วงเดือนแรกมีผู้ใช้งานจากภายในเท่านั้น เพื่อทำการ setup ระบบต่างๆ
ช่วง 3 เดือนเริ่มให้ผู้ใช้งานกลุ่มแรกเข้ามาใช้งาน
ช่วง 6 เดือนทำการเปิดระบบให้ผู้ใช้งานทั่วไปใช้งาน

หรือจำนวน transaction การใช้งานจะค่อยๆ เพิ่มขึ้นในแต่ละเดือน
เช่น ใน ช่วงเดือนแรกจำนวน transaction จะยังน้อยมากๆ
แต่ในช่วง 3 เดือนจะสูงขึ้น
และในช่วง 6 เดือนจะสูงมากๆ

หรือในช่วงเดือนแรกคือ alpha release เพื่อทำการศึกษา และ เรียนรู้ ระบบและผู้ใช้งาน
ช่วง 3 เดือน เริ่มให้ผู้ใช้งานกลุ่มแรก เข้ามาใช้งานจริง
ช่วง 6 เดือน จึงเปิดให้ใช้งานทั้งหมด

หรือในช่วงเดือนแรกทาง IT จะเป็นฝ่ายเพิ่มข้อมูลผู้ใช้งานแบบ manual
ช่วง 3 เดือน เริ่มมี user interface สำหรับให้ฝ่าย operation ทำการเพิ่มผู้ใช้งานได้
ช่วง 6 เดือน ผู้ใช้งานสามารถสมัคร และ เพิ่มข้อมูลได้เอง

หรือในช่วงเดือนแรก อาจจะมีเรื่อง security บ้างแต่ยังไม่มาก (Basic security)
ช่วง 3 เดือนทำการเน้น security ในทุกๆ ส่วน
ช่วง 6 เดือนทำการ audit ระบบ security

จากคำตอบเหล่านี้ มันทำให้เรารู้ว่า
ในช่วงแรกๆ นั้นควรทำอะไรก่อน เน้นอะไร นั่นคือ สนใจการส่งมอบงานให้รวดเร็ว (time to market)
เพื่อสร้างความเชื่อมั่นของฝ่าย IT กับทางฝ่าย business
เมื่อมีความเชื่อมั่นซึ่งกันและกันแล้ว ต่อจากนั้นจึงเริ่มพัฒนาในส่วนอื่นๆ ต่อไปจะง่ายขึ้น

ลองคิดดูว่า ถ้าฝ่ายพัฒนา หรือ IT ไม่สามารถส่งมอบได้ตรงตามเวลา
เพราะว่า ติดปัญหาภายในกันเอง เช่น Architecture ของระบบยังไม่ดีพอ
แล้วอะไรจะเกิดขึ้น หนึ่งในนั้นคือ ความเชื่อมั่น และ ไว้ใจ ไม่มีเลย

ดังนั้น MVA จึงมีความสำคัญขึ้นมา พอสมควรนะ

หัวใจของ Minimum Viable Architecture ประกอบไปด้วย

  • YAGNI (You Ain’t Going to Need It) ทำเท่าที่จำเป็นเท่านั้น
  • เลือกใช้เครื่องมือให้เหมาะสมกับงาน และ ถูกที่ถูกเวลา
  • การเปลี่ยนแปลงต้องเกิดขึ้นตลอดเวลา แต่เป็นแบบเล็กๆ ไปเรื่อยๆ

เมื่อนำไปเทียบกับ phase ทำการงานของ Startup แล้วเป็นดังนี้

  • Search  คือ การทำ prototype ของ architecture ที่จะนำมาใช้งาน มีเป้าหมายเพื่อหาสิ่งที่สร้างได้อย่างรวดเร็ว ในราคาที่สมเหตุสมผล
  • Execution คือ การตรวจสอบเพื่อทำให้แน่ใจว่า architecture นั้นมันเพียงพอต่อความต้องการอันใกล้ และสามารถปรับปรุงไปตามความต้องการได้ นั่นคือ Just Enough Architecture นั่นเอง
  • Scaling เป้าหมายเพื่อให้สามารถรองรับการขยายตัวของธุรกิจได้ ซึ่งประกอบไปด้วย ทีม เทคโนโลยี และ ประสิทธิภาพการรองรับผู้ใช้งาน ซึ่งทำแบบค่อยเป็นค่อยไป ไม่ใช่ทำทุกอย่างเผื่อไว้ทั้งหมด ไม่ใช่เพียงให้ความสนใจกับเรื่องเทคโนโลยีอย่างเดียวนะ

สิ่งที่น่าสนใจ คือ Execution phase

คือ Just Enough Architecture มีลักษณะดังนี้

  • Modularity หรือ Monolithic Architecture ซึ่งทำให้ง่ายต่อการเพิ่มหรือลดความสามารถของระบบงาน
  • มีระบบ logging ทั้งในแง่ของพฤติกรรมการใช้งานของผู้ใช้งาน และ monitoring ของระบบ
  • มีระบบ Continuous Delivery เพื่อให้สามารถ deploy ระบบงานได้บ่อยตามที่ต้องการ

ซึ่งมี infrastructure ที่พอเพียงกับความต้องการ
และจำเป็นต้องมีระบบ Continuous Delivery
เพื่อให้สามารถ deploy ระบบงานได้บ่อยตามที่ต้องการ
โดย architecture แบบนี้มันมีข้อดีดังนี้

  • เริ่มต้นด้วยความเรียบง่าย อย่าเยอะ
  • ทำแบบค่อยเป็นค่อยไป
  • Single codebase และ ทำการ deploy แบบย่อยๆ หรือเป็นส่วนเล็กๆ ได้
  • ใช้งาน resource ต่างๆ อย่างมีประสิทธิภาพ

ง่ายๆ ลองกลับไปดูว่าระบบที่คุณพัฒนาหรือดูแลอยู่ว่าเป็นอย่างไร ?

ถ้าระบบของคุณมีลักษณะดังต่อไปนี้ ก็น่าจะได้เวลาปรับเปลี่ยน หรือ ปรับปรุงนะครับ

  • ในการขยายระบบ มีส่วนที่เกี่ยวข้องจำนวนมาก นั่นคือ overhead ที่เสียไป ทั้งเวลาและค่าใช้จ่าย
  • ระบบไร้ซึ่งความเป็น modularity นั่นคือระบบผูกกันไปหมด
  • แย่ต่อการขยายระบบ ส่วนใหญ่มักจะทำแบบ vertical เป็นหลัก
  • ใช้เวลาในการ deploy ระบบงานนานมาก ทั้งการ rollout และ rollback
  • ใช้เวลาในการ build นานมาก

และทางคุณ Martin Fowler ก็ได้เขียนเกี่ยวกับแนวคิดของ Sacrificial Architecture
ซึ่งมันยังคงอยู่ในบริบทของ Just Enough Architecture นั่นก็คือ

The best code you can write now is the code you will discard in a couple of years time.

แปลได้ว่า code ที่คุณคิดว่ามันสุดยอดในตอนนี้ มันอาจจะถูกเลิกใช้ไปในเวลา 1-2 ปีเท่านั้น

โดยสรุปแล้ว

การสร้างระบบที่ perfect ตั้งแต่ต้นนั้นมันไม่น่าจะเป็นแนวทางที่ถูกต้องมากนัก
ดังนั้น อย่าพยายามสร้างและออกแบบ architecture ของระบบที่มัน over หรือเผื่อมากเกินไป

สิ่งที่บอกว่า architecture คุณดีพอ
นั่นก็คือ คุณสามารถที่จะ re-architecture ได้ง่าย
ทั้งการเพิ่มและลดขนาดลงมาตามความต้องการ

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

ปิดท้ายด้วยภาพขำๆ เกี่ยวกับ Architect ครับ
architecture

Reference Websites
http://www.infoq.com/news/2014/11/minimum-viable-architecture
http://www.kavistechnology.com/blog/minimal-viable-architecture/
http://www.slideshare.net/RandyShoup/minimum-viable-architecture-good-enough-is-good-enough-in-a-startup
http://www.slideshare.net/johnb/minimum-viable-architecture-for-web-apps