SOA (V2) ומפת"ח

מבוא

הרעיון המרכזי ב- SOA הוא בניית מערכות IT ממרכיבים (Components). תפיסה זו שונה מהותית מהתפיסה של בניית יישומים מונוליתיים גדולים (כלומר – בנויים ממקשה אחת), השלטת במערכות המחשוב בארבעים השנים האחרונות. הרכיבים הבסיסיים נקראים שירותים (Services). הארגון מייצר מאגר של שירותים ששילובם יוצר את היישום. באופן  תיאורטי, ניתן בתפיסה זו לבנות מערכות באמצעות איסוף שירותים. המערכות השונות נבדלות זו מזו בשירותים הנכללים בהן, בסדר ביצועם ובהתניות להפעלתם.

מרכיב חשוב נוסף בתפיסה התיאורטית הוא חיבור קל ופשוט בין השירותים על מנת שהרכבתם תעשה במאמץ קטן יחסית ולא תחייב פיתוח מנגנונים מורכבים של אינטגרציה. תיאורטית, החיבור בין השירותים אינו תלוי בשרת בו מתבצע השירות ובפלטפורמה הטכנולוגית בה הוא ממומש, כך שסביבת העבודה היא סביבה מבוזרת מרובת שרתים.

לבניית מערכות המבוססות על שירותים עשויים להיות יתרונות בגמישות וביכולת לעשות שימוש חוזר באותו רכיב במערכות שונות במקום לפתחו מחדש. במערכת בקלות יחסית,.

אנלוגיה פשטנית במקצת המבהירה את התפיסה היא שימוש באבני לגו. ניתן להרכיב מהן בקלות מגוון  של מבנים. קלות ההרכבה נובעת מהמודולאריות ומהאופן הקל והפשוט בו ניתן לחבר את האבנים. בעולם ה- SOA, השירותים הם המקביל לאבני הלגו, הממשקים התקניים הם המקביל לקלות החיבור והיישומים מקבילים למבנים.

הגדרות

SOA - Service Oriented Architecture

אין הגדרה אחת ל- SOA המקובלת על כלל תעשיית ה- IT. ההגדרה תלויה, בין השאר, בזוית הראיה של המגדיר, איש עסקים, ארכיטקט, מפתח תוכנה, איש תשתיות וכו'. עם זאת, רוב ההגדרות מסכימות עם האלמנטים המשותפים הבאים:

 ·         סגנון ארכיטקטוני המבוסס על שירותים

 ·         תפיסה ברמת הפשטה גבוהה או סגנון ארכיטקטוני. כלומר נדרש תרגום של התפיסה למרכיבים טכנולוגיים מעשיים.

 ·         ממשקים מתוכנתים.

 ·         הגדרת השירות כפי שהיא מופיעה בסמוך.

 ·         אי-תלות בין הממשק לשירות.

 ·         אוטונומיות של השירות, כלומר: אי-תלות בין שירותים.

שירות - Service

השירות הוא אבן הבניין היסודית של ארכיטקטורת SOA.  השירות הוא פונקציה מוגדרת היטב, מוכלת בעצמה (Self-Contained), שאינה תלויה במצבם ובהקשרם של שירותים אחרים.

המאפיינים העיקריים של שירות, המבחינים בינו לבין רכיבים במודלים מבוססי רכיבים קודמים (כגון: CBD ,CORBA, EJB,  COM/DCOM) שקדמו ל-  SOA, הם:

 ·         כל שירות ממוחשב  מייצג שירות עסקי, כלומר הגבולות של שירות מוגדרים ברמת המהות העסקית ולא ברמה טכנולוגית.

 ·         השירותים הם בעלי רזולוציה גסה (Coarse Grained).

 ·         הטווח הוא הארגון כולו (Enterprise) או הארגון הווירטואלי (Virtual Enterprise), העשוי לכלול גם שותפים עסקיים ובמקרים מסוימים גם את רשת האינטרנט העולמית(WWW)  בניגוד לתפיסות קודמות מבוססות רכיבים, שהטווח שלהן היה בתוך יישום ולא בארגון כולו.

תפיסת SOA אינה מחייבת ביצוע כל השירותים הנצרכים בשרתי הארגון. חלק מהשירותים עשויים להתבצע בשרתים של שותפים עסקיים או גורמים אחרים ב- Web.

 

צרכן שירות - Service Consumer

הצרכן (Consumer) הוא משתמש קצה או  שירות אחר המפעיל את השירות.

ממשק - Interface

הממשק מגדיר את אופן הקשירה (Binding) בין השירות לצרכן באמצעות חוזה (Contract). הממשק מאפשר אי-תלות בין הצרכן לבין המימוש של הפונקציונאליות בתוך השירות, כך שעבור הצרכן השירות הוא קופסא שחורה (Black Box).

פרסום - Publishing

על מנת שצרכנים יוכלו להפעיל שירותים, נדרש מנגנון של פרסום השירותים הזמינים. השאיפה היא להגיע למנגנונים אוטומטיים ככל האפשר באמצעותם ניתן לאתר ולהפעיל שירותים ישירות מקטלוג או מ- Repository.

תהליך - Process

בתפיסת SOA, תהליך בנוי משילוב (Orchestration) של שירותים. תהליך עשוי להתפרס על פני מספר מערכות. בתהליך עשויות להיכלל פעולות אוטומטיות של שילוב שירותים ממערכות שונות, אבל עשויות להיות גם פעולות ידניות. כך למשל תהליך של מתן משכנתא, עשוי לכלול אישורים ידניים של עורכי דין ותהליכים ידניים של החתמת ערבים. עם סיומם מסמן פקיד במערכת הממוחשבת את סיומה של הפעילות הידנית. תהליך בתפיסת SOA דומה לתהליך בתפיסה מקובלת של BPM או Workflow. השוני העיקרי הוא בכך שהיחידה הבסיסית בתהליך מבוסס SOA היא שירות, בעוד בתהליך BPM קלאסי לא בהכרח קיימת ישות בסיסית כזו המוגדרת מראש.

מושגי יסוד

סוגי שירותים

קיימים שלושה סוגי שירותים הכוללים לוגיקה עסקית:

 ·         שירות חדש - New Service

 ·         שירות עטוף - Wrapped Service

 ·         שירות מורכב - Composite Service

 

סוג נוסף של שירות הוא שירות מידע - Data Service. שירות זה אוסף מידע ממספר מקורות הטרוגניים והוא אינו כולל לוגיקה עסקית.

 

שירות חדש - New Service

שירות שפותח מראש כשירות, בדרך כלל בטכנולוגיות חדשות כגון: J2EE או Dot Net.  מבנה השירות החדש הוא פשוט: צרכן, שירות ובתווך ממשק של כל אחד מהם. אם נתבונן באיור הבא המתאר שירות עטוף ונתעלם מהחלק של ה Legacy  נוכל לראות תיאור גרפי של שירות חדש. חלק זה של האיור כולל את השירות (Service)  וממשק השירות (Service Interface) והצרכן(Consumer)  וממשק הצרכן (Consumer Interface) .

שירות עטוף - Wrapped Service

בניית שירותים מסוג זה מתבצעת באמצעות עיטוף פונקציונאליות קיימת והוספת ממשק. הכוונה היא בעיקר ל- Legacy, כגון: תכניות COBOL, אך גם ל- EJB, CORBA ולאובייקטים בסביבת מיקרוסופט. שירותים אלה צפויים להיות נפוצים בתקופה הקרובה בגלל קלות הקמתם. האיור הבא מתאר את המבנה של שירות עטוף:

 

שירות מורכב - Composite Service

מספר יישומים  המשולבים ביניהם. ניתן להפעילם באמצעות ממשק רצף של אפליקציות אלה. האפליקציות עשויות לכלול שירותים חדשים, יישומי Legacy ויישומים מוכנים (חלק מ- ERP או CRM למשל). ההפשטה (Abstraction) מאפשרת להסתיר את המורכבות של מספר אפליקציות המייצגות ביחד שירות.

קיימת אינטגרציה פנימית בין היישומים, שאינה בהכרח מבוססת SOA.

 השירות המורכב מתואר באיור הבא:

עקרונות עבודה

הרכבת יישומים

יישומים עסקיים מכווני שירותים (Service Oriented Business Applications) SOBAs הם יישומים הבנויים באופן המאפשר להם להתבצע תחת ארכיטקטורת SOA. הם מורכבים מאוסף שירותים. ה- SOBAs הם מימוש ארכיטקטורת ה-SOA בעולם האפליקציות.

עיקרון השימוש החוזר

אחת התועלת העיקריות במימוש ארכיטקטורת SOA היא השימוש החוזר (Reuse) באותו שירות או באותו תהליך ביישומים שונים. שימוש חוזר מונע כפילויות בפיתוח ובתחזוקה ומקצר את זמן הפיתוח.

ביזור

SOA היא ארכיטקטורה המתאימה לתפיסה מבוזרת. שירותים שונים עשויים להיות ממומשים בשרתים שונים בארגון ומחוצה לו.

ריבוי פלטפורמות שירות

ארכיטקטורת SOA מאפשרת לא רק ביזור השירותים, אלא גם ריבוי פלטפורמות תשתית. הממשק מאפשר לצרכן להיות אדיש לפלטפורמת השירות ולאופן בו ממומש בה השירות. תכונה זו עשויה להוות בסיס להחלפה או הרחבה של השירות באמצעות פונקציונאליות הממומשת בפלטפורמה שונה מהפלטפורמה המקורית בה יושם השירות.

ריבוי פלטפורמות צרכן

באופן דומה לריבוי פלטפורמות שרת ניתן לצרוך שירות מכל פלטפורמה או יחידת קצה. הקשר בין הממשק מצד הצרכן והממשק מצד השירות מאפשר מימוש קל יחסית של ריבוי פלטפורמות צרכן. כפי שצוין בהגדרת צרכן, בשונה מהמקובל בארכיטקטורת קודמות, צרכן הוא לא בהכרח ממשק משתמש, הוא עשוי להיות גם שירות אחר.

הארכיטקטורה

שכבות ארכיטקטוניות

הארכיטקטורה מורכבת ממספר מודלים הקשורים ביניהם:

 ·         ארכיטקטורה עסקית – מתארת את הישויות העסקיות

 ·         ארכיטקטורת מידע – מתארת מודל נתונים ארגוני

 ·         ארכיטקטורה יישומית – מתארת את הרכיבים היישומיים

 ·         ארכיטקטורה טכנולוגית – מתארת את התשתית למימוש הארכיטקטורה היישומית.

 

האיור הבא מתאר את השכבות הארכיטקטוניות השונות והקשרים ביניהן.

השכבה של תהליכים עסקיים (Business Processes) בנויה משירותים עסקיים (Business Services). שכבת ה- Business Services ממומשת באמצעות משאבי יישום, יישומים ממגוון סוגים, שירותים ונתונים. מנגנוני אינטגרציה ממפים ישויות אלה וצירופיהן לשירותים.

הארכיטקטורה העסקית

הארכיטקטורה העסקית מתארת את המודל העסקי של הארגון בכלים ממוחשבים. מרכיביה הם שירותים עסקיים (Business Services) ותהליכים עסקיים (Business Processes) המופיעים באיור לעיל. לארכיטקטורה העסקית שני מאפיינים מהותיים:

 ·         כל המונחים הם עסקיים. אין בה שימוש במונחים טכניים מתחום המחשוב.

 ·         רמת המורכבות שלה אינה גבוהה בדרך כלל.

 

שילוב של שני מאפיינים אלה מאפשר למשתמש עסקי, שאינו מיומן בתחום המחשוב להבין את הארכיטקטורה העסקית כשהשאיפה היא שהוא גם יבצע פעולות לשינוי והתאמת הארכיטקטורה, כגון בנייה או שינוי תהליכים והרכבת יישומים.

 

ארכיטקטורה מוכוונת אירועים ו-SOA2.0

ארכיטקטורה לטיפול באירועים

ארכיטקטורה מוכוונת ארועים - EDA  (Event Driven Architecture)

למענה ארכיטקטוני על דפוסי הפעילות העסקית של ארגונים, אין די בארכיטקטורה המבוססת על עיבוד סדרתי של שירותים (Services). במציאות מתרחשים אירועים  (Events) שטיפול בהם מחייב סגנון ארכיטקטוני אחר. אירועים הם בלתי צפויים. אינם נגזרים מבקשה לביצוע או מזמן שעבר מתחילת העבודה, עליהם מבוססות רוב המערכות היום. בעקבות הגלובליזציה, ה- Web והמחשוב הגדל של מערכות יש הרבה מידע על אירועים. ה- Business חייב להגיב עליהם, תחום ה-IT בתהליך התאמה לכך.

EDA היא תפיסה ארכיטקטונית המטפלת באירועים, המבוססת על המושגים והעקרונות הבאים:

 ·         אירוע הוא שינוי מצב במונחי מכונת מצבים

 ·         בשונה מ SOA ודפוסי אינטגרציה הזרימה היא חד-כיוונית

 ·         היחידה הבסיסית של הארכיטקטורה היא אירוע (Event)

 ·         לאירוע יש יצרן (Event Producer)  וצרכן (Event Consumer)

 ·          המנגנון לטיפול באירוע נקרא Event Handler

 ·         אירוע מעורר פעילויות. פעילויות עשויות להתבצע במקביל ולאו דווקא באופן סדרתי או במושגים של ארכיטקטורת מחשוב. הפעילויות הן Decoupled  ולא Loosely Coupled כמו ב- SOA.

 ·         אירוע עשוי להיות אירוע מורכב (Complex Event), כלומר שילוב של מספר אירועים .

 ·         ב- EDA עשויים להיות כל היחסים  האפשריים בין ה- Event Producer ל- Event Consumer 1:1, 1:M, M:1, M:M .

 ·         לאירוע יש ממשק בצד יצרן האירוע ובצד של ה- Event Handle.

SOA 2.0 - שילוב SOA ו- EDA

ארכיטקטורה המשלבת SOA ו- EDA מספקת מענה נאות יותר לצרכי ארגונים מאשר ארכיטקטורה המבוססת על SOA בלבד, כמתואר בשקף להלן.

בשקף ניתן לראות זרימה פשוטה של אובייקט אירוע והפעלה של שירותים (Services) כתוצאה מניתוח האירוע המבוצע ב-  Event handler.

הקשר בין אירועים ושירותים יכול להיות דו-כווני, אירוע עשוי להפעיל שירותים, כמתואר בשקף. במהלך ביצוע שירות, עשוי להתרחש אירוע.

Logical Unit Work עשויה להכיל בתוכה אירועים ושירותים, כשלכל אחד מהם Flow נפרד.

SOA Design Patterns

שימוש ב- Design Patterns נפוץ ומקובל בפיתוח תוכנה בסביבות תוכנה מודרניות. הרעיון הוא לעשות שימוש חוזר בתבניות פיתרון כלליות ומוכרות בעיצוב מערכת. השימוש בתבניות ידועות מראש מקצר את זמן הפיתוח. גם בהקשר של עיצוב פתרונות SOA, יש מקום לשימוש בתבניות כאלה.   SOA Design Patterns מתיחסות לבעיות ספיציפיות לעיצוב פיתרונות SOA.

כל Pattern מורכב מארבעה מאפיינים: שם, הבעיה, הפיתרון ומשמעויות הפיתרון.

כך למשל Proxy היא תבנית עיצוב SOA בה מטפלים במספר  מימושים (Implementations) שונים של ה- Service  ברמה הטכנולוגית.

בדוגמה לעיל לשירות של תביעה מחברת ביטוח קיימים שלושה מימושים שונים. התביעה בשלוש מחלקות שונות מסיבות היסטוריות. תבנית ה- Proxy מאפשרת לשירות להתבצע בכל אחת מהמחלקות באמצעות המימוש הקיים באותה מחלקה.

סוג אחר של Patterns בהם ניתן לעשות שימוש ב- SOA, הם Patterns תשתיתיים. הרעיון דומה, אבל ההקשר הוא של תבניות שונות של אינטגרציה בהם משתמשים במימוש מוצר ESB.

SOA ו- WOA

ההתאמה בין המחשוב לעסק ביחד עם הרכבת היישום משירותים, מעלות את השאלה מי ירכיב את היישום מאוסף השירותים?

האידיאל הוא שמשתמש עסקי ולא איש מחשוב יבצע את ההרכבה, אך אנחנו עדיין רחוקים ממצב זה. על מנת שמשתמש קצה יוכל לבצע הרכבה של יישום משירותים קיימים והתאמתו לתהליך העסקי, נדרשים פתרונות טכנולוגיים עם מורכבות נמוכה יותר.  Web 2.0 מהווה פוטנציאל למימוש חזון זה.

WOA (Web SOA) הוא שילוב של Web 2.0 ביחד עם SOA שעשוי לקרב אותנו לחזון זה. עם זאת, חשוב לזכור את ההבדל בהקשר - SOA הוא ארגוני, Web 2.0 הוא תופעה חברתית קהילתית. השילוב בין השניים מחייב לשים לב להיבטים המפורטים להלן.

 

Long Tail

ב- Web 2.0 יש יכולת בניה של אפליקציות אישיות באמצעות איסוף ושילוב של אפליקציות ונתונים. זאת בניגוד לתפיסה שקדמה ל- Web 2.0 בה אפליקציה מוכנה היוותה מוצר תוכנה ששווק כפי שהוא למספר גדול של משתמשים (למשל תוכנות Office או ERP). כתוצאה מכך נוצר מגוון רחב של הרכבות (Meshups) שונות מהאפליקציות הבסיסיות, כשכל צירוף שימש מספר קטן יחסית של צרכנים.

ב- Web 2.0 משתמש הקצה בונה אפליקציה באמצעות איסוף שירותים קיימים. חשוב לזכור כי בניגוד להקשר הארגוני ב- SOA, אין התחיבות של יוצרי השירותים לתמיכה במחזור חיים ובגרסאות עתידיות

RIA - Applications Rich Internet

RIA מיועד לספק למשתמשי האינטרנט סביבת Client עשירה מבחינה גראפית בדומה לסביבת ה- GUI המוכרת מעולם השרת/לקוח (Client/Server). מימוש RIA הוא באמצעות טכנולוגיות הנכללות ב- Web 2.0 דוגמת AJAX(Asynchronous JavaScript and XML).

כמו כן, ככל שחווית המשתמש של הצרכן הביתי בהקשר הקהילתי תהיה מבוססת יותר על RIA ועל טכנולוגיות ותפיסות של Web 2.0  יזדקקו ארגונים המספקים שירותים להתאים את ארכיטקטורת הצרכן המוצעת על ידם לתפיסת WOA.

 

תשתיות

ESB - Enterprise Service Bus

ESB הוא פלטפורמת תווכה Middleware)) למימוש אינטגרציה בתפיסת SOA. ניתן לראות בו מודל משופר של ה- Integration Broker המסורתי, כשהשיפור מתבטא בקלות מימוש ובהקטנת עלויות. ESB הוא אפיק מרכזי לאינטגרציה בדומה ל- Integration Broker המסורתי ב- EAI. המטרה של שניהם זהה, הקטנת המורכבות הגדולה של קשרי אינטגרציה בין נקודה לנקודה (Point to Point).

ה- ESB מבצע אינטגרציה בין שירותים ובין מסרי XML (מסרים מבוססי תקנים)  הפונקציונאליות הכלולה בו:

 ·          תווך (Mediation)

 ·         טרנספורמציות ומיפוי - שינוי פורמט הנתונים

 ·         העשרה (Enrichment) - הוספת נתונים

 ·         אגרגציה של נתונים

 ·         השמטה או פיצול של נתונים

 ·         הפנית המסרים (Routing) - ליעדים נוספים

 ·         התניות ובדיקות

 ·         טיפול באירועים (Events) הניזונים ממספר מקורות.

 ·         קישוריות (Connection)

 ·         העברת מסרים.

 ·         שליטה (Control)

 

שירותים נוספים, אינטגרטיביים עם שירותי התווכה (Middleware), כגון: טיפול באבטחת מידע ובניהול.

כתוצאה מיכולותיו אלה, ה- ESB עשוי להיות שידרה על גבה יתבצעו שירותים שהם Loosely Coupled.

בנוסף לכך ל- ESB יש יכולות אינטגרציה של מרכיבים באופן לא תקני באמצעות מתאמים (Adapters) ומסרים קנייניים כפי שמבצעים Integration Brokers מסורתיים.

 

Repository/Registry

כלי לרישום וניהול של ה- Services המיושמים בארגון. Repository מתייחס לרוב לשלב הפיתוח ו- Registry לזמן ההפעלה או הריצה של השירותים. חלק מהמוצרים בשוק הם מוצרים המשלבים Repository ו- Registry ומנהלים את השירותים בזמן ריצה ובשלב הפיתוח.

Service Oriented Infrastructure (SOI)

SOI אינו תשתית למימוש SOA אלא שירותים תשתיתייים הניתנים בארכיטקטורה ובתפיסה של SOA.

מרבית השירותים ב- SOA הם שירותים יישומיים. כ- 10% עד 20% מהשירותים הם שירותי תשתית הפועלים בתפיסה דומה לשירותים היישומיים.

הרעיונות המרכזיים ב SOI הם:

 ·         הפשטה  (Abstraction) של השירות התשתיתי

במקום קבלת שירות מרכיב תוכנה/חומרה ספציפי, קבלת שירות מאחד מתוך קבוצה של רכיבים היכולים לספק את השירות.

מקבל השירות אדיש לאופן הטכני של מימוש השירות, כפי שמקבל שירות יישומי ב-SOA אדיש לפלטפורמה בה מתבצע השירות היישומי.

 ·         Orchestration של שירותי תשתית, כלומר ביצוע רצף של שירותי תשתית, בדומה לביצוע רצף של שירותים יישומיים במקום ביצוע כל שירות תשתיתי בנפרד. המשמעות היא אוטומציה של ניהול שירותי SOI.

 ·         שימוש בתשתיות XML ובמקרים רבים גם בתשתיות Web Services לביצוע רצף שירותי SOI. השירותים התשתיתיים ב-SOI ממומשים בדרך כלל תוך שימוש בטכנולוגיות של וירטואליזציה.

 

דוגמאות לשירותי תשתית

 ·         שירותי הדפסה

 ·         שירותי מעבד

 ·         שירותי אחסון

 ·         שירותי מערכת הפעלה

 ·         שירותי שרתי אפליקציות

 ·         שירותי בסיסי נתונים

Cloud Computing & SOA

ענן מחשוב (Cloud Computing) הוא תשתית להרחבת השימוש בשירותי SOA מעבר לגבולות הארגון  (Enterprise).

להלן הדגשים בהקשר של ענן מחשוב ו- SOA :

 ·         בענן המחשוב ממומשים שירותים יישומיים באמצעות SaaS (Software as a Service). המימוש הוא בדרך כלל בתפיסה של Multi Tenancy, כלומר: שיתוף של מספר ארגונים  באותו מופע של שירות ובאותו בסיס נתונים.

 ·         שיתוף זה מציב אתגרים ייחודיים בתחומים כמו אבטחת מידע ואינטגרציה.

 ·         בענן המחשוב ממומשים שירותי SOI באמצעות שימוש ב- IaaS (Infrastructure as a Service) ובאמצעות PaaS (Platform as a Service).

 ·         PaaS  עשוי  לשמש גם כתשתית לפיתוח שירותים יישומיים שימומשו בתוך גבולות הארגון.

 ·         מרבית ספקי מחשוב ענן משתמשים ב- Web Services לצורך גישה לשירותים. נפוץ במיוחד השימוש בסטנדרט REST.

ITIL ו- SOA

התפיסת מערך המחשוב כספק שירותים למחלקות העסקיות משותפת ל- ITIL ול- SOA. שתי התפיסות אינן מתייחסות לשירותים כשירותים טכנולוגיים בלבד.

ITIL (Information Technology Infrastructure Library) הוא אוסף Best Practices בנושא שירותי תפעול של מערכות מחשוב. המושג שירות (Service) ב ITIL עוסק בשירותים תפעוליים כגון:

 ·         Configuration Management

 ·         Change Management

 ·         Release Management

 ·         Incident Management

 ·         Availability Management

 

ITIL משמש לסטנדרטיזציה של ניהול התפעול באירגון ההתייחסות היא לתהליכים למימוש שירותי ITIL.

חשוב להבין כי למרות שהמושג שירות הוא מושג עיקרי ב- SOA ומושג עיקרי ב- ITIL המושגים שונים מהותית בהגדרתם.

הקשר בין שני התחומים הוא בשימוש במסגרת של שירותי ITIL  עבור  SOA Services ו- SOA Processes. מזווית הראיה של ITIL, SOA הוא אוסף שירותים ותהליכים.

על שירותים ותהליכים אלה ניתן להפעיל את ה- Best Practices של שירותי ITIL, למשל ניתן להשתמש בהם לניהול שינויים ב- SOA Services , מחזור חיים של SOA Services או לניהול רמת שירות של  SOA Services.

מהדורה 3 של ITIL הותאמה לטיפול במערכות מחשוב מבוססות Services SOA ולא רק  לטיפול במערכות מחשוב מונוליתיות.

ITIL מטפל גם נושאים תשתיתיים וגם בנושאים יישומיים.  שימוש ב ITIL ישים גם לשירותי  SOI.  השימוש העיקרי האפשרי ב- ITIL בהקשר של SOA הוא לצורך יישום SOA Governance.

מבחינה טכנית ניתן לקשור בין ה CMDB שהוא ה Repository של תצורת נכסי המחשוב באירגון, כגון חומרה, תוכנה בסיסית, תוכנה יישומית ל- SOA Registry שתפקידו דומה בהקשר המצומצם של ניהול Services SOA.

 

תקינה

תקני Web Services

אחת הדרכים לבניית שירותים ולשילוב שירותים בפלטפורמות הטרוגניות היא שימוש ב-Web Services. הרעיון מאחורי Web Services הוא יצירת ממשקים בלתי תלויים בטכנולוגיה ובפלטפורמה בה  ממומש השירות. לצורך כך נבחרו כבסיס טכנולוגיות תקניות ונפוצות באינטרנט כשהכוונה היא בעיקר ל- XML ו- HTTP. על בסיס טכנולוגיות אלה נבנה אוסף של תקנים. תקן כזה מגדיר מבנה של מסמך XML ואת אופן פירוש הנתונים. במידה שהתקן מחייב העברת נתונים ברשת, נעשה בדרך כלל שימוש בפרוטוקול HTTP לצורך העברת הנתונים.

אוסף תקני ה- Web Services מגדיר מחסנית במבנה  הבסיסי המתואר באיור הבא:

·         Wire Stack היא השכבה המטפלת בהעברת המידע באופן תקני בין השירות והצרכן (Consumer).

 ·         Description stack היא השכבה המטפלת בתיאור של מה מבצע ה- Web Service וכיצד.

 ·         Discovery Stack היא השכבה המאפשרת איתור ה- Web Service (היכן נמצא ה- Web Service).

 

התקנים השונים של Web Services ממופים לשלוש שכבות אלה. תקנים שמתייחסים לכל שלוש השכבות, למשל תקנים בנושאי Security ובנושאי טיפול בטרנזקציות, נמצאים מחוץ למחסנית.

קיימים למעלה ממאה תקני Web Services. הם נבדלים זה מזה ברמת הבשלות וברמת קבלתם על ידי יצרנים וארגונים. ברוב המקרים מיושם מספר קטן של תקנים בשלים.

 

התקנים הנמצאים בשימוש רב הם:

 ·         SOAP (Simple Object Access Protocol) תקן עיקרי בהעברת מידע (Wire Stack)

 ·         WSDL (Web Services Description Lagunage) ב- Description stack, המשמש לקשירה (Binding) בין השירות לצרכן

 ·          UDDI (Universal Description Discovery and Integration) ב- Discovery Stack. השירותים מפורסמים במאגר (Registry) בדומה לדפי זהב בטלפוניה. חלק מהארגונים משתמשים ב-  Registry קנייני ואחרים משתמשים בRegistry המבוסס על תקן UDDI.

 ·         BPEL-WS (Business Process Execution Language) - תקן לבניית תהליכים הנכלל ב- Description Stack. זהו  תקן משותף ל- SOA ול- BPM. פירוט נוסף מופיע בקיט BPM בכרך התמחויות – מערכות מידע.

 ·         WS-Security - אוסף תקנים המטפלים בהיבטים שונים של אבטחת מידע. פירוט בסעיף תקני אבטחת מידע ל-  Web Services בהמשך מדריך זה.

 

תקנים חשובים נוספים הנמצאים בשימוש:

 ·         REST (Representational State Transfer) - סטנדרט לעבודה בסביבת Web. חלק מהתקן האינטרנטי HTTP (Hyper Text Transmission Protocol). משמש להעברת מידע על שינוי ב- State בתפיסת State Machineבארכיטקטורת Client/Server  ובטיפול בתוצאות השינוי. המגמה היא להשתמש בו במקום SOAP, משום שהוא קל יותר למימוש והביצועים בו טובים יחסית ל-  SOAP. השימוש בתקן זה נפוץ במיוחד להפעלת שירותים בסביבת מחשוב ענן (Cloud Computing).

 ·         WSDM (Web Services Distributed Management) תקן לניהול Web Services.

 ·         SCA (Service Component Architecture) תקן ליצירת שירות ממספר רכיבים יישומיים.

 ·         SDA (Service Data Objects) תקן ליצירת שירות ממספר מקורות מידע.

 

תקני אבטחת מידע ל- Web Services

קיימים מספר רב של תקנים לאבטחת מידע בסביבת Web Services. התקנים מתייחסים לאספקטים שונים, וממומשים בסביבת מסמכי XML המהווים את הבסיס ל- Web Services. מרבית התקנים אינם בשלים וחלקם בשלב של טיוטה (Draft). התקנים עוסקים בהיבטים כגון:

 ·         ניהול זהויות (WS-SPML)

 ·         הצפנה (למשל: XML-Enc, XKMS)

 ·         הרשאות וזיהוי (למשל: XACML, SAML)

 ·         חתימה דיגיטלית (XML-DSig)

 ·         מדיניות אבטחת מידע (WS-Policy).

SOA & Web Services

יש המזהים את המושג SOA ב- Web Services. זיהוי זה אינו נכון ואינו מדויק ברמה התיאורטית ועשוי להיות בעייתי ברמה המעשית.

אחד ההבדלים המהותיים הוא ש- SOA הוא אסטרטגי ולכן יש לו השלכות עסקיות, ארגוניות וטכנולוגיות מהותיות. מימוש SOA הוא שילוב של  Top-Down ו- Bottom-UP.

Web Services הם טקטיים. ארגון המנסה לפתור בעיה נקודתית של אינטגרציה מגיע למסקנה ששימוש ב-  Web Services מתאים, בדרך כלל משיקולים של עלות וזמן פיתוח.

הגישה במימוש Web Services  היא Bottom-UP. בפועל, מימושים רבים  של SOA מבוססים על שימוש ב Web Services.

לארכיטקטורת SOA המבוססת עלWeb Services  (להלן WSF SOA) מתווספים שני מאפיינים שלא צוינו בסעיף תפיסה במדריך זה:

 ·         הממשקים מבוססי תקנים - מקטין תלות בין הטכנולוגיה באמצעותה מומש השירות לבין הטכנולוגיה של הצרכן.

 ·         Loose Coupling – מקטין תלות בין הצרכן לשירות.

ארגוני תקינה

תקני Web Services נוצרים ביוזמה של קבוצת יצרני תוכנה המביאה טיוטת הצעה לארגון תקינה, במקרים רבים על בסיס עבודה בשטח. השלב הבא הוא צוות עבודה המגבש תקן על בסיס הטיוטה. מהדורות נוספות כוללות הרחבות על פי דרישות משתמשים והצעות יצרנים.

התקנים של Web Services  נקבעים על ידי שני ארגוני תקינה עיקריים:

 ·         W3C (World Wide Web Consortium) - ארגון הקובע תקנים ב- Web. 

 ·         OASIS (Organization for Advancement of Structured Information Standards)

 

ארגון שלישי WS-I (Web Services Interoperability) מנסה לתת מענה להבדלים בפרשנות ובמימוש תקנים על ידי יצרנים שונים. כתוצאה מהבדלים אלה, למרות שמימושים שונים עונים על אותו תקן, אין עבודה משולבת (Interoperability) בין מימושים שונים בשטח של אותו התקן.

המפרטים של WS-I   מתייחסים לאוסף מצומצם של תקנים ולמהדורה מסוימת של כל אחד מהתקנים. WS-I מצרף הנחיות מעשיות למימוש התקנים ומעניק מעין תו תקן של עמידה במפרטיו.

מעשית, ניתן לצפות לשילוב בשטח בין פתרונות Web Services של שני יצרנים התואמים את מפרטי WS-I.

 

מימוש SOA באירגון

מניעים למעבר ל- SOA

המניעים למעבר ל- SOA עשויים להיות שונים בארגונים שונים.

יעד עיקרי של יוזמת SOA הוא סנכרון בין הצרכים העסקיים של הארגון לבין מערכות המחשוב (Business & IT Alignment). כאשר מושג יעד זה, מערכות המחשוב מהוות גורם הממנף את היכולות העסקיות של הארגון. כאשר אין התאמה כזו, עלולות מערכות המחשוב להוות גורם המעכב את צמיחת העסקים בארגון עסקי או אי מימוש של יעדי הארגון בארגון שאינו עסקי.

בדרך כלל המניעים העסקיים  השכיחים הם:

 ·         גמישות תהליכים עסקיים - SOA מאפשר התאמת הארגון לשינויים בשוק.

 ·         מיזוגים ורכישות – SOA מאפשר שילוב מהיר של תשתיות ואפליקציות שונות.

 ·         פיצול חברות – כתוצאה מרגולציה וממניעים עסקיים. פיצול הוא תמונת ראי של מיזוגים ורכישות. ארכיטקטורת SOA מאפשרת הפרדה מהירה של מערכות מחשוב.

 ·         קיצור זמני פיתוח של תוכנה – SOA מאפשר קיצור Time to Market של מוצרים.

 ·         תמיכה בריבוי ערוצים (Multi-Channel) – שימוש במספר רב של ערוצים, שכולם מפעילים את אותם שירותי Back office.

 

המניעים הטכנולוגיים השכיחים למעבר ל- SOA הם:

 ·         הקטנת עלויות התחזוקה

 ·         הקטנת עלויות הפיתוח

 ·         קלות באינטגרציה

 ·         קלות בשילוב טכנולוגיות חדשות

SOA Governance

מימוש תקין של יוזמת SOA בארגון מחייב הגדרת אופן הביצוע באמצעות מדיניות, הנחיות וכללים המתייחסים לשאלה איך לבצע ולא לשאלה מה לבצע. מדיניות, הנחיות וכללים צריכים להיאכף ולהתאים את עצמם לשינויים בארגון וללקחים ממה שכבר בוצע.

SOA Governance מתייחס לטכנולוגיה, אנשים ותהליכים. הוא מתייחס לנושאים אלה בשלושה היבטים עיקריים:

 ·         ארכיטקטורה

 ·         פיתוח

 ·         זמן ריצה

 

SOA Governance מבוצע באמצעות כלים ייעודיים ובאמצעות SOA Registry.

ביצוע לא נאות של SOA Governance עשוי לגרום למימוש SOA שאינו מועיל לארגון.

למימוש SOA באירגון משמעויות ארגוניות ותרבותיות ולא רק משמעויות מחשוביות ולכן SOA Governance. חורג מגבולות  IT Governance ל-  Corporate Governance כמתואר באיור להלן.

אסטרטגית המעבר

האסטרטגיות הבסיסיות  הנפוצות למעבר הן:

 ·         להתחיל במימוש יוזמת SOA באמצעות התקנת והכנסת תשתיות SOA. בדרך כלל מתחילים במימוש מוצר ESB

 ·         התחלה  בנקודת כאב – פיתרון בעיה נקודתית באמצעות SOA והמשך טקטי של יישום SOA כתוצאה מההצלחה בפיתרון נקודת הכאב.

 ·         מימוש מתוכנן המתחיל ב- Pilot מחלקתי. בשלבים הראשונים מסתמכים על מוצרי תשתית קיימים באירגון, שאינם מוצרי SOA.

 

תהליך המעבר

האופן בו מתבצע המעבר ל- SOA הוא ייחודי לכל ארגון. שאלות מרכזיות בהקשר של תהליך המעבר:

 ·         האם לבצע מעבר הדרגתי (Incremental) או בבת אחת (Big Bang)?

 ·         אם מבוצע מעבר הדרגתי היכן להתחיל?

 ·         באיזה אופן לבצע את השלבים הראשונים במעבר הדרגתי (כיצד לבצע Pilot, כיצד למדוד תועלות וכיוצא בזה)

בדרך כלל יבוצע המעבר ל- SOA בארבעה או חמישה שלבים. הטבלה להלן מתארת תסריט נפוץ למעבר בשלבים:

 

	השלב	מהות השלב	טקטי/ אסטרטגי
1.	טיפול בנושאים נקודתיים	הקמת אפליקציות ראשונות בתפיסת SOA. פיתרון בעיות כואבות באמצעות SOA. הצגת תועלות מהירות.	טקטי
2.	הרחבה	הקמת אפליקציות נוספות תוך ניצול והרחבת שירותים שנבנו. בתוך קו עסקים או יחידה עסקית. הוספת תשתיות	טקטי
3.	מימוש בארגון	הרחבה מעבר ליחידות עסקיות. מימוש תהליכים ולא רק שירותים. השלמת הוספת תשתיות SOA, כולל תשתית BPM	אסטרטגי
4.	בית-חרושת (Fabric)	הארגון עובד ברובו בארכיטקטורת SOA. תהליכי יצירת שירותים ושימוש חוזר בשירותים מוטמעים בארגון (בית-חרושת לשירותים) .  המבנה הארגוני והתרבות הארגונית מותאמים לתפיסת SOA.	אסטרטגי

 

עלות תועלת

למרות תועלות אפשריות גדולות הגלומות במעבר ל- SOA קשה להצדיק פרויקט SOA. מירב הקשיים הם תוצאה של שני גורמים עיקריים:

 ·         בשבעים עד שמונים אחוזים מהמקרים ההצדקה היא עסקית - תועלות מחוץ ליחידת המחשוב, בעוד שגורם הביצוע העיקרי הוא יחידת המחשוב עצמה. נוצר לפיכך הצורך לשכנע מנהלים גם ביחידות העסקיות וגם ביחידות המחשוב.

 ·         התועלות אינן מיידיות אלא מצטברות במשך הזמן (Cascading Effect). תועלות של שימוש חוזר (Reuse) עשויות שלא לבוא לידי ביטוי בפרויקטים הראשונים המתבססים על SOA. גם תועלות הנובעות מקלות שינוי תהליכים עסקיים עשויות להתבטא רק בשלב מאוחר יותר

אתגרים ומכשולים במימוש SOA

ארגון וניהול

הקושי העיקרי הוא ניהולי וארגוני ולא טכנולוגי. הוא עשוי לבוא לידי ביטוי בהיבטים כגון:

 ·         רמת בשלות של הארגון

 ·         חוסר מעורבות מחלקות עסקיות ביוזמת ה- SOA

 ·         תרבות ארגונית נוגדת שימוש חוזר

 ·         מודל תמחירי לשירותים שנעשה בהם שימוש על ידי מחלקות וקווי עסקים שונים

 ·         שינויים ארגוניים בשלבים מתקדמים של מימוש SOA

אבטחת מידע

עבודה בסביבה של SOA בכלל וב- Web-Services בפרט, עלולה ליצור בעיות ייחודיות של אבטחת מידע:

 ·         טווח צרכני השירות כולל את הארגון כולו, ולפעמים גם מחוץ לגבולות הארגון, ולא רק מערכת יישומית מסוימת.

 ·         העבודה מבוססת על תוכן המסר (Content Based) ולא על פרוטוקול (Protocol Based). עובדה זו מחייבת פתיחת ההודעות על ידי שרתי ביניים ו- Proxies.

 ·         Web-Services מבוססים על HTTP, פרוטוקול בו יש בעיות אבטחה ו- XML שהיא טכנולוגיה חדשה יחסית ולכן אבטחת המידע בה פחות בשלה.

 ·         נדרש פיתרון לניהול זהויות (Identity Management) משום שעשויה להידרש גישה למספר מערכות בארגון ומחוץ לו, כך שלאותו משתמש עשוי להיות ריבוי זהויות מבחינת המערכות.

 

ציפיות ריאליות

כמו בכל תפיסה חדשה או טכנולוגיה חדשה, רמת בשלות גבוהה יותר, פירושה התאמת ציפיות גבוהות מדי למציאות. בהקשר זה יש לשים לב לנקודות הבאות:

 ·         הסטנדרטים של Web-Services אינם הצלחה. במרבית הסטנדרטים מסוג זה יש שימוש מועט. גם לסטנדרטים נפוצים כמו SOAP יש מגבלות

 ·         רמת השימוש החוזר (Reuse) אינה מתקרבת ל- 90% או 100%. בארגונים שמימשו בהצלחה SOA נמצאה רמה נמוכה בהרבה של כ- 30%. לא תמיד מעשי לעשות שימוש חוזר לשירות באירגון כולו. יש שירותים שהשימוש החוזר בהם מוגבל לרמה של יישומים במחלקה מסוימת או קו עסקים מסוים.

 ·         מודל הלגו של הרכבת שירותים פשטני ולא תמיד ניתן ליישום מלא. כך למשל קיים קושי בשימוש בו במערכות Batch.

 

מפת"ח ו- SOA

כללי

כפי שניתן להבין מהמבוא, SOA היא תפיסה ארכיטקטונית חדשה המבוססת על משאבים קיימים. היא מוסיפה שכבת שירותים ברמה מופשטת. בנוסף לכך, המעבר לגישה החדשה מבוססת השירותים הוא תהליך הדרגתי ארוך.. מכיוון שכך, תידרש תחזוקה והקמה של מערכות בשיטות ובתפיסות שהיו נהוגות עד היום ומטופלות באופן מקיף בנוהל מפת"ח.

מצד שני, SOA היא תפיסה ארכיטקטונית חדשה ששיטות קיימות, כולל מפת"ח לא התייחסו אליה באופן מפורש.

ההשלכות של צירוף שני היבטים אלה על הקשר בין מפת"ח ו- SOA הן:

 ·         לא משתנה דבר בכל האלמנטים הנכללים במפת"ח כאשר עוסקים בנושאים באופן בהם עסקנו בעבר, גם אם ההקשר הוא הקשר של פרדיגמת SOA . כך למשל אם מפתחים תוך שימוש ב- UML, ניתן להשתמש בידע המופיע בקיט גישת האובייקטים UML  כפי שהוא.

 ·         התפיסה האוניברסלית במפת"ח מאפשרת הרחבת השימוש בעקרונות קיימים גם ל- SOA.

 ·         על מנת לממש את ארכיטקטורת SOA, נדרשות תוספות והרחבות למגוון רחב של נושאים הכלולים במפת"ח. התוספת העיקרית הנדרשת נובעת מהצורך להתייחס לכל מרכיב של מערכת  ולכל שלב במחזור החיים גם בהיבט כלל ארגוני וגם בהיבט של הקשר בין יחידת המחשוב לבין היחידות העסקיות. כמו כן נדרשת הרחבה המתייחסת לשכבה החדשה של שירותים (Services).

 

תכנון אסטרטגי ותוכנית אב על פי מפת"ח ובהקשר של SOA

מעבר ארגון לארכיטקטורת SOA הוא אסטרטגי. בטווח ארוך הוא משנה את מבנה המערכות, תהליכי העבודה והמבנה הארגוני. לפיכך הנושא צריך להשתלב בתוכנית האב. בדרך כלל יבוצע המעבר ל- SOA בארבעה או חמישה שלבים כמתואר בסעיף "המעבר ל- SOA" לעיל.

ברור כי שלבים מתקדמים של מימוש SOA  משפיעים באופן מהותי על התכנון האסטרטגי בארגון, יחד עם זאת הם לא בהכרח משנים סדרי עדיפויות ולכן ניתן לשלב מעבר ל- SOA בתוכנית האב או התכנון האסטרטגי על פי תפיסת מפת"ח.

אמנות האיזון בין גישה מעשית הממוקדת במערכות ובתשתיות נחוצות ובין ראיה אסטרטגית כוללת נותרת גם בתפיסת SOA, על אף העמקת הפרספקטיבה של הראייה הכוללת המהווה מרכיב מהותי של פרדיגמת SOA.  

ניתן להמשיך לבצע תכנון אסטרטגי על פי מפת"ח, עם ההדגשים הבאים בהקשר של SOA:

 

נושא	ההדגש
מידע ותהליכים	התמקדות בתהליכים, מודל נתונים ארגוני ו- Metadata הרחבת ההתייחסות לתהליכים החוצים את גבולות הארגון הרחבת אפשרויות של Hosting   של שירותים במרכזי מידע חיצוניים ולא רק Outsourcing של מערכות שלמות
מערכות מידע	בחינה מעמיקה יותר של טיב הקשרים בין המערכות ברמה של מרכיבים משותפים: אילו חלקים מהמערכות מפותחים באופן עצמאי  ולא באילו מערכות ייעשה שימוש בשירותים קיימים האם השימוש בשירותים קיימים דורש הרחבתם?
התארגנות כללית	בחינת בשלות הארגון למעבר ל- SOA (טווח קצר וטווח ארוך), מבנה ארגוני היוצר קשר הדוק יותר בין היחידות העסקיות ליחידת המחשוב (טווח ארוך), הקמתSOA Excellence Center, בחינת העברת פונקציות מיחידת המחשוב ליחידות עסקיות ומיקור חוץ מורחב שינויים בנושאים תקציביים בין יחידות ובמנגנוני התגמול לעובדי מחשוב דגש על פרודוקטיביות גבוהה של עובדים באמצעות שימוש בשירותים קיימים

 

תכנון מתגלגל

בקיט תכנון אסטרטגי בכרך ניהול מציג מפת"ח אפשרות של תוכנית עבודה שנתית מתגלגלת במבנה דומה למבנה התוכנית האסטרטגית. אפשרות זו משלבת בין ראיה כוללת ארוכת טווח ודינאמיקה בתכנון השנתי. אפשרות זו עשויה להתאים במקרים רבים ליוזמות SOA, שאחת ממטרותיהן היא הפיכת הארגון לארגון מגיב במהירות לשינויים עסקיים. זאת ועוד, מימוש יוזמות SOA יוצר דינאמיקה פחות צפויה של הקמת מערכות, שינוי תהליכים וצריכת שירותים. הכול יותר דינאמי ותכנונים סטאטיים ארוכי טווח של מערכות ממוחשבות הם פחות מתאימים (כמו גם לעולם העסקים המשתנה). תכנון אסטרטגי מתגלגל הכולל שינויים בתוכניות העבודה השנתיות עשוי להתאים מאד ליישום ארכיטקטורת SOA.

רמת הארגון והפרויקט

 ·         ארכיטקטורת SOA מחייבת יותר מתפיסות אחרות כי ההתייחסות היא לארגון כולו ביחד עם ההתייחסות לפרויקט. 

 ·         תפיסת מפת"ח  הבנויה על עץ מוצר דומה ברמת הפרויקט וברמת הארגון תומכת בהתייחסות זו.

מחזור חיים

מחזור החיים על פי מפת"ח מתייחס למערכת. בעולם ה- SOA, עשויים להיות מחזורי חיים במספר רמות המתוארות להלן מהגבוהה לנמוכה.

 ·         מחזור חיים של ארכיטקטורה

 ·         מחזור חיים של מערכת

 ·         מחזור חיים של  תהליך (Process)

 ·         מחזור חיים של שירות (Service)

מחזור חיים של ארכיטקטורה

הארכיטקטורה היא דינאמית ומתפתחת ולכן עשויים להיות בה מספר שלבים במחזור החיים.

מחזור החיים ברמה זו אינו כולל את כל השלבים ברצף. כך למשל ברוב המקרים לא נראה שלב של בקשה להצעות RFP. במקום זאת עשויים להיות מספר RFP's בנקודות שונות על ציר הזמן, כשכל אחד מהם מתייחס לחלק אחר במימוש הארכיטקטורה. היות שהארכיטקטורה היא מופשטת, אין למעשה שלב בדיקות, התקנה והרצה ותפעול של הארכיטקטורה עצמה, אלא של כל אחת מהמערכות (כולל מערכות התשתית) הכלולות בארכיטקטורה.

להלן פירוט דגשים ושינויים במחזור החיים של הארכיטקטורה בהשוואה למחזור החיים של מערכת מידע או תשתית על פי מפת"ח.

 

כללי

האילוצים המעשיים מכתיבים במקרים רבים ארכיטקטורה חלקית בשלבים הראשונים של מחזור החיים עם תהליך איטרטיבי של הרחבת הארכיטקטורה. כך למשל בשלבים ראשונים עשויה להיבנות ארכיטקטורה המתאימה ל- Domain מסוים בארגון.

ייזום

·         הקלט של מהות המערכות הקיימות ומרכיביהן חשוב במיוחד בשלב הייזום וגם בשלבים הבאים אחריו. בגלל המורכבות עשוי להידרש שימוש בכלים ממוחשבים למיפוי המשאבים והקשרים ביניהם (Metadata Repositories) ולכלים אוטומטיים למחצה למידול פירוק (Decomposition) הפונקציונאליות לשירותים.

 ·         המערכות הראשונות הן פרויקטי חלוץ (Pilot) או POC (Proof of Concept) לארכיטקטורה. בחינתן צריכה להתבצע גם בהקשר הארכיטקטוני הכולל ולא רק בהקשר היישומי הספציפי.

 

בקשה להצעות RFP

ה- RFP לבחירת יועץ הוא מפתח להצלחת היוזמה. בנוסף לו עשויים להיות RFP's תשתיתיים ויישומיים. חשוב לראות כל אחד מהם בהקשר הכולל של ארכיטקטורת SOA ולא כפיתרון העומד בפני עצמו.

עיצוב ובנייה

בשלב העיצוב והבנייה יש לבנות ממשקים במבנה אחיד ככל האפשר ובהסתמכות על Metadata. 

תפעול

נדרשת הדרכה של משתמשים עסקיים ואנשי IT ביחס לתפיסה הארכיטקטונית, זאת משום שלטווח ארוך עשויה להיות לה השפעה מרחיקת לכת עליהם.

מחזור חיים של מערכת

זו הרמה אליה מתייחס מפת"ח לפיכך אין שינויים מהותיים במחזור חיים זה על פי תיאורו במפת"ח. יש לשים לב להיבטים הבאים:

 ·         סקר (DR) יעשה על ידי קבוצה רחבה יחסית עם נציגים ממערכות אחרות העשויות להשתמש בעתיד בשירותים. חברי הקבוצה צריכים להיות מחויבים לשימוש חוזר (Reuse).

 ·         ניתוח החלופות באפיון העל צריך לכלול את השאלה: "האם לפתח את המערכת בארכיטקטורת SOA?". שאלה זו חשובה במיוחד ביחס למערכות ראשונות בארגון המוקמות בארכיטקטורת SOA.

 ·         בניתוח המערכת בשלב האפיון יינתן דגש לשירותים וממשקים.

 ·         לעקרונות המנחים בשלב העיצוב והבנייה יש להוסיף הקפדה על יצירת שירותים ברי שימוש חוזר.

 ·         בבניית המערכת יושם דגש על שימוש חוזר בשירותים קיימים במקום בניית שירותים חדשים.

 ·         בבדיקות המערכת יש לשים דגש על בדיקת כל שירות בנפרד ובאופן עצמאי (ולא רק כל המערכת יחד), וזאת כדי לאפשר שימוש חוזר בעתיד. ראה "מחזור חיים של שירות" להלן.

 

מחזור חיים של תהליך (Process)

נושא זה מפורט בקיט העוסק ב- BPM בכרך התמחויות – מערכות מידע.

מחזור חיים של שירות (Services)

מחזור החיים של שירות הוא מלא. על פי ניסיונם של ארגונים שמימשו SOA, מומלץ להתייחס למחזור החיים של שירות כאל מחזור החיים של מוצר תוכנה ולתמוך בשלוש מהדורות: קודמת, נוכחית ומהדורה בפיתוח.

 ·         שלב הייזום אינו נדרש בדרך כלל. שלב זה נעשה עבור יחידות גדולות יותר מאשר שירות.

 ·         אם יוחלט על בקשה להצעות, היא תתייחס ליחידה גדולה יותר של אוסף שירותים.

 ·         בשלב הבדיקות יש לתת משקל רב לניסויי Performance ו- Load Balancing. ל- Service  עשוי להיות מספר לא חזוי מראש של צרכנים.

 ·         יש לתת משקל רב יחסית לבדיקות החוקיות. לאי-עמידה במדיניות (Policy) וכללים אחרים בארגון, עשוי להיות טווח השלכות גדול מאשר במערכת מסורתית בגלל השימוש החוזר בשירות במספר רב של יישומים.

 ·         בשלב התחזוקה עשויה להידרש תחזוקה של מספר מהדורות (Multiple Versions). הסיבה לכך היא שעיקרון חשוב בהרבה מקרים  הוא Loose Coupling בין השירות לצרכן ולכן לא בהכרח כל הצרכנים של השירות יהיו מודעים לשינויים בשירות ולא בהכרח כל הצרכנים יוכלו להתאים את עצמם לשינוי.

 ·         כמו כן, בשלב התחזוקה צפויים הרחבות ושינויים כתוצאה משימוש חוזר ב- Service במערכות נוספות.

 ·         הסכם רמת השירות (Service level Agreement) צריך להיות מוגדר ברמה של Service. מדידתו מורכבת יחסית בגלל הטרוגניות גדולה יחסית של צרכנים. ניתן להיעזר במתודולוגיות של ITIL (כולל ביצוע תהליכי Optimization  בשלב התפעול והתחזוקה).

 

עץ מערכת

בשימוש בעץ המערכת בפרויקט SOA חשוב לזכור כי:

 ·         הפרויקט אינו עומד בפני עצמו אלא קשור גם במערכות ובתשתיות אחרות ומהווה חלק מארכיטקטורה כוללת.

 ·         עץ המערכת צריך לטפל גם בהיבטים המסורתיים של מערכת מידע או תשתית וגם בשכבת השירותים והתהליכים.

 

בהקשר של עץ המערכת, כולל מפת"ח עץ מערכת אוניברסלי, ווריאנטים המתאימים למערכות מידע ולתשתיות. במימוש SOA, יהיו חלקים הקשורים במערכות מידע (כגון: הקמת פרויקט חדש הנבנה בתפיסת SOA) ותשתיתיים (כגון: בחירת מוצר ESB, בחירת מוצר Registry). באופן טבעי, חלקים תשתיתיים של מערכות SOA, יתאימו יותר לוריאנט תשתיתי וחלקים הקשורים במערכות מידע יתאימו יותר לוריאנט המתאים להקשר זה.

להלן תקציר השינויים בעץ המערכת במערכות המפותחות בגישת SOA. לפירוט המלא יש לעיין בתבנית הלימוד המצויה בלשונית תוצרים בקיט זה.

 

פרק 1 - יעדים

פרק היעדים אינו משתנה במימוש יוזמת SOA, מבחינת מבנה הסעיפים. עשויים להיות שינויים בתכנים, הדגשים ובתפיסה הכוללת שמאחורי התכנים.

להלן תיאור קצר של שינויים אפשריים  בפרק היעדים, בהקשר של מערכות מידע המהוות חלק מיוזמת SOA:

 

הסעיף	מהות השינוי
1.1 לקוח / מומחה יישום	לכל שירות מתווספים לקוחות/ מומחים נוספים העשויים לצרוך אותו ואינם שייכים לאותו פרויקט, על מנת להבטיח שימוש חוזר.
1.4 הקשר ארגוני / עסקי	מורחב יחסית למערכות שאינן SOA, עקב ההשלכות לכלל הארגון.
1.6 ישימות ועלות/תועלת	מורכב מהיבטי עלות/תועלת ישירים באותו פרויקט ותועלות מתגלגלות בעקבות אפשרויות לשימוש חוזר עתידי.
1.7 אופק הזמן	עשוי להיות צורך להתייחס לאופק זמן ארוך יותר.

 

פרק 2 – יישום, מהות המערכת

בפרק היישום נדרשים שינויים והרחבות מרובים. שינוי התפיסה משפיע על מכלול רחב של סעיפים.

בהקשר זה  יש לשים לב לנקודות הבאות:

 

הסעיף	מהות השינוי
2.2 תיחום חיצוני 2.2.0 תיחום כללי 2.2.1 משתמשים (צרכנים) 2.2.2 מערכות ושירותים משיקים	יש שינוי של שמות הסעיפים, עקב הצורך לכלול במשתמשים (2.2.1) גם "צרכנים" (Consumers) בהגדרה של SOA וכמו כן הוספת שירותים משיקים בסעיף 2.2.2. אם יש צורך, ניתן להפריד בחלוקת משנה בתוך סעיפים אלה. צרכנים עשויים להיות משתמשים וגם חלקים ממערכות אחרות (שירותים אחרים). כבר בשלב זה רצוי למפות, ככל שניתן, צרכנים אפשריים לכל שירות וצרכנים שייאסר עליהם לעשות שימוש בשירות. קיים קושי מהותי במיפוי  הצרכנים, שחלקם עשויים לבוא מחוץ לארגון.
2.3 תיחום פנימי 2.3.1 שירותים 2.3.2 תת מערכות	הבעייתיות של הכללה כתת סעיף של 2.3 היא בשני מישורים: היות שהמערכת תפותח גם באמצעות שיטת פיתוח רגילה (SOA היא שכבה מעל) עשוי להידרש גם פירוק לפי השיטה הרגילה  (UML או שיטה פרוצדוראלית) בנוסף לפירוק לשירותים. במקרה זה, צריכה להיות הבחנה בין שתי רמות הפירוק. לכן הוגדרו תת סעיפים 2.3.1 שירותים  ו- 2.3.2 תת-מערכות או פונקציות ובתוך 2.3.2 נעשה פירוק לפי שיטת הפיתוח. יש לשים לב כי הפירוק לשירותים הוא לא רק בתוך המערכת אלא חוצה גבולות של מערכות אחרות . בפירוק לשירותים צריך להתייחס בנפרד לשירותים קיימים בהם יעשה שימוש חוזר (Reuse) ולשירותים חדשים, שנדרש לפתח או לרכוש.
2.4 ממשק משתמש	יש לאפשר גמישות לריבוי ממשקי משתמש השונים חזותית זה מזה (ואשר משתמשים כולם באותם השירותים).
2.5 תהליכים ושירותים	רכיב זה  עשוי לקבל משקל גדול יחסית ולחייב פירוט רב. הישויות בתהליך הן שירותים (Services). אם הארגון רכש כלי של מידול תהליכים, ניתן להשתמש בו לתיאור תהליכים.
2.6. טרנזקציות	ברוב המקרים  ההתייחסות לטרנזקציות תהיה ברמת Components   בתוך Service ולא ברמת ה Service. עשויה להידרש התמודדות עם עבודה שבמהותה אינה טרנזקציונאלית והתמודדות עם  עבודה אסינכרונית ו- Stateless.
2.19 אבטחת מידע	יש להוסיף התייחסות לרמת השירותים.
2.22 ממשקים וקישורים	נדרש תת-סעיף נוסף המתייחס לממשקים בין שירותים לצרכנים. ממשקים אלה יהיו בחלקם חיצוניים למערכת ובחלקם פנימיים. חשוב להתייחס לשימוש ב- Metadata במסגרת הממשק. ההתייחסות  ל-  Metadata ולהיבטים נוספים עשויה להיות משותפת לכלל השירותים בארגון ולכן יעשה בהם שימוש חוזר (Reuse) בתוך עצי מוצר של פרויקטים שונים הכלולים בערכת ה- SOA.

 

פרק 3 – טכנולוגיה ותשתית

פרק הטכנולוגיה  אינו עובר שינויים עקרוניים מהותיים. יש לשים לב לנקודות הבאות:

 ·         אם נעשה שימוש בכלי תוכנה ייעודיים ל- SOA (למשל: מוצר ESB) או כלי חומרה ייעודיים לסביבה מבוססת סטנדרטים, יש להוסיף התייחסות אליהם בסעיף המתאים (למשל: DataPower IBM בהקשר של תקשורת מבוססת XML).

 ·         במידת הצורך יש להוסיף סעיף להתייחסות ל- Repository/Registry.

 

פרק 4 – מימוש

פרק המימוש עשוי להיות מושפע בצורה משמעותית משינוי הגישה ל- SOA. צפויים ההדגשים והשינויים הבאים:

הסעיף	מהות השינוי/ההדגש
4.1  גורמים מעורבים	סעיף מורחב. יש לציין גורמים מחוץ לפרויקט או הנושא, העשויים להשתמש בשירותים כגורמי פיתוח ביחידת המחשוב, ועל צרכנים פוטנציאליים ומשתמשים בשירותים (ברמת הפיתוח, לא ברמה אפליקטיבית). חשוב להתייחס לקבוצת השיקוף (Review-Team) שעשוי להיות לה תפקיד מרכזי. יש להתייחס לגורמים האחראים על שירותים בהם נעשה שימוש חוזר במערכת.
4.2 תכנית עבודה	נדרש סעיף מורחב יחסית
4.7 השתלבות בארגון	נדרשת התייחסות לאופן בו ישולבו בארגון שירותים  (Services) שפותחו (הן ברמת השימוש האפליקטיבי בשירותים והן ברמת הפיתוח של מערכות עתידיות אשר יבצעו שימוש חוזר בשירותים).
4.8 חוסן ואמינות	תכנית הבדיקה צריכה להתייחס גם להיבטי Governance ולבחון תסריטים עתידיים של צריכה ומשמעותם מבחינת עומסים וביצועים.
4.9 תצורות	יש להתייחס גם לתצורות ברמת שירות: סוג השירות (חדש, עטוף, מורכב, נתונים), ומיפויו למשאבים קיימים (כגון: תכניות, רכיבים, נתונים). בהקשר של אוסף השירותים הנכלל התצורות הן תיאור חלקי של הארכיטקטורה.

 

פרק 5 - עלות, משאבים

פרק העלות אינו צפוי לעבור שינויים מבניים. מבחינת מודל העלות צפוי שינוי. יש להוסיף התייחסות למודל לחלוקת עלויות בין פרויקטים שונים, העושים שימוש חוזר (Reuse) בשירותים (Services). מודל זה נדרש על מנת להימנע מהעמסת כל עלויות הפיתוח על פרויקט המפתח שירותים ועל מנת לעודד שימוש חוזר.

SOA במפת הידע של מפת"ח

SOA היא ארכיטקטורה כלל ארגונית ולכן עשויות להיות לה השלכות על מערכות מידע ותשתית מכל הסוגים המוגדרים במפת"ח. פרק זה סוקר מספר קיטים לפי כרכים ומתייחס לסוגי מערכות ונושאים בהם בא לידי ביטוי באופן בולט במיוחד הקשר ל SOA.

כרך התמחויות/מערכות מידע

מערכות BPM

(Business Process Management) - קיים קשר הדוק בין SOA ו- BPM. שני התחומים עוסקים גם בתהליכים ושירותי SOA מהווים את היחידה הבסיסית (Sub Process) בתהליכים אוטומטיים.  ההמלצה היא לבצע בו זמנית את פרויקט הBPM הארגוני ואת יוזמת ה- SOA באירגון ולהקים Competence Center משולב לשני התחומים.

אפליקציות מוכנות (ERP, CRM)

יצרני האפליקציות המוכנות בונים דור חדש של מוצריהם המבוסס על שירותים (Services) במקום על מרכיבים (Components) גדולים, כגון: ניהול ספר ראשי, ניהול מלאי ומחסנים. למרכיבים הגדולים של הדור הקודם ניתן להתייחס כאל אפליקציות מונולוטיות משופרות (מודל נתונים אחיד, בסיס נתונים אחיד, ממשקים אחידים וכדומה). התהליך דומה לתהליך של מעבר ארגון לפרדיגמת SOA. הבדל מהותי בין יצרן אפליקציות מוכנות וארגון הוא ה- Ecosystem, כלומר: קהיליית משתמשי החבילה, היכולה לתרום יותר באופן משמעותי להרחבת החבילה במודל SOA מאשר במודל הקודם.

ארגונים המשתמשים במפת"ח ומפעילים יישומים מוכנים ומתכננים מעבר ל- SOA צריכים לשים לב לנקודות הבאות:

 ·         בבניית ארכיטקטורת SOA ובתכנון מימושה יש להתייחס גם לאפליקציות מוכנות שמותקנות או יותקנו בארגון.

 ·         בתהליכי בקשה להצעות לבחירה של יישומי ERP או CRM מוכנים, יש להתייחס לתמיכת היצרן ב- SOA וב- Composite Applications כחלק מהקריטריונים במפ"ל (בחירת הספק והפיתרון המוצע בבקשה להצעות).

 ·          תפיסת SOA עשויה לאפשר גמישות במימוש פתרונות ERP ו- CRM בהקשרים הבאים:

             ·         ניתן לממש חלק מהרכיבים או כולם באמצעותHosting  מחוץ לארגון במודל של SAAS (Software As A Service).

             ·         במקרים מסוימים ניתן לשלב רכיבי ERP של יצרנים שונים בהסתמך על שימוש של יצרנים שונים  באותם סטנדרטים.

             ·         בפרק 4 מימוש בעץ המערכת עשוי להיות מגוון רחב יותר של אפשרויות מימוש למערכת/פרויקט.

             ·         עשוי להידרש שילוב תשתיות SOA של יצרן האפליקציה המוכנה  (למשל: ESB) עם תשתיות של יצרני תשתית אחרים.

 

קיט מחסן נתונים Data Warehouse

הדור הבא של מערכות Data Warehouse ומערכות אינטליגנציה עסקית (BI) יהיה מבוסס SOA. בהקשר של שילוב מערכות אלו בסביבת SOA, יש לשים לב לנקודות וההדגשים הבאים, בהתייחס  לקיט  בנושא זה במפת"ח:

 ·         מחסן הנתונים (Data Warehouse) המתעדכן אחת לשבוע או אחת ללילה, אינו פיתרון מספק לנתונים בארכיטקטורת SOA. נדרשים נתונים מעודכנים יותר הקרובים לזמן אמת (Real Time) שבאים לפעמים מחוץ לארגון. שילובם בעיבודי הניתוח ובדיווחים עשוי להיעשות באמצעות Data Services   ולא באמצעות העתקתם לבסיס הנתונים של מחסן הנתונים.

 ·         דיווחים יופעלו כשירותי  Data Services וניתוחים  כשירותים עם לוגיקה עסקית.

 ·         יש להביא בחשבון שירותים שישמשו גם את מחסן הנתונים וה- BI וגם את המערכות התפעוליות.

 

כרך התמחויות/מערכות תשתית

קיט תשתית אבטחת מידע

אבטחת מידע הוא נושא חשוב בתפיסת SOA במידה דומה למערכות בתפיסות אחרות. עקרונות ושיטות אבטחת מידע המוזכרים בקיט זה ישימים גם בעבודה בפרדיגמת SOA. יש לשים לב לאתגרים המיוחדים (ראה סעיף אבטחת מידע בפרק מימוש SOA באירגון)

קיט רשתות תקשורת

תהליך הטיפול בתשתית תקשורת זהה במערכות SOA ובמערכות אחרות, כך שניתן להשתמש בחומר המצוי במפת"ח כבסיס למחזור החיים של תשתית התקשורת.

יש לשים לב להיבטים הבאים:

 ·         מרבית התעבורה עשויה להיות מבוססת על XML ולכן תכנון הקיבולת של הרשת צריך בדרך כלל  להביא בחשבון קצב גידול גבוה יותר של התעבורה ברשת

 ·         יתכן ויידרש ציוד תקשורת מתמחה המטפל במסרי XML.

כרך נושאים תומכים

קיט שיתוף המשתמש

שיתוף המשתמש חשוב במיוחד בהקשר של מערכות בארכיטקטורת SOA. להלן תוספות והדגשים על בסיס הקיים בערכת שיתוף משתמש במפתח.

לסוגי המשתמשים יש להוסיף ברמת המערכת:

 ·         מומחה חדשנות (Innovation Expert) – מומחה שתפקידו לבחון את התהליכים שנבנו בתפיסת SOA ולהציע תהליכים עסקיים משופרים.

 ·         מומחי יישום של מערכות אחרות – בנוסף למומחה היישום חשוב לשתף מומחים של  יישומים אחרים, במיוחד כאלה העשויים להיות הצרכנים הבאים של שירותים שמפותחים במערכת.

 ·         אחראי על איסוף שירותים – משתמש שתפקידו להרכיב מערכות משירותים קיימים. תפקיד זה הוא תפקיד עתידי וברוב הארגונים לא נראה בשלב זה בעלי תפקיד כזה.

 

ברמת הארכיטקטורה הכוללת, יידרש שיתוף משתמשים בכירים נוספים.

הדרג הניהולי צריך להיות ער במיוחד לצורך בשימוש חוזר בשירותים.

יש לשקול מעורבות גדולה יחסית של המשתמש בשלב התפעול והתחזוקה במחזור החיים, כולל ביצוע איסוף שירותים.

במסגרת ניהול הידע של הארגון יש צורך לתאר את השירותים הקיימים בו, על מנת שמידע זה יהיה זמין גם למשתמשים.

 

קיט ניהול שינויים

חשוב לזכור שטווח ההשפעה של שינוי שירות בארכיטקטורת SOA גדול יותר מאשר טווח ההשפעה של שינוי במערכת מסורתית, זאת משום שמספר הצרכנים עשוי להיות גדול יותר, לכלול צרכנים מחוץ לארגון וממגוון רחב של יחידות בארגון. לכן יידרש מנגנון מיוחד להודעה לצרכנים על שינוי. יש לצפות לכך שחלק מהצרכנים, עשוי לא להיות מודעים לשינוי.

קיט גישת האובייקטים UML

השירות (Service) מורכב מרכיבים (Components). בבניית רכיבים חדשים (ברוב המקרים בסביבת J2EE או Dot Net, אך לפעמים גם בסביבות טכנולוגיות אחרות) מבנה והתנהגות הרכיבים מוגדר בשפת UML. בין UML בכלל ובין UML2בפרט, לבין SOA קיים דמיון במספר אלמנטים:

 ·         רמה של הפשטה (ב- SOA רמת ההפשטה גבוהה יותר),

 ·         שימוש בממשקים בין המרכיבים,

 ·         העיקרון של שימוש חוזר ב- Service או ב- Component.

 

בין Service ל- UML Component  קיימים גם הבדלים משמעותיים המתוארים להלן:

Component	Service
Tightly Coupled	בדרך כלל   Loosely Coupled
תומכים בטרנזקציונאליות (ACID)	בדרך כלל לא תומכים בטרנזקציונאליות (ACID)
בדרך כלל מוגדרים בתוך אפליקציה (Local). טכנית יכולים להיות מעבר לגבולות אפליקציה	באופן טבעי, מוגדרים מעבר לגבולות אפליקציה (Remote).
סמנטיקה של אפליקציה	סמנטיקה של Enterprise
Granularity קטנה יחסית. ממשקים פשוטים יחסית	Granularity גסה יחסית. ממשקים מורכבים יחסית במטרה להקטין את תעבורת הרשת
מספר Components מרכיבים בד"כ Service	מספר Components מרכיבים בד"כ Service
רמת הפשטה נמוכה יחסית	רמת הפשטה גבוהה יחסית

 

באופן מעשי באותה מערכת אנו יכולים להידרש לעבוד בשיטת UML לגבי Components וברמת הפשטה גבוהה על Services המורכבים מ-  Components.

היות שדיאגרמות UML אינן מגדירות את הרזולוציה של הרכיבים בהן הן מטפלות, ניתן להשתמש בכלים של Use Case ו Activity Diagram לאפיון ועיצוב מערכות בתפיסת SOA וב State Machine Diagrams ככלי עזר לאפיון אירועים בארכיטקטורת SOA 2.0.

 

כרך איכות, מתודולוגיות וסטנדרטים

קיט CMMI

CMMI מתייחס לרמות שונות של בשלות האירגון. מרמת הבשלות של הארגון נגזרים נושאים בתחום טכנולוגיות המחשוב שניתן לטפל בהם ונושאים אחרים, שהטיפול בהם צריך להידחות עד לרמת בשלות גבוהה יותר של הארגון.

בגלל ההיבטים הארגוניים הקיימים במימוש SOA, קיים קשר ברור בין היכולת לממש באופן נאות יוזמת SOA באירגון לבין רמת הבשלות שלו. ארגון  Open Group The וחלק מיצרני פתרונות SOA בנו מודלים דמויי CMMI שהם ספציפיים לתחום  של SOA.

כרך ניהול, ניהול פרויקט

פיתוח זריז - Agile

שני התחומים חולקים עיקרון משותף זמישות (Agility). למרות זאת אין קשר הכרחי ביניהם.

 ·         מימוש SOA אינו עוסק בהכרח בפיתוח. באופן עקרוני ניתן לממש SOA עם פיתוח מזערי או ללא פיתוח  במצבים בהם הדגש הוא על שימוש בנכסי תוכנה קיימים.

 ·         הרמה אליה מתייחסות מתודולוגיות Agile היא רמת התוכנית או המערכת בעוד SOA מתייחס לארגון (Enterprise) או גם מעבר לארגון (Virtual Enterprise) ולכן עקרונית,  פיתוח שירותים ותהליכים ב- SOA אינו תלוי במתודולוגית הפיתוח של תכניות ורכיבי תוכנה. באופן עקרוני ניתן לפתח במתודולוגית Water Fall, באותה מידה שאפשר לפתח במתודולוגיות Agile.

 ·         מתודולוגיות Agile מיועדות לקצר את זמן הפיתוח בטווח הקצר. SOA עשוי לקצר את זמן הפיתוח, אבל רק לאחר שבטווח הזמן הקצר הושקע זמן רב יותר בתכנון ובטווח הזמן הבינוני פותח מספר גדול של שירותים ותהליכים.

 

למרות זאת יש יתרון לאופן חשיבה המעודד היערכות לקצב שינויים מהיר ולשימוש באיטרציות  המשותף למתודולוגיות Agile ו- SOA. אחד הביטויים לקרבה באופן החשיבה הוא המניפסט. בשנת 2001 פורסם מניפסט של המומחים המובילים בעולם ה-  Agileהנקרא Agile Manifesto. המניפסט הוא מסמך עקרונות והנחיות למפתחי Agile. בשנת 2009 פורסם מניפסט מקביל בעולם ה- SOA בעקבות הצלחת ה  Agile Manifesto.

 

כרך ניהול

קיט מיקור חוץ

בסביבת SOA ניתן להשתמש במיקור-חוץ הממוקד ביחידות קטנות באופן רב יותר מאשר בארכיטקטורות מסורתיות. ניתן לבצע מיקור חוץ ברמה של שירות בודד, קבוצת שירותים וברמה של תוכנה כשירות SaaS (Software as a Service). למעט SaaS, מיקור חוץ ברזולוציה הקטנה ממערכת אינו מעשי בארכיטקטורות מסורתיות.

יתרונות בולטים של מימוש  מיקור-חוץ ברמת שירות עשויים להיות:

 ·         מומחיות ה- Outsourcer

 ·         חיסכון בעלויות

 ·         בחלק מהמקרים השירות כבר קיים וניתן להשתמש בו מבלי לפתח

 

מן הראוי להזכיר כי בשונה מהמצב במיקור-חוץ תחת ארכיטקטורות אחרות, התפיסה תהיה של קופסה שחורה גם במקרים של Outsourcing סלקטיבי ולא רק במקרים של Outsourcing  כוללני.

 

קיט ניהול יחידת המחשוב

ניהול יחידת המחשב בארגון אינו צריך להשתנות בתחילת תהליך מימוש יוזמת SOA. בטווח ארוך מאד צפויים שינויים ביחידות מחשוב פנימיות בחלק מהארגונים כתוצאה משילוב של מספר גורמים ובכלל זה המעבר לפרדיגמת SOA. עיקרי השינויים:

 ·         התמקדות רבה יותר בתהליכים

 ·         השתלבות הדרגים הניהוליים הבכירים בארגון ה IT בהיבטים עסקיים שאינם מחשוביים

 ·         התמקדות בליבה עסקית כשפונקציונאליות אחרת יוצאת למיקור-חוץ

 ·         ניהול תשתיות מבוזרות יותר

 ·         שיתוף מערכות ותשתיות עם שותפים עסקיים מחוץ לארגון

 

ניהול איכות

נושא ניהול איכות בארכיטקטורה מכוונת שירותים הוא נושא מורכב ביותר, שלא ניתן למצותו במסגרת קיט זה.

להלן מספר הבהקים ביחס לנושא ניהול איכות SOA:

 ·         הטיפול באיכות הוא במספר רמות: הארכיטקטורה, Portfolio ומחזור החיים.

 ·          Portfolio מתייחס לאסטרטגית ה- IT, למשל איזה פרויקטים לפתח.

 ·         מחזור החיים מתייחס למחזור החיים של פיתוח, תחזוקה ותפעול שירותים.

 ·         הטיפול בנושא האיכות הוא באמצעות SOA Governance.

 ·         רמה נוספת לטיפול היא רמת המשאבים המרכיבים את השירותים. הטיפול באבטחת איכות של רמה זו זהה למתואר במפת"ח ביחס למערכות שאינן בתפיסת SOA.    

 

נהלים

כמו בכל תפיסה או שיטת פיתוח נהלי הארגון יתבססו על מפת"ח ונהלים ארגוניים ספציפיים. יש צורך לבנות נהלים ארגוניים בנושא SOA.

מדיניות (Policy)

הבסיס ל- Governance SOA הוא מדיניות הארגון בנושא שירותים. המדיניות צריכה לספק הנחיות (Guidelines) בנושאים עסקיים, טכניים ואבטחת מידע.

למדיניות שלושה היבטים:

הגדרת מדיניות

החלטה על מדיניות וכתיבת מסמך המדיניות.

דוגמא: המדיניות יכולה לכלול הנחיה שפיתוח Web Services יהיה תואם ל- WS-I Basic Profile 1.1.

 

אכיפת המדיניות

בקרה שאכן העובדים פועלים על פי המדיניות. בדוגמא לעיל האכיפה של עבודה על פי WS-I Basic Profile 1.1 יכולה להיעשות באמצעות בקרה ידנית ובאמצעות ניסויים.

שינוי מדיניות

למדיניות יש היבט דינאמי. כתוצאה משינויים ארגוניים או טכנולוגיים וכתוצאה מניסיון מצטבר, עשוי להידרש שינוי במדיניות. כך למשל באותה דוגמה, עשוי  להיות צורך להתאים את העבודה למהדורה חדשה של WS-I Basic Profile. 

ניהול תצורה ברמת השירות

העקרונות והנהלים בקיט ניהול תצורה בכרך איכות הם עקרונות הנדסיים כלליים ללא קשר למהות הישויות שאת התצורה שלהן אנו מנהלים, ולכן הם ישימים גם לארכיטקטורת SOA. חשוב לציין שלצורך אבטחת איכות, יידרש במקרה זה לשים דגש על ניהול התצורה של שירות. מומלץ לנהל את תצורת השירות באופן דומה לניהול תצורת מוצר תוכנה (על פי גרסאות). 

מדדים לאיכות שירותים

המדדים המוצעים קשים להערכה. חלקם ניתנים להערכה מלאה רק בדיעבד. עם זאת בהיעדר מדדים טובים יותר גם הם יכולים לתרום לשיפור איכות השירותים.

 ·         מידת השימוש החוזר (Reuse)

שימוש חוזר רב פירושו איכות גבוהה. חוסר שימוש חוסר הוא אינדיקציה לאיכות נמוכה של השירות.

חשוב להבין שלפחות במערכות הראשונות שמפותחות בפרדיגמת SOA, יהיה קשה למצוא שימוש חוזר מעשי רב בשירותים. התחליף לכך עשויה להיות הערכה איזה מערכות יוכלו לעשות בעתיד שימוש חוזר בשירות (גם להערכה תיאורטית זו יש מגבלות).

 ·         אחידות הממשקים והסתמכותם על Metadata  ולא על ממשק ייחודי לכל Service.

 ·         רמת Granularity  מתאימה

אין מדד מדויק לבחינת הרמה המתאימה. כלל אצבע העשוי לעזור בהערכה האם הרמה מתאימה הוא האם השירותים נבנו ברמה כזו שהם יכולים להוות יחידה אטומית של תהליך. במקרה זה סביר להניח  שהאיכות שלהם בהיבט ה- Granularity  טובה.

 ·         מדד נוסף הוא האם השירותים מייצגים שירות עסקי או שהגבולות שלהם שונים מגבולות שירותים עסקיים. בחינת מדד זה היא באמצעות חוות דעת של משתמשים שהם מומחי היישום.