רבות כבר נכתב על ארכיטקטורה חשובה זו. עם זאת דומה שאין תמימות דעים לגבי מימוש SOA בפועל. בפוסט זה נתייחס לפירושים הרבים למונח "מימוש SOA" תוך הסתכלות על מידת המימוש בפרספרטיבה של זמן. בעקבות פרסום הפוסט המקורי קיבלתי תגובות מלקוחות המעדנות יותר את מדרג השימוש ב- SOA . אני מפרסם כעת את המדרג המעודכן.
1. סביבת קישוריות מרכזית- ESB (בעבר EAI) כל המערכות מדברות האחת לשנייה כולל רמה של web services דרך תשתית זו. זאת שיטת עבודה מקובלת אצל רוב הארגונים. התשתית מבצעת ניתוב, אבטחת מידע , LOGS, ואפילו לוגיקה בסיסית.
2. שימוש בכלי BPM (חלק מ- SOA) לביצוע משימה ספציפית – במקום קידוד בסביבת פיתוח רגילה. הדבר מתאים במיוחד כאשר המשימה הנה תהליך עסקי המערב אפליקציות קיימות הקיימות בטכנולוגיות שונות, צורות גישה מגוונות (גם GUI גם MAIL גם SMS גם קשר בין אפליקציות) וגם התהליך העסקי משתנה בצורה תדירה. ישנו ניסיון מסוים בשימוש בתחום זה בישראל.
3. כמו הפירוש הראשון אך קיים גם גורם אשר מרכז את הכנסת כל הממשקים\שירותים ומציע את לגופי פיתוח להשתמש בממשקים\שירותים קיימים. זהו שיפור חשוב שמחייב הכנסת כלי soa governance. גופי הפיתוח יכולים להשתמש בשירותים קיימים אך אינם חייבים.
4. המדרג החדש שהוספתי - כמו הפירוש הקודם אך אותו גורם מרכזי שמכניס את השירותים ל- ESB\SOA יכול לאשר או לבטל הכנסה של ממשק\שירות ולהכריח את הגורם הדורש להשתמש בממשק\שירות שכבר קיים (כלומר גורם זה לא רק מציע אלא גם מחייב).
5. הדרגה הגבוהה ביותר של SOA היא שישנה הסתכלות כוללנית על תהליך הפיתוח בארגון. כל משימת פיתוח מוצבת בפני גוף ארכיטקטים המחליט מי מבצע איזה חלק, האם להשתמש בשירותים שכבר קיימים, האם להשתמש בטכנולוגיה של BPM או בטכנולוגיית פיתוח סטנדרטית וכד'. כלומר גוף הארכיטקטים לא מסתכל רק על הממשקים\שירותים "חיצוניים" שאפליקציה צריכה אלא גם מה קורה "בתוך" האפליקציה. מימוש זה מחייב שינוי מהותי בתהליכי הפיתוח של רוב הארגונים. זאת מכיוון שברוב ארגונים לכל גוף עסקי יש גוף ב- IT שממחשב אותו. פחות או יותר בצורה אוטונומית – ללא הסתכלות כוללנית ומשותפת על כל האפליקציות בארגון.
מבחינת מידע מהשטח, רוב הפידבקים שאנחנו מקבלים עוסקים ברמת המימוש הראשונית – חיבור של כל האפליקציות דרך תשתית מרכזית. לקוחות מדברים על כך שייצוב התשתית אורך זמן וגם שלא פשוט "לחנך" את המפתחים להשתמש בתשתית זו למול point to point. דבר נוסף בעייתי הוא נושא השליטה והבקרה. אין לעלות לאוויר ללא תשתית שליטה ובקרה מתאימה בין אם מפותחת בארגון או מוצר מהתחום של Run Time SOA Governence (כמו Amberpoint או DataPower). יש לציין שרוב הלקוחות מתייחסים לתשתית הקישוריות הארגונית כדבר הכרחי.
לגבי המדרגים הבאים יש פחות ניסיון כאשר מה שמעכב את התהליך הוא הצורך בשינוי ארגוני אך מצד שני ישנו פוטנציאל רב הן בחסכון כי מפתחים רק פעם אחת והן (יותר חשוב) באפשרות לענות על הדרישות העסקיות בצורה מהירה יותר. פידבק נוסף הוא שניהול הפרויקטים בצורה זו מורכב הרבה יותר.
זאת בקצרה. אני ממליץ גם לקרוא בבלוג של אבי רוזנטל שמכסה תחום זה בצורה מעמיקה וגם בבלוג של עקיבה מרקס בעל נסיון רב מהשטח. בכדי לקבל הסברים בעברית על המונחים הרבים בתחום זה מומלץ לבדוק ב- WIKIT.
1. סביבת קישוריות מרכזית- ESB (בעבר EAI) כל המערכות מדברות האחת לשנייה כולל רמה של web services דרך תשתית זו. זאת שיטת עבודה מקובלת אצל רוב הארגונים. התשתית מבצעת ניתוב, אבטחת מידע , LOGS, ואפילו לוגיקה בסיסית.
2. שימוש בכלי BPM (חלק מ- SOA) לביצוע משימה ספציפית – במקום קידוד בסביבת פיתוח רגילה. הדבר מתאים במיוחד כאשר המשימה הנה תהליך עסקי המערב אפליקציות קיימות הקיימות בטכנולוגיות שונות, צורות גישה מגוונות (גם GUI גם MAIL גם SMS גם קשר בין אפליקציות) וגם התהליך העסקי משתנה בצורה תדירה. ישנו ניסיון מסוים בשימוש בתחום זה בישראל.
3. כמו הפירוש הראשון אך קיים גם גורם אשר מרכז את הכנסת כל הממשקים\שירותים ומציע את לגופי פיתוח להשתמש בממשקים\שירותים קיימים. זהו שיפור חשוב שמחייב הכנסת כלי soa governance. גופי הפיתוח יכולים להשתמש בשירותים קיימים אך אינם חייבים.
4. המדרג החדש שהוספתי - כמו הפירוש הקודם אך אותו גורם מרכזי שמכניס את השירותים ל- ESB\SOA יכול לאשר או לבטל הכנסה של ממשק\שירות ולהכריח את הגורם הדורש להשתמש בממשק\שירות שכבר קיים (כלומר גורם זה לא רק מציע אלא גם מחייב).
5. הדרגה הגבוהה ביותר של SOA היא שישנה הסתכלות כוללנית על תהליך הפיתוח בארגון. כל משימת פיתוח מוצבת בפני גוף ארכיטקטים המחליט מי מבצע איזה חלק, האם להשתמש בשירותים שכבר קיימים, האם להשתמש בטכנולוגיה של BPM או בטכנולוגיית פיתוח סטנדרטית וכד'. כלומר גוף הארכיטקטים לא מסתכל רק על הממשקים\שירותים "חיצוניים" שאפליקציה צריכה אלא גם מה קורה "בתוך" האפליקציה. מימוש זה מחייב שינוי מהותי בתהליכי הפיתוח של רוב הארגונים. זאת מכיוון שברוב ארגונים לכל גוף עסקי יש גוף ב- IT שממחשב אותו. פחות או יותר בצורה אוטונומית – ללא הסתכלות כוללנית ומשותפת על כל האפליקציות בארגון.
מבחינת מידע מהשטח, רוב הפידבקים שאנחנו מקבלים עוסקים ברמת המימוש הראשונית – חיבור של כל האפליקציות דרך תשתית מרכזית. לקוחות מדברים על כך שייצוב התשתית אורך זמן וגם שלא פשוט "לחנך" את המפתחים להשתמש בתשתית זו למול point to point. דבר נוסף בעייתי הוא נושא השליטה והבקרה. אין לעלות לאוויר ללא תשתית שליטה ובקרה מתאימה בין אם מפותחת בארגון או מוצר מהתחום של Run Time SOA Governence (כמו Amberpoint או DataPower). יש לציין שרוב הלקוחות מתייחסים לתשתית הקישוריות הארגונית כדבר הכרחי.
לגבי המדרגים הבאים יש פחות ניסיון כאשר מה שמעכב את התהליך הוא הצורך בשינוי ארגוני אך מצד שני ישנו פוטנציאל רב הן בחסכון כי מפתחים רק פעם אחת והן (יותר חשוב) באפשרות לענות על הדרישות העסקיות בצורה מהירה יותר. פידבק נוסף הוא שניהול הפרויקטים בצורה זו מורכב הרבה יותר.
זאת בקצרה. אני ממליץ גם לקרוא בבלוג של אבי רוזנטל שמכסה תחום זה בצורה מעמיקה וגם בבלוג של עקיבה מרקס בעל נסיון רב מהשטח. בכדי לקבל הסברים בעברית על המונחים הרבים בתחום זה מומלץ לבדוק ב- WIKIT.
תגובה 1:
Next, do the same thing for the pandora jewerly right front side of the shirt.Once you have done Pandora Bangles both front sides of the shirt, you then will need pandora bead to do the back of the shirt. Take the shirt and place the back of the discount pandora shirt so that the direct middle is on the ironing board. The pandora sale back collar of the shirt should be right up at the edge discount pandora charms of the "head" of the ironing board or even slightly hanging off. Pull the bottom buy pandora bracelets of the shirt to create that taught resistance again and pandora beads charms begin to spray the shirt and iron in the opposite direction of pandora earrings the pull.p
הוסף רשומת תגובה