לפני מספר שנים ביקש ממני לקוח לפתח עבורו טופס אלקטרוני. פתחנו visual studio, באמצעות drag & drop לכמה שדות על המסך וכמה שורות קוד, קיבלנו טופס ונתוניו נשמרו בבסיס הנתונים. אחר-הצהריים המערכת עבדה, הלקוח מרוצה, והמחיר זול. הטופס, דרך אגב, עדיין עובד.
בחודש שעבר, לקוח אחר ביקש ממני לפתח עבורו טופס אלקטרוני. ישבנו עם הלקוח, קיימנו דיון האם לפתח את הטופס כ-smart client , דפי web או שההפעלה תהיה בכלל באמצעות terminal server. בכל מקרה, שכבת ה-GUI תתקשר עם יתר המערכת באמצעות web services. סיימנו להגדיר את שכבת התצוגה והתלבטנו אם וכיצד לשלב את הטופס במערכת BPM. לשם כך הגדרנו עוד כמה web services. אח"כ הגדרנו סכמת XML. את שכבת העיבוד ושכבת בסיס הנתונים (המערכת כתובה כך שאין תלות בבסיס הנתונים והלקוח יכול להחליפו פעמיים ביום). לבסוף, הגדרנו את השירותים אותם הטופס מחצין כלפי חוץ באמצעות web service. נעזרנו כמובן גם במנוע לניהול חוקים עסקיים, באמצעות ארכיטקטורת SOA.
אני מעריך שבשבוע הבא המערכת תעבור מבחני עומסים, בדיקות חדירה בהיבטי אבטחת מידע, בדיקות מול מערכת השו"ב ארגונית, שילוב הטופס בפורטל הארגוני, ועוד. מייד אח"כ נעביר את המערכת לייצור. גם הלקוח הזה יהיה מרוצה. אגב, שני הטפסים הנ"ל, זהים בפונקציונאליות.
התיאור אשר הבאתי בפניכם, כתוב כמובן בצורה מוקצנת ומטרתו היא להדגים ולחדד כי אין די בשימוש בטכנולוגיה איכותית - יש לדעת מתי להשתמש בטכנולוגיה, וכיצד ליישמה. זו היא מתודולוגית המימוש.
ההיסטוריה של פיתוח תוכנה מסתכמת בחיפוש בלתי פוסק אחר רמת הפשטה גבוהה יותר מהרמה שקדמה לה. חוק שימור האנרגיה, אחד מחוקי השימור הבסיסים של הפיזיקה, קובע שהאנרגיה איננה נוצרת יש מאין ואיננה אובדת, אלא עוברת "גילגולים" שונים והתמרה. ככל שרמת ההפשטה גבוהה יותר, כך עולה רמת הסיבוכיות של התשתית המממשת אותה. כדי שתוכניתן אחד יעבוד פחות, תוכניתן אחר צריך לעבוד קשה יותר. זהו חוק שימור האנרגיה, בתוכנה.
קצת על ה-SOA
טכנולוגית SOA משנה את תפיסת המיחשוב המבוזר המקובלת ומציעה מודל חדש של מערכות מידע. המעבר ליישום תפיסת ה-SOA כרוך בשינוי תפיסתי. ארכיטקטורת SOA היא קודם כל תפיסה רעיונית ורק אח"כ ארכיטקטורה פיזית וטכנולוגית. כלים, טכנולוגיות ומוצרים אינם מייצרים SOA באופן אוטומטי. לכן, תפיסת SOA ניתנת למימוש הן במערכות מידע חדשות והן כשיפור מערכות מידע קיימות.
לפני שנתייחס להיבטי הטכנולוגיה, יש להפנים כי מדובר בארכיטקטורה שונה של מערכות מידע. ארכיטקטורה זו מתייחסת לעולם המידע כאל רשת של רכיבים. הארכיטקטורה מאפשרת הפעלה טכנולוגית אחידה של כל רכיב ברשת, בלא תלות במקום המאחסן אותו. ברמה הפשטנית ביותר, SOA מהווה גישה ותכנון של עולם ה-IT כעולם שנותן וצורך שירותים. כל אחת מהמערכות אמורה להתממשק עם מערכות אחרות, לקחת נתונים רלוונטיים וליצור מערכת אחת שמספקת שירותים שונים ומגוונים, הכול תוך שימוש בשפה המובנת לכולם.
הרעיון המנחה הוא שפניה לקבלת שירות וקבלת תוצאות השירות הוא בפורמט מקובל שאינו תלוי פלטפורמה או טכנולוגיה. ישנם תקנים שמקובלים בעולם פתרונות ה-SOA כגון XML,SOAP,UDDI, WSDL ועוד.
SOA - העתיד כבר כאן
למרות שטכנולוגית SOA איננה טכנולוגיה חדשה וכבר נצבר בה ניסיון לא מועט, יש מספר טעויות החוזרות על עצמן בפרויקטים רבים, בעקבות ההנחה השגויה כי פרויקט SOA הינו עוד פרויקט טכנולוגי, בעוד שאל פרויקט SOA יש להתייחס כאל פרויקט ארגוני. קיימת חשיבות מכרעת לניתוח ולמיקום נכון של ארכיטקטורת ה SOA בארכיטקטורת הארגון. יש להפעיל שיקולי "עלות / תועלת" בצורה "מאוזנת" כאשר הנושאים המרכזיים עליהם יש לתת את הדעת הם:
1) האם ניתן לייצר שירותים באמצעות תוך ניצול יכולות של אפליקציות קיימות באמצעות הרחבות SOA ובכך לשמר את ההשקעה שנעשתה בעבר ולמקסם את הערך, או לחילופין יש לפתח שירותים חדשים על כל המשתמע מכך.
2) היכן ואיך למקם את השירותים השונים ועל בסיס זה לתפעל את המערכות לצורך ניצול נכון ומושכל של ארכיטקטורת SOA.
כאמור, טכנולוגית SOA איננה טכנולוגיה חדשה שיצאה לאחרונה. מחזור החיים של מוצרים הוא:
1) שלב הצגת המוצר,שיווק ויחצ"נות - המוצר מוחדר לראשונה לשוק.
2) שלב הצמיחה / התפכחות.
3) שלב הבגרות - התבססות כמציאות.
4) שלב הדעיכה והחלפה במוצר אחר.
ארכיטקטורת SOA נמצאת בסוף ההתחלה של שלב מספר 3 של מחזור החיים - שלב הבגרות והתבססות כמציאות. ע"פ ניתוחי אנליסטים, שלב זה יימשך כ 20 שנה בהם טכנולוגיה זו תוביל את תחום מערכות המידע. גרטנר צופה כי עד 2010, 50% מארגוני ה-IT יטמיעו SOA וכי מדובר בתהליך הכרחי המהווה פתרון לדרישה העסקית.
הניסיון המצטבר במימוש פרויקטי SOA משלבים 1 ו-2 במחזור החיים לעיל, מלמד כי SOA יכול להאיץ תהליכים עסקיים ולהזניק את הארגון קדימה. מאידך, הטמעה לקויה של SOA טומנת בחובה סכנות רבות. תפיסת SOA היא טובה ומועילה עבור ארגונים המפעילים מערכות מורכבות, מבוזרות, מרובות טכנולוגיות ופלטפורמות, כאשר SOA משמשת כתפיסה לשימור נכסים קיימים או/ו פיתוח שירותים חדשים.
מאידך, יש לחשוב פעמיים לפני הטמעת SOA במערכות SMB, בשירות חד פעמי, או בשירות המפותח מחדש כתחליף ליכולת קיימת במערכות הישנות. ליישום תפיסת SOA ישנן השלכות מעבר לתחום הפיתוח ובהם תחזוקה, ביצועי המערכות השונות, היבטי אבטחת מידע, שליטה ובקרה על השירותים ומדידת SLA. מימוש SOA שגוי יגרום יותר נזק מתועלת.
כיצד יש להיערך לפרויקט SOA?
בשלב הראשון של הפרויקט, יש לנתח ולמפות את תפיסת ה-SOA הארגונית כך שתתאים לצרכי הארגון. יש לנתח ולזהות את השירותים המרכזיים הן מבחינת היישומים והם מבחינת התהליכים העסקיים / המגבלות העסקית. שירותים אלו יהוו את שלד תשתית הSOA הארגונית. כל זאת עוד לפני שבוחרים את כלי התוכנה ליישום התפיסה בפועל. חשוב לזכור שלא כל שירות מתאים ל SOA ולכן יש לבצע ניתוח מושכל של הצורך העסקי.
לאחר שלב המיפוי, מגיע השלב השני. שלב בחירת הכלים והטכנולוגיות. השיקולים בבחירת הכלים והטכנולוגיות הינם רחבים ומתייחסים להערכת הארכיטקטורה הקיימת - תשתיות ומערכות הקיימות בארגון, ל-roadmap הטכנולוגי של הארגון, שיקולים כלכליים, וכד'. השיקולים פחות מתייחסים ליכולות מוצר כזה או אחר. מוצרי ה-SOA רובם ככולם דומים אחד לשני ונכון להתייחס אל המוצרים הטכנולוגים כ-commodities.
בשלב השלישי, מגדירים את מבנה הפרויקט, לוח זמנים, ניהול תהליכים, ניהול תצורה, מתודולוגית פיתוח, ניהול סיכונים ועוד.
לסיכום
אומרים שאינטגרציה היא מילה יפה לחיבור בלתי מתוכנן. לכן, כשמיישמים פרויקט אינטגרציה, ניכרת חשיבות מכרעת לתכנון ולמתודולוגיית המימוש. העלות הגבוהה של פיתוח מערכות מתוחכמות והצורך בשמירה על עדכניות לאור המרוץ הטכנולוגי מחייבת משנה זהירות. המתודולוגיה שפותחה בקבוצת מלם, המבוססת על ניסיון ועבודה בכל הפלטפורמות הקיימות, כוללת הבנת היעדים, תכנון ארכיטקטוני המשלב צרכים עסקיים עם טכנולוגיה ופיתוח המשולב במפת הדרכים של הארגון. גישה זו מבטיחה הצלחה במימוש הפרויקט.