ארכיטקטורה מונחית-שירותים (SOA): על מה המהומה?

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

לא מדובר ביהדות או בנצרות, אם כי בדת לא פחות אדוקה - ושמה: Service Oriented Architecture - SOA.

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

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

ישנן גישות שונות ל SOA, רובן כוללות אלמנטים בירוקרטיים של ארגון גדול:

• יש כאלו שחושבים שסט תקני ה WS-* הם הבסיס לכל פתרון, גם לאינטגרציה בין ארגונים וגם פנימית בתוך הארגון. כיום, זהו קומץ קטן וסהרורי, דיברתי על האלטרנטיבות כאן.
• יש כאלו שמאמינים ש SOA היא לא רק טכנולוגיה, אלא כמעט דרך-חיים. SOA חוצה את הצד הטכנולוגי וממפה את תהליכי העבודה הקיימים באירגון. כשרוצים להוסיף תהליך עסקי / אירגוני חדש יש ללכת ולמדל אותו ב SOA. סוג של איחוד שמיימי בין אדם ומכונה - שהגבולות הולכים ומטשטשים. כדי לתאר כמעט-כל תהליך בארגון יש לנהל אלפי שירותים. מי ששולט בשירותים שולט בארגון ויש לשים Governance מרכזי על השירותים והשימוש בהם. אלו הם האורתודוקסים של SOA. הם לוקחים את התורה רחוק, רחוק. לפעמים נדמה שעבורם SOA היא כמעט-מטרה ולא "עוד כלי". האמונה שלהם ב SOA - גדולה.
• יש כאלו שמנסים להעמיק בלמידת  הצדדים הטכנולוגיים של SOA. הם מתמודדים עם בעיות שונות ומשונות בעזרת כל מיני משחקים (Patterns) ברמת השירותים והרשת. הם משתמשים ב REST, אך גם ב WS-*. מנסים למצוא איזון בין השניים ולחתור במאמץ לא קטן ל"ארכיטקטורת SOA נכונה". הם מאמינים. אלו הם ה"כיפות הסרוגות" של SOA, הם הכי קרובים בתפיסה לחילונים, להם אין כל רגשות ל SOA, אבל לעיתים נדמה שאנשי ה"כיפות הסרוגות" מתאמצים קצת יותר מדי בכדי לפתור בעיות דווקא בעזרת SOA.

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

בראשית

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

לפני עשור (וקצת) דובר הרבה על Component-Based Development. הרעיון היה להחיל את עקרונות ה OO על "קוביות גדולות יותר". "אם תכנון מונחה אובייקטים הוא טוב, למה לא לעשות אותו גם ב High Level?" שאלו.

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

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

אמנם החשיבה של שירותים סותרת לכאורה את סגנון התכנון ה Object Oriented הנפוץ כיום, אך יש לה שני יתרונות:

היא פשוטה והיא עובדת. אין מניעה, ואולי אפילו מומלץ, שכל שירות יהיה בנוי בעצמו בצורה Object Oriented.

"כל מה שעשינו עד היום - רע, ומהיום הכל יהיה טוב" רומזת כרזה שיווקית של SUN, אחת המשקיעות הגדולות ב SOA.
נדמה לי שאני זוכר את השקף השמאלי מככב בצד ימין לפני עשור כשדובר על ארכיטקטורת N-Tier :)  מקור sun.com

שמות
ואלו שמות ומושגים בעולם ה SOA:
WS-*, ESB, EAI, SOAP, MOM, WSDL, UDDI, REST, SLA, DDS, JBI, CEA, E-SOA, Event-Driven SOA, Middleware, Business Process, BPM, BPMN, BPEL, SOMA ועוד ועוד...

סתם, לספוג קצת אווירה.


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

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

הכמסה של שירותים
על השירות לכמוס (= לא לשתף) את פרטי המימוש שלו. האם הוא בנוי Object Oriented או Data Oriented? האם הוא משתמש בבסיס נתונים או בזיכרון? האם הוא משתמש ב Cache או לא? - כל אלה פרטים שכדאי למנוע ממשתמשי השירות כך שלא ייקשרו אליהם ויפגעו משינויים במימוש.

Service Contract
לכל שירות יש חוזה פעולה ברור. החוזה של השירות הוא לרוב ה API.
עד כמה ששפות התכנות מפותחות - הן עדיין מוגבלות ביכולת הביטוי. חשוב להבין שה API הוא רק חלק מהחוזה הכולל. כלומר, בעזרת Interface בשפת #C או Java אני יכול לומר מהן המתודות והמשתנים שהשירות מצפה לקבל, אך אני לא יכול לבטא דברים כמו:

• האם קריאה לשירות היא יקרה או זולה (Performance)
• לאיזה התנהגויות הוא תוכנן ולאיזה לא (הנחות יסוד). באיזה מקרים הוא לא תומך או לא נכון להשתמש בו.
• התנהגות במקרי קיצון
• וכו'

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

• אכיפה ברמת השפה  (למשל טיפוסים) / פרוטוקול (למשל MIME TYPE).
• שמות נכונים של השירות, המתודות והמשתנים.
• מטאפורה, חלוקה לשירותי משנה בצורה שמכוונת את המשתמש נכונה.
• תיעוד, תיעוד תיעוד.

באופן תאורטי היה נחמד אם היה אפשר להחליף את שירות אחד בשירות עם מימוש אחר שעונה לאותו contract, מבלי שאף אחד מהלקוחות שלו ישים לב.

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

Service Policy

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

הרבה פעמים מקובל להגדיר כמה סוגי מדיניות שונים של שירותים. הדבר דומה לרשיונות קוד-חופשי נוסח Apache או GPL - במקום שספק הספרייה יתעמק בנושאים משפטיים על מנת להגדיר רשיון הוא בוחר בנוסח סטנדרטי שמתאים לו ביותר, מסט רשיונות קיימים. גם הצרכן של הספריה יכול מהר מאוד ללמוד: MIT = אומר משהו כזה, LGPL = אומר משהו כזה.

אין הגדרה חד משמעית מה אמור להכיל ה Policy - יש גישות שונות. יש כאלו שיכילו אלמנטים של אבטחה וגישה - יש כאלו שיכללו בהם SLA או צורת ההתקשרות (messaging, request-response). העניין המעניין הוא שזהו חלק בחוזה שמשותף להרבה שירותים ואין טעם להגדירו כל פעם מחדש, יהיה החלק מה שיהיה.


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

תכננו לעצמאות מירבית
כפי שציינו, השירותים לרוב יהיו חלק ממערכת מבוזרת. במערכת מבוזרת יש לעיתים Latency (אם היא מבוזרת על פני Data Centers) אבל גם ייתכנו כשלים: שירות לא זמין, נתק ברשת וכו'.
כשאתם מתכננים שירות עליכם לדאוג שהוא ימשיך לעבוד טוב ככל האפשר כאשר שירותים אחרים שהוא מסתמך עליהם אינם זמינים. טעות דבילית למדי (סליחה, היסטוריה אישית) היא לבצע קריאה סינכרונית שנכנסת לBlocking לשירות אחר. אם השירות האחר חי אבל תקוע - גם השירות שלכם ייתקע במהרה.
כאשר שירות אחר שאתם תלויים בו כושל - תרצו להחזיר תשובות פחות-טובות או להחזיר הודעות שגיאה. לא תרצו לא-להגיב או להתקע (ואולי לתקוע שירותים אחרים שאינם זהירים).


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

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

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

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

סכנה אחרונה שאציין היא התעסקות עם תקני WS-*. אלו תקנים סבירים לחיבור בין מערכות שונות מאוד (שפה שונה, אירגון שונה, מערכות Legacy) - אבל דיי overkill לרוב השימושים האחרים. התחילו בקטן עם שירותים מבוססי HTTP Messages או REST.


דברים
כמה דברי סיכום:

SOA קושרה בצדק או לא (תלוי את מי שואלים) ל Web Services ו WS-* עם הבעיות הרבות שלהם. SOA יכולה להיות מוצלחת למדי - אם מצליחים לעשות אותה במידה ובמקומות המתאימים.

ל SOA יש כמה ייתרונות ברורים:

• צורה פשוטה יחסית לבניית מערכת מבוזרת - מערכות שקל מאוד להסתבך איתן.
• פוטנציאל טוב לשימוש חוזר בקוד (רעיון נשגב, שפעמים רחוקות יוצא אל הפועל). שירות הוא רמה מצויינת לשימוש חוזר: בעל משמעות, אך לא נקודתי מדי.
• פרדיגמה פשוטה שקל להבין.
• בניה של שירותים עצמאיים עם תלות נמוכה תקל על ה Upgrade ותפחית את ה down-time של המערכת: ניתן לעשות upgrade לשירות אחד בלבד - ושאר השירותים יתמודדו עם ה down time בצורה טובה. יכולת זו תקל על יישום של Continuous Delivery.
• הגדרה של שירותים הפועלים ע"פ חוזים תקל על מתכנני המערכת לבקר את נכונות הארכיטקטורה של המערכת: ניתן להתמקד בחוזה של השירותים והתלויות בין השירותים - ללא הצורך להכיר כל פינה במערכת.

שמים לב לקשר בין הנקודות?
מערכות מבוזרות...? שימוש-חוזר בקוד...? Continuous Delivery ו Availability...?

SOA והענן. מקור: http://webtechnologiesarticle.blogspot.com/

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


בהצלחה והמשיכו בזהירות. נתראה בחגים!

עננים ציבוריים ועננים פרטיים (Cloud Computing)

זהו פוסט המשך לפוסט שדיבר על PaaS, SaaS ו IaaS, ולפוסט 10 תכונות של שירותי ענן.

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

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

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

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

כשאמזון הציגו את פתרון הענן שלהם הם עשו תצוגת תכלית של אבטחה: קירות בטון, מצלמות אבטחה, שומרים מגודלים וכלבים רעים. משהו נוסח חומת ברלין בזמן המלחמה הקרה[1]. "בוודאי יותר אבטחה ממה שיש לכם היום" הם הצהירו. מה קרה מאז? עד כמה מנגנון האבטחה החזיק מעמד? אף עובד שכפוף אליכם לא יכול "לקפוץ לביקור פתע". מנהלים מכירים היטב את הפער ברמת המחויבות של עובדים שכפופים אליהם וכאלו שלא.
במידה רבה אלו הם שיקולים פסיכולוגיים, קרוב לוודאי שגם אמאזון דואגים לאבטחה - יש להם הרבה מה להפסיד. בכל זאת אלו דאגות מוחשיות המקשות על ארגונים לעבור לענן ציבורי.

אינטרנט פרטי?
באופן דומה להפליא, ארגונים רבים התקנאו בעבר באינטרנט וכל היכולות שהוא הציע. בתחילת שנות התשעים רוב הארגונים עוד עבדו עם רשתות של נובל או מייקרוסופט שתוכננו במקור לקנה מידה קטו בהרבה: עשרות עד מאות מחשבים. טכנולוגיות כמו Token Ring ו NetBIOS (או גרסה יותר מתקדמת שנקראה NBF) איפשרו יכולות די בסיסיות והיוו את הסטנדרט הארגוני. "רשת" לא הייתה יכולת מובנית במערכת ההפעלה. על המשתמש היה להתקין מערכת הפעלה, "חומרה יעודית לרשתות" (כרטיס רשת) ותוכנה (נובל או מייקורוספט) להרצת הרשת. לנובל, אם אני זוכר נכון, היה נדרש שרת ש"ינהל את הרשת". חשבו באיזה קלות אתם מתחברים היום עם ה iPad לרשת הביתית.
האינטרנט נחשב לאיטי (הגישה לרוב הייתה דרך קווי טלפון), חסר תמיכה בצרכים ארגוניים (לדוגמא הדפסה) ובלתי-ניתן לשליטה. בכלל - הוא תוכנן כאילו יש בעולם רק אינטרנט אחד(!). למרות זאת, טכנולוגיות האינטרנט היו יעילות בהרבה וככל שלארגונים נוספו עוד ועוד מחשבים, "הרשתות הארגוניות" התקשו לעמוד במשימה.

בתחילת שנות ה-90 אוניברסיטאות, וכמה שנים אח"כ גם ארגונים עסקיים, התחילו להטמיע "טכנולוגיות אינטרנט" ברשת הארגונית. על מגבלת המחסור ברשתות התמודדו עם subnet masking ואת שירותי ההדפסה העבירו על גבי TCP. בהדרגה, פחת החלק של הטכנולוגיות של מייקרוסופט ונובל והוחלף ע"י טכנולוגיות אינטרנט סטנדרטיות: HTTP, אתרי אינטרנט ("פורטל ארגוני"), Firewalls, דואר אלקטרוני ועוד.
הסיפור אינו אמור להפליא, הוא מתרחש שוב ושוב במהלך ההיסטוריה: טכנולוגיה עם ייתרון מובנה (scale במקרה שלנו) מתחילה בעמדת נחיתות, המתחרים מזלזלים וצוחקים עליה אך הבעיות בה נפתרות אחת אחת עד שהיא הופכת להיות מתמודדת ראויה. בשלב זה הייתרון המובנה של הטכנולוגיה החדשה אינו ניתן לחיקוי ע"י המתחרים המסורתיים - והמערכה מוכרעת לטובתה. כך היה עם הטלפון שבגרסאות הראשונות היה מוגבל לטווח של 10 ק"מ ודרש חיווט ידני. מנהלי המוצר של חברות הטלגרף, חברות בעלות אמצעים אדירים, צחקו על הטלפון והסבירו ש"בשביל 10 ק''מ תלך ותפגש עם האדם פנים-מול-פנים. כל הבלאגן כדי לדבר איתו בטלפון הוא פשוט use-case מגוחך". בל ניסה למכור ל Western Union את הפטנט ב 100,000 דולר - אך הם ויתרו. התוצאה כיום ידועה. הרכבים הראשונים היו ללא בלמים, על הנהג היה ללחוץ על הקלאץ' כל הדרך לעצירה. חברות הרכבת, תאגידים עצומי-מימדים, גיחכו והתעלמו. התוצאה ידועה. כך גם עם המחשב הפרטי (PC) ועוד ועוד... [3]

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

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

• ענן פרטי (Private Cloud)
• ענן מנוהל (Hosted Cloud)
• ענן משותף (Community Cloud)

ענן פרטי
מגמה שתופסת תאוצה היא ארגונים שרוצים להריץ את אפליקציות הענן - In House. "שלחו לנו את ה Appliances" הם מבקשים מאיש המכירות של אפליקציית ה SaaS - "ה IT שלנו יתקין ויתחזק אותם, מקסימום עם קצת תמיכה מכם". ספקי הענן לרוב מופתעים בהתחלה - אך יש כסף בצד השני והמעבר הוא לא כ"כ קשה:

• אפליקצית הענן לרוב נכתבה עבור חומרה לא ידועה. ניתן לבחון שרתים סטנדרטיים של חברות כמו IBM או HP ולמכור אותם כ "Appliance".
• נוהלים וכלי אוטומציה לניהול הענן - כבר יש. לבנות גוף תמיכה על בסיס ידע קיים - לא כ"כ קשה.
• "טכנולוגיות הענן" אינן נחלתן הבלעדית של אמזון או מייקרוסופט, ישנן ספריות קוד-פתוח כגון OpenStack או vCloud שמספקות יכולות דומות.

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

שאלה לגיטימית היא למה פתרון שכזה הוא "ענן פרטי" ולא "Data Center מנוהל מרכזית"?
השוני הוא, במידה רבה, בשימוש בוירטואליציה. וירטואליזציה שמאפשרת לאפליקציות לרוץ על מספר שונה של שרתים - ע"פ הצורך. אמנם הארגון צריך להחזיק מספיק מכונות לתמוך ברגעי שיא של צריכה, אך הוא יכול לווסת בין האפליקציות השונות שרצות על אותה חומרה. הסבירות ל Peak בשימוש בכל האפליקציות בו-זמנית הוא קטן[4]. עוד יכולת מעניינת היא היכולת של ה IT לחייב את היחידות הארגוניות השונות ע"פ שימוש בשירותי המחשוב בפועל.
לרוב הענן הפרטי יהיה קצת יותר יקר מענן ציבורי - יש פחות ייתרון לגודל והנצילות של החומרה נמוכה יותר, אך יתרונות האבטחה והרשת המהירה מצדיקים את מחיר הפרמיום עבור ארגונים רבים.

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

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

ענן מנוהל
זהו שלב-ביניים בין ענן פרטי לציבורי: ארגון הרוצה אבטחה גבוהה ורשת יציבה ממה שמספקים ספקי ענן ציבוריים, אך לא רוצה לנהל את הענן בעצמו. חברות כמו HP, GoGrid ו IBM ישמחו לעשות זאת עבורו עבור תשלום (לא-)צנוע. חברות אלה מספקות שירותים של Hosting ל Data Centers של ארגונים כבר במשך שנים והן צברו מיומנות לא מבוטלת. אמנם ספק ה Hosting יושב באתר מרוחק (עם כל המגבלות שבכך), אך עבור התשלום המתאים הוא ישמח לפתוח VPN על גבי קו אינטרנט מהיר שישפר בהרבה את ביצועי הרשת והאבטחה שלכם.

ענן משותף
סוג ענן זה הוא עדיין בחיתוליו - אך נראה שיש לו הרבה פוטנציאל. חשבו על הענן הפרטי שמקימה רשת בתי חולים גדולה, למשל (Hospital Corporation of America (HCA - רשת אמריקאית של 150 בתי חולים ב 270 אתרים. HCA הוא ארגון-העל המשרת בתי-חולים רבים. כאשר ארגון מנהל מידע רפואי של חולים, יש עליו דרישות מחמירות בתחום אבטחת הפרטיות של של חולה. רופא שיחשוף פרטים חסויים של מטופל - עלול להשלל רשיונו. מה יקרה לאיש-IT רשלן? לצורך כך הגדירו בארה"ב תקן מחמיר בשם HIPPA המחייב ארגונים המחזיקים במידע רפואי של חולים לנהוג ע"פ סדרה מסוימת של נוהלים. אני לא מקנא בקבוצת הפיתוח שתאלץ להתמודד עם התקן בפיתוח תוכנה בענן,  אך לאחר שתאימות ה-HIPPA הושגה, תוכל HCA להציע את השירות לכל בתי-החולים ברשת.
ומה עם שותפי-מחקר? אוניברסיטאות, חברות תרופות ועוד? גם הם מחזיקים במידע רגיש הנכלל בתקן ה HIPPA. מלבד הייתרון של "לא להמציא את הגלגל מחדש", יש עוד ייתרון לאותו שותף עסקי שיצטרף לענן של HCA: הוא יוכל להציע את השירותים שלו לבתי-החולים השונים עם Latency נמוך (הרי השירותים יושבים באותו Data Center) ואבטחה גבוהה (התקשורת לא עוברת באינטרנט הפתוח)!

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

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

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

בהצלחה.


הערות שוליים

[1]  מערך ההגנה של חומת ברלין הוא סיפור מעניין בפני עצמו:

• 302 מגדלי שמירה עם שומרים חמושים.
• קיר בטון חלק בגובה 4 מטר עם גדרות תייל בראשו
• שדה של ברזנטים מחודדים (שנקרא "העשב של סטאלין") שמקשה מאוד על ריצה והופך נפילה למסוכנת.
• 20 בונקרים עם שומרים בקו ההיקף של השדה
• מאות שומרים חמושים מלווים בכלבים תוקפניים
• שביל גישוש ברוחב 6 עד 15 מ' עם פטרול לגילוי חדירות למרחב
• תעלה למניעת מעבר של רכבים
• גדר חשמלית וגלאי תנועה
• מרחב גדול שהושטח על מנת להסיר מקומות מחבוא אפשריים (שנקרא "רצועת המוות")

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

[2] מנכל אינטל, אנדי גרוב, ניסה ללמוד את הלקח וגרס "רק הפרנואידים שורדים". עד היום אינטל הפליאה להיות קשובה לשינויים: קו מעבדי הסלרון, מעבדים חסכניים באנרגיה ועכשיו מעבדים למחשבי tablet ואבטחה בחומרה. כל אלו תגובות של אינטל למגמות שלא הומצאו אצלה אך היא נותרה קשובה. האם מודעות מספיקה? האם ארגון רגיש-לשוק יצליח להיות מספיק גמיש כדי לשרוד את שינויי המגמה בעולם? האם התרבות הארגונית וההשקעות הקיימות לא יכבלו אותו, מתישהו, להשאר בפינה "נוחה"? שאלה טובה - אין לי תשובה.

[3] המעבר מ Appliances לענן הוא לרוב קשה בהרבה!

[4] אמזון וספקי IaaS אחרים אוהבים ליצור את הרושם שיש להם Data Centers אינסופיים - אך גם הם מוגבלים.

על Domain Driven Design

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

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

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

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

כיצד ניתן לשנות זאת?

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

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

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

ובכן, היכונו! אוונס וה DDD (כלומר [Domain Driven Design [1) הולכים ללמד אתכם כיצד לקבל דרישות איכותיות יותר וכיצד לבנות מערכת שתהיה גמישה יותר לקבלת דרישות עתידיות. הדרך להתמקצעות היא לא פשוטה, אך כל מי שיש לו גישה לדרישות של לקוחות וקצת חשיבה מופשטת יכול די מהר להגיע לתוצאות ראשונות.

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

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

על התהליך הנפוץ לתכנון תוכנה
לא משנה אם אתם עובדים Waterfall או Agile, קרוב לוודאי שהמתכנתים לא אוספים את הדרישות מהלקוח בעצמם. יתרה מכך, גם שמדברים עם הלקוח לא תמיד יהיה זה המומחה העסקי. ייתכן ואתם מדברים עם מנהל התפעול בבנק ("לקוח") שרוצה מערכת לניהול משכנתאות, אבל אתם לא מדברים עם מי שמתעסק עם זה בפועל (Domain Expert). על מנת לפשט לכם את הנושא, מנהל התפעול משתמש במושגים שיותר קלים להבנה. ה PM לוקח צעד אחד הלאה ומשתמש במושגים יותר מקובלים מהעולם-הלא-מקצועי כי "מפתחים יאבדו כיוון אם נציף אותם בכל המידע הזה". זהו הרי תפקידו.
הארכיטקט או המומחה הטכנולוגי מפשט את הדברים קצת יותר להתאים לתשתית הקיימת , זה תפקידו, והופ - המפתחים מבינים בקלות על מה מדובר וניגשים מייד לעבודה.

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

מקור: softwarearchiblog

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

מקור: softwarearchiblog

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

בואו נעצור לרגע: אנו מדברים במושגים ("חשבונית") ובתסריטים (Use-Cases) אך מאחורי כל אלה יש לנו מודל תפיסתי (Conceptual Model) שמתאר איך הדברים מתרחשים. בני-אדם, כמונו, נוטים להרגיש אי-נוחות בעת שהם עוסקים בנושא לא מוכר. כתרופה, מנגנוני החשיבה שלנו גורמים לנו להשלים, באופן כמעט מיידי, את סט העובדות שניתנו לנו למודל תפיסתי הגיוני (מבחינתנו). איכות העובדות שהועברה לנו, כשרון ומזל יכתיבו עד כמה נכון המודל שבנינו. לא מעט ריבים / חוסרי-הבנה נוצרים בגלל הפער שבין המודל של אדם א' לאדם ב', שניהם ניזונו מאותן עובדות.

הפתרון "הרשמי"
אז מה עושים? אחד העקרונות המרכזיים של DDD הוא שפה-רוחבית (ubiquitous language). על מישהו, ה business analyst, לחפור ללמוד ולהגדיר עם ה DEs שפה אחידה ומוסכמת על פיה כולם יעבדו, שפה שבעצם תגזר מתוך Conceptual Model ברור ומלוטש (במידת האפשר).

מקור: softwarearchiblog

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

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

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

אז מה יותר יציב מרשימת use-cases ומסכי UI? היכן אנו יכולים להשקיע בלמידה של המקור ממנו באות הדרישות? ידע יציב שאינו נוטה להשתנות בקלות?
ובכן - זהו ה Domain, תחום העיסוק, הביזנס, הידע שמי שעוסק בתחום חייב לדעת על מנת לעסוק בו. הביזנס אינו משתנה במהירות.

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

ע"פ DDD, יש להשקיע זמן לא דווקא בשמיעת עוד דרישות וציור עוד מסכים - דבר שאנו מתפתים לעשות, אלא בלמידה לעומק של הדומיין. הדומיין יתואר במודל (להלן Conceptual Model) שהשימוש בו יהיה חוצה גבולות: לקוחות, מחלקת מוצר/שיווק ומחלקות הפיתוח השונות. כל דרישה עתידית תעבור דרך אותו מודל ותעדכן אותו ע"פ הצורך, אך סביר שהשינויים יהיו קטנים והגיוניים.
אם הקוד יהיה שיקוף של המודל - גם השינויים בו יהיו קלים יותר.

המודל לא צריך להיות מושלם או מפורט במיוחד - הוא צריך להיות נכון לשם המטרה ומועיל.
דרך מקובלת ונוחה לתאר מודל היא תרשימי Class Diagram של UML. כמובן שזו רק דרך אחת, אפשר בכל תרשים חופשי, טקסט וכו'.

מודל קונספטואלי המתאר פעולה בנקאית. האם המפתחים, מנהלי המוצר והלקוחות שותפים לאותה תמונה (או הבנה)? מקור: martinfowler.com

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

אילוסטרציה: domain experts.
כמעט ושמתי תמונה אומנותית של מנהל חשבונות זקן משנות ה-50, אך כנראה שבישראל בשנות ה-10, תתקלו יותר ב domain experts שדומים לאלו, שני מנהלים ב-888.
מקור: כתבה ב"אנשים ומחשבים".

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

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

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

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

כלל #2: אם אינכם יכולים לבטא רעיון מרכזי או דרישה (למשל: "יש בסוף כל שנה להוציא דו"ח של החשבוניות שלא זוכו ממס") מבלי להתבסס על המושגים הבסיסיים במודל - עליכם לחזור ולהבין למה. לרוב זה יהיה אי-דיוק, בהירות או שלמות של המודל.

זכרו: "(You can run, but you cannot hide (a bad conceptual model". אם "תשקרו" את המערכת ותעבדו עם מודל לא מדוייק, זה יחזור אליכם בדמות תחזוקה קשה ודרישות עתידיות הקשות ליישום.
לדוגמא: תיאור של מחשב עם 2 כתובות IP כשני מחשבים עם אותו השם, כל אחד עם כתובת IP אחת - אולי יקצר את הפיתוח בשלב הראשון, אך יחזור אליכם כמוברנג כחלק מדרישות עתידיות. ניסיתם "לשקר" במודל.

סיכום
למי שהתנסה בהצלחה במידול בכלל או DDD בפרט, מידול נראה חלק הכרחי בבנייה של כל מערכת. תורת המידול אינה נפוצה ואינה קלה - אך היא מביאה תוצאות ממשיות. המקור הטוב ביותר שאני נתקלתי בו עד היום הוא הספר Analysis Patterns של Martin Fowler, ספר קצת לא-מסודר אך בעל תובנות עמוקות.

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

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

[1] בעברית: תכנון מונחה-תחום, תרגום לא כל-כך מוצלח לדעתי - אך לא מצאתי טוב יותר.

כיוונים חדשים-ישנים במתודולוגיות פיתוח תוכנה (Data-Oriented Programming)

תשאלו אנשים הכותבים מערכות ב #C או Java מהי מתודולוגית הפיתוח הנפוצה ביותר כיום וקרוב לוודאי שתשמעו "תכנות מונחה-עצמים, ברור!".

הייתי מקשה ושואל: "איך עובד לכם תכנות מונחה-עצמים, טוב? עומד בציפיות?" והתשובה היא לרוב "האמת, ביננו? קצת חטאנו ויש מה לשפר - אבל בגרסה הבאה קצת נשפר / במערכת הבאה נכתוב הכל 'כמו שצריך' והכל יהיה טוב..."

ובכן, לצערי רוב המערכות שראיתי (וראיתי) היו לא-מוצלחות בהיבטי ה Object-Oriented. כינויים נפוצים למערכות אלו הן:

• Anemic Object Model - מצב שבו האובייקטים הם דלילים ולרוב מחזיקים רק נתונים או רק פונקציות.
• או Big Ball Of Mud - "גוש גדול של בוץ" (שהאמת, מתייחס למגוון רחב יותר של בעיות).

רבים מאיתנו רוצים ליצור תוכנת Object-Oriented הבנויות לתפארת עם Domain Model עשיר, אך אנו נכשלים לעשות זאת שוב-ושוב. האם רוב המתכנתים בעולם גרועים? או שאולי מתודולוגית ה Object-Oriented אינה טובה? (השם ירחם - דברי כפירה)

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

אז אם לא תכנות מונחה-עצמים, אז מהי האלטרנטיבה? תכנות פרוצדורלי? תכנות פונציונאלי? או אולי לכתוב את כל המערכת בפונקציה אחת גדולה? (הכי קל - בהתחלה)

פיתוח מונחה-נתונים (Data Oriented Programming)
בתכנות מונחה-עצמים, האובייקטים הם במרכז ובתכנות פרוצדורלי - הפונקציה היא במרכז. בתכנות מונחה-נתונים (DOP מותר לבטא כ Dope) תשומת הלב נעה מן הקוד לכיוון הנתונים: מהו הקלט, איזה טרנספורמציות (עיבוד) המידע עובר וכיצד הוא נראה בסוף.

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

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

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

על האנומליה של הזכרון
בוודאי למדתם באוניברסיטה קורס "מבני נתונים" - קורס חשוב המכסה חומר לא טריוויאלי.
למדתם שיש רשימה משורשרת עם הכנסה של (O(1 ו"טיול" (traversal) של (O(n, ויש וקטור (נקרא ArrayList ב #C וג'אווה) עם מחיר הכנסה של (O(1 או (O(n (עבור הכנסה באמצע או מילוי המחסנית שהוקצה) ו"טיול" (traversal) של (O(n.

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

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

פיזור מקובל של תפוסת-זכרון של רשימה משורשרת (באדום). מקור: תוכנת ה disk defrag שלי ;-)

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

• אנו יודעים שמערכת ההפעלה עובדת עם Virtual Memory. אם בלוקים של זכרון בהם שמור אלמנט אחד לפחות מהרשימה שלנו הם paged out (כלומר נשמרו לדיסק על מנת לשחרר זכרון פיסי), מערכת ההפעלה תקבל Page Fault שיגרור Context Switch וטעינת הדף / כתיבת דפים אחרים לדיסק - פעולה יקרה!
• זכרון המטמון (בעיקר L2 ו L3) במעבד נוטים לעשות prefetch ואחזקה של בלוקים של זכרון - לא תאי זכרון בודדים. כאשר אנו משתמשים בזכרון רציף גישה זו תהיה מועילה, אך עבור רשימה משורשרת היא יכולה אפילו להזיק ולבצע prefetch לזכרון לא רלוונטי [1].

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

במשך 30 השנים האחרונות - המעבדים הלכו והפכו מהירים עוד ועוד , משמעותית מהר יותר מהקצב בו התפתח הזכרון. אם ב 1980 המעבד המתין Cycle אחד לקריאה מהזכרון, היום הוא ממתין בערך 400 Cycles. הבעיה מחמירה כאשר הזכרון הזמין גדל (המעבר לעבדי 64 ביט פרץ את גבולות 4GB זכרון) ואנו רוצים להשתמש בזכרון על מנת לעבד כמות רבה יותר של נתונים - בעיה הידועה כ"צוואר הבקבוק של פון-ניומן". מעבדים מודרניים יודעים לעבוד עם Bus רחב בהרבה לזכרון, כלומר קריאה של יותר ביטים במקביל שמושגת ע"י קריאה (וכתיבה) במקביל מ 2 עד 4 יחידות זכרון (עקרון שדומה מאוד ל RAID 0 בכוננים קשיחים).

שיפורים בביצועי המעבד מול הזכרון ב30 בשנים האחרונות. מקור: Computer architecture: a quantitative approach

כיצד מתכנתים ב Data Oriented Programming
אלו שפות הן שפות "Data Oriented"? ובכן, השפה היחידה שאני יכול לחשוב עליה ככזו היא SQL: אנו מודעים לטבלאות וחושבים בפעולות על הנתונים. לטבלה B יש Foreign Key המצביע על טבלה A? אנו יכולים לבצע Select על טבלה B ולמצוא את כל ההצבעות - אין צורך (או משמעות גדולה) בהצבעה כפולה (כמו באובייקטים). ב #C יש את LINQ שהיא אמנם שפה לטיפול בנתונים, אך טבעית מאוד גם לנתונים במודל אובייקטלי - לכן אני לא בטוח שהיא דוגמא טובה.

העקרון של תכנות מונחה נתונים Per-Se הוא להחזיק נתונים (כאשר יש רבים מהם) בזכרון בצמידות. ממש כמו שמירה של טבלאות של בסיס נתונים רלציוני. כך יהיו לנו הרבה Collections גלובאליים של "אובייקטים", כאשר האובייקטים הם רזים (יותר דומים ל struct של נתונים ופחות אובייקטים קטנים ועשירים). מצד שני יהיה ניתן להפעיל כל פעם פונקציה אחרת על אותו struct - מעבר שהוא "זול" מבחינת עלות זכרון (מכיוון שיש יחסית מעט פונקציות נפוצות שיכולות להשמר ב Cache).
בעוד תכנות מונחה-עצמים יוצר מבנה דומה ל LinkedList - אובייקטים הפזורים לכל עבר בזכרון, כאשר קריאות getX.GetY.GeyZ המפורסמות של ג'אווה מדלגות בזכרון לא-רציף, תכנון מונחה-נתונים הוא דומה יותר לוקטור (ArrayList) רציף בזכרון המאפשר להשתמש ב Cache בצורה יעילה ופונציות שונות שפועלות בצורה ממוקדת על הנתונים ללא "קפיצה" תכופה לאובייקטים אחרים.

השימוש בData-Oriented Programming כמתודולוגיה מקובלת חזר בשניים האחרונות בעקבות אפליקציות ה Mobile (כלומר Android, iPad, iPhone) - אפליקציות קטנות הנכתבות עבור מכשירים בעלי כח עיבוד חלש.
מתכנתים מדווחים על ביצועים גבוהים פי 2 עד 4 בהמרה של אפליקציות Object Oriented להיות אפליקציות Data Oriented ובקלות פיתוח גבוהה יותר.

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

כמו שאנשים חששו להשתמש ב"אובייקט פשוט של ג'אווה" (והשתמשו ב EJB) עד שניתן לו השם המכובד POJO, כך גם אין לחשוש בתכנות מונחה נתונים ולהתייסר שאנו לא כותבים OOP, הנה עכשיו יש לו שם מכובד: DOP.
בסופו של דבר כל אלו הם כלים, עם יתרונות וחסרונות, ומקצוען אמיתי ידע לבחור בניהם בחוכמה ולא ייקלע למלכודת של "חייבים לעבוד ב EJB או OOP או <כלי אחר> - כי כולם עובדים כך".
דוגמא קרובה נוספת היא ההצלחה של REST - מודל פשוט וממוקד נתונים / פרוטוקול רשת, שהצליח יותר בשטח ממודלים מונחי אובייקטים או שירותים, ארכיטקטורות נבונות מגובות בהמון תאוריה.

אני חושב שאפשר בהחלט לכתוב מודולים במערכת שהיו מונחי נתונים, ועדיף שזה יהיה מהלך מודע. תכנות מונחה-עצמים הוא בהחלט לא קדוש.
גישה אחת ל DOP היא הגישה הקלאסית[2] (מערכיים של structs) וגישה אחרת היא עבודה עם בסיס נתונים רלציוני בזכרון (כגון H2, HSQLDB או SQLite), עם היכולת לשמור את הנתונים לדיסק בקלות ובכל רגע.

היתרונות של DOP על OOP
אני מניח שהיתרונות של OOP (הכמסה, מידול, ריבוי-צורות ועוד) מוכרים לכולם, בואו נסקור כמה יתרונות של ה DOP:

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

Unit Testing
מי שעובד עם unit tests יודע שהכי קל לכתוב בדיקות לפונקציות המרה פשוטות של נתונים, כמו פעולות parsing, למשל. שימוש ב DOP יהפוך גם את ה unit tests לפשוט וטבעי יותר מכיוון שיהיו הרבה יותר פונקציות ש"רק מעבדות נתונים" ויפחית משמעותית את הצורך ב mocks, stubs וחברים. אימוץ Unit Tests הוא לא דבר קל, ושימוש ב DOP יכול להיות סיוע משמעותי.

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

שימוש יעיל בהרבה בזכרון / מנגנוני cache
כמו שדובר למעלה. ברוב במקרים זו לא סיבה לעבור, אך בהחלט נחמד לקבל.

מאגר אדיר של בסיסי נתונים (רלציוניים) התואמים למודל כמו כפפה.
מודל ה OOP לא רק הקשה על החשיבה הלוגית שלנו ועל ארגון התוכנה לאובייקטים, הוא גם הקשה מאוד על שימוש בבסיסי הנתונים הרלציוניים, אשר בטבעם הם מונחי-נתונים.
במשך שנים ניסו לבנות כלי (ORM (Object-Relational Mapping עם הצלחה חלקית בלבד. אפילו Hibernate/NHibernate - ה framework הפופולארי ביותר, הוא נחמד לשמירת קונפיגורציה אך כושל כאשר אנו זקוקים לביצועים טובים על הרבה נתונים. גם אני האמנתי למצגות שמספרות שברוב המקרים Hibernate יבנה סכמה יעילה יותר מהמתכנת ויספק Cache שישפר את הביצועים אפילו יותר. הנסיון שלי הוא שכאשר יש דרישה לביצועים טובים, ישנו מאבק ארוך עם Hibernate שבסופו Hibernate מוצא את עצמו מחוץ למשחק.
אמנם אם היינו יוצרים באופן ידני את אותה הסכמה ש Hibernate מייצר - הוא יכול היה להיות מהיר יותר, אך ההבנה שלנו בנתונים מובילה אותנו לסכמות שונות לחלוטין ממה ש Hibernate ייצר.
אחד המניעים של תנועת ה NoSQL היא השתחררות ממיפוי אובייקטים למודל רלציוני ועבודה ישירות מקוד OO למודל שמירת נתונים OO (כגון בסיסי נתונים KV). על אותו מטבע אם הקוד שלנו הוא מונחה-נתונים, כך גם בסיסי נתונים רלציונים ישרתו אותנו היטב ובקלות - ויש המון כאלה.

העליונות של Object Oriented Design
בעוד יש ספקות על העליונות של תכנות מונחה-עצמים, לי אישית יש מעט מאוד ספקות על העליונות של תכנון מונחה-עצמים (Object-Oriented Design).
תכנון מערכת מונחה-נתונים, סביר לדעתי, שיסתיים באסון (כלומר אי הצלחת הפרוייקט - לא משהו מעבר לזה).

היתרונות של חלוקה של מערכת למודולים עם אחריויות ברורות, הכמסה נוקשה (encapsulation) של כל מודול ותיאור המערכת כשיקוף של העולם האמיתי / הבעיה העסקית (מה שנקרא גם DDD - Domain Driven Design) - הם יתרונות ברורים שעובדים היטב בשטח.

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

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

בהצלחה.


[1] בשקפים 31 עד 101 של מצגת זו - ניתן למצוא הסבר מפורט של התופעה.

[2] יש לזכור שמערך בג'אווה הוא רשימה רציפה של מצביעים. האובייקטים עצמם (אליהם אנו מצביעים מה ArrayList) עדיין מפוזרים באופן שרירותי בחלק הזכרון הנקרא Heap. ב #C המצב נוח יותר - יש structs שיכולים להיות מוגדר באופן רציף. בכל מקרה אני רוצה להדגיש ולחזור שאופטימזציית performance היא לא עצם העניין, עצם העניין הוא מודל שקל יותר לשימוש המפתח - אופטימזציות הביצועים בדיון זה היא משנית.

הקרב בתעשיית התוכנה: Development vs. Marketing

הקרב בין מחלקת השיווק ([1]Marketing) למחלקת הפיתוח מתנהל כבר שנים, במשך דורות, אבות ובנים. אלה רוצים "עוד פיצ'רים ומהר" אלו רוצים "איכות, דיוק ושיטתיות" (ע"פ המפתחים. אנשי שיווק יספרו את הסיפור קצת אחרת). נקודת ההכרעה אינה נראית באופק.

האם זה קרב מחוייב המציאות? האם לא ברור שהפעם "אנחנו" צודקים?

שאלה: כאשר בא אליך איש מוצר ורוצה עוד פיצ'רים על חשבון איכות, מה אתה אומר לו?

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

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

Best Practices: פיתוח כנגד שיווק

במשך השנים נוצרו כמה פרקטיקות בעולם הפיתוח שאין מערערים עליהן (כלומר, היינו רוצים שכך יהיה):

• DRY - אל תחזור על עצמך
• Bake Quality In - איכות צריכה להיות בכל שלב בתהליך
• Abstraction / Loose Coupling - צמצם תלויות בקוד כך ששינוי באזור אחד לא יזעזע אזורים אחרים.
• Naming / Clean Code - קוד "ספרותי" שמתאר את עצמו.
• וכו'

אנשי השיווק העתיקו מאיתנו, המפתחים, את הרעיון של Best Practices ויצרו רשימה משלהם. הנה כמה הרלוונטיים לדיון:

רגל בדלת
בניגוד לקונוטציה האגרסיבית של "לדחוף את הרגל" כדי לחסום דלת נסגרת (שמתאימה לתיאור של איש מכירות אגרסיבי במיוחד), "רגל בדלת" לרוב מתייחס לצורה המנומסת (האמריקאית אולי) של נקודת הכניסה לבית הלקוח. במקום לשאול: "האם אתם רוצים לקנות שואב אבק חדש?" יפתח איש המכירות בשאלה "האם גם לכם האובך האחרון לכלך את הבית?" - שאלה תמימה ולא מחייבת. "כן בוודאי - פשוט נורא" המשכתם, פתחתם את הדלת לרווחה ואפשרתם לאיש המכירות לחצות פיסית את קו הדלת ולהניח שם רגל. הקרבה המעטה הזו (והכניסה בהסכמה למרחב האישי שלנו) היא כבר נקודת פתיחה טובה בהרבה להצעה עסקית.
באופן דומה אנשי שיווק ירצו שתספקו להם פיצ'ר, אולי חלקי ולא עובד, שאיתו יוכלו לגשת ללקוח ולומר "גם לך יש בעיות ABC"? "יש לנו דווקא משהו מעניין לדבר עליו" - יפתחו דיון עם לקוח שזקוק לפ'יצר אך ירגיש הרבה יותר נוח לדבר עם מישהו שיש לו משהו ולא רק רעיון באוויר. עד שיגיע הזמן למסור את הפתרון ללקוח, הפיתוח יוכל כבר לפתח את הפי'צר כמו שצריך [2].

Feature Superiority
הרבה יותר קל למכור מוצר שיש לו רשימה גדולה יותר של פ'יצרים. ללקוח זו מרגישה קנייה בטוחה יותר ומי שמוכר אותה נתפס מנוסה יותר. ב SAP שמעתי את האמרה הבאה (שנכונה גם לחברות אחרות): "The Suite Always Wins". כלומר ל SAP לא חייב להיות מוצר לניהול משאבי אנוש הכי טוב או כלי לניהול פרוייקטים הכי טוב, אך כשהיא מוכרת חבילה שמחליפה 10 מוצרים שונים ויותר - יש לה ייתרון אדיר. עקרון זה נכון כאשר מדובר במוצרים נפרדים תחת אותה קורת גג ("One Stop Shop") ואפילו קצת יותר כאשר מדובר במוצרים שמדברים אחד עם השני ("Suite").

ייתכן והרצון להגיע ל Feature Superiority דוחף לבקש עוד פ'יצרים על חשבון סגירת ושיפור הקיימים. למי שמכיר את תאוריית האוקיינוס הכחול[3] (או בכלל את פורטר) - זו נראית לעיתים קרובה טעות נפוצה של אנשי שיווק ולא Best Practice, אך נראה שאנשי שיווק לא מעטים פספסו את השיעור הזה ב MBA שלהם. אציין שאנשים נבונים שעבדתי איתם עשו, למיטב הבנתי, את הטעות הזו. נראה שתחת לחץ ותחרות (אנשי מכירות שמכפישים את שמכם בחברה כי הפסידו עסקה בגלל המחסור בפ'יצר X) - קל מאוד להגיע לשם. באופן אירוני, מתחרה שלו יש עדיפות במספר הפ'יצרים ואולי הגיע לשם בעקבות לחץ, עלול לגרור את החברה שלכם לריצה אחר רשימת פ'יצרים במקום להתבונן על התמונה השלמה.

Check-box Feature
לעיתים קרובות, תהליך מכירה של תוכנה ארגונית עובד כך: הלקוח שולח RFP - Request For Proposal לכמה ספקי תוכנה שנשמע שיש להם תוכנה שמתאימה לצורכיו. ה-RFP הוא מסמך עם רשימה ארוכה של דרישות "יש"/"אין" שעל הספק למלא. מי שעומד בדרישת הסף עובר לשלב הבא בו משוחחים על הפתרון, עושים פיילוט וממשיכים למכירה. אם חסר לכם ברשימת הדרישות פ'יצר שמוגדר כקריטי - יסננו אתכם עוד בשלב ה RFP, לעיתים ללא הבנה מה אתם במקום לאותה הבעיה, ללא ודאות שזה באמת מה שנחוץ וכו'. על מנת לעבור את התהליך יש לסמן כמה שיותר סימני V.
זה תהליך דומה מאוד לשילחת קורות חיים. מתכנת עם 10 שנות ניסיון ב Web יציין ידע ב JQuery, Comet, Ajax ו Cross-Browser DOM אבל אולי ידלג על HTML ו CSS. הוא עלול לגלות שאשת כח-האדם שעושה Pattern-matching על קורות החיים שלו פשוט מסננת אותו "אין לו מספיק ידע" כי "צריך ידע ב CSS" או CSS3 או XHTML (מול HTML - הבדל סמנטי) וכו'.
מה הפתרון? על מנת לעבור את הסינון הזה אותו מתכנת יכתוב אינסוף מושגים הקשורים לווב, שחלקם אולי לא כ"כ נכונים על מנת להגיע למראיין המקצועי (כלומר - טכנולוגי) הראשון שיוכל להתרשם באמת מכישוריו.

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

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

פי'צר כזה מסומן כ Check-box Feature - תחמושת חשובה שאיש השיווק רוצה לספק לאנשי המכירות שלו. הם יוכלו לטעון "בטח - גם לנו יש Mobile Cloud EAI Service Integration 2.0 ואולי יוכלו לעבור איזה Demo של כמה דקות. אבל הפ'יצר עצמו לא באמת צריך לעבוד על מנת למכור או אפילו ליצור לקוח מרוצה - חבל לבזבז עליו זמן פיתוח.
מה עדיף? לחנך את הלקוחות/שוק (והגרורות שלהם) שזה פ'יצר מיותר (קשה מאוד) או לבקש מהמפתחים פ'יצר חלקי ונבוב בהשקעה מינימלית (יחסית קל)? האופצייה השנייה ישימה יותר ועובדת טוב יותר (לצערנו, המפתחים).

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

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

אנחנו בפיתוח מעדיפים לדייק בפרטים ולא "לנפח". אנו נעדיף לקרוא לאובייקט "SnmpMessage" ולא "SystemWellBeingReport" (קצת מוגזם - לא?). אנו נעדיף "XmlParser" ולא "Cross-SystemTranslator". לכן כשאנחנו רואים את החומר השיווק של המוצר שפיתחנו, בעוד אנו יודעים מה הוא באמת עושה, אנו עלולים להיות מופתעים. "הם חיים בעננים" אנו מספרים על אנשי השיווק, "רואים סרטים בעננים", מוסיפים. קרוב לודאי שהסבר כמו "הלקוחות שמחים לקנות את הסיפור, זה נותן להם אמון שאנחנו מבינים אותם ויודעים על מה אנחנו מדברים" רק מעצים את תחושת הניכור.


סיכום
טעות נפוצה היא לחשוב ש"המוצר מוכר את עצמו" או ש"מספיק מוצר טוב". אמנם יש מעט מוצרים שנמכרים ללא שיווק (למשל מנוע החיפוש של גוגל) ולמשתמש ישירות, אך את רוב המוצרים עדיין מוכרים בעזרת אנשי מכירות, שיווק וחומר פרסומי ועל המוצר למלא חלק במערכה. הלקוחות שלנו אינם תמיד מבקשים את מה שהם צריכים [4], השוק לעיתים קרובות "טיפש" (או "לא רציונלי") וזו הטייה שחשוב להבין להתמודד איתה על מנת להצליח בעסקים. לא מעט סטראט-אפים נופלים על הטעות הזו. אם לא שמתם לב - ברוב חברות ההייטק, לפיתוח מוקצים כ 10-15% מהתקציב ולשיווק - כ 40-60% מהתקציב. לא סתם.

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

בתחומים שבהם איכות היא חיונית להצלחה עסקית (למשל מכשור רפואי, ניהול כספים) - תהיה איכות גבוהה ובתחומים בהם הדרישה פחות מחמירה (למשל תוכנה שהמצאותה נדרשת על מנת לעמוד בתקן [5], מה שנקרא Compliance)  - תהיה איכות נמוכה יותר [6].
הלקוחות יאמרו לנו מה רמת האיכות הנכונה בעבורם, והם יאמרו זו בצורה עקיפה. לרוב אלו יהיו מעשים (אי קנייה / קנייה ממתחרה) ולא דיבורים (הרי, מי לא רוצה איכות?).

אפרופו, המנהלים בארגון שלכם כמעט ותמיד יכריזו שהם רוצים איכות - אך המעשים בשטח הם אלו שקובעים. על מה מקדמים אנשים? על יותר פ'יצרים או על יותר איכות? לא מזמן שוחחתי עם VP R&D של חברה קטנה שהפסידו עסקת ענק (עבורם) בגלל באגים שצצו בתהליך בחינת המוצר ע"י הלקוח. "המוצר שלכם נחמד, אבל יש בו יותר מדי תקלות" הסביר הלקוח מדוע הוא דוחה את העסקה. לא נראה שיש מוטיבציה טובה מזו להשקיע באיכות. האם הלקוחות שלכם דוחים מוצר על איכות או רק על מחסור פ'יצרים?

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

תודה לניר דרמר על ההערות המועילות על הפוסט.


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

[2] או שלא. יש פה סיכון מסוים. אנחנו בפיתוח נוטים לזכור היטב את המקרים שבהם זה לא עבד - אבל הרבה פעמים זה עובד יפה. בכל זאת זהו Best Practice ולא Flawless practice.

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

[4] ב XP נוהגים לומר: תן ללקוח מה שהוא צריך, לא מה שהוא מבקש.

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

[6] מדידה של איכות תוכנה הוא דבר מורכב ובעייתי, במיוחד מכיוון שאין מדדים מוסכמים ל"מהי איכות". לכן לכל מחקר או נתון על איכות תוכנה יש להתייחס בזהירות.