בכדי להבין מדוע ארכיטקטורה מונחית עצמים כה פופולרית, 30 שנה לאחר שהוצגה לראשונה, צריך להבין את הבעיות שמולם ניצבים ארגוני תוכנה שונים.
ראשית, תוכנה היא קשה לפיתוח, שינויים ואחזקה.
שנית, רוב התוכנות יוצאות לשוק מאוחר מהמתוכנן ובעלויות גבוהות מהתקציב שיועד להם במקור. בנוסף, מפתחים עדיין נאלצים ליצור תוכנה מהבסיס, מכיוון שלא קיים שימוש מחדש לקוד כתוב.
לאור הקשיים הללו, ארגונים מוכנים לנסות למצוא גישה אחרת של פיתוח שתהיה יעילה יותר מבחינה כלכלית, כלומר שתצא לשוק בזמן וכך תקנה להם יתרון על המתחרים ע"י הספקת המוצר מהר יותר. בנוסף, הם נזקקים ליכולת להתמודד במהירות עם שינויים שנדרשים בתוכנה כתוצאה משינוי בדרישת הלקוחות, ושינויים והתפתחויות בעולם התוכנה.
גישה אחת שנוסתה כדי להתמודד עם הבעיות הללו היא גישת התכנות המובנה (structured programming). התכנות המובנה השתמש בגישה שנקראת "מלמעלה למטה" (top down), כלומר, פירוק התוכנית לרכיבים עד אשר הרכיבים לא ניתנים יותר לפירוק. גישה זו יצרה שיפור גדול מבחינת איכות התוכנה, אולם יצרה גם בעיות אחרות לדוגמא: העובדה שבגישה זו רק לעיתים נדירות ניתן לחזות איך מערכת תעבוד ללא מימוש המערכת ממש, וחשוב מכל במקרה שנמצאה שגיאה בתוכנית לאחר שהתכנות החל אז עיצוב התוכנית עצמו יאלץ להיות משוחזר מהבסיס וזה עולה זמן וכסף.
ההבדל בין תכנות מובנה לתכנות מונחה עצמים היא בצורה שבה נשמרים הפונקציות והעצמים. בעוד שבתכנות המובנה הפונקציות והנתונים מופרדים, לרוב כל הנתונים ממוקמים לפני כל הפונקציות בצורה שבה קשה לדעת אילו נתונים עובדים אם אילו פונקציות. בתכנות מונחה עצמים הנתונים והפונקציות הקשורים לאובייקט כלשהו ממוקמים יחד ביחידה אחת.
בגישת התכנות מונחה העצמים עיצוב המערכת ניתן לשינויים בשלב מאוחר יותר .כל בעיה בעיצוב התוכנה יכולה להיות מתוקנת בשלב זה, ללא הצורך להתחיל בתכנות מחדש.
בנוסף, אנשים יכולים להבין בקלות רבה יותר את המערכת כאובייקטים מאשר כפרוצדורות, מכיוון שצורת החשיבה האנושית היא חשיבה בצורת אובייקטים.
לדוגמא, אנשים רואים מכונית כמערכת עם מנוע, מיכל דלק, גלגלים וכו', ולא רואים אותה כסדרת פעולות הגורמת לה לנסוע.