בתחום התשתיות אנו רואים לעתים קרובות מדי מגוון אינסופי של רכיבים. לדוגמה, יכול להיות שרת עבור יישום ERP (עם זיכרון, CPU ומאפייני קלט/פלט משלו), שרת ייעודי עבורBI, וכן הלאה. זה נכון גם לגבי התהליכים הקשורים לרכיבי תשתית אלה. לדוגמה, למשתמשים יש לעתים קרובות מדיניות גיבוי אחת לניהול קשרי לקוחות (CRM), ומדיניות גיבוי שונה עבוד סביבת יישומי ה-Web שלהם, כמו גם דרך ייעודית לטיפול בדרישות מנהלן מסדי הנתונים למערכות שונות.
אנו מאמינים כי כפי שארגוןIT מיישם עקרונות SOA בתחום העסקי והיישומי, כך הוא חייב גם ליישם תפישות SOA בתחום התשתיות. ארגונים צריכים להגדיר שירותים מכל אחד מתחומי התשתית (אחסון/גיבוי, מיחשוב/שרתים, DBMS, וכו') ולעשות ככל הניתן שימוש חוזר בשירותים אלה.
לדוגמה, בתחום המיחשוב/שרתים, צריכים ארגוני תשתית להגדיר שירותים כמו "שרת ברמת כניסה", "שרת בינוני באשכול", ו"שרת קצה עליון", וכן הלאה. השירות המוגדר צריך לכלול גם את ה"כוח" של השרת (בסיסית מתייחס למספר המעבדים), כמו גם למערכות ההפעלה הנתמכות, תוכנות, ותהליכים נלווים כמו התקנה, החלפת השרת בעת השבתה, ועדכון טלאי אבטחה. במילים אחרות, השירות צריך לכלול SLA (הסכם רמת שירות) מלא הקשור לצרכי מיחשוב/שרת. בדרך זו, כאשר מוכנסת לשימוש מערכת חדשה, רק שירותי מיחשוב/שרת המוגדרים ישמשו לבניית תשתית היישום החדש.
כמו בתחום היישומים/שירותים עסקיים, יישום עקרונות ה-SOA בתחום התשתית יאפשר שימוש חוזר בטכנולוגיה, תהליכים, ואנשים.
משתמשים עשויים לטעון כי עקרונות אלה עלולים לגרום בזבוז מסוים, מאחר שפרויקטים לעתים יקבלו (וישלמו עבור) SLA טוב יותר מכפי שהם דורשים.
לדוגמה, אם יישום דורש אחסון ברמת ביניים עם תכנון התאוששות מאסונות (DRP), אך DRP קיים רק באופציית אחסון קצה-עליון, הרי פרויקט זה ישתמש באחסון קצה עליון היקר יותר עם DRP. בטווח הארוך, היצמדות לשירותים המוגדרים תהיה בעלת יחס עלות/תועלת גבוה לארגון, מאחר שהוספת שירות חדש דורשת לא רק טכנולוגיה שונה, אלא גם תהליכים וכישורים שונים.
בשורה התחתונה: משתמשים צריכים ליישם היום עקרונות SOA לתחום התשתית, כדי להפחית עלות בעלות כוללת ולזכות בזריזות וגמישות רבה יותר לטווח ארוך.
