דוגמנות נתונים בסביבה זריזה

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

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

אריק קוואנה: אוקיי גבירותיי ורבותיי. ברוך הבא שוב. יום רביעי בשעה 4:00 EST. זה אומר שהזמן שלה עבור Hot Technologies. אכן כן. שמי אריק קוואנה, אני אהיה המארח שלך.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שלישית, מה קרה להביא לזה? ובכן, יש מאמר ב -1986 שנכתב על ידי זוג ג'נטלמנים ששמם ניסיתי נואשות לעשות צדק, הירוטקה טייקוצ'י ואיקוג'ירו נונאקה, לדעתי מבוטא, הפיקו מאמר שהם כותרו "הזזת Down Scrum Downfield". הם הציגו הרעיון הזה של מתודולוגיה של ניצחון במשחק רוגבי הנובע מהפעילות הזו, שם כולם מסתובבים במקום אחד ושתי קבוצות בעצם נועלות ראשים במשהו שנקרא scrum כדי לנסות להשיג שליטה על הכדור ולשחק אותו במגרש כדי להגיע לקו הניסיון ולגעת באדמה עם הכדור ולקבל נקודה, שנקראת תלתל, ואתה חוזר על התהליך הזה ומקבל יותר נקודות עבור הקבוצה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

וזה הכל! מכאן ניקח שאלות נוספות.

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

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

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

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

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

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

ד"ר רובין בלור: ובכן זה מרשים. ורק למעט יותר פירוט על זה - האם בסופו של דבר השלמת, מה הייתי קוראת, מפת MDM של כל אזור המידע בסוף אותו פרויקט?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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