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