M365Con 2027 – כנס אונליין חינמי · 11–22 Jan 2027 · 120 sessions→ m365con.net

2026-09-03

ארכיטקטורה של Power Platform לפתרונות ארגוניים מורכבים עם Ian Tweedie [MVP]

ארכיטקטורה של Power Platform לפתרונות ארגוניים מורכבים עם Ian Tweedie [MVP]
Microsoft Power Platform מתואר לעיתים קרובות כפלטפורמת low-code. אבל מה קורה כאשר היישומים שנבנים בה הופכים לקריטיים לעסק, משולבים מאוד ומורכבים מדי לגישה פשוטה המיועדת ליוצרים?בפרק זה של M365 FM, Mirko Peters משוחח עם Ian Tweedie, Power Platform Solution Architect, על מה שקורה כאשר Power Platform יוצאת מעבר ליישומי low-code פשוטים ונהפכת לחלק מארכיטקטורה ארגונית רצינית.LOW-CODE אינו שווה LOW ARCHITECTURE Power Platform יכולה לספק חלק גדול מערך העסק במהירות, אך פתרונות ארגוניים כמעט תמיד כוללים דרישות שחורגות מיכולות ה-low-code הסטנדרטיות.Ian מסביר מדוע אין לבלבל בין low-code לבין no-code, ומדוע עקרונות ארכיטקטורת תוכנה מסורתיים עדיין חשובים בעת בנייה עם Power Apps, Power Automate, Dataverse, custom connectors, APIs ושירותי Azure.

Microsoft Power Platform is often described as a low-code platform. אבל מה קורה כשהאפליקציות שאתם בונים הופכות לקריטיות לעסק, משולבות מאוד, ומורכבות מדי לגישה פשוטה שמתמקדת ביוצר (maker-first)?בפרק הזה של M365 FM, Mirko Peters משוחח עם Ian Tweedie, Power Platform Solution Architect, על מה שקורה כאשר Power Platform עובר מעבר ליישומי low-code פשוטים ונהפך לחלק מארכיטקטורה ארגונית רצינית.

LOW-CODE לא אומר ARCHITECTURE נמוכה
Power Platform יכול לספק חלק גדול מערך עסקי במהירות, אבל פתרונות ארגוניים כמעט תמיד כוללים דרישות שחורגות מיכולות low-code סטנדרטיות.Ian מסביר למה אסור לבלבל בין low-code ל-no-code, ולמה עקרונות ארכיטקטורת תוכנה מסורתית עדיין חשובים כשבונים עם Power Apps, Power Automate, Dataverse, custom connectors, APIs ושירותי Azure.

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

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

Low-code + Pro-code = ארכיטקטורה היברידית
Power Platform לא חייב להתחרות בפיתוח תוכנה מסורתי.חזית Power Apps עשויה לייצג רק חלק קטן מיישום הרבה יותר גדול המשתמש ב-Azure, AWS, GCP, APIs או שירותים מותאמים אישית.השאלה הארכיטקטונית החשובה אינה האם משהו הוא "low-code" או "pro-code".השאלה היא איזו טכנולוגיה מתאימה ביותר לכל מאפיין.

Citizen Developers, Makers וארכיטקטורה
מפתחי אזרח (citizen developers) מביאים ערך רב מאוד: ידע עמוק על התהליכים העסקיים שאיתם הם עובדים מדי יום.אבל מומחיות עסקית לא מתורגמת אוטומטית לארכיטקטורת יישום טובה.Ian דן באיזון בין מתן יכולת ליוצרים לבין הכנסת מספיק ארכיטקטורה, ממשל (governance), נרמול וביקורת טכנית כדי למנוע מפתרונות להפוך לקשים לתחזוקה.

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

Power Platform, APIs ו-Azure
היכן צריכה הלוגיקה העסקית להתקיים?האם יש לאחסן סודות בתוך Power Platform? מתי Azure Key Vault, Azure Functions או API Management צריכים להפוך לחלק מהארכיטקטורה?Ian מסביר מדוע הארכיטקטורה צריכה תמיד להתחיל מהבעיה שנפתרת, ולא מהוספת שירותי Azure רק משום שהם זמינים.

Git, בקרת מקור ו-CI/CD
ככל שפיתוח Power Platform הופך לשיתופי יותר, שיטות פיתוח מסורתיות נעשות רלוונטיות יותר.השיחה בוחנת את Git, מאגרים (repositories), סביבות פיתוח, pipelines, בקרת מקור, בידוד מאפיינים, תלויות הדדיות ו-CI/CD.לעיתים אין גישה מושלמת לבקרת מקור ב-Power Platform — לפעמים המטרה היא לבחור את "האפשרות הפחות גרועה" עבור הפרויקט.

ספר ההנחיות הארכיטקטוני של Ian ל-Power Platform

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

הסבב המהיר
Mirko מציב בפני Ian סדרת שאלות מהירות:האם כל יישום ארגוני צריך להשתמש ב-Dataverse?האם Power Platform יכול לבנות יישומים קריטיים למשימה?האם Power Automate יכול להחליף את Logic Apps?האם low-code מפחית אוטומטית חוב טכני?האם Power Platform יכול להחליף פיתוח יישומים מסורתי?ואולי החשוב מכולם: מה כדאי להזמין כשמבקרים בניוקאסל?

המסקנה המרכזית
Low-code לא אומר low architecture.ככל שפתרונות Power Platform גדלים, מתחברים יותר ונעשים חשובים יותר לעסק, יסודות הנדסת התוכנה נותרים רלוונטיים.ארכיטקטורה חשובה.מודלים של נתונים חשובים.ממשל חשוב.אבטחה חשובה.עיצוב API חשוב.DevOps חשוב.ופיתוח ארגוני מוצלח ב-Power Platform הוא יותר ויותר עניין של הבנה כיצד low-code, pro-code, Azure, APIs, אוטומציה ושיטות הנדסת תוכנה מסורתיות פועלים יחד.

הפכו לתומכי הפודקאסט הזה: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Apple Podcasts · Spotify · YouTube · Deezer

Architecting Power Platform for Complex Enterprise Solutions with Ian Tweedie [MVP] (English)