לא פעם ולא פעמיים נשאלתי מהי תפיסת העולם הטכנולוגית שלי כ-CTO של חברת בי-דיוק, מתוך ההנחה שככל שיותר עמיתים יעיינו במאמר זה ויעירו את הערותיהם תשתפר בהכרח מתודולוגיית העבודה של כל העוסקים בתחום ובכלל זה גם שלי, החלטתי לפרסם את המאמר הזה המכיל את התפיסה שלי בהקשר לטכנולוגיות המידע בארגונים בכלל ובארגונים העוסקים בתחום דומה או משיק לתחום בו עוסקת חברת בי-דיוק. על סמך נסיוני, אני סבור כי אם ארגונים יישמו את הכללים המופיעים במאמר זה יהיה ניתן לצפות להגדלת התפוקה של גופי הפיתוח שבאחריותם ביחס למחיר ששולם עד כה בשל קיטון משמעותי בעלויות הפיתוח שצפוי בשל ההתייעלות בתחומים אלו.
1. שימוש בעובדים רב-תחומיים – לדעתי, תוכניתן שמבין טוב את עולם הסיסטם ואבטחת המידע התשתיתית, יהיה תוכניתן טוב יותר והתוצרים שלו יהיו יציבים יותר ואיכותיים יותר. באופן דומה, איש רשת שמבין את עולם הפיתוח יוכל לעצב טוב יותר את מבנה הרשת שלו בכדי לייצר תשתית טובה ויציבה יותר למערכות הקיימות בה. אני השתדלתי, במהלך חיי המקצועיים להתמחות בכמה שיותר "שטחים טכנולוגיים". מנהלים רבים סבורים כי עובד שהוא תוכניתן צריך להיות 100% תוכניתן ולהתמחות באופן מלא בעבודתו זו. אני סבור אחרת – העולם שלנו, מעצם טבעו הוא שזור ותחומים שונים שלובים זה בזה. זה נשמע קצת אולי פילוסופי מדי, אבל אם נתבונן סביבנו נראה כי תחומים שבעבר נחשבו שונים בתכלית היום התמזגו ופועלים כאחד, במיוחד תחומי המחשוב השונים אשר בהגדרה הם שזורים ואנו, מתוך הנוחות שלנו מעדיפים לחשוב עליהם כתחומים נפרדים. על כן אני ממליץ לנסות זווית ראיה חדשה ואינטגרטיבית המשלבת מספר דיסציפלינות על מנת להשיג תוצאות איכותיות ואפקטיביות בהרבה. דוגמאות לפיתוחים שביצעתי שמדגימים את היכולות הללו כוללות בין השאר, שירות שליחת הודעות SMS המאפשר את חיבורו לכל ספק שירותי SMS שהוא ובכך מבטל את הצימוד בין מערכת הלקוח השולחת את הודעת ה-SMS לספק שירותי ה-SMS ומאפשר את החלפתו בכל עת לפי העלות הנהוגה בשוק, שירותי שליחת פקסים (על בסיס הודעת דואר), שירות טיפול בהודעות דואר (POP3) המאפשרת את צמצום כמות החיבורים לשרת הדואר למינימום ההכרחי תוך טיפול רובאסטי ומהיר בכמויות גדולות של דואר מסוגים שונים, מערך סנכרון קבצים בין שרתים, מערכת ניהול קריאות שירות (SCMS) המאפשרת את הטיפול בקריאות שירות מסוגים שונים ומערכות נוספות. (ניתן לקרוא עוד על יתרונות גישה זו במאמר הויקיפדיה על רב-תחומיות כתפישה)
2. פיתוחים תשתיתיים קטנים וזריזים בעלי ממשקים בתשתית אחידה (HTTP/s) וצימוד רפוי – פיתוחים המבוצעים כך שהם מפותחים כשירותים קטנים המבצעים פעולה מוגדרת ואשר חוצצים בין הלקוח של השירות למערכת המספקת את השירות, יאפשרו להנות הן מנטל הפיתוח ההולך וקטן (בשל הקיטון בהשלכות על פיתוחים כתוצאה משינוי באחד מאותם שירותים), הן מכך שניתן יהיה לשלב כוחות בפיתוח כך שלא יהיה מצב שבו תוכניתן אחד אחראי על פיתוח אחד גדול ומורכב אלא על פיתוח מספר שירותים קטנים. למרות שנשמע כאילו מדובר בארכיטקטורת SOA קלאסית, הכוונה שלי מעט שונה שכן בעוד שביישומי SOA קלאסיים מבוצע תהליך של "עטיפת" שירותים ישנים במעטפת SOA, דבר אשר מייצר צווארי בקבוק ובעיות ביצועים ואבטחה, הרעיון שאותו אני מנסה להעביר הינו לייצר עבור כל מערכת סט שירותים המייצגים את השירותים אותם מספקת מערכת זו כאשר שירותים אלו ניגשים ישירות ללב המערכת וכך מאפשרים ביצועים טובים ופעמים רבות אף ביצועים טובים יותר מהממשקים המקוריים של המערכת. חשוב להוסיף, כי בשל הצימוד הרפוי, יהיה ניתן בקלות יחסית להסב את צד הלקוח ו/או את צד השרת באופן פשוט וקל ללא צורך בשינויים דראסטיים בצד השני. השימוש ב-HTTP, כפרוטוקול התקשורת בין השירותים ללקוחותיהם ובין השירותים לבין עצמם, מאפשר, במידה והפיתוח בוצע באופן תקין מבחינת מודל ניהול הזכויות והרשאות של המערכת, לאבטח את הגישה אליה באמצעים תשתיתיים רבים ובכך לחסוך את הצורך בפיתוח שכבות רבות כגון, הצפנה, התמודדות עם מתקפות כגון Brute force, SQL Injection, HTML Injection, Cross site scripting ואחרות. דוגמאות לפיתוחים שביצעתי אשר מדגימים את היכולות הללו כוללים בין השאר שירות WS המשמש לארכוב מסמכים לארכיון הדיגיטלי הארגוני, מערכת ניהול האירועים (EMS) המאפשרת את ניהול ההרשמה לאירועי חברה שונים. (ניתן לקרוא עוד אודות SOA ב-SOA Manifesto)
3. פיתוחים מוכווני Troubleshooting – מפתחים רבים מפתחים את מערכותיהם כאשר הם משתדלים לחסל כל אפשרות לתקלה בזמן הפיתוח, וכאשר בתהליך ה-Debug מתעוררות בעיות, התכניתן מנסה לתת להן מענה בקוד המפותח. גישה כזו, מתעלמת במשתמע מן העובדה הבלתי נמנעת שמערכת ממוחשבת בהיותה כזו, תהיה, בשלב כזה או אחר של חייה חשופה לתקלות שונות. אני מנסה להנחיל מתודולוגיית פיתוח חדשה אשר בה התוכניתן נדרש להביא בחשבון את כל התקלות האפשריות, קרי, כל המסלולים הלוגיים הנובעים מהאלגוריתם אותו הוא מפתח מתוך הנחה מודעת שקיים סיכוי סביר להתממשותן בשלב כזה או אחר ולטפל באותן שגיאות באופן המאפשר את ניתוחן ואת קבלת מלא הפירוט אודותן לכשיקרו. פיתוח במתודולוגיית פיתוח זו אמנם מאריך את משך הפיתוח אך למיטב ניסיוני, משך זמן זה מוחזר במלואו בתוספת ריבית כאשר ניגשים לאתר תקלה שאירעה באותה מערכת ובמקום להתמודד עם שגיאת "File not found" או "Error 35" או "Unexpected exception" מקבלים את מלוא הנתונים הדרושים על מנת לפתור את הבעיה.
4. פיתוח רב שכבתי כאשר שכבת ממשק המשתמש מופרדת בצימוד רפוי משאר השכבות – בהמשך לנאמר בסעיפים הקודמים, חשוב להדגיש כי בשל העובדה שממשק המשתמש הוא הממשק המאפשר את ביצוע הפעולות במערכת, לכן, הפרדתו מן המערכת באמצעות צימוד רפוי כלשהו ובמיוחד כזה המבוסס על פרוטוקול HTTP תאפשר בנוסף לנאמר לעיל גם את קישורם של ממשקים של מערכות אחרות דרך אותו ממשק המשמש את ממשק המשתמש ובכך תאפשר לצמצם עוד יותר את נטל הפיתוח הקיים בארגון. דוגמא טובה לנושא זה היא מערכת שרת הפקסים (Alt-N RelayFax) אשר הטמעתי בארגון ואשר משמשת אותנו מזה כעשור. מערכת זו מאפשרת פיתוח של ממשק משתמש אלטרנטיבי בקלות רבה, דבר שאכן בוצע על ידי בעבר ובנוסף, ישנן מערכות רבות בארגון המשתמשות בשירות זה משום שהאופן המקשר את ממשק המשתמש למערכת נשען באופן בלעדי על תשתית פרוטוקולים סטנדרטיים, פשוטים ליישום ופתוחים. בנוסף, פיתוח באופן זה מאפשר האצלת סמכויות כך שאת פיתוח ליבת המערכת תבצע מחלקת הפיתוח הארגונית בעוד שאת ממשק המשתמש ניתן באופן זה להטיל על גורם חיצוני שזו התמחותו (תחום פיתוח ממשקי משתמש אפקטיבים הינו אומנות נפרדת שיש ללמוד אותה ולהתמחות בה. לדוגמא: המלצות לעיצוב UI של מיקרוסופט, המלצות Powerful and Simple של מיקרוסופט, אתר חברת Nielsen Norman Group המתמחה בעיצוב ממשק משתמש יעיל) בנוסף לאפשרות לשדרג את ממשק המשתמש על ידי הוספת אפשרות להפעלת אותה פעילות ממקומות שונים בממשק המשתמש (משימה הנדרשת לעיתים קרובות מכפי שנדמה) תהיה גם אפשרות ליצירת מספר ממשקי משתמש שונים המוכוונים לתרחישים שונים (למשל ממשק לטלפון, ממשק אינטרנטי למוקד וממשק שורת פקודה לצורך ממשקים ופעולות אצווה) פשוטה וקלה ותחת הסכמי פיתוח מול צד ג' ולא תלויה במפתחים פנימיים.
5. פיתוח התומך בהפעלת hooks או ממשק כלשהו המאפשר חיבור רכיבי צד ג' לתהליכי העבודה המבוצעים במערכת (Plugins) – פיתוח מסוג זה יאפשר חיבור ממשקים בין מערכות ללא תלות בגורמי הפיתוח בשני הצדדים ובכל זאת, תתאפשר קישוריות איכותית וטובה בין מערכות באופן שהוא Event Driven ומשום כך מייצר חוויית משתמש טובה ותגובתית וכל זאת, כאמור, ללא צורך בפיתוח בשני צידי הממשק אלא רק ברכיב שיופעל באחד מ-2 הקצוות על ידי מנגנון ה-hooks. פיתוח מסוג זה מחייב אופן חשיבה שונה באופן מהותי מכפי שהיה מקובל בפיתוחים אחרים, בניגוד לתפיסה הגורסת כי על מנת לקשר בין שתי מערכות המפתחים של שתי המערכות חייבים להכיר זה את המערכת של זה (אם לא אחד את השני), אופן פיתוח זה מחייב תפיסה אחרת אשר בה כל רכיב אחראי ליציבותו ולרובאסטיות שלו מתוך הנחת היסוד שלעולם לא ברור מראש מי יפנה אליו וכמה פניות יבוצעו ביחידת זמן. הדוגמא למערכת כזו היא מערכת Microsoft Exchange 2010 המאפשרת את פיתוחם של רכיבים שישתלבו בתהליך עיבוד הדואר. לאחרונה ביצעתי פיתוח כזה על מנת להוסיף תוכן שיווקי ופרסומי להודעות יוצאות כפי שניתן לראות במאמר הזה. דוגמא נוספת היא תוכנת TortoiseSVN המשמשת אותנו לעבודה מול שרת ה-SVN לצורך ניהול גרסאות. תוכנה זו מאפשרת, באופן עקרוני להשוות בין גרסאותיו של כל קובץ מכל סוג בתנאי שישנו כלי כלשהו (ללא תלות בשפת הפיתוח של אותו הכלי) המאפשר השוואת שני קבצים כאלו. (ניתן לקרוא עוד אודות Hooking בויקיפדיה כאן)
6. פיתוח מבוסס סביבת Dot Net – בשל אופן ניהול הזיכרון בסביבת Dot Net ניתן, גם במקרים שבהם התוכניתן לא ביצע פעולות מיוחדות לשם כך, לאתר סיבת כשל שמוביל לאיטיות, לקריסה או לדליפות זיכרון בתהליכים שונים (Post mortem debugging). שוב, ביצוע פעולות מסוג זה על רכיבים מבוססי Web קל ופשוט לעין ערוך מאשר ביצוע אותן פעולות בתוכניות חלונאיות. בנוסף, בפיתוחים מבוססי Dot Net ניתן לבצע במידת הצורך ובמידה והדבר אינו נוגד את החוק, תהליכי Decompile בקלות רבה. ביצוע תהליכים אלו מאפשר לא רק לימוד מעמיק של אופן פעולתו של רכיב כזה או אחר על מנת לתחזק אותו באופן הטוב ביותר אלא גם מאפשר להתאים אישית את אופן פעולתו על ידי הקמת רכיב זהה הפועל באופן מעט שונה. כמובן, שאין דרך אחת ויחידה המהווה פתרון המתאים לכולם. ובכל זאת, בהכללה גסה, ניתן לומר שברוב המקרים של פיתוח אפליקציות ארגוניות (כמובן שאין הדבר מתייחס לפיתוח באופן כללי) השימוש בסביבה זו יהיה מוצלח לאין ערוך מכל אלטרנטיבה אחרת ובמקרים שבהם נדרש פיתוח שעשוי להשתנות באופן תכוף ובמיוחד במקרים שבהם הוא נדרש להתעדכן על ידי אנשים שאינם מתכנתים הרי ששימוש בשפות Script הוא רצוי, שפת ה-Script שהייתי ממליץ עליה היא ללא ספק שפת Kixtart אשר מאפשרת פיתוח גמיש מאד אשר מסוגל להשיג תוצאות מרשימות במיוחד. דוגמה לשילוב שכזה בין פיתוח Dot Net לפיתוח Kixtart ניתן למצוא בפיתוח שביצעתי למערכת הלוגין סקריפט הארגוני אשר בוצע ב-Kixtart ואשר מספק חוויית משתמש מרשימה של חלונות ואלמנטים גרפיים ויזואליים ומייצרת קובץ יומן פעילויות (Log) בפורמט HTML המאפשר לטכנאי ה-Help Desk להבין במהירות ובקלות את פעילות המערכת ובנוסף, במקרים תקינים ביצוע אוסף תהליכי הלוגין סקריפט הכולל תהליכים רבים נמשך לכל היותר כחצי דקה. על מנת לוודא שאכן תהליך הלוגין סקריפט רץ אחת לפרק זמן קבוע מראש, הוקמה על ידי/בהנחייתי מערכת בסביבת Dot Net המשמשת להזנקת תהליך הלוגין סקריפט באופן שאינו תלוי בביצוע Login על ידי המשתמש ובכך התאפשרה העבודה עם מערכות תלויות מיפויים גם בתחנות מרוחקות המחוברות ב-VPN.
7. ביצוע פיענוח של פניות SSL והצפנתן מחדש בתעודה הקיימת בארגון (SSL Proxy) – כיום, בניגוד לאופן החשיבה המקובל אצל אנשים רבים וביניהם גם אנשי מקצוע רבים, פרוטוקולים מוצפנים מהווים את סיכון האבטחה הגדול ביותר לארגון, זאת משום שהם, ללא שימוש ב-SSL Proxy מצפינים את התעבורה מקצה לקצה ולכן מאפשרים לתוקף פוטנציאלי להציב באופן כלשהו ברשת רכיב (תוכנתי או חומרתי) אשר מעביר נתונים האמורים להיות חסויים, באופן מוצפן הישר למחשבו של התוקף. בנוסף, במקרה שבו ישנם עובדים הגולשים באופן מוצפן, או עובדים באופן מוצפן (למשל באמצעות SSH) לא ניתן להפעיל שום סינון משמעותי על הנתונים המועברים בחיבור זה או על האתרים/שרתים אליהם גולש המשתמש. כמובן שלכך השלכות מרחיקות לכת על היכולת לזהות מתקפות, וירוסים, אתרים שלא תורמים לעבודת המשתמש ו/או נסיונות להדלפת/זליגת מידע.
8. חיבור עולם העסקים עם עולם הפיתוח – לעיתים רבות אנו נתקלים במקרים שבהם שינוי קל בדרישות הלקוח היה מאפשר להשיג תוצאות טובות בהרבה גם עבור הלקוח עצמו בטווח הרחוק יותר יחסית ולעיתים, דרישות שהלקוח העיסקי בהיותו מנותק מהעולם הטכנולוגי, אינו מסוגל להציג היו עשויות לתרום תרומה משמעותית לארגון ולהוות ייתרון תחרותי בשוק האגרסיבי בו אנו חיים. לדוגמה, דרישה עסקית לקבלת דו"חות ממערכת ה-CRM עשויה להיות מוכתבת כדרישה לדו"חות הנכונים למועד שליפתם. על אף שלכאורה מדובר בדרישה טריוויאלית, הרי שלעיתים בשל אופי הנתונים הנשלפים בדו"ח ובשל העומס הנגרם כתוצאה מהפקת דו"חות אלו נדרשת הקמה של שרת נפרד לצורך הטיפול בדו"חות הללו, וכאשר, על מנת לספק את הדרישה לנתונים הנכונים למועד שליפתם, הוא מוגדר ב-Cluster עם השרת המשמש את משתמשי המערכת בשוטף ובשל היות השרתים הללו מוגדרים ב-Cluster, ובשל מבנה התשתית הוירטואלית נגרם מצב שבו המנגנונים התשתיתיים האחראים לנייד באופן אוטומטי שרתים וירטואליים בעת עומס על מנת לשמור על רמת ביצועים מקסימלית אינם יכולים לעבוד בתצורת Cluster כזו וגם תהליכי גיבוי ושחזור הופכים מורכבים וארוכים יותר וחשופים לתקלות יותר וכל זאת בשל הדרישה לנתונים הנכונים למועד שליפתם. לעומת זאת, תיקון קל בדרישה כך שהנתונים יהיו נכונים לאחד מ-3 מועדים ביממה היתה מפשטת לאין ערוך את התצורה ומאפשרת לספק ביצועים טובים יותר למשתמש משום שהיה ניתן, בטכנולוגיה הקיימת, ללא הקמת Cluster להקים שרת Database נפרד שאינו קשור לתשתית ה-CRM הקיימת ואשר יחובר באופן אוטומטי ב-3 מועדים ביממה לגיבוי Snapshot המבוצע באופן אוטומטי באותם מועדים ואשר מולו יבוצעו שאילתות הדו"חות יאפשר לשרת המרכזי שעליו עובדים משתמשי המערכת ביצועים טובים יותר משום שהוא יהנה ממנגנוני האוטומציה הקיימים בתשתית אשר מניידים אוטומטית שרתים לפי העומס בכל רגע נתון. בנוסף, ארכיטקטורה כזו תפשט ותקצר משמעותית את תהליכי הגיבוי והשחזור של מערכת ה-CRM. מובן אם כן, ששינוי קל בדרישת המשתמש היה להשיג תוצאות טובות בהרבה עבור המשתמש עצמו בטווח הארוך יחסית. דוגמא נוספת, יכולה להיות העובדה שלקוחות רבים שלנו הם ארגונים גדולים המכילים גופי פיתוח ו-IT מתקדמים ואיכותיים, אפשר להניח כי אילו היינו יכולים לחשוף לעולם, בנוסף לאתר אינטרנט, גם שירותי אינטרנט המהווים מעין API/SDK לפעילותינו בדומה לאופן שבו מתנהלות חברות אינטרנט רבות (כגון Flickr של Yahoo) היו אותם גופים רואים בכך יתרון תחרותי המאפשר להם לשפר ולהדק את הפעילות מולנו על ידי חיבור מערכותיהם ישירות לאותו API ובכך, על ידי הצגת דרישה טכנולוגית שלעולם לא סביר שתגיע מהגורמים העסקיים, היה ניתן להשיג יתרון תחרותי משמעותי.
9. שימוש ברכיבי תשתית מבוססי Open Source או ברכיבים גנריים קטנים ופשוטים – רכיבי תשתית רבים זמינים כיום כמערכות קוד פתוח או כמערכות גנריות פשוטות המבוססות בחלקן על קוד פתוח. שימוש ברכיבים אלו, כגון מערכת ניהול פעילויות המשמשת אותי (BugTracker.Net) ומערכת ניהול גרסאות (SVN) ומערכת ניהול אתרים (WordPress) ומערכת ניהול זמן (Grindstone) ומערכות נוספות מאפשרות להשיג בקלות וביעילות פתרונות זולים וגמישים הניתנים בדרך כלל להתאמה בקלות. עם זאת, חשוב להדגיש בהקשר הזה שאני בדרך כלל, למעט מקרים מיוחדים, לא בעד ביצוע שינויים בקוד הפתוח שלהם אלא רק בפיתוח הרחבות נתמכות (Skins/Widgets/Plugins) זאת, על מנת שלא להפוך את המוצר לפיתוח עצמי אלא להישאר במצב שבו ניתן בקלות לשדרג מגרסה לגרסה ולהנות הן מהגרסאות החדשות פרי פיתוחם של אחרים והן מתחושת התרומה לקהילה על ידי פיתוח הרחבות אבל ללא השקעת משאבי פיתוח אשר עשויים להפוך את המוצר למוצר שפיתוחו הופך להיות יותר ויותר פיתוח עצמי. בנוסף, חשוב להוסיף ששימוש בפלפורמות מורכבות המייצרות קוד באופן דינאמי (למשל Sharepoint) מצריכות עבודה מיוחדת וזהירה מאד במנגנוני הגנה מבוססי תוכן (למשל WAF) בשל העובדה שציודים אלו "לומדים" באופן אוטומטי את אופן הפניות לאתר/למערכת ומתאימים את מדיניות החסימה שלהם באופן אוטומטי, מערכות המייצרות קוד באופן אוטומטי ואקראי עשויות לגרום לציודים אלו לאשר גישה לא מורשית לרכיבים באותה מערכת בעוד שמערכות פשוטות יותר וקלות יותר מבחינת היקף הקוד המיוצר יאפשרו לציודי האבטחה לעבוד באופן יעיל ואיכותי.
10. סטנדרטיזציה – פיתוח תוך שימוש ככל האפשר בסטנדרטים בינלאומיים (למשל סטנדרט לייצוג תאריך ISO 8601, סטנדרט לשמירת מסמכים ניידים ISO 32000, סטנדרט הצפנה סימטרית ISO/IEC 18033-3) ובמקרים שאלו אינם קיימים או אינם ישימים עבור סוג הפעילות הנדרש, שימוש בתקנים דה-פאקטו הנהוגים בתעשייה (למשל פרוטוקול HTTP המתועד במאמר RFC 2616, שירותי רשת Web Services) ובמקרים שאף אחד מאלו אינו ישים להגדיר תקנים ארגוניים רוחביים אשר ישמשו לביצוע אותה פעילות. פיתוח שביצעתי שמדגים את ביצוע הסעיף הזה (כמו גם סעיפים רבים אחרים במאמר זה) הוא מערכת (המכונה על ידי OI – ראשי תיבות של Organizational Info) המשמשת לשליפה מאובטחת ומהירה מאד של נתוני עובדים, סנכרון נתוני עובדים בין מערכות, עדכון נתוני עובדים וביצוע הזדהות. מערכת זו כתפיסה מחייבת את המערכות המחוברות אליה לחשוף ממשק אחיד, הנשען על תקינה בין לאומית, תקינה דה-פאקטו ותקינה ארגונית על מנת לחסוך באופן משמעותי בפיתוחים עתידיים מתוך הנחה שכל נתון הקיים בארגון משוייך בפרק זמן מסויים לעובד מסויים.
11. אפיון "היברידי" – לדעתי, אפיון, מעצם טיבעו הוא תהליך המשלב את כל הגורמים הרלוונטיים למערכת קרי: הגורמים העסקיים, יוזמי הפרויקט, צוות הסיסטם, מפתחים, אנשי אבטחת מידע, מעצבים וכולם יחד, אמורים לייצר מסמך אחד אשר בתהליך הייזום היקפו קטן והוא הולך ומתרחב ככל שהפרויקט מתקדם עד שבסופו של דבר הוא הופך להיות התיעוד המהימן ביותר של המערכת/המוצר. לדעתי, כל נסיון לצמצם את היקף הגורמים המעורבים באפיון יגרום בהכרח, במוקדם או במאוחר, לליקויים במערכת/במוצר אשר יתבטאו בבעיות ביצועים, השלכות על התשתיות או בשביעות הרצון של הלקוח העיקרי של המערכת. לדעתי, טוב עשתה חברת מתודה בהרכיבה את "נוהל מפת"ח" אשר מיישם הלכה למעשה את התפישה הזו.