הקדמה
=====
לא מזמן הייתי בפגישה שבה הבחנתי, שוב, שאנשים לא באמת מבינים מה זה SOA (Service Oriented Architecture). בפגישה המדוברת, ובהרבה אחרות, שמעתי משפטים כמו "המערכת הזאת כתובה ב SOA" ו "עשינו WS אז זה SOA", שכשמבינים את המשמעות האמיתית של המושג הם ריקים מתוכן.
הקטע הבא לא מתיימר להיות כיסוי מלא של כלום. הוא נועד לתת רעיון מסדר לנושא ולהסביר את הרציונאל מאחוריו עם התייחסות היסטורית ורלוונטיות לעסק. בגלל זה, ובגלל שהוא עובד מהסבר שנועד במקור לאנשים שההבנה שלהם את עולם התכנה לא מספיק בשלה, אני נדרשת לסוגיות די בסיסיות קודם.
אז מה אנחנו עושים כאן, בעצם? (או – המתכנת בראי הארגון)
====================
אחת השאלות שרובנו לא עוצרים לחשוב עליהן בדרך כלל היא "מה אנחנו עושים כאן, בעצם?" – למה החברה שמעסיקה אותנו משקיעה ככה וככה זוזים בחודש כדי לשלם לנו משכורת + תנאים סוציאליים + רכב וטלפון סלולארי+ צהריים במזנון? הקורא התמים עשוי לחשוב בשלב זה שהסיבה לכך ברורה מאליו – אנחנו כאן כדי לתכנת! זה מה שכתוב בהגדרת התפקיד שלנו, לא?
אז זהו, שלא.
מאז שהאדם הראשון הבין שממחשבים אפשר לעשות כסף, אנחנו לא כותבים קוד רק כדי לכתוב קוד. הדבר שקל לאנשים במקצוע שלנו לשכוח זו העובדה שאנחנו לא חיים בבועה של טכנולוגיה – אנחנו חלק מארגון גדול יותר. לכל ארגון יש מטרה שלשמה הוא הוקם, וסט של מטרות ארגוניות שנגזרות ממנה. צה"ל כאן כדי לשמור על שלומם וביטחונם של אזרחי מדינת ישראל, גרינפיס פועלים לשימור הסביבה, ומה שטורד את מנוחתם של פרנסי קוקה קולה בלילות, למרות מה שמנסים למכור לנו בפרסומות, היא לא השאלה איך לעשות אותנו צעירים, יפים ומאושרים יותר, אלא איך למכור לנו כמה שיותר בקבוקי משקה, לקורת רוחם של בעלי המניות.
לכל ארגון יש מבנה ארגוני של מחלקות ותתי מחלקות שפועלות יחד ומתוך יחסי כוחות מסוימים כדי לקדם את המטרות שלו. אם נחזור לחברת המשקה האהובה, מחלקת כח האדם שלה שוכרת ומנהלת את האנשים שמייצרים את הרעל שמוכרים לנו, מחלקת הייצור שלה מייצרת אותו, ומחלקת השיווק מספרת לנו שבעצם זה נורא טעים. מחלקת ה IT (חברים, אלה אנחנו!) היא אחת מהמחלקות הללו. אנחנו כותבים את המערכות שמחלקות אחרות עושות בהן שימוש (ניהול רשומת עובד, מישהו?), מתחזקים את מסדי הנתונים של הארגון, ומספקים תשתיות מחשוב לשאר העובדים.
אבל רגע, זה לא מה שטענו שאנחנו עושים קודם? לא בדיוק. עכשיו שמנו יותר דגש על התמונה הגדולה ומערכת הכוחות בארגון כולו. הבחנה זו היא כללית, כמובן, אבל נקודת המבט הארגונית תהיה רלוונטית לנושא ה SOA בהמשך.
כל התורה על שלוש רגליים
==================
לכל מחלקה יש מדדים שמאפשרים לדעת עד כמה טוב התפקוד שלה. מה המדדים שמעניינים אותנו כשאנחנו בוחנים את מחלקת ה IT? הקלישאה אומרת שזה עולם כלכלי ושזמן שווה כסף, וכיוון שכך, שתיים מהשאלות החשובות ביותר הן כמה מהר אנחנו מספקים את הפתרונות שלנו, ועד כמה הם כואבים למנהל הכספים בכיס. מדד נוסף וחשוב נקרא IT/Business Alignment (It to Business Alignment). מדד זה עונה על השאלה – עד כמה הפתרון שאנחנו מציעים אכן תואם את צרכי המשתמשים בארגון?
עולם הנדסת התכנה קיים כבר כמה שנים והרבה מהידע שנצבר בתחום מתייחס לדרכים בהן אנחנו יכולים לשפר את התפקוד שלנו בשלושת המדדים הללו. לצורך הדיון הנוכחי, אני אתייחס לשלושה תחומים בהם צברנו ידע ולמדנו לשפר לאורך השנים:
- טכנולוגיה
======
טכנולוגיה היא המובן מאליו ומה שכולנו רגילים לחשוב עליו בתור פתרון של קסם לכל בעיה. תחת הכותרת "טכנולוגיה" אני כוללת את כל החומרה שלנו, שפות הפיתוח, המוצרים וסביבות העבודה שאנחנו רוכשים, בקיצור – כל מה שמרכיב את ה "מה" של עולם ה IT בארגון.
קל מאד לראות בעין בלתי מזוינת את ההתקדמות שעשינו בתחום במהלך השנים – אם פעם כדי ללמוד מדעי המחשב היית צריך לנקב כרטיסיות, היום, אחרי שעולם המחשוב עף דרך שפות אסמבלר, שפות עליות, RAD ומה לא, אפשר לכתוב תכנה בלחיצת כפתור (טוב, אולי לא :)). מספיק לקרוא את האג'נדה של .Net Framework כדי להבין מה הכיוון שאנחנו הולכים אליו – הסרת כמה שיותר מעמסות מהתכניתן כדי שהוא יוכל להתמקד בתכנות ה Business Logic ו (כן, ניחשתם) – לספק פתרונות איכותיים יותר, מהר יותר, וכפועל יוצא מכך – יותר בזול.
- ארכיטקטורה
========
ארכיטקטורה מתעסקת עם הצורה בה רכיבים שונים מתייחסים אחד לשני, כלומר – למבנה. הארכיטקטורה לא תלויה ישירות בטכנולוגיה (אפשר לממש את אותה ארכיטקטורה במספר שפות תכנות ועל גבי כל מיני כלים, לצורך הדוגמה), אם כי היא מושפעת ממנה.
גם תחום הארכיטקטורה התפתח במהלך השנים – אנחנו יודעים היום לכתוב בשפות Object Oriented ולעשות שימוש ב Design Patterns, אנחנו יודעים שכדאי להפריד את האפליקציה לשכבות כדי שאם משהו בצרכים של הארגון ישתנה יהיה לנו קל להחליף חלקים ממנה ואנחנו יודעים שזה רעיון טוב לעשות Reuse לקוד כדי לחסוך בזמן פיתוח.
כל השיטות הללו, בסופו של דבר, משפרות את היכולת שלנו לכתוב תכנה בצורה איכותית ע"פ המדדים שציינו.
- מתודולוגיה
=======
מתודולוגיה היא אוסף השיטות והתהליכים שאנחנו עוקבים אחריהם כשאנחנו מפתחים תכנה, כלומר – ה "איך" של הפיתוח. עם הזמן למדנו שיטות ששומרות עלינו ממוקשים ידועים: החל מדברים שהיום נראים טריוויאליים כמו אפיון האפליקציה יחד עם הלקוח (כדי להיות בטוחים שאנחנו יודעים מה הוא צריך), דרך סקרי קוד, ניהול תצורה ופיתוח איטרטיבי, ועד רעיונות יותר אקסצנטריים כמו פיתוח Agile (שיטות כמו XP, Scrum וחברים).
מפה לשם הגענו למצב שאנחנו יודעים לפת אפליקציות פחות-או-יותר "כמו שצריך": פחות-או-יותר בזמן, פחות-או-יותר בזול ופחות-או-יותר עושות מה שצריך.
אז אם אנחנו כל כך חכמים, מה אני רוצה מכם בעצם?
מי הזיז את הבעיה שלי?
================
כאן אנחנו חוזרים לנקודת המבט הארגונית שהשארנו מתחת לכותרת השניה. בואו נסתכל על הארגון הממוצע – בארגון כזה קם ברנש וחשב שיהיה חכם לנהל את כח האדם שבאחריותו, במקום בקלסרי קרטון, במערכת מחשוב אוטומטית. הועברו תקציבים, נחתמו הסכמים ובסופו של דבר קמה מערכת Java חדשה ונוצצת שעשתה בדיוק את זה. גברת נוספת חשבה שאולי כדאי לנהל את קשרי הלקוחות במערכת ייעודית משלה. אחרי סקר שוק מעמיק נרכשה מערכת CRM מבוססת דוט נט, ושנה מאוחר יותר החברה המדוברת התמזגה עם חברה אחרת שמנהלת את כל נושא הכספים מעל ה MF. הבנתם את הרעיון – עם הזמן תוספות ושינויים קטנים מצטברים ומה שאנחנו מקבלים זה עולם IT הטרוגני שמכיל שפע של יישומים שונים ממגוון טכנולוגיות.
הבעיה עכשיו היא שאנחנו הולכים ונעשים מתוחכמים בדרישות שלנו מהטכנולוגיה, ואם עד אתמול הסתפקנו במערכת ייעודית לכל תחום בארגון (Line of Business), היום הדרישות הולכות ונעשות חוצות ארגון ופתאום אנחנו מגלים שבעולם ההטרוגני שיצרנו, המערכות לא ממש מדברות אחת עם השניה. איך, למשל, גורמים לכך שכל חשבון שנפתח עבור לקוח במערכת הCRM הדוט נטית שלנו יגרום לפתיחת חשבון מקביל במערכת ה Billing על ה MF?
יש מגוון פתרונות לבעיה הזאת ואנחנו לא נכנס לכולן. היסטורית, עברנו דרך ניסיון לקשר בין מערכות בגישת P2P (חיבור ישיר בין מערכת אחת לשניה תוך שימוש בממשקים ייעודיים) וממשקי EAI (Enterprise Application Integration).
כיום, אני מבחינה בין שתי גישות עיקריות לפתרון הבעיה שהצגתי: ניסיון לבטל את ההטרוגניות בארגון (למשל, באמצעות מערכת ERP), או אימוץ של ההטרוגניות וגישור מעליה, כפי שעושים ביישום SOA.
איכס, זו בכלל לא ארכיטקטורה…
=====================
SOA היא גישה לניהול של ארכיטקטורה ארגונית. מה זאת אומרת? בחלק הראשון של המאמר דיברנו על הדברים שאנחנו שואפים להשיג בכתיבת אפליקציה אחת – פיתוח מהיר, זול ואיכותי. אבל כיוון שאנחנו פועלים בתוך ארגון וארגון נסמך על הרבה אפליקציות, השאלה הנוכחית היא איך נשיג את אותן מטרות עבור כל עולם ה IT של הארגון? כלומר, איך ניצור עולם IT שמגיב במהירות לצרכים של העסק (שאם תיזכרו – הם מורכבים יותר ויותר, והם חוצי ארגון ואפליקציות), ועושה את זה בצורה זולה ומדויקת? וכמו שאת התשובה במקרה של אפליקציה בודדת לא מצאנו בתחום אחד: לא טכנולוגיה, לא מתודולוגיה ולא ארכיטקטורה לבדן היו פותרות את הבעיה, כך SOA היא תפיסה כוללת והוליסטית שמגדירה איך צריך להראות עולם ה IT בארגון, והגדרתה כ"ארכיטקטורה" היא חלקית ומטעה.
תפיסת ה SOA, גם היא, מכילה שלושה תחומים עיקריים:
- ארכיטקטורה
========
הכי קל להתחיל לדבר על SOA מפן הארכיטקטורה. אם פתרון ה ERP גורס שכדי להתמודד עם ההטרוגניות בארגון צריך לבטל אותה, גישת ה SOA טוענת שיש לעשות שימוש בפתרון ארכיטקטוני כדי לגשר מעליה. ע"פ גישה זו, נסתכל על עולם ה IT בארגון כאילו הוא מורכב מ"שירותים" – "אבני לגו" של יכולות, אשר יכולות להיות ממומשות בכל טכנולוגיה שנבחר. למשל, מערכת כח האדם יכולה לייחצן יכולת של חיפוש רשומת עובד ע"פ מספר תעודת זהות. על מנת להקל על האינטגרציה של יכולות חדשות וקיימות, כולן ייעטפו ע"י ממשק סטנדרטי ואחיד שיגדיר הארגון, וכדי למנוע מצב של צמידות גבוהה בין מערכות, החיבור ביניהן לא יתבצע בצורה ישירה, אלא דרך מתווך שיעשה אבסטרקציה לקישור ביניהן
למה המצב דומה? לחיבור מכשיר חשמל לתקע החשמל. אני צורכת שירות (חשמל) באמצעות ממשק סטנדרטי (תקע החשמל) אחיד עבור כל הצרכנים. ספק השירות שלי הוא חברת החשמל, וכיוון שאני לא מחוברת ישירות לספק, אני לא יודעת מאיזו תחנת כח החשמל שלי מגיע כל פעם.
- טכנולוגיה
======
SOA היא תפישה שכל עניינה ממשקים. הסיבה לכך היא שרוב ההתעסקות ב SOA היא גישור בין טכנולוגיות. מהן, אם כן, הדרישות מטכנולוגיה שתתמוך במימוש SOA?
ממשקים מוגדרים היטב
בלתי תלויה בטכנולוגיה
סטנדרטית
אפשר לענות על הדרישות האלה במגוון דרכים, ובאמת, הטכנולוגיה שעושים בה שימוש כדי לממש SOA היא פחות "מעניינת" וכל עוד הצורה בה מתבצעת התקשורת היא אחידה ומוסכמת על כל הארגון, כל האמצעים כשרים. ארגון אחד יכול לממש SOA באמצעות פרוטוקול פנימי, ארגון אחר באמצעות מוצר MQ ואחר יפתח ממשקים מבוססי DB. עם זאת, הבחירה הנפוצה היא מימוש הממשקים באמצעות WS (לא בהכרח מעל HTTP, אבל זה נושא לדיון נפרד). יש לכך מספר סיבות:
תמיכה רחבה של היצרנים בטכנולוגיה
התבססות על סטנדרטים נפוצים כבסיס וסטנדרטים משלימים עבור יכולות מתקדמות
יכולת עבודה בין פלטפורמות שונות
- מתודולוגיה
=======
לארגון שמנסה לממש את תפיסת ה SOA יש פוטנציאל להיכנס לבלגן גדול: הדרישה לאחידות בין הממשקים משמעותה שהרבה מאד גופים צריכים לעבוד לפי אותם חוקים. ריבוי הממשקים בין המערכות גורם לרשת ענפה של תלויות, שאם לא מנהלים אותה נכון, עשויה להביא לכך שכשמשאב מסויים נופל, רק האורות האדומים בניטור יוכלו לספר לנו מה הנזק, וריבוי של שירותים שאינם מתועדים היטב לא יאפשר לנו לנצל את מגוון היכולות בארגון בצורה יעילה.
למעשה, האתגר האמיתי בSOA, כמו תמיד בפיתוח תכנה, הוא לא הטכנולוגיה, אלא ניהול האנשים כך שיפעלו בהתאם למתודולוגיה.
מאחר ואלו האתגרים העיקריים שיש להתמודד איתם ביישום SOA, חלק גדול ומרכזי בתפיסה מדבר על השיטות לניהול השירותים. תחום זה נקרא Governance והוא עונה על שאלות כמו "כיצד נגדיר שירות", "איך נדע אילו שירותים קיימים בארגון", "מה קורה כששירות משתנה" וכך הלאה.
אז מה למדנו, בעצם?
==============
הגדרנו רעיון מסדר לנושא ה SOA:
דיברנו על האתגרים בפיתוח תכנה (זמן, כסף, תכולות), ועל שלושה תחומים שאנחנו נוקטים בהם פעולות כדי לתת מענה לאתגרים האלה (טכנולוגיה, ארכיטקטורה ומתודולוגיה).
הראנו שלבעיות בפיתוח תכנה נתן לעשות אסקלציה לרמת הארגון, וש SOA היא תפיסה שנותנת מענה מסוג מסוים לבעיות הללו באותם שלושה תחומים (ארכיטקטורה, טכנולוגיה ומתודולוגיה).
ככה אני חושבת על SOA. בהמשך מאמרים קטנים יותר וממוקדים יותר במגוון נושאים קשורים.
שאו ברכה :)
