מאת : ערן לסר וזיו מנדל
אין ספק שאם נחפש את המילה הפופולארית ביותר במודעות הפרסום של יצרני התוכנה השונים (אורקל , יבמ ,מיקרוסופט, סאן , BEA , SAP , מג'יק) נראה שכולם חושבות כנראה שלמילה SOA יש כנראה השפעת "מאגית" בשיקולי הבחירה של הלקוח . כמעט כל המודעות והפרסומים של יצרני התוכנה מעוטרות במותג SOA וחברת אורקל אף הגדילה לעשות ושמה המושג הטכנולוגי על גבי לוחות מודעות של שילוט חוצות באחד מהקמפיינים האחרונים שלה. אין ספק ששנת 2007 תהייה כנראה שנת ה- SOA ולא רק ברמת לוח המודעות אלא גם מתוך הצורך של ארגונים להתמודד עם אתגר הזריזות ויכולת השינוי של התוכנה מצד אחד ומצד שני הרצון לשלב את הישן עם החדש. במסגרת הכתבה שלנו היום ננסה לתת על הקצה המזלג תאור ממצה על מה כל הרעש ומה צריך לעשות על מנת להצליח בהגדרת אסטרטגית ה- SOA של הארגון ובעיקר בהצלחת המימוש של חזון ה- SOA.
ה- SOA (Service Oriented Architecture) הינה תפיסה טכנולוגית ניהולית של בניית ארכיטקטורת מונחת שירותים. הבסיס והרציונאל העסקי של ה- SOA מדבר על הצורך לבנות את מערך פיתוח ותחזוקת התוכנה של הארגון כך שניתן יהיה לבצע שינויים ולהגיב בבניית פונקציונאליות נדרשת בצורה המהירה ביותר. מה המכשולים העומדים בפני היכולת שלנו לבצע פיתוח מהיר של שינויים וכתיבת פונקציונאליות חדשה ? הבעיה המרכזית הינה יכולת האינטגרציה ויכולת ההפעלה של רכיב תוכנה אחד מהשני. יכולת ההפעלה של רכיבי תוכנה בצורה מהירה , גמישה ובטוחה (כלומר שלא נצטרך להשקיע זמן רב בבדיקת השילוב) תאפשר לנו לייצר יכולת פיתוח מהירה על ידי שימוש ברכיבי תוכנה קיימים בארגון ומחוצה לו. השימוש ברכיבי תוכנה ישנים שנכתבו בעבר בארגון ועובדים היטב יחסוך כתיבה חוזרת ומיותרת. במקום לכתוב את אותם קטעי קוד (בקובול לדוגמא) מחדש נוכל פשוט לעטוף אותם ולהשתמש בהם מחדש. השימוש ברכיבי תוכנה חיצוניים אותם נרכוש מיצרני התוכנה או נאתר מתוך רכיבי הקוד הפתוח יאפשר לנו להשיג חסכון נוסף בכתיבת קוד שכבר נכתב בפועל על ידי אחרים. ה- SOA יאפשר לנו למזג ולשלב גם בין מערכות שונות בצורה יחסית קלה כך שלא נצטרך לכתוב פונקציונאליות כפולה בשתי מערכות. עם מערכת ה- ERP צריך למשל את רכיב הטיפול בלקוח היושב במערכת ה- CRM אנחנו פשוט נחבר דרך ה- SOA את הפונקציונאליות הנדרשת ב- ERP מתוך קטעי הקוד הקיימים ב- CRM
תפיסת ה- SOA נותנת לנו את היכולת לקשר בין הפעילויות והתהליכים ברמה העסקית של הארגון תוך חיבור רכיבי התוכנה השונים. בעזרת כלי ה- SOA נפרק את התוכנה בארגון לרכיבים שונים אותם אנחנו נעטוף במעטפת של שירותי רשת ונחבר מחדש דרך אותה מעטפת חדשה. טכנולוגיית ה- SOA מאפשרת לנו לעטוף רכיבי תוכנה קיימים במערכות לגסי , לעטוף רכיבי תוכנה חיצונים ורכיבי תוכנה חדשים ולבנות מערכת מידע אינטגרטיבי של חדש עם ישן. הדגש ביישום SOA צריך להיות מבוסס על כלי מתקדם שמיישם בצורה המתקדמת והמלאה יותר את הסטנדרט ומאפשר לקשר בין כל העולמות. הפתרון המערכתי בארגון בנוי כתהליך, לתוכו ממפים את השירותים השונים כמו "פס ייצור" מודולארי, של "מכונות IT". השימוש בסטנדרטים (מחברים סטנדרטיים בין מערכות) מאפשר לשבץ שירותים שנוצרו במקומות שונים, ע"י ספקים שונים, יחד עם שירותים קיימים המפורקים ונעטפים כשירות. ביישום תפיסת ה- SOA נשתמש בסט הסטנדרטים המקובלים כיום על כל התעשייה : XML - דרך סטנדרטית לייצוג המידע, SOAP - מבנה גמיש להגדרת מסרים, WSDL - שיטה פשוטה לתאר את השירות ליישומים אחרים ו – UDDI - היכולת לפרסם/לאתר את היישום.
כפי שציינו כבר קודם לכן לכל היצרנים יש היום פתרונות של SOA והשאלה מה הקריטריונים לבחירת המוצר המתאים. אנחנו מבחינים בארבעה קריטריונים מרכזים : קלות האינטגרציה, היכולת להתחבר לכל הסביבות, מהירות היישום ועלויות נמוכות (גם של התוכנה וגם של עקומת הלימוד והיכולת לבצע את האינטגרציה). על בסיס הקריטריונים שהגדרנו אנחנו מחפשים כלי SOA הכולל סביבת פיתוח אחת עם מילון נתונים מרכזי , המכסה את כל הטכנולוגיות והסביבות ללא העדפה ועם יכולת התאמה מלאה. חשוב מאוד שכלי הפיתוח של ה- SOA יהיו קלים לשימוש עם סביבה גראפית (כמעט ללא קידוד) ויכולת עבודה על בסיס משותף וקל להבנה מרמת מנתח המערכות והמשתמש העסקי ועד לרמת התוכניתן.כמובן שכלי ה- SOA שנבחר חייב להיות מבוסס על התקנים מקובלים בתחום ה- WEB SERVICES
מה ההמלצות שלנו לארגון ברמת הגדרת חזון ה- SOA ? ראשית חשוב מאוד להתחיל לעבוד בנושא הגדרת חזון ה- SOA של הארגון וחשוב מאוד ששנת 2007 (במידה והדבר לא נעשה עדיין) תהייה השנה של הגדרת החזון, בחירת הטכנולוגיה והתחלת היישום של תפיסת ה- SOA ברמת כול הארגון. חשוב לציין שכמו בכל עולם הטרוגני בהחלט יתכן שבחלק מהארגונים תפיסת ה- SOA תיושם על בסיס מספר פתרונות SOA כאשר במרכז ישב הכלי המרכזי ואליו יהיו מחוברים כלי SOA שונים שיתחברו לטכנולוגיות השונות הקיימות בארגון. בעולם אידיאלי כמובן שעדיף ללכת על פתרון אחד אבל במציאות המורכבת זה כנראה לא יקרה. חשוב מאוד להתחיל בשנת 2007 במימוש חזון ה- SOA על ידי בחירת האפליקציות הקיימות אותם נפרק ונעטוף במעטפת ה- SOA וחשוב להתחיל ולפתח את היישומים החדשים מראש על בסיס ה- SOA. יש לשים לב שבשלב הראשון המעבר ל- SOA דורש השקעות ליצירת תשתית ה- SOA ועל מנת שנוכל להנות מה- SOA ברמת גמישות ומהירות הפיתוח אנחנו חייבים ראשית לבנות תשתית של רכיבי תוכנה היושבת על ה- SOA. שלב זה הינו שלב שאיננו מביא פירות מיידים ברמת החזר ההשקעה והוא גם דורש בחירה נכונה של המקומות בהם ניישם אותו. לאחר מימוש העברת רכיבי התוכנה לתשתית ה- SOA חשוב מאוד לעסוק בתיעוד פרסום והדרכה של הרכיבים היושבים במילון הנתונים על מנת שבפרויקטים חדשים ובפעילות התחזוקה השוטפות יעשה שימוש באותם רכיבים דרך ה- SOA לשימוש חוזר ואינטגרציה קלה יותר
יש לכם הערות ? יש לכם הארות ? יש לכם שאלות ? אתם רוצים סתם לאמור לנו משהו ? אתם מוזמנים לפנות אלינו באי-מיל ziv@johnbryce.co.il