AI בשלב הארכיטקטורה: חקירת חלופות מהירה

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

המאמר מסביר את ההבדל בין החלטה ארכיטקטונית להחלטה טכנולוגית, מה AI תורם בכל אחת מהן, איך עובדים איתו כך שההמלצות יתאימו להקשר האמיתי של הפרויקט, ואיך משלבים את כל זה בתהליך. הוא מיועד לארכיטקטים, למהנדסי Embedded ולמנהלי R&D שמובילים החלטות תכנוניות.

ארכיטקטורה וטכנולוגיה הן שתי החלטות נפרדות

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

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

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

למה חוקרים פחות חלופות ממה שצריך

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

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

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

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

AI בשכבת הארכיטקטורה: הצעה והתאמה של מבנים

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

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

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

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

AI בשכבת הטכנולוגיה: חלופות מימוש לכל ארכיטקטורה

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

דוגמה, עבור המבנה שתואר קודם, של ליבת זמן אמת לצד מעבד אפליקציה:

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

הקשר הוא מה שהופך הצעה כללית להמלצה מותאמת

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

ההקשר שכדאי להעביר לכלי כולל שלוש שכבות:

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

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

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

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

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

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

סיכונים שמכירים מראש

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

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

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

היכן נשאר המהנדס

גם עם הקשר מלא, יש דברים שנשארים בידי הצוות.

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

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

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

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

איך משלבים את זה בתהליך

1. מגדירים את הבעיה ואת ההקשר. מה המערכת צריכה לעשות ומה נחשב הצלחה, לצד מסמך הקשר שמתאר את הצוות, הפרויקט והחברה.
2. חוקרים ארכיטקטורות. מבקשים מהכלי שתיים עד ארבע ארכיטקטורות מועמדות, כולל כאלה שהצוות לא עבד איתן, ומתאימים כל אחת לבעיה.
3. ממפים חלופות מימוש. לכל ארכיטקטורה מועמדת, חלופות טכנולוגיות עם יתרונות, חסרונות, עלויות ומידת ההתאמה לצוות.
4. ממפים סיכונים. לכל צירוף של ארכיטקטורה וטכנולוגיה, מה עלול להשתבש ואיך נערכים לכך.
5. מעמיקים ומאמתים. מצמצמים לשתיים או שלוש חלופות ריאליות, ומבצעים חישובים, בדיקות היתכנות ולעיתים אב טיפוס.
6. מחליטים ומתעדים. ההחלטה, השיקולים, החלופות שנדחו והסיכונים שהתקבלו במודע נכתבים במסמך החלטה. הכלי מקצר את הכתיבה, וכשבעוד שנתיים מישהו ישאל למה נבחרה הגישה הזו, התשובה תהיה שם.

טעויות נפוצות

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

שאלות נפוצות

מה ההבדל בין החלטה ארכיטקטונית להחלטה טכנולוגית?

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

איך AI עוזר לבחון ארכיטקטורות שהצוות אינו מכיר?

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

האם AI יכול להתאים את ההמלצה לצוות ולפרויקט שלנו?

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

איזה הקשר כדאי לתת לכלי?

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

מה עושים כשהחלופה המתאימה ביותר כרוכה בסיכון?

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

איך משווים כמה ארכיטקטורות וכמה טכנולוגיות יחד?

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

האם AI מחליף את סקירת הארכיטקטורה?

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

היתרון של TandemG

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

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

למי מתאים

• חברות שמתכננות מוצר חדש ורוצות לבחון יותר מארכיטקטורה אחת לפני שמתחייבות
• צוותים ששוקלים מעבר לארכיטקטורה או לטכנולוגיה שלא עבדו איתן בעבר
• מנהלי R&D שרוצים שההחלטות יתאימו לצוות ולאילוצים, ולא רק לדרישות הטכניות
• פרויקטים שבהם הסיכונים צריכים להיות מוכרים ומנוהלים מההתחלה

צוותי המהנדסים שלנו פועלים כ-AI-powered developers ומשתמשים בכלי AI מתקדמים כמו Claude ו-GitHub Copilot כדי לקצר את תהליכי הפיתוח, לשפר את איכות הקוד, ולהאיץ את סקירות הארכיטקטורה, תוך שמירה על כך שההכרעות מתקבלות על בסיס אימות והבנה ולא על בסיס הצעה.

הפרויקט הבא שלכם מתחיל בשיחה

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

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