สถาปนิกและนักพัฒนาต่างดิ้นรนกับแนวคิดเรื่องความเป็นโมดูล (modularity) มาเป็นเวลานาน ดังจะเห็นได้จากคำกล่าวใน Composite/Structured Design (Van Nostrand Reinhold, 1978):
คำพูด 95% [ที่เขียนเกี่ยวกับสถาปัตยกรรมซอฟต์แวร์] ล้วนเป็นการยกย่องประโยชน์ของ “ความเป็นโมดูล” แต่แทบไม่มีใครพูดถึงวิธีการทำให้มันเกิดขึ้นจริงเลย
Glenford J. Myers
แต่ละแพลตฟอร์มมีกลไกการใช้โค้ดซ้ำ (reuse) ที่แตกต่างกัน แต่ทุกแพลตฟอร์มล้วนรองรับวิธีจัดกลุ่มโค้ดที่เกี่ยวข้องกันไว้ด้วยกันในรูปแบบ module แม้แนวคิดนี้จะเป็นสากลในโลกของสถาปัตยกรรมซอฟต์แวร์ แต่กลับพิสูจน์แล้วว่านิยามได้ยากอย่างน่าประหลาด การค้นหาแบบผ่าน ๆ บนอินเทอร์เน็ตจะให้นิยามนับสิบแบบ ซึ่งไม่สอดคล้องกัน (และบางนิยามยังขัดแย้งกันเองด้วยซ้ำ) นี่ไม่ใช่ปัญหาใหม่แต่อย่างใด อย่างไรก็ตาม เนื่องจากยังไม่มีนิยามที่เป็นที่ยอมรับกันทั่วไป เราจึงต้องกระโดดเข้าไปในสมรภูมินี้และกำหนดนิยามของเราเองเพื่อความสอดคล้องกันตลอดทั้งเล่ม
การเข้าใจความเป็นโมดูลและรูปแบบต่าง ๆ ของมันในแพลตฟอร์มการพัฒนาที่เลือกใช้เป็นเรื่องสำคัญมากสำหรับสถาปนิก เครื่องมือหลายอย่างที่เราใช้วิเคราะห์สถาปัตยกรรม (เช่น metrics, fitness function และการทำ visualization) ล้วนพึ่งพาความเป็นโมดูลและแนวคิดที่เกี่ยวข้อง Modularity คือหลักการจัดระเบียบ (organizing principle) หากสถาปนิกออกแบบระบบโดยไม่ใส่ใจว่าชิ้นส่วนต่าง ๆ จะเชื่อมต่อกันอย่างไร ระบบนั้นจะเผชิญปัญหามากมาย หากเปรียบเทียบกับหลักฟิสิกส์ ระบบซอฟต์แวร์จำลองระบบที่ซับซ้อน ซึ่งมีแนวโน้มจะเข้าสู่ภาวะเอนโทรปี (หรือความไร้ระเบียบ) ในระบบทางกายภาพ จำเป็นต้องเติมพลังงานเข้าไปเพื่อรักษาความเป็นระเบียบ ระบบซอฟต์แวร์ก็เช่นกัน สถาปนิกต้องคอยทุ่มเทพลังงานอย่างต่อเนื่องเพื่อรักษาความมั่นคงเชิงโครงสร้าง เพราะสิ่งนี้จะไม่เกิดขึ้นเองโดยบังเอิญ
การรักษาความเป็นโมดูลที่ดีคือตัวอย่างชั้นเยี่ยมของสิ่งที่เรานิยามว่าเป็นคุณลักษณะสถาปัตยกรรมแบบ implicit แทบไม่มีข้อกำหนดของโปรเจกต์ใดที่ระบุตรง ๆ ให้สถาปนิกต้องรับประกันการแบ่งแยกและการสื่อสารระหว่างโมดูลที่ดี แต่โค้ดเบสที่ยั่งยืนก็ต้องอาศัยความเป็นระเบียบและความสม่ำเสมอที่สิ่งนี้นำมาให้