Elvitel: Eric Kavanagh házigazda az adatmodellezés fontosságát az agilis fejlesztés során Robin Bloor, Dez Blanchfield és az IDERA Ron Huizenga közreműködésével tárgyalja.
Jelenleg nincs bejelentkezve. Kérjük, jelentkezzen be vagy jelentkezzen be a videó megtekintéséhez.
Eric Kavanagh: Oké, hölgyeim és uraim. Üdvözöljük még egyszer. Szerdán, 4:00 órakor. Ez azt jelenti, hogy ideje van a Hot Technologies számára. Igen valóban. A nevem Eric Kavanagh, én leszek a házigazdam.
A mai témához régi, de jó öreg. Minden nap egyre jobb, mert alakítja az adatkezelési világunkat, az „Adatmodellezés egy agilis környezetben.” Igaz, hogy az önről való diavetítés a @eric_kavanagh oldalra engem mutat. Tényleg rá kellett helyeznünk erre a diára. Be kell tudnom venni ezt.
Tehát az évek forróak. Az adatmodellezés örökre megtörtént. Valójában az információkezelési üzlet középpontjában és lelkén állt: adatmodelleket tervez, megpróbálja megérteni az üzleti modelleket és összehangolja azokat az adatmodellekkel. Tényleg mit akarsz csinálni, igaz?
Az adatmodell alapvetően ábrázolja az üzletet, tehát hogyan változtatják meg az összes új adatforrás a játékot? Tudnunk kellene erről. Megtudnánk, hogyan lehet agilisan a dolgok tetején maradni. És természetesen ez az év szava.
Robin Bloors velünk, fő elemzőnk, Dez Blanchfield, az ausztráliai Sydney-ből, és Ron Huizenga, az IDERA vezető termékmenedzsere - régóta barátom, kiváló hangszóró ezen a téren, ismeri a dolgát, szóval ne félj, kérdezd meg őt kemény kérdések, emberek, a kemények. Ezzel megteszem Robint az előadónak, és elviszem.
Dr. Robin Bloor: Oké. Nos, köszönöm érte, Eric. Azt kell mondanom a modellezésről, hogy azt hiszem, hogy valójában az IT világában voltam, még mielőtt létezett volna, abban az értelemben, hogy emlékszem a biztosítótársaságban, ahol dolgoztam, hogy volt egy srác, aki bejött, és mindenkit adott nekünk. az adatok modellezéséről szóló műhelymunka. Tehát körülbelül 30 évet néztünk, ez 30 év? Talán még ennél is hosszabb, talán 35 évvel ezelőtt. A hosszú, hosszú ideje tartó modellezés valójában az ipar részét képezi, és ennek természetesen semmi köze sincs a kifutón járó hölgyekhez.
A dolog, amit el akartam mondani, mert amit általában csinálunk, az én és Dez különféle dolgokról beszélünk, és azt gondoltam, hogy átfogó áttekintést adok a modellezésre, de ennek van valósága, ami most nyilvánvalóvá válik.
Tudod, van nagy adataink valósága, több adatunk van, több adatforrásunk van, olyan adatfolyamokat kaptunk, amelyek az egyenletbe léptek az elmúlt három vagy négy évben, és nagyobb részét kezdik elérni, és van nagyobb szükség van az adatok megértésére és megnövekszik a változás üteme, ami azt eredményezi, hogy több adat kerül hozzáadásra és több adatszerkezet is felhasználásra kerül.
Ez egy nehéz világ. Itt egy kép róla, amely valójában olyasmi, amit körülbelül három évvel ezelőtt felhívtunk, de alapvetõen, ha beilleszti a streambe a keveréket, és megkapja ezt az ötletet az adatok finomításáról, adatközpontról, adatkapcsolatról vagy bármi másról, láthatja, hogy vannak adatok valóban nyugalomban abban az értelemben, hogy nem mozog sokat. És akkor az adatok, a stream-ek és az összes tranzakciós alkalmazás megvan, plusz manapság olyan események, esemény-adatfolyamok is vannak, amelyek az alkalmazásokban fordulnak elő, és amelyekre szükség lehet, és manapság a mindennapi lambda-architektúrákkal való tényleges hatással vannak csak az egész adatmező.
És manapság azon gondolkodni kell, hogy létezik-e egy adatréteg. Az adatréteg létezik egyfajta virtuális módon, abban az értelemben, hogy egy jó része felhőben lehet, és elosztható az adatközpontok között, létezhet munkaállomásokon. Az adatréteg bizonyos mértékig mindenhol létezik, és ebben az értelemben mindenhol vannak olyan folyamatok, amelyek valamilyen módon megkísérelik feldolgozni az adatokat, és az adatokat áthelyezik. Nagyon fontos az is, ha tudod, mi az, amikor mozgatod.
Ha az adatmodellezést az általános értelemben vettük át, akkor az ilyen típusú verem alján fájlok és adatbázisok találhatók. Van adatelemeinek, amelyek kulcsokkal, elemdefiníciókkal, álnevekkel, szinonimákkal, speciális fizikai formátumokkal rendelkeznek, és akkor megvan ez a metaadatréteg.
A metaadatok érdekessége, hogy a metaadatok teljesen az, ahogyan az adatok megértik a jelentését. Ha valójában nem rendelkeznek metaadatokkal, akkor a legjobb esetben kitalálni tudja az adatok jelentését, de borzasztóan sok nehézséggel kell számolnia. A metaadatoknak ott kell lennie, de a jelentésnek felépítése van. Nem akarok belemenni a jelentés filozófiájába, de az adatokkal való foglalkozás során is nagyon kifinomult az emberi gondolkodás és az emberi nyelv, ami nem könnyű kifejezni magát az adatokban. De még a világban ténylegesen feldolgozott adatok szempontjából is a metaadatoknak van értelme és a metaadatok felépítése - az egyik adat a másikhoz viszonyítva, és mit jelent ez, amikor összerakják, és mit jelent, amikor összekapcsolódnak más adatok, megköveteli, hogy modellezzük. Nem elég ahhoz, hogy csak metaadat-címkéket rögzítsen a dolgokhoz, valójában a struktúrák szerinti jelentést és a struktúrák közötti kapcsolatot kell rögzíteni.
Akkor a legfelső rétegben vannak az üzleti meghatározások, amelyek általában olyan rétegek, amelyek megkísérelik átadni a jelentést a metaadatok között, ez az adatmeghatározás egy olyan formája, amely megfelel az adatok számítógépes megszervezésének és az emberi jelentésnek. Tehát üzleti feltételei, meghatározásai, kapcsolatai, entitás szintű fogalmak léteznek ebben a rétegben. És ha inkoherencia mutatkozik e rétegek között, akkor adatmodellezésre van szükség. Nem igazán választható. Minél többet megtehetsz automatizálásával, annál jobb. De mivel ez köze van a jelentéshez, nagyon nehéz váltakozni. Elég egyszerű ahhoz, hogy a metaadatokat begyűjtse egy nyilvántartásba, és képes legyen azokat egy jelentéssorozatból kinyerni, de nem mondja meg a rekordok felépítését, vagy azt, hogy mit jelentenek a rekordok, vagy amelyek a nyilvántartás következményei.
Szóval, véleményem szerint erről szól az adatmodellezés. Megjegyzendő, hogy minél összetettebbé válik az adatok világa, annál többet kell modellezni. Más szavakkal, ez kissé olyan, mintha nem csupán több példányt adna hozzá a világhoz, amely megfelelne az adatrekordoknak, hanem valójában több jelentést adott a világnak azáltal, hogy egyre több és több dologra vonatkozó adatokat gyűjtött. Egyre bonyolultabb érzés, amelyet meg kell értenünk.
Az elméletben egy adat-univerzum létezik, és szükségünk van annak áttekintésére. A gyakorlatban a tényleges metaadatok az adathalmaz része. Tehát ez nem egy egyszerű helyzet. A modellezés kezdete felülről lefelé és alulról felfelé. Mindkét irányba kell építnie, és ennek oka az, hogy az adatoknak van értelme a számítógépnek és a folyamatnak, amelynek feldolgoznia kell, de önmagában is jelentéssel bír. Szüksége van egy alulról felfelé irányuló jelentésre, amely kielégíti az adatokhoz való hozzáférést igénylő szoftvert, és szüksége van a fentről lefelé mutató jelentésre, hogy az emberek megértsék. A metaadat-modellek felépítése nem és soha nem lehet projekt; folyamatos tevékenysége - folyamatos tevékenység legyen minden létező környezetben. Szerencsére nagyon sok olyan környezet van, ahol valójában nem ez a helyzet, és a dolgok ennek megfelelően kikerülnek az ellenőrzés alól.
Ha tovább megyünk, akkor a modellezés a technológia előrehaladtával növekszik. Ez a véleményem. De ha az IoT-t nézzük, akkor jobban megérthetjük a mobilitást, mint régen, bár annak új dimenzióit vezettük be: a helymeghatározás dimenzióját a mobilnal. Miután eljutott az IoT-hez, olyan rendkívüli adatproblémákra nézett, amelyekre soha nem kellett volna tennünk, és így vagy úgy kell megértenünk, hogy pontosan mire jutottunk, pontosan hogyan tudjuk összesíteni, mit tehetünk. az aggregálás értelmezésének szempontjából, és természetesen, mit tehetünk vele, amikor feldolgozzuk.
Azt hiszem, engem eléggé mondani. Átadom Dez Blanchfieldnek, aki egészen valamit mond.
Dez Blanchfield: Köszönöm. Mindig kemény lépést kell követnünk, de ezt a témát egyeztettük és röviden beszéltük a bemutató show-ban, és ha korán tárcsázol, valószínűleg egy csomó nagyszerű drágakövet fogott el. Az egyik elvihető, és nem akarom ellopni ennek a mennydörgését, de az egyik előadás a show-ban résztvevő rendezvényektől, amelyet meg akarok osztani, ha nem sikerült elkapni, éppen az adatutazás témája körüli. , és engem bántalmazott, hogy ténylegesen leírom azt az utazást, amikor az adatok más generáción vesznek részt a generációk élettartama körül - év, hónap, hét, nap, óra, perc, másodperc -, és az adatok körüli con található abban a con . Függetlenül attól, hogy fejlesztőként futok-e kóddal, vagy adatkezelőként gondolok-e, és gondolok-e az egyes elemek struktúrájára és formátumára, valamint a metaadatokra, vagy arra, hogy a rendszerek és az üzleti vállalkozások milyen módon kölcsönhatásba lépnek vele.
Érdekes kis elvitel, csak megjegyezni, de egyébként engedje, hogy belemerüljek. Különösen az adattervezés egy olyan kifejezés, amelyet az összes adatról beszélek, különös tekintettel az alkalmazások vagy az adatbázis-infrastruktúra fejlesztésére. Úgy gondolom, hogy az adattervezés egy olyan kifejezés, amely csak mindent nagyon jól megrajzol a fejemben. Manapság, amikor az adattervezésről beszélünk, a modern agilis adattervezésről beszélünk, és véleményem szerint nem olyan régen volt, hogy a fejlesztők és az adatszakértők egyedül dolgoztak; a saját silójukban voltak, és a tervezett darabok egyik silótól a másikig mentek. De manapság nagyon nagy a véleményem, hogy nem csak az, hogy megváltoztak, hanem meg is kell változni; ez egyfajta szükségszerűség, és ez az alkalmazás - a fejlesztők és az adatkezeléssel kapcsolatos fejlesztések, a tervezők, akik a sémák és mezők és nyilvántartások megfelelő tervezési elemeit, valamint a hely- és adatbázis-rendszereket és infrastruktúrákat, a modellezést és a teljes menedzsmentet kihívás körül. Ez most egy csapatsport, és ennélfogva az én képem egy csomó emberről, aki egy repülőgépből kiugrott, csapatként működve, hogy az égbolton eső emberek vizuálisan érdekes képét játssza le.
Harmadszor, mi történt ezzel? Nos, van egy cikk, amelyet 1986-ban írt néhány úriember, akinek a nevét én kétségbeesetten próbáltam igazságot tenni: Hirotaka Takeuchi és Ikujiro Nonaka, azt hiszem, hogy ezt kimondani kell. ez a rögbi játék nyerésének módszertanának gondolata, amely ebből a súrlódási tevékenységből indul ki, ahol mindenki egy helyen mozog, és két csapat lényegében becsavarja a fejét valamilyen úgynevezett súrlódásba, hogy megpróbálja megszerezni a labdát és ellenőrizni a pályán, hogy érjen el a próbavonalhoz, érintse meg a talajt a labdával, és kap egy pontot, az úgynevezett trine-t, és megismétli ezt a folyamatot, és több pontot kap a csapat számára.
Ezt a cikket 1986-ban tették közzé a Harvard Business Review-ben, és kíváncsi módon ez valójában sok figyelmet kapott. Nagy figyelmet kapott, mert lenyűgöző új fogalmakat vezetett be, és itt van egy képernyőkép a képernyő elejéről. Tehát kivették ezt az ötletet a játék rögbijéből, és bevezették az üzleti életbe, különösen a tervezés és a projektszállítás, nevezetesen a projektszállítás területén.
Amit a scrum csinált, új módszertant adott nekünk a PRINCE2 vagy a PMBOK hasonlóságaival összehasonlítva, amelyeket korábban már használtunk az úgynevezett vízesés módszertannál, tudod, csináld ezt a dolgot, ezt a dolgot és ezt a dolgot, és követed őket egymás után, és csatlakozhatsz az összes pötty körül, ami attól függ, milyen volt, vagy ne végezze el a második részt, amíg nem végezted el az első részt, mert az az első résztől függött. Amit adott nekünk, egy új módszer, amely kissé agilisabbá válik, ahonnan a szó származik, arról, hogy miként szállítjuk a dolgokat, különös tekintettel a tervezési és fejlesztési kezdeményezésekre.
Néhány kulcsfontosságú bérlő - csak úgy tudok tovább foglalkozni ezzel - a kerek bérlők körében van.Bemutatta az instabilitás építésének gondolatát, hogy ha a káosz félelmére gondolsz, akkor a világ a káosz állapotában létezik, de a bolygó kialakult, ami érdekes, tehát az épületek instabilitása, a képesség egy kicsit visszapattanni és továbbra is működésbe hozza a dolgokat, önszerveződő projektcsapatokat, átfedő előnyöket biztosítva a nagyon felelősségteljes fejlesztés, a különféle típusú tanulás és irányítás révén a projekt megvalósításának útján, a tanulás szervezeti átadásán keresztül. Tehát hogyan vehetjük át az információkat az üzleti vállalkozások egyik részéről, és átadhatjuk azokat a másiknak azoktól az emberektől, akiknek van ötlete, de nem fejlesztenek kódot, vagy nem fejlesztenek adatbázisokat és infrastruktúrákat, hanem adatokat azoknak az embereknek? És kifejezetten az időzített eredményekre. Más szavakkal, tegyük ezt egy ideig, akár egy nap, akár 24 óra alatt, akár egy hét vagy néhány hét, és nézzük meg, mit tehetünk, majd lépjünk vissza, és nézzünk rá.
És tehát, ha megbocsátja a büntetést, ez valóban egy új játék a projekt megvalósításában és annak három alapvető alkotóeleménél, amelynek értelme lesz, ha egy kissé tovább megyünk itt - ott van a termék: mindezen embereknek van ötlete és van valami elkészítésének szükségessége és a körülvevő történet. Azok a fejlesztők, akik az agilis modellje szerint elsajátítják a történeteket, és a napi standupekon keresztül a scrum módszertant használják, hogy megvitassák azt és megértsék, mit kell tennie, majd csak menjenek tovább, és csinálják. Aztán az emberekről hallottunk olyan súrolómesterektől, akik felügyelik ezt az egész dolgot, és elég jól megértik a módszertant annak vezetéséhez. Mindannyian láttuk ezeket a képeket, amiket a jobb oldali fal és a táblák tele Post-It feliratokkal láttak el, és Kanban falakként szolgálták őket. Ha nem tudod, ki a Kanban, felhívlak a Google-be, ki volt Kanban úr, és miért változtatta meg azt, ahogyan a dolgokat egyik oldalról a másikra a falon szó szerint, de egy projektben mozgatjuk.
Röviden: a scrum munkafolyamat ezt teszi: elkészíti a dolgok listáját, amelyeket a szervezet meg akar tenni, végigviszi azokat a sorsokat, amelyeket úgynevezett ss-nek nevezünk, amelyek fel vannak osztva 24 órás periódusokra, egy hónapos periódusokra, és mi kapja meg ezt a kimeneti növekményes sorozatot. Ez jelentős változás abban, ahogyan a projektek szállításukban megtörténtek, egészen addig a szakaszig, mert annak egy része áramlik úgy, mint az amerikai hadsereg, akik nagy szerepet játszottak a PMBOK néven kifejlesztett dolgok kidolgozásában, mint például az a gondolat, hogy ne szállítsák a tartályt a mezőre amíg golyókat nem tesz a tárgyba, mert ha a mezőben lévő tartálynak nincs golyója, az haszontalan. Ezért tehát az első részbe golyókat helyezzen a tartályba, a második részbe a tartályt tegye a mezőbe. Sajnos azonban, ami történt a fejlesztõkkel a fejlõdési világban, valahogy megragadta ezt az agilis módszertant, és hamarosan kifogyott vele, ha megbocsátod a büntetést.
Mindig, ami történt, amikor az agilisra gondolunk, általában fejlesztőkre gondolunk, nem pedig adatbázisokra, és bármi köze van az adatbázisok világához. Sajnálatos eredmény volt, mert a valóság az, hogy az agilis nem korlátozódik a fejlesztőkre. Valójában véleményem szerint az agilis kifejezést gyakran tévesen társítják kizárólag a szoftverfejlesztőkhöz, nem pedig az adatbázis-tervezőkhez és az építészekhez. Mindig ugyanazokkal a kihívásokkal kell szembenéznie, amelyekkel szembesül a szoftver- és alkalmazásfejlesztésben, mindazon dolgokkal kapcsolatban, amelyek a tervezéshez és fejlesztéshez, valamint a működtetéshez és a karbantartáshoz kapcsolódnak, tehát az adatinfrastruktúrához és különösen az adatbázisokhoz. Az adott adatgyűjtő szereplői között szerepelnek az adatok építészek, öntőformák, az adminisztrátorok, az adatbázis-infrastruktúrák kezelői és a tényleges adatbázisok egészen az üzleti és a rendszerelemzők és építészek, az emberek, akik ülnek és gondolkodnak a rendszerekről és az üzleti vállalkozások működnek, és hogyan jutottunk el ezeken keresztül az adatok áramlásához.
Ezt a témát rendszeresen felvetem, mivel állandó csalódásom az, hogy véleményem szerint az adatszakértőknek - és nem is - szorosan be kell vonniuk a projekt megvalósításának minden elemébe, sőt, különösen a fejlesztésbe. Ha nem, akkor valójában nem adjuk meg a legjobb esélyt a jó eredmény elérésére. Gyakran vissza kell fordulnunk, és újból gondolkodnunk kell ezekről a dolgokról, mert létezik forgatókönyv, eljutunk egy épülő alkalmazáshoz, és felfedezzük, hogy a fejlesztők nem mindig az adatok szakértői. Az adatbázisokkal való munka nagyon speciális készségeket igényel, különös tekintettel az adatokra, és tapasztalatokat teremt. Nem csak egy éjszakánként válik azonnal adatbázis-guru vagy adattudás-szakértővé; ez gyakran valami egész életen át tartó tapasztalatból származik, és természetesen Dr. Robin Bloornak a Code Today iránti kedvéért, aki meglehetősen gazdagon írta a könyvet.
Sok esetben - és ez sajnálatos, de valóságos - hogy ennek az érmének két része van, vagyis a szoftverfejlesztőknek megvan a saját áramszünet az adatbázis-szakember számára, és felépítették az adatbázis-tervezés modellezéséhez szükséges készségeket, a modellfejlesztés pedig csak a alapvető fontosságú a guruk számára az adatok bejutásának, az utazás megszervezésének, valamint annak, hogyan kell vagy nem kell kinéznie, vagy kétségtelenül az, hogy elfogyasztották és megértették, hogy általában a szoftverfejlesztők számára készített natív készségekhez jutottak el. És a közös kihívások némelyike, csak összefoglalva, magában foglalja az alapvető létrehozás, karbantartás és az alap-adatbázis-tervezés kezelését is, az adatok és az adatbázis-infrastruktúra dokumentálását, majd az adatok felhasználását, sématervezést, sémagenerációk, a séma adminisztrációja és karbantartása, valamint azok használata, a tudás megosztása, miért ezt a sémát egy adott módon fejlesztették ki, valamint az ehhez kapcsolódó erősségek és gyengeségek az idő múlásával az adatok időbeli változásait, az adatmodellezést és a típusokat a modellek közül, amelyeket alkalmazunk a rendszerekre és azokra az adatokra, amelyeket rajtuk átfolytatunk. Adatbázis-kód generálása, és ez folytatódik az integráción, majd modellezett adatokkal körülötte, majd gyorsabban hozzáférve az adatok körüli biztonság ellenőrzéséhez, az adatok integritása az adatok mozgatásával jár, amikor megőrizzük integritását, van-e elegendő metaadat azt kell látni, ha az eladóknak látniuk kell a táblázat összes rekordját, vagy csak a címet, az utónevet és a vezetéknevet kell látniuk? És akkor természetesen a legnagyobb kihívás az adatbázis-platformok modellezése, amely önmagában teljesen más beszélgetés.
Nagyon azon a véleményen vagyok, hogy mindezt szem előtt tartva, hogy ennek a nirvánának bármelyikét lehetővé tegyük, feltétlenül kritikus, hogy mind az adatszakértőknek, mind a fejlesztőknek rendelkezzenek a megfelelő eszközökkel, és hogy ezek az eszközök képesek legyenek a csapatorientált projekt megvalósítására, tervezés, fejlesztés és folyamatos üzemeltetési karbantartás. Tudod, olyan dolgokról van szó, mint például az adatszakértők és a szoftverfejlesztők közötti projektek közötti együttműködés, az igazság egyetlen pontja vagy egyetlen igazságforrás mindazon dolgok vonatkozásában, amelyek maguk az adatbázisok, az adatok, a sémák, ahonnan az iratok származnak, azoknak a tulajdonosainak . Úgy gondolom, hogy manapság ez abszolút kritikus, megkapjuk az adatok nirvánáját, hogy királyok legyenek, hogy a megfelelő eszközöknek helyükre kell lenniük, mivel a kihívás túlságosan nagy ahhoz, hogy manuálisan tegyük, és ha az emberek ha belépünk egy szervezetből és onnan kívül, túl könnyű számunkra, hogy ne kövessük ugyanazt a folyamatot vagy módszertant, amelyet egy ember állíthat fel, jó, és nem feltétlenül továbbadjuk ezeket a készségeket és képességeket a továbblépéshez.
Ezt szem előtt tartva átadom az IDERA jó barátunknak, és meghallom az eszközről, és hogyan kezeli ezeket a dolgokat.
Ron Huizenga: Nagyon köszönöm, és köszönöm Robinnak és Deznek is, hogy valóban jól beállították a színpadot, és látni fogtok egy-egy átfedést néhány olyan dologban, amiről beszéltem. De valóban nagyon szilárd alapot teremtettek néhány olyan koncepcióhoz, amelyről adatmodellezési szempontból fogok beszélni. És sokuk, amit mondtak, visszatér a saját tapasztalataimhoz, amikor tanácsadóként dolgoztam az adatmodellezés és az architektúra területén, a csapatokkal együtt - mind a vízesés a kezdeti napokban, mind pedig modern termékekké alakultak olyan projektekkel, amelyekben agilitást alkalmaztunk. módszerek a megoldások megvalósításához.
Tehát amiről ma beszélni fogok, azokra a tapasztalatokra, valamint az eszközök nézeteire és az eszközök bizonyos képességeire épül, amelyeket az utazás során felhasználunk. Amit nagyon röviden megemlítek, az az, hogy nem fogok sok részletbe belemenni; csak nagyon jó áttekintést kaptunk arról, hogy mi ez. Arról fogok beszélni, hogy mi az adatmodell és mit jelent valójában ez számunkra? És hogyan tegyük lehetővé az agilis adatmodellező koncepció kialakítását szervezeteinkben: hogyan vonjuk be az adatmodellezőket, mi a modellezők és építészek részvétele a programok során, milyen típusú tevékenységeket kellene elvégezniük , és ennek hátterében néhány fontos modellező eszköz képességeit használjuk fel, amelyek valóban elősegítik a munka megkönnyítését? Akkor belemegyek egy kicsit, és csak egy kicsit beszélek az adatmodellező részvételének egyes üzleti értékeiről és előnyeiről, vagy ahogy a történetet tényleg el fogom mondani, az a probléma, hogy nincs adatmodellező teljes mértékben bevonva a projektekbe, és megmutatom nektek, tapasztalatok és egy tényleges projekt előzetes és utáni képének diagramja alapján, amelyben sok évvel ezelőtt vettem részt. Aztán összefoglalunk még néhány pontot, és kérdéseinkkel és válaszaival is foglalkozunk.
Röviden: az ER Studio egy nagyon nagy teljesítményű csomag, amely rengeteg különféle komponenssel rendelkezik. A Data Architect, ahol az adatmodellezők és építészek idejük nagy részét adatmodellezéssel töltik. Vannak más alkatrészek is, amelyekről ma még nem fogunk beszélni, mint például az üzleti építész, ahol folyamatmodellezést végezünk, és a szoftver-építész, az UML-modellek egy részéhez. Aztán ott van a Repository, ahol bejelentkezünk, megosztjuk a modelleket, és lehetővé teszjük a csapatoknak, hogy együttműködjenek azokon, és közzétegyék őket a csapatkiszolgálón, hogy a projektben részt vevő több érdekelt közönség valóban láthassa azokat a tárgyakat, amelyeket „ újból adatkezelési szempontból, és más dolgokkal is dolgozunk, amelyeket magunknak a projekteknek a végrehajtásában teszünk.
Amit ma összpontosítani fogok, néhány olyan dolgot fogunk látni, amelyet látni fogunk az Data Architect-en keresztül, és mivel nagyon fontos, hogy ennek a Repository-alapú aspektusainak együttműködése működjön együtt. Különösen akkor, amikor olyan fogalmakról beszélünk, mint például a változásmenedzsment, amelyek nélkülözhetetlenek nem csak az agilis fejlesztési projektekhez, hanem a jövőbeni bármilyen típusú fejlesztéshez is.
Tehát beszéljünk egy pillanatra az Agile Data Modeler-ről. Mint ahogyan az a bemutató korábbi szakaszaira utal, az elengedhetetlen, hogy rendelkezzünk adatmodellezőkkel és / vagy építészekkel, akik teljes mértékben részt vesznek az agilis fejlesztési folyamatokban. Most, ami történelmileg történt: igen, fejlesztési szempontból valóban gondolkodtunk az agilisról, és van néhány dolog, amelyek megy tovább, amelyek valóban okozták ezt. Ennek részben annak a természetének tudható be, hogy a fejlesztés maga kibontakozik. Ahogy az agilis fejlesztés elkezdődött, és ezzel az önszerveződő csapat koncepcióval kezdtük, ha egy kicsit túl tiszta italt a Kool-Aid-ot, és a dolgok szélsőséges programozási oldalán állt, akkor a dolgok nagyon szó szerint értelmezték a önszervező csapatok, amelyeket sok ember úgy értett, hogy csak egy fejlesztői csoportra van szükségünk, amely teljes megoldást felépíthet. Legyen szó a kód, az adatbázisok vagy a mögötte lévő adatbázisok fejlesztéséről, és mindent átadtak a fejlesztőknek. De ami ezzel történik, akkor elveszíti az emberek különleges képességeit. Megállapítottam, hogy a legerősebb csapatok azok, akik különböző háttérrel rendelkező emberekből állnak. Ilyen például az erős szoftverfejlesztők, adatépítészek, adatmodellezők, üzleti elemzők és üzleti érdekeltek kombinációja, akik együtt működnek együtt egy végső megoldás kidolgozása érdekében.
Amit ma is beszélek, az az, hogy ezt egy fejlesztési projekt keretében fogom megtenni, ahol olyan alkalmazást fejlesztünk ki, amely nyilvánvalóan hozzá fog kapcsolódni az adatelemhez. Mégis meg kell tennünk egy lépést hátrafelé, mielőtt ezt megtennénk, mert fel kell ismernünk, hogy nagyon kevés Greenfield fejlesztési projekt van odakint, ahol összpontosítunk olyan adatok létrehozására és felhasználására, amelyek csak a fejlesztési projekten belül korlátozottak . Lépést kell hátrálnunk, és át kell néznünk az általános szervezeti szempontot adat- és folyamat-szempontból. Mert megtudjuk, hogy az általunk felhasznált információk már léteznek valahol a szervezetekben. Mint modellezők és építészek ezt felvilágosítottuk, hogy tudjuk, honnan származhatnak ezek az információk a projektekben. Ismerjük az érintett adatszerkezeteket is, mivel olyan tervezési mintákkal rendelkezünk, mint a fejlesztőknek a kódjukhoz. És ezt az átfogó szervezeti perspektívát is figyelembe kell vennünk. Nem csak az épített alkalmazás adatait tekinthetjük meg. Az adatokat modelleznünk kell, és ügyelnünk kell arra, hogy dokumentáljuk, mert sokkal túl élnek az alkalmazásokon túl. Ezek az alkalmazások jönnek és mennek, de meg kell tudnunk nézni az adatokat, és meg kell győződnünk arról, hogy azok robusztusak és jól strukturáltak, nemcsak az alkalmazásokhoz, hanem a tevékenységeket jelentő döntésekhez, a BI jelentésekhez és az egyéb alkalmazásokhoz történő integrációhoz, belső és szervezeteinkön kívül is. Tehát meg kell vizsgálnunk az adatoknak a teljes nagy képet, és az adatok életciklusát, és meg kell értenünk az információdarabok útját a szervezetben a bölcsőtől a sírig.
Visszatérve a magukhoz a csapatokhoz és annak, hogy valójában hogyan kell dolgoznunk, a vízesés módszerét túl lassúnak találták az eredmények elérése érdekében. Mivel, ahogyan azt a tartály példáján rámutattak, lépésről lépésre volt, és gyakran túl sokáig tartott, hogy működőképes végeredményt nyújtsanak. Amit most csinálunk, szükségünk van egy iteratív munkastílusra, ahol fokozatosan fejlesztettük ki annak alkatrészeit, és idővel kidolgozzuk azt, ahol felhasználható kódot vagy felhasználható műtermékeket állítunk elő, azt mondom mindenkinek. Fontos dolog a csapat műszaki és üzleti érdekelteinek együttműködése, mivel együttműködünk annak érdekében, hogy ezeket a felhasználói történeteket a kód és a kódot támogató adatok megvalósítható képévé alakítsuk. És maga az Agile Data Modeler gyakran azt fogja tapasztalni, hogy nincs elég modellezőnk a szervezetekben, így egy adatmodellező vagy építész egyszerre támogathat több csapatot.
És ennek másik aspektusa, még ha több modellezőnk is van, meg kell győződnünk arról, hogy van-e olyan eszközkészletünk, amelyet használunk, amely lehetővé teszi több, egyidejűleg repülésben lévő projekt együttműködését és ezek megosztását. adatelemek, valamint a be- és kijelentkezés képességei. Nagyon gyorsan megyek erre, mert az előző szakaszban már ismertettük. Az agilis valódi előfeltétele, hogy a dolgokat a lemaradástól, a történetektől vagy a követelményektől veszi alapul. Az iterációkon belül csoportként működünk együtt. Általában egy kéthetes vagy egyhavi s, a szervezettől függően, nagyon gyakori. Napi áttekintést és standup értekezleteket is folytatunk, hogy kiküszöböljük a blokkolókat, és ügyeljünk arra, hogy minden szempontot előremozdítsunk anélkül, hogy megállnánk a különböző területeken, amint átmenünk. És ezekben a ss-kben azt akarjuk biztosítani, hogy felhasználható eredményeket állítsunk elő minden s részeként.
Csak egy kicsit másképp veszem figyelembe, és tovább bővítve a scrum módszertant, amelyről itt konkrétabban fogok beszélni, és ezt az előző képet alapvetően néhány további aspektussal kiegészítettük. Általában van egy termékmaradás, majd van egy elmaradás. Tehát van egy olyan általános elmaradásunk, amely minden ismétlés kezdetén azt mondja: “Mit fogunk építeni ezekre?”, És ezt egy tervezési értekezleten készítjük el. Ezután felbontjuk az ehhez kapcsolódó feladatokat, és az egy-négy hetes ss-ben végrehajtjuk a napi áttekintéseket. Amint ezt megtesszük, nyomon követjük az előrehaladást az égési diagramokon és a leégett táblázatokon keresztül, hogy alapvetően nyomon követhessük, hogy mi marad az építéshez viszonyítva, és mit építünk, hogy létrehozzunk olyan dolgokat, mint például a mi fejlesztési sebességünk, mi ütemterv, az összes ilyen típusú dolog. Mindezt folyamatosan fejleszti az egyes évek során, ahelyett, hogy néhány hónapos úton haladnának, és megtudnák, hogy röviddel fog jönni, és meg kell hosszabbítania a projekt ütemtervét. És nagyon fontos, hogy ennek részeként, az egész csapat számára, legyen egy áttekintés a végén és visszamenőleges, tehát mielőtt elkezdené a következő iterációt, átnézi, mit tett, és keressen olyan lehetőségeket, amelyekkel javíthatja legközelebb át.
A teljesítményeket tekintve ez alapvetően egy dia, amely összefoglalja a tipikus dolgokat, amelyek az ss-ben folynak. És nagyon fejlõdés-központú, tehát sok olyan dolog, amit itt látunk, például a funkcionális tervek és használati esetek, a tervezési kód tesztelése, amikor itt megnézzük ezeket a dobozokat, és nem megyek átmenni rajtuk. bármilyen részletességgel, nagyon fejlődés-orientáltak. És itt van eltemetve az a tény, hogy ezen erőfeszítések támogatása érdekében szükségünk van olyan adatszolgáltatásokra is, amelyek ezzel együtt járnak. Tehát minden alkalommal, amikor látunk olyan dolgokat, mint a háttérmagatartás, a követelmények és a felhasználói történetek, ahogy megyünk keresztül, meg kell vizsgálnunk, hogy mi a fejlesztési elem, amelyet meg kell tennünk, mi az elemző elem, amelyet meg kell tennünk, mi a helyzet a adattervezés vagy adatmodell, mi a helyzet az üzleti szótárakkal, így az üzleti jelentést az összes előállított tárgyhoz hozzárendelhetjük? Mert minden felhasználható eredményt el kell készíteni.
Néhányan azt állítják, hogy minden kód végén el kell készítenünk a használható kódot. Nem feltétlenül ez a helyzet, vagyis a legtisztább fejlesztési szempontból, de elég gyakran - különösen a kezdetben - lehet, hogy valami olyan, mint az nulla, ahol pusztán az állásra koncentrálunk, olyan dolgokra tesszük, mint például a tesztstratégiánk beolvasása hely.Magas szintű tervezés az induláshoz, még mielőtt kitöltenénk a részleteket, és ellenőriznünk kell, hogy tiszta-e a kezdő történetek vagy követelmények, mielőtt más közönséget vonzanánk, majd továbbépítjük csapatként. Mindig van egy kis előkészítési idő, tehát gyakran nulla vagy akár nulla és egy lesz. Lehet, hogy egy kicsit elindul, mielőtt teljes megoldást érünk el a megoldás szállításában.
Röviden röviden beszéljünk az adatmodellekről. Amikor az emberek adatmodellekre gondolnak, gyakran úgy gondolják, hogy az adatmodell olyan kép, amely szemlélteti, hogy a különféle információk hol kapcsolódnak egymáshoz - ez csak a jéghegy csúcsa. Annak érdekében, hogy teljes mértékben megtestesítse az adatmodellezés megközelítésének szellemét - legyen az agilis fejlesztés és egyéb dolgok is -, fel kell ismernie, hogy az adatmodell, ha helyesen készítik el, akkor teljes specifikációja lesz annak, mit jelent ez az adat a szervezetben, és hogyan telepíti a háttér-adatbázisokban. Amikor az adatbázisokat mondom, nemcsak a relációs adatbázisokra gondolok, amelyeket esetleg használunk, hanem a mai architektúrákban is, ahol nagy adataink vannak vagy NoSQL platformok, ahogyan én inkább nekik hívom. Ugyancsak azok a nagy adattárolók, mert valószínűleg sok különféle adattárolót kombinálunk az információk felhasználása és a megoldásainkba történő beépítés szempontjából, valamint az, hogy hogyan tároljuk vagy tároljuk ezeket az információkat a megoldásainkból is.
Előfordulhat, hogy egy adott alkalmazás során egyidejűleg több adatbázissal vagy adatforrással dolgozunk. Nagyon fontos, hogy teljes specifikációval rendelkezzünk, tehát logikai specifikációval kell megfogalmazni, hogy mit jelent ez szervezeti perspektívaként, hogy mi a fizikai konstrukció az, ahogyan ténylegesen meghatározzuk az adatokat, milyen kapcsolat áll fenn az adatbázisok, a referencia-integritási korlátozások, az ellenőrzési korlátozások, az összes érvényesítési elem, amelyekre általában gondolkodik. A leíró metaadatok rendkívül fontosak. Honnan tudja, hogyan tudja felhasználni az adatokat az alkalmazásaiban? Hacsak nem definiálhatja és nem tudja, hogy mit jelent, vagy tudja, honnan származott, hogy megbizonyosodjon arról, hogy helyes adatokat fogyaszt-e ezekben az alkalmazásokban - ügyeljen arra, hogy helyes elnevezési konvenciókkal, teljes definíciókkal rendelkezzünk, ami nem csak a teljes adat-szótárt jelenti a táblázatokat, de az azokat tartalmazó oszlopokat - és a részletes felhasználási tudnivalókat annak felhasználásáról, mivel ki kell építenünk ezt a tudásbázist, mert még akkor is, ha ezt az alkalmazást elkészítjük, ezt az információt más kezdeményezésekre fogjuk használni, ezért meg kell győződnünk arról, hogy mindent dokumentáltunk a jövőbeli megvalósításokhoz.
Ismét olyan dolgokhoz jutunk, mint az adattípusok, kulcsok, indexek, maga az adatmodell megtestesíti a sok üzleti szabályt, amelyek érvénybe lépnek. A kapcsolatok nem csupán korlátozások a különböző táblák között; gyakran segítenek nekünk leírni, hogy mi az igazi üzleti szabályok az adatok viselkedése és az összetartozó egységként történő működése körül. És természetesen az értékkorlátozások nagyon fontosak. Most természetesen az egyik dolog, amivel folyamatosan foglalkozunk, és ez egyre inkább elterjedt, olyan dolgok, mint az adatkezelés. Tehát adatkezelési szempontból is meg kell vizsgálnunk, hogy mit határozunk meg itt? Olyan dolgokat akarunk meghatározni, mint a biztonsági osztályozás. Milyen típusú adatokkal foglalkozunk? Mit fognak tekinteni a törzsadatkezelésnek? Milyen tranzakciós üzleteket hozunk létre? Milyen referenciaadatokat használunk ezekben az alkalmazásokban? Gondoskodnunk kell arról, hogy ezt megfelelően felismerjük modelleinkben. Az adatminőségi szempontok mellett bizonyos információk is fontosabbak egy szervezet számára, mint mások.
Olyan projektekben vettem részt, ahol több mint tucat régi rendszert cseréltek új üzleti folyamatokra, és új alkalmazásokat és adattárakat terveztünk ezek helyett. Tudnunk kellett, honnan származik az információ. Melyik a legfontosabb információ szempontjából, üzleti szempontból, ha megnézzük ezt a konkrét adatmodellt, amelyre itt jutottam, akkor látni fogja, hogy ezeknek az entitásoknak az alsó négyzete, amely csak egy kis részhalmaz, én Valójában képes volt felmérni az üzleti értéket. Akár magas, közepes vagy alacsony az ilyen típusú dolgokra a szervezeten belüli különféle konstrukciók számára. És olyan képeket is rögzítettem, mint a törzsadatok, függetlenül attól, hogy mester táblák, referenciák, ha tranzakciók. Tehát kibővíthetjük modelleinkben a metaadatainkat, hogy sok más tulajdonságot kapjunk nekünk az adatokon kívül is, ami valóban segített nekünk az eredeti projekten kívüli más kezdeményezésekben és továbbvittük őket. Most, hogy sok volt egy csúszda, ezeket a fennmaradó részeket meglehetősen gyorsan áttekintem.
Most nagyon gyorsan beszélek arról, hogy mit csinál egy adatmodellező, miközben megyünk ezen a különféle ss-en. Mindenekelőtt a tervezési ülések teljes résztvevője, ahol felvesszük a felhasználói történeteket, elkötelezzük magunkat azzal, amit ezekben fogunk szállítani, és kitaláljuk, hogyan fogjuk felépíteni és átadni. Amit adatmodellezőként is csinálok, azt tudom, hogy külön területeken fogok dolgozni különböző fejlesztőkkel vagy különböző emberekkel. Tehát az egyik fontos jellemzõ, hogy adatmodellt készíthetünk, megoszthatjuk azt az adatmodellt különbözõ nézetekre - függetlenül attól, hogy tantárgyaknak vagy almodelleknek nevezzük - a terminológiánk. Tehát a modell felépítésekor ezeket a különféle almodell perspektívákban is megmutatjuk, így a különböző közönség csak azt látja, ami releváns számukra, így összpontosíthatnak arra, amit fejlesztenek és előterjesztenek. Tehát lehet, hogy valaki dolgozik egy alkalmazás ütemezési részén, vagyok, hogy valaki más dolgozzon egy rendelésbejegyzésnél, ahol mindezeket egyetlen lépésben hajtjuk végre, de a nézeteiket azokon az almodelleken keresztül adhatom meg, amelyek csak vonatkoznak arra a területre, amelyen dolgoznak. Aztán azok lépnek fel az általános modellre és az almodelek teljes struktúrájára, hogy eltérő közönség-nézeteket adhassanak ahhoz, amit látniuk kell.
Az adatmodellezési szempontból az alapok, amelyekre szükségünk van, mindig rendelkezzen olyan alapvonallal, amelyre vissza tudunk térni, mert az egyik dolog, amit meg kell tudnunk tenni, függetlenül attól, hogy a végén vagy a végén van. Több ss, szeretnénk tudni, honnan indultunk, és mindig van alapvető tudásunk arról, hogy mi volt a delta vagy a különbség abban, amit egy adott s-ben előállítottunk. Gondoskodnunk kell arról is, hogy gyors fordulatot érjünk el. Ha adatmodellezőként lépsz be, de a hagyományos kapuőr szerepében, amikor azt mondják: „Nem, nem, ezt nem teheted meg, mindezt először meg kell csinálnunk”, akkor ki lesznek zárva a csapatból, amikor valóban szüksége van rá aktív résztvevőnek lennie az agilis fejlesztési csapatokban. Ez azt jelenti, hogy egyes dolgok leesnek a kocsiból, ha egy adott feladatot végrehajtanak, és később felveszik őket.
Példaként arra összpontosíthat az adatstruktúrákra, hogy a fejlesztés érthető legyen, az a rendelésbeviteli darab, amelyről beszélek. Később visszatérhet, és kitölti az adatokat, például az általad létrehozott melléktermékek körül az adatszótár dokumentációját. Nem fogod ezt a definíciót egyidőben kitölteni; fokozatosan fogja folytatni a teljesítményeket, mert előfordulhat, hogy ezeket az információkat kitölti üzleti elemzőkkel együttműködve, amikor a fejlesztők elfoglalták az alkalmazások kiépítését és az adatok tárolása körül fennmaradó kitartást. Meg akarja könnyíteni, és nem lenne a szűk keresztmetszet. Különböző módon működhetünk együtt a fejlesztőkkel. Bizonyos dolgokhoz vannak tervezési minták, tehát teljes körű résztvevők vagyunk az elején, tehát lehet olyan tervezési mintázatunk, ahol azt mondjuk, hogy beillesztjük a modellbe, kinyomtatjuk a fejlesztők homokozó adatbázisaiba, és akkor ők kezdjen vele dolgozni, és kérjen változtatásokat vele.
Lehet, hogy vannak más területek is, amelyek mellett a fejlesztők dolgoznak, kaptak valamit, amelyen dolgoznak, és prototípizálnak néhány dolgot, így kipróbálnak néhány dolgot saját fejlesztési környezetükben. Fogjuk azt az adatbázist, amellyel dolgoztak, bevisszük a modellező eszközünkbe, összehasonlítjuk a meglévő modellekkel, majd megoldjuk és visszatelepítjük a változásokat rájuk, hogy újra tudják alakítani a kódjukat, hogy kövessék a megfelelő adatszerkezetet amire szükségünk van. Mivel előfordulhat, hogy olyan dolgokat hoztak létre, amelyek már másutt már megvannak, ezért gondoskodunk arról, hogy a megfelelő adatforrásokkal működjenek. Csak folyamatosan iterálunk mindaddig, amíg a saját adatainkhoz nem kapunk teljes adatszolgáltatást, teljes dokumentációt és az általunk előállított összes adatszerkezet meghatározását.
A legsikeresebb agilis projektek, amelyekben részt vettem a nagyon jó szállítások terén, az volt, hogy filozófiánk volt, hogy a teljes fizikai adatbázis specifikációban bekövetkezett változásokat modellezzük. Lényegében az adatmodell olyan telepített adatbázisokká válik, amelyekkel dolgozik valami újonnan, amit létrehozunk, és teljes referenciákkal rendelkezik a többi adattárolóról, ha más külső adatbázisokból fogyasztunk. Ennek részeként inkrementális szkripteket állítunk elő, szemben a teljes generáció minden alkalommal történő elkészítésével. És a tervezési mintáinkat használjuk annak érdekében, hogy ezt a gyors javulást biztosítsuk számunkra annak érdekében, hogy a dolgok a különféle fejlesztési csapatokkal együtt működjenek együtt.
A tevékenységekben is az összehasonlítás / egyesítés alapja, tehát vegyük át az ötlet az egyes változások modellezésének ötletét. Minden alkalommal, amikor egy változtatást végrehajtunk, azt akarjuk modellezni, és ami nagyon fontos, mi hiányzott az adatmodellezésből a közelmúltban, sőt, amíg vissza nem vezetjük azt, az a képesség, hogy a modellezést összekapcsoljuk. feladatok és a felhasználói történetekkel és azokkal a teljesítménnyel kapcsolatos információk, amelyek valóban okozzák ezeket a változásokat. Szeretnénk ellenőrizni a modellváltozásainkat, ugyanúgy, ahogy a fejlesztők ellenőrzik a kódokat, hivatkozva a már meglévő felhasználói történetekre, így tudjuk, hogy miért végeztünk először változtatásokat, ezt csináljuk. Amikor ezt megtesszük, előállítjuk az inkrementális DDL szkripteket, és elküldjük őket, hogy azokat felvehessük a többi fejlesztési teljesítménnyel, és ellenőrizhessük beépítési megoldásunkba. Ismét előfordulhat, hogy van egy modellünk, vagy több csapattal dolgozhatunk. És mint amiről már beszéltem, néhány dolgot az adatmodellező kezdeményez, másokat a fejlesztők származnak, és a közepén találkozunk, hogy kidolgozzuk az átfogó legjobb dizájnt, előre toljuk és ellenőrizzük, hogy megfelelően megtervezzük-e általános adatszerkezetek. Fenn kell tartanunk annak felelõsségét, hogy biztosítsuk az adatmodellünkben a megfelelõ konstrukciók továbblépését, ideértve olyanokat is, mint null és nem null értékek, referenciakorlátozások, alapvetõen ellenõrzési korlátozások, mindazok a dolgok, amelyekre tipikusan gondolkodnánk .
Beszéljünk most néhány képernyőképről néhány olyan eszközről, amelyek segítenek bennünket. Fontosnak tartom az együttműködő adattár meglétét, tehát adatmodellezőkként - és ez egy háttérkép egy részlet az adatmodell egy részéről - megtörténhetünk, amikor olyan dolgokon dolgozunk, amelyeket meg akarunk győződni arról, hogy csak azokon az objektumokon dolgozhat, amelyeket meg kell változtatnunk, elvégezzük a módosításokat, generáljuk a DDL szkripteinket a változtatásokhoz, amelyeket a dolgok visszatelepítésekor végeztünk el. Tehát amit tehetünk, az ER Studio példája, kijelenthetjük azokat a tárgyakat vagy tárgycsoportokat, amelyeken dolgozunk, nem kell teljes modellt vagy almodellt kiolvasnunk, csak azokat a dolgokat nézhetjük meg, amelyek érdeklik számunkra. Azt akarjuk, hogy ez utáni kijelentkezéskor vagy bejelentkezéskor legyen - mindkét irányban csináljuk, mert a különböző fejlesztői csoportok különböző módon működnek. Biztosítani akarjuk, hogy ezt hozzákapcsoljuk a felhasználói történethez vagy feladathoz, amely az erre vonatkozó követelményeket támasztja alá, és ugyanaz lesz a felhasználói történet vagy feladat, amelyet a fejlesztők fejlesztenek ki, és ellenőriznek kódot.
Tehát itt van egy nagyon gyors részlet az egyik változáskezelő központ néhány képernyőjéről. Mi ez, nem megyek itt részletesen, de a felhasználói történetet vagy feladatot látod, és mindegyik alá behúzva azokat, amelyeket látsz a tényleges változásrekordokon - létrehoztunk egy automatizált változási rekordot, amikor elvégezzük a be- és kijelentkezésünket, és részletesebb leírást adhatunk erre a változási rekordra is. Ez a feladathoz van társítva, feladatonként több változtatást is végrehajthatunk, amire számíthat. És amikor belemegyünk a változás rekordjába, megnézhetjük, és ami még fontosabb, láthatjuk, hogy mi valójában megváltozott? Ehhez a kiemelt történethez egyfajta változás történt, és amikor maga a tényleges változási rekordot vizsgáltam, azonosította a megváltozott modell egyes részeit. Itt megváltoztattam egy pár attribútumot, újraszekvenáltam őket, és ez az útra hozta azokat a nézeteket, amelyeket meg kellett változtatni, amelyek attól is függtek, hogy azok létrejöjjenek az inkrementális DLL-ben. Nemcsak az alapobjektumokon történő modellezés, hanem egy ilyen nagy teljesítményű modellező eszköz is észleli azokat a változásokat, amelyeket az adatbázisban vagy az adatmodellben lévő függő objektumokon keresztül kell áthidalni.
Ha fejlesztőkkel dolgozunk, és néhány különféle dolgot csinálunk, akkor csinálunk valamit a homokozóban, és összehasonlítani és látni akarjuk, hol vannak a különbségek, összehasonlítási / egyesítési képességeket használunk, ahol a jobb és a bal oldalon oldal. Azt mondhatjuk: „Itt van a modellünk a bal oldalon, itt az adatbázisuk a jobb oldalon, mutasd meg a különbségeket.” Ezután kiválaszthatjuk, hogy hogyan oldjuk meg ezeket a különbségeket, akár beküldjük a dolgokat az adatbázisba, akár vannak olyan dolgok az adatbázisban, amelyeket visszahozunk a modellbe. Kétirányúak lehetünk, így mindkét irányba mehetünk, egyszerre frissítve mind a forrást, mind a célt, majd előállíthatjuk a növekményes DDL szkripteket, hogy telepítsük ezeket a változásokat maga az adatbázis-környezetbe, ami rendkívül fontos. Azt is megtehetjük, hogy ezt az összehasonlítási és egyesítési képességet bármikor felhasználhatjuk is. Ha pillanatfelvételeket készítünk útközben, mindig összehasonlíthatjuk az egyik kezdetét a másik kezdetéhez vagy végéhez, így láthatjuk annak teljes inkrementális változása, amit egy adott fejlesztési s során vagy egy ss sorozaton keresztül végeztek.
Ez egy nagyon gyors példa egy megváltozott szkriptre, bárki, aki adatbázisokkal dolgozik, látta ezt a fajta dolgot, ezt változtathatjuk meg a kódból, mint egy megváltozott szkriptet, így biztosítva, hogy itt tartsd meg a dolgokat. Amit elhúztam innen, csak a rendetlenség csökkentése érdekében, azt is megtesszük ezekkel az alter szkriptekkel, ha feltételezzük, hogy ezekben a táblákban is vannak adatok, tehát létrehozunk egy DML-t is, amely az ideiglenes táblák és helyezze vissza az új adatszerkezetekbe is, így nemcsak a struktúrákra nézünk, hanem azokra az adatokra is, amelyeket már tartalmazhattunk ezekben a struktúrákban.
Nagyon gyorsan beszélünk az automatizált építkezési rendszerekről, mert amikor agilis projektet hajtunk végre, automatizált építkezési rendszerekkel dolgozunk, ahol együtt kell ellenőriznünk a különféle teljesítményeket, hogy megbizonyosodjunk arról, hogy nem törjük el a konstrukcióinkat. Ez azt jelenti, hogy szinkronizáljuk a teljesítendő eszközöket, azokat a változási szkripteket, amelyekről a DDL szkripttel beszélték, be kell jelentkezni, a megfelelő alkalmazáskódot ugyanakkor be kell jelentkezni, és sok fejlesztő jelenleg természetesen nem közvetlenül az SQL-rel az adatbázisok és az ilyen típusú dolgok ellen. Nagyon gyakran perzisztencia-keretrendszereket vagy épületadat-szolgáltatásokat használunk. Gondoskodnunk kell arról, hogy ezeknek a kereteknek vagy szolgáltatásoknak a változásai pontosan ugyanabban az időben legyenek bejelentkezve. Egyes szervezetekbe beépülnek az automatizált összeállítási rendszerbe, és ha az összeépítés megszakad, egy agilis módszertan szerint a fedélzeti rögzítést mindenki kezdi építeni, mielőtt továbblépnénk, hogy tudjuk, hogy működő megoldásunk van, mielőtt továbbmennénk. És az egyik projektben, amelyben részt vettem, ezt egy szélsőséges helyzetbe vittük - ha az építkezés megszakadt, amit valójában a környékünk számos számítógépéhez csatoltunk, ahol az üzleti felhasználókkal együtt dolgoztunk, akkor csak piros villogó fények voltak mint a rendőrautók teteje. És ha az építkezés megszakadt, akkor azok a piros villogó fények kialudtak, és tudtuk, hogy mind a fedélzeten van: javítsuk meg az építést, és folytassuk azzal, amit csináltunk.
Más dolgokról szeretnék beszélni, és ez az ER Studio egyedülálló képessége, ez igazán segít, amikor ezeket a tárgyakat fejlesztőként próbáljuk építeni ezekre a perzisztenciahatárokra, van egy üzleti adat objektumoknak nevezett koncepció, és ami lehetővé teszi számunkra, hogy ha ezt a nagyon egyszerűsített adatmodellt példaként nézi, akkor ez lehetővé teszi számunkra az entitások vagy entitáscsoportok beágyazását arra a helyre, ahol a perzisztencia határok vannak. Ahol adatmodellezőként gondolhatunk valami hasonlóra, mint például a megrendelés fejlécére, a megrendelés igazítására és más részletes táblázatokra, amelyek ehhez hozzákapcsolódnának a felépítéshez, és az adatszolgáltatók fejlesztőinek tudnia kell, hogy a dolgok miként állnak fenn ezeknek a különböző adatoknak szerkezetek. Fejlesztőink olyan dolgokra gondolnak, mint a megrendelés, mint objektum, és mi a szerződésük azzal, hogyan készítik ezeket az objektumokat. Kihúzhatjuk azt a technikai részletet, hogy az adatkiszolgálókat építő emberek láthassák, mi az alatt van, és meg tudjuk védeni a többi közönséget a komplexitásoktól, hogy csak látják a különböző magasabb szintű objektumokat, ami szintén nagyon jól működik az üzleti vállalkozásokkal való kommunikációban. elemzők és üzleti szereplők, amikor a különböző üzleti koncepciók kölcsönhatásáról is beszélünk.
A jó dolog az is, hogy ezeket konstruktív módon kibővítjük és összecsukjuk, hogy fenn tudjuk tartani a kapcsolatokat a magasabb rendű objektumok között, még akkor is, ha azok olyan konstrukciókon alapulnak, amelyek magukban az üzleti adatobjektumokban találhatók. Most mint modellező, érje el az évek végét, az összefoglalás végén van egy csomó tennivaló, amit meg kell tennem, amit a következő házirendnek nevezem. Minden egyes alkalommal, amikor elnevezem a Nevezett Kiadást, elkészítem a kiindulási alapot ahhoz, amit most kaptam a kiadás végén. Tehát ez azt jelenti, hogy továbbléptem a kiindulási alapon, és ezeket az alapvonalakat vagy elnevezett kiadásokat, amelyeket elkészítek és tároltam a tárolóban, összehasonlításra / egyesítésre használhatom, így bármikor összehasonlíthatom az összes többi végpontot, nagyon fontos tudni, hogy az adatmodelljében milyen változások történtek az útja során.
Készítek egy delta DDL szkriptet is, az ismételt összehasonlítás / egyesítés használatával, s kezdetétől végéig. Lehet, hogy egy egész köteg növekményes szkriptet ellenőriztem, de ha szükségem van rá, most van egy szkript, amelyet telepíthetek más homokozó dobozok felállításához, így csak azt mondhatom, hogy ez volt a kezdet elején, nyomja végig, épít egy adatbázist, mint egy homokozó, a következő lépésekkel kezdve, és ezeket a dolgokat felhasználhatjuk például a standup QA példányok elvégzésére is, és végül természetesen azt akarjuk, hogy változtatásainkat előállítsuk a termelésbe, így több dolgunk is zajlik ugyanabban az időben. Ismét teljes mértékben részt veszünk a tervezésben és a retrospektívákban, a retrospektívák valóban a megtanultak, és ez rendkívül fontos, mivel az agilis időszakban nagyon gyorsan elindulhat, meg kell állnia és meg kell ünnepelnie a sikereket, mint most. Kitalálja ki, mi a baj, tegye jobbá a következő alkalommal, de ünnepelje meg azokat a dolgokat is, amelyek helyesen mentek, és építjen rájuk, miközben tovább haladsz a következő ss előrehaladtával.
Most nagyon gyorsan beszélek az üzleti értékről. Volt egy olyan projekt, amelybe sok évvel ezelőtt bekapcsolódtam, és amely agilis projektként indult, és ez egy szélsőséges projekt, tehát egy tiszta önszerveződő csapat volt, ahol csak a fejlesztők tettek mindent. Röviden összefoglalva, ez a projekt megállt, és azt tapasztalták, hogy egyre többször költenek a feltárt hibák kijavítására és kijavítására, mint a több funkcionalitás előmozdítására, sőt, amikor a projektre alapozva is megnézték őket. A leégett táblázatok szerint hatalmas költségekkel kellett volna meghosszabbítaniuk a projektet hat hónappal. És amikor megnéztük, a probléma orvoslásának módja az volt, hogy megfelelő adatmodellező eszközt használunk, és maga a projekt részt vesz képzett adatmodellezőn.
Ha megnézi az adott diagram ezen függőleges sávját, akkor kumulatív hibákat mutat, szemben a kumulatív objektumokkal, és olyan adatobjektumokról vagy konstrukciókról beszélek, amelyeket létrehoztak, például a megszorításokkal ellátott táblákra és az ilyen típusú dolgokra, ha megnézték az adatmodellező bevezetése előtt a hibák száma ténylegesen meghaladta a kezdeti objektumok számát, és azóta egy kis hézagot kezdett építeni ahhoz az időpontig. A 21. hét után, azaz amikor az adatmodellező belépett, újból feljavította az adatmodellt, annak alapján, hogy mit kell megjavítani, és aztán a projektcsoport részeként elkezdett modellezni, haladva, a projekt előrehaladtával történt változások . És látta egy nagyon gyors fordulatot, hogy körülbelül másfél perc alatt óriási megnövekedést tapasztaltunk a generált és épített objektumok és adatkonstrukciók számában, mert az adatmodellező eszközből állítottuk elő, nem pedig egy fejlesztői bot épületét. környezetükben voltak, és helyesek voltak, mert megfelelő referencia-integritással rendelkeztek, és a többi konstrukciónak is rendelkeznie kellett. A hibák szintje a szinte síkban lévőkkel szemben. A megfelelő intézkedés meghozatalával és az adatmodellezés teljes körű bevonásával megbizonyosodott arról, hogy a projektet jóval magasabb színvonalú időben hajtották végre, és valójában egyáltalán nem valósult volna meg, ha ezek a lépések nem történtek volna meg. Nagyon sok agilis kudarc van ott, és sok agilis siker is van, ha a megfelelő embereket bekapcsolja a megfelelő szerepekbe. Az agilis, mint operatív tudományág hatalmas támogatója vagyok, de meg kell győződnie arról, hogy a projektcsapatként részt vevő összes megfelelő csoport ismerete van, amikor egy agilis típusú erőfeszítést folytatsz.
Összefoglalva: az adatépítõket és a modelleket be kell vonni minden fejlesztési projektbe; valóban ezek a ragasztók, amelyek mindent együtt tartanak, mert adatmodellezőkként és építészekként megértjük, nemcsak az adott fejlesztési projekt adatkonstrukcióit, hanem azt is, hogy hol vannak az adatok a szervezetben, és honnan tudjuk ezeket az adatokat felhasználni, és hogy fogják használni és hasznosítani az adott alkalmazáson kívül, amelyen dolgozunk. Megértjük a bonyolult adatkapcsolatokat, és rendkívül fontos, hogy tovább tudjunk lépni, és egyúttal kormányzási szempontból is dokumentálni tudjuk a dokumentumot, és megértsük, hogy néz ki az Ön teljes adatállománya.
Olyan, mint a gyártás; A gyártási háttérből származtam. A végén nem ellenőrizheti a minőséget valami formában - a minőséget be kell építenie a tervezésbe előre és végig, és az adatmodellezés egy olyan módszer, amellyel a minőséget a formatervezésbe hatékonyan és költséghatékonyan építik be egész végig. . És ismét, emlékezni kell valamitre - és ez nem lehet csalás, hanem az az igazság -, hogy az alkalmazások jönnek és mennek, az adatok létfontosságú vállalati javak, és meghaladják az összes alkalmazási határt. Minden alkalommal, amikor valamelyik alkalmazást beilleszti, valószínűleg felkérést kap arra, hogy tárolja az adatokat a korábban megjelenő más alkalmazásoktól, ezért csak emlékeznünk kell arra, hogy ez egy létfontosságú vállalati eszköz, amelyet idővel fenntartunk.
És ez az! Innentől további kérdéseket teszünk fel.
Eric Kavanagh: Rendben, jó, hadd dobjam át először Robinnak. És akkor, Dez, biztos vagyok benne, hogy van néhány kérdése. Vedd el, Robin.
Dr. Robin Bloor: Oké. Hogy őszinte legyek, még soha nem volt problémám az agilis fejlesztési módszerekkel, és számomra úgy tűnik, hogy az, amit itt csinálsz, rendkívül értelmes. Emlékszem, hogy valamit néztem az 1980-as években, amely valóban azt jelezte, hogy az a probléma, amellyel ténylegesen szembesül az ellenőrzés alól kikerülő projekttel kapcsolatban, általában az az, ha hagyja, hogy egy hiba egy adott szakaszon túl is fennálljon. Egyre nehezebb kijavítani, ha nem érted jól ezt a stádiumot, tehát az egyik dolog, amit itt csinálsz - és azt hiszem, ez a csúszda -, de az egyik dolog, amit itt csinálsz n nulla, véleményem szerint feltétlenül fontos, mert tényleg megpróbálsz odaadni a szállítmányokat. És ha nem lesz rögzítve a szállítmányok, akkor a szállítmányok megváltoztatják a formát.
Ez egyfajta véleményem. Ez is a véleményem - valójában nincs érvem azzal a gondolattal, hogy meg kell szereznie az adatmodellezést egy bizonyos részletességgel, mielőtt átmenne. Amit én szeretném, ha megpróbálná tenni, mert nem értettem be teljesen, csak leírja e projektek egyikét méretének szempontjából, azaz annak folyamát illetően, hogy ki tudja, ahol a problémák felbukkantak, megoldódtak? Mivel úgy gondolom, hogy ez a diák alapvetően a szíve, és ha még kicsit részletesebben kidolgozhatná ezt, nagyon hálás lennék.
Ron Huizenga: Persze, és néhány példát is felhasználok. Az egyik, amely egyfajta módon elhaladt a síneken, visszavezette azáltal, hogy ténylegesen bekapcsolta a megfelelő embereket, és elvégezte az adatmodellezést, és minden valóban egyfajta módszer volt annak biztosítására, hogy a formatervezés jobb megértést érjen el, és nyilvánvalóan jobb a megvalósítási terveink. útján modellezés útján. Mert amikor modellezi, tudod, hogy előállíthatja a DDL-jét és mindent az eszköz hátuljából és kihúzásából, ahelyett, hogy ragaszkodnia kellene ehhez, mint az emberek általában megteszik, ha egyenesen egy adatbázis-környezetbe lépnek. És tipikus dolgok, amelyek a fejlesztőkkel történnek, az, hogy bemennek, és azt mondják: oké, szükségem van ezekre a táblákra. Tegyük fel, hogy megrendelési bejegyzéseket készítünk. Így létrehozhatják a rendelés fejlécét és a rendelés részleteit tartalmazó táblázatokat, valamint az ilyen típusú dolgokat. De gyakran elfelejtik vagy elhanyagolják, hogy megbizonyosodjanak arról, hogy vannak-e korlátok a külföldi kulcskapcsolatok ábrázolására. Lehet, hogy nem megfelelőek a kulcsok. Az elnevezési megállapodások szintén gyanúsak lehetnek. Nem tudom, hányszor mentek be egy olyan környezetbe, ahol például egy csomó különböző táblát látsz különböző nevekkel, de akkor az ezekben a táblákban szereplő oszlopnevek olyanok, mint az azonosító, név vagy bármilyen más, tehát Tényleg elveszítettük a vádtáblázatot anélkül, hogy pontosan bemutatnánk a táblázatot.
Tehát általában az adatmodellezés során gondoskodunk arról, hogy a megfelelő elnevezési konvenciókat alkalmazzuk az összes olyan tárgyra, amely a DDL-ben is megjelenik. De hogy pontosabban fogalmazjam meg maguk a projektek jellegét, általában véve meglehetősen nagy kezdeményezésekről beszélek. Az egyik 150 millió dolláros üzleti átalakítási projekt volt, ahol több mint egy tucat régi rendszer helyettesítésére került sor. Öt különböző agilis csapat volt egyidejűleg. Volt egy teljes adat-architektúrával foglalkozó csapatom, tehát a csapatomból modellezőket beépítettem az összes többi alkalmazási terület csoportjába, és a házon belüli üzleti szakértők kombinációjával dolgoztunk, akik ismerik a témát, és felhasználói történetek maguknak a követelményeknek. Mindegyik csoportban volt üzleti elemzőnk, akik ténylegesen modellezték az üzleti folyamatot az aktivitási diagramokkal vagy az üzleti folyamatok diagramjaival, és így elősegítették a felhasználói történetek pontosabb kidolgozását a felhasználókkal, még mielőtt a csapat többi tagja felhasználta őket.
És akkor természetesen azok a fejlesztők, akik az alkalmazáskódot építették föl. És együtt dolgoztunk is, azt hiszem, négy különböző rendszerintegrációs gyártó építette az alkalmazás különféle részeit is, ahol az egyik csapat az adatszolgáltatást építette fel, a másik az alkalmazás logikáját építteti az egyik területen, a másik az, aki rendelkezik szakértelemmel egy másik üzleti területen építette fel az alkalmazás logikáját ezen a területen. Tehát egy teljes együttműködés volt az emberekkel, akik ezen a projekten dolgoztak. Különösen abban volt, hogy 150 ember volt a parton a csapatnál, és további 150 erőforrás volt a csapatban, akik kéthetes együttműködésben dolgoztak ki, hogy kihúzzák ezt a dolgot. És ehhez meg kell győződnie arról, hogy minden hengert tüzel és mindenki jól szinkronizálva van-e a szállítmányuk szempontjából, és ezeket a gyakori visszaállítást elvégezte, hogy megbizonyosodjon arról, hogy befejeztük az összes szükséges termék szállítását. minden s végén.
Dr. Robin Bloor: Nos, ez lenyűgöző. És csak egy kicsit részletesebben - a projekt végén elkészült egy teljes, az én adatlapomat tartalmazó MDM térkép az egész adatterülettel?
Ron Huizenga: Teljes adatmodellünk volt, amelyet a bomlás során lebontottunk az összes üzleti terület között. Maga az adatszótár a teljes definíciók szempontjából kissé elmaradt. A táblák nagy részét meghatároztuk; az oszlopok többségét pontosan meghatározták, hogy mit jelentenek. Vannak olyanok, amelyek nem voltak ott, és érdekes módon, ezek közül sok olyan információ volt, amely a régi rendszerekből származott, ahol a projekt hatályának lejártát követően még mindig dokumentáltak átvitt készletként. tárgyak, amint vannak, magán a projekten kívül, mert ezt valami olyasmit kellett fenntartania, amelyet a jövőbeni szervezet folytat. Tehát ugyanakkor a szervezet sokkal fokozottabb nézetet vett az adatkezelés fontosságáról, mivel sok hiányosságot láttunk azokban a régi rendszerekben és azokban a régi adatforrásokban, amelyeket megpróbáltunk felhasználni, mivel nem dokumentáltak. Sok esetben csak olyan adatbázisunk volt, amelyeket vissza kellett állítanunk, és meg kellett próbálnunk kitalálni, mi van és mi az információ.
Dr. Robin Bloor: Ez nem meglepő, ennek a sajátos aspektusa. Az adatkezelés rendkívül modern aggodalomra ad okot, és azt hiszem, valóban sok munka van, amit mondhatnánk, történelmileg az adatkezelés területén kellett volna elvégezni. Soha nem azért volt, mert valamilyen módon meg is tudta menni, ha nem csinálta. De amint az adatforrás csak növekedett, végül nem tudtad.
Mindenesetre átadom Dez-nek, mert azt hiszem, hogy megvan a rá időm. Dez?
Dez Blanchfield: Igen, köszönöm. Az egész dologon keresztül figyelek és gondolkodom magamnak, hogy arról beszélünk, hogy agilisnak sokféle módon használjuk fel a haragot. Bár ennek negatív konnotációja van; Ezt pozitívan értem. Lehet, hogy megad egy forgatókönyvet, úgy értem, két helyen láthatom, hogy ez egy tökéletes készlet: az egyik olyan új projekt, amelyet csak az első naptól kell elkészíteni, de szerintem mindig, tapasztalataim szerint, gyakran az a helyzet, hogy amikor a projektek elég nagyokká válnak, és ez több szempontból is szükséges, érdekes kihívás van a két világ ragasztása között, igaz? Adhat-e valamilyen betekintést néhány olyan sikertörténetbe, amelyet már látott valamelyik szervezetnél, világossá válik, hogy a két világ enyhe ütközéssel rendelkezik, és sikeresen tudtad ez a helyén van, és összehozza a nagy projekteket, ahol esetleg egyébként mentek volna a sínre? Tudom, hogy ez egy nagyon széles kérdés, de csak azon gondolkodom, hogy van-e egy adott esettanulmány, amelyet valamilyen módon megmutathatsz, hol mondtad, tudod, mindezt a helyére helyeztük, és az összes fejlesztői csapat összehozta az adatcsapat és mi valamilyen módon foglalkoztunk valamival, ami egyébként esetleg elsüllyedt volna a hajón?
Ron Huizenga: Persze, és valójában az egyik olyan projekt, amelyre csővezetékként került sor, utaltam rá, ahol megmutattam a diagramot az adatok modellezője előtti és utáni hiányosságokkal. Gyakran, és vannak előzetes elképzelések, különösen, ha a dolgok úgy fordulnak elő, hogy pusztán fejlesztési szempontból történjenek, az alkalmazásokat csak a fejlesztők vesznek részt az agilis projektekben. Tehát, ami történt, természetesen az, hogy kiszálltak a sínekről, és különösen az adatok műtermékei, vagy az általuk előállított adatszolgáltatások minőségi szempontból elmaradtak a jelektől, és valóban összességükben foglalkoztak a dolgokkal. És gyakran az a tévhit, hogy az adatmodellek lelassítják a projekteket, és akkor is, ha az adatmodellező nem rendelkezik megfelelő hozzáállással. Mint mondom, el kell veszítenie - néha vannak olyan adatmodellezők, akiknek ez a hagyományos kapuvezető hozzáállása van, amikor „itt vagyunk, hogy ellenőrizzük, hogyan néznek ki az adatszerkezetek”, és ennek a mentalitásnak eltűnnie kell. Bárki, aki részt vesz az agilis fejlesztésben, és különösen az adatmodellezők, szerepet vállal, mint segítő, hogy valóban segítse a csapatokat az előrehaladásban. A legjobb módszer annak bemutatására, ha nagyon gyorsan megmutatjuk a csapatoknak, hogy mennyire eredményesek lehetnek, ha először modellezik a változásokat. És ismét, ezért beszéltem az együttműködésről.
Vannak olyan dolgok, amelyeket először modellezhetünk, és előállíthatjuk a DDL-t, hogy továbbadjuk a fejlesztőknek. Azt is szeretnénk biztosítani, hogy ne érezzék magukat korlátozás alatt. Tehát, ha vannak dolgok, amelyekkel dolgoznak, hagyja, hogy tovább dolgozzanak a fejlesztési homokozóikban, mert itt a fejlesztők saját asztalukon vagy más adatbázisokon dolgoznak, hogy változtatásokat végezzenek, amikor tesztelik a dolgokat. És működjön együtt velük és mondja: „Oké, dolgozz vele.” Bevesszük az eszközbe, megoldjuk, majd továbblépjük és megadjuk azokat a szkripteket, amelyeket telepíthet a adatbázisokat, hogy frissítsék őket annak valódi szankcionált valódi termelési nézetére, ahogyan tovább haladunk. És ezt nagyon gyorsan meg lehet fordítani. Azt tapasztaltam, hogy a napjaim tele voltak, amikor csak előre-vissza megyek, és különféle fejlesztési csapatokkal iteráltam, megvizsgáltam a változásokat, összehasonlítottam, generáltam a szkripteket, elindítottam őket, és elég egyszerûen tudtam lépést tartani a négy fejlesztõcsoporttal. lendületet ért el.
Dez Blanchfield: Az egyik dolog, amelyre eszembe jut, az az, hogy tudod, sok olyan beszélgetés, amelyet naponta folytatok, arról szól, hogy ez a tehervonat hozzánk érkezik, egyfajta gép-gép és tárgyak internete. És ha azt gondoljuk, hogy rengeteg adatunk van a jelenlegi vállalkozási környezetünkről, akkor tudod, ha egy pillanatra félretesszük az egyszarvúkat, amikor tudjuk, hogy a Google-nak és az S-nek és az Ubers-nek petatabátái vannak, de egy hagyományos vállalkozásban még mindig több száz terabyte-ról és sok adatról beszélünk. De véleményem szerint ez a tehervonat érkezik a szervezeteknél, és Dr. Robin Bloor már utalt rá az IoT-re. Tudod, nagyon sok a webes forgalom, a szociális forgalom, most már megvan a mobilitás és a mobil eszközök, a felhő máris felrobbanott, de most van intelligens infrastruktúránk, okos városok és ott van az adatok egész világa, amely éppen felrobbant.
Egy hétköznapi szervezethez egy közepes és nagy szervezet, aki ott ül, és látja a fájdalom világát, és rájuk néz, és nem gondolja azonnali tervét, mi az a néhány elhangzó mondat közül néhány, amit mondasz nekik, hogy mikor és hol kell beszélgetniük kell gondolkodni ezen módszertanok bevezetéséről. Mennyire kell kezdeniük azt, hogy szinte felálljanak, figyelmet fordítsanak, és azt mondják, hogy ez a megfelelő idő, hogy valamilyen eszközt beszerezzenek, a csapatot felkészítsék, és beszélgetést folytassanak a szóban forgó kihívás körül? Mennyire késő a történetben, vagy mikor túl korán? Hogyan néz ki ez az egyes látott szervezetek?
Ron Huizenga: Azt mondanám, hogy a legtöbb szervezet számára, ha még nem tették meg, és az adatmodellezést és az architektúrát ilyen hatékony eszközökkel adaptálták, akkor erre tegnap szükségük van. Mivel érdekes, hogy még ma is, amikor a szervezetek adatait nézzük meg, annyi adat van a szervezetünkben, és általánosságban elmondhatjuk, hogy néhány felmérés alapján, amit már látunk, ezen adatok kevesebb, mint öt százalékát használjuk hatékonyan. amikor átnézzük a szervezeteket. És az IoT vagy akár a NoSQL esetében a nagy adatok - még ha nemcsak az IoT, hanem általában csak a nagy adatok - ahol most még több információt kezdünk el fogyasztani, ami a szervezeten kívülről származik, ez a kihívás egyre nagyobb és nagyobb mindig. És egyetlen lehetőségünk van arra, hogy megbirkózzunk azzal, hogy segítsünk megérteni az adatokról.
Tehát a használati eset egy kicsit más. Mi úgy találjuk magunkat, hogy amikor ezeket az adatokat megvizsgáljuk, elfogjuk, vissza kell állítanunk azokat, meg kell vizsgálnunk, mi van azokban, legyen az adatlakkjainkban vagy akár házon belüli adatbázisunkban, és szintetizálják, mi a az adatok, alkalmazzanak jelentéseket és definíciókat rá, hogy megértsük, mi az adat. Mivel amíg meg nem értjük, mi ez, nem tudjuk biztosítani, hogy helyesen vagy megfelelően használjuk-e. Tehát tényleg meg kell tudnunk kezelni, hogy mi az adat.És a másik rész az, hogy ne csináld, mert az összes külső adat felhasználása szempontjából ellenőrizheti, hogy van-e olyan felhasználási esete, amely támogatja a külső adatok felhasználását. Összpontosítson a szükséges dolgokra, ahelyett, hogy megpróbálna húzni és felhasználni azokat a dolgokat, amelyekre később szüksége lehet. Először összpontosítson a fontos dolgokra, és amint végigment rajta, akkor el fog fogyasztani és megpróbálja megérteni a többi információt kívülről.
Erre a tökéletes példa az, hogy tudom, hogy tárgyak interneteről és érzékelőkről beszélünk, de ugyanaz a probléma sok szervezetben évek óta fennáll, még az internet előtt is. Bárki, akinek van termelési vezérlőrendszere, függetlenül attól, hogy egy csővezeték-gyártó cég, gyártó, vagy bármilyen folyamat-alapú cég, amelynek olyan dolgai vannak, ahol sok automatizálást végeznek vezérlőkkel, és adatfolyamokat használnak, és hasonlókat, ezek az adatok tűzcsövei, amelyeket megpróbálnak kiüríteni, hogy kitalálják, milyen események történtek a gyártóberendezéseimben, jelezve - mi történt és mikor? És ezen a hatalmas adatfolyam között csak olyan információk vagy címkék találhatók, amelyek érdekli őket, hogy szétváljanak, szintetizálják, modellezzék és megértsék őket. És figyelmen kívül hagyhatják a többi részét, amíg el nem jön az idő, hogy valóban megértsék, majd kibővíthetik alkalmazási körüket, hogy egyre többet vonjanak hatálya alá, ha ennek értelme van.
Dez Blanchfield: Valóban így van. Van egy kérdés, amelybe bevezem ezt: Eric nevű úriembertől, és magánbeszélgetésről beszéltünk. Csak arra kértem az engedélyét, amelyet megadott, hogy tőlem kérdezzem. Mert ez szépen vezet ehhez, csak azért, hogy becsavarjuk, mert egy kicsit tovább megyünk az idő múlásával, és visszaadom Ericnek. De egy másik Eric kérdése az volt, hogy indokolt-e feltételezni, hogy az induló vállalkozók ismerik és megértik a modellezés terminológiájának egyedi kihívásait, és így kell-e másnak értelmezni? Tehát más szavakkal: egy indítónak képesnek kell lennie és készen kell lennie, és hajlandó-e és képes-e arra összpontosítani, és ennek megvalósulnia? Vagy valószínűleg ki kell vásárolniuk, és be kell vonniuk a szakértőket?
Ron Huizenga: Azt hiszem, a rövid válasz az, hogy valóban függ. Ha ez egy induló vállalkozás, amelynek nincs házon belül olyan adatépítész vagy modellező, aki valóban megérti az adatbázist, akkor a leggyorsabb módszer az induláshoz, ha valaki olyan tanácsadói háttérrel rendelkezik, aki nagyon jól ismeri ezt a helyet, és megszerezheti nekik megy. Mert amit találsz - és valójában nagyon sok olyan elkötelezettséggel tettem, amit tettem, mielőtt átmentem volna a termékmenedzsment sötét oldalára - az lenne, hogy tanácsadóként bemennék a szervezetekbe, vezetnék adat-architektúra csapataimat, hogy valamilyen módon újra összpontosítsák magukat és kiképzzék az embereket arra, hogyan kell csinálni az ilyen típusú dolgokat, hogy fenntartsák és folytatják a missziót. És akkor folytatnék a következő elkötelezettségüket, ha ennek van értelme. Nagyon sok ember csinálja ezt, nagyon jó tapasztalattal rendelkezik az adatokkal, ami elindíthatja őket.
Dez Blanchfield: Ez nagyszerű elfoglalási pont, és teljesen egyetértek vele, és biztos vagyok benne, hogy Dr. Robin Bloor is ezt tenné. Különösen az induláskor arra koncentrál, hogy kkv-ként koncentráljon annak a javaslatnak az adott értékére, amelyet magának az induló vállalkozásának a részében kíván építeni, és valószínűleg nem kell mindenért szakértőnek lennie, ezért nagyszerű tanácsok. De nagyon köszönöm, fantasztikus bemutató. Nagyon jó válaszok és kérdések. Eric, vissza fogom adni Önöket, mert tudom, hogy valószínűleg tíz perc alatt elmentünk, és tudom, hogy szeretsz közel állni az időablakunkhoz.
Eric Kavanagh: Rendben van. Legalább néhány jó kérdésünk van. Hadd dobjak egyet neked. Azt hiszem, válaszoltál a többiekre. De egy nagyon érdekes megfigyelés és kérdés egy résztvevő részéről, aki ír, néha az agilis projekteknél az adatmodellező nem rendelkezik a teljes hosszú távú képpel, így befejezik, hogy megtervezzenek valamit egyben, majd három vagy négy másodpercben kell újratervezniük. Nem tűnik ellentétesnek? Hogyan kerülheti el ezt a fajta dolgot?
Ron Huizenga: Csak az agilis jelleg, hogy nem fog minden rendben lenni egy adott időben. És ez valójában a mozgékonyság szellemének része: dolgozzon vele - prototípust fog végezni, ahol egy adott kódban dolgozik, és finomításokat fog végezni rajta. És ennek a folyamatnak az a része, hogy a dolgok átadásakor a végfelhasználó látja, és azt mondja: „Igen, ez nagyon közel van, de valóban szükségem van rá, hogy ezt kicsit extra is megtegyem.” Annak érdekében, hogy ne csak a funkcionális kialakítás legyen hatással, magát a kódot, de elég gyakran módosítanunk vagy hozzáadnunk kell az adatszerkezetet ezen bizonyos dolgok alá, hogy a felhasználói igényeket elérjük. És ez minden tisztességes játék, és ezért valóban használni szeretné a nagy teljesítményű eszközöket, mert nagyon gyorsan modellezheti és elvégezheti ezt a változást egy modellező eszközben, majd létrehozhatja a DDL-t az adatbázishoz, amelyet a fejlesztők ekkor dolgozhatnak annak érdekében, hogy még gyorsabban változnak. Megmenti őket attól, hogy az adatszerkezeteknek a kézikódoláshoz hasonlóan elvégezzék, és hagyja, hogy a legjobban jártas programozási vagy alkalmazási logikára összpontosítsanak.
Eric Kavanagh: Ennek teljesen értelme van. Volt néhány másik ember, akik csak konkrét kérdéseket tettek fel azzal kapcsolatban, hogy hogyan kapcsolódik ez az eszközhöz. Tudom, hogy egy ideje átélte a példákat, és képernyőképeket mutatott arról, hogyan valósítja meg ezeket a dolgokat. Az egész folyamat szempontjából milyen gyakran látja a szervezetekben játszott játékot, szemben azzal, hogy milyen gyakran lát olyan tradicionális folyamatokat, ahol a dolgok egyszerűen, valamiféle módon elmozdulnak és több időt vesznek igénybe? Mennyire prevalens az s-stílusú megközelítés?
Ron Huizenga: Azt hiszem, egyre inkább látjuk. Tudom, hogy azt mondanám, valószínűleg különösen az elmúlt 15 évben, sokkal többet láttam olyan emberek elfogadásában, amelyek felismerték, hogy valóban át kell venniük a gyorsabb szállítást. Tehát láttam, hogy egyre több szervezet lép fel az agilis szalagkocsira. Nem feltétlenül teljes egészében; Lehet, hogy elindítanak egy pár kísérleti projektet annak bizonyítására, hogy működik, de vannak olyan projektek, amelyek még mindig nagyon hagyományosak, és betartják a vízesés módszerét. A jó hír természetesen az, hogy az eszközök nagyon jól működnek ezekben a szervezetekben is az ilyen típusú módszertanokhoz, de megvan az az alkalmazkodóképesség, hogy azok, akik hajóznak a fedélzeten, rendelkezzenek az eszközökkel az eszközkészletben ujjhegyeik. Ilyenek például az összehasonlítás és az egyesítés, például a fordított tervezés képességei, így láthatják, hogy mi a meglévő adatforrás, így valóban összehasonlíthatják és előállíthatják a növekményes DDL szkripteket. És amint elkezdenek ezt átfogni, és látják, hogy megvan a termelékenység, akkor még inkább növekszik az agilis átfogási hajlandósága.
Eric Kavanagh: Nos, ez nagyszerű cucc, emberek. Csak feltettem egy linket a diákra a csevegőablakban, tehát nézd meg; ez egy kicsit kicsit benned az Ön számára. Megtaláljuk ezeket a webes adásokat későbbi megtekintésre. Nyugodtan ossza meg őket barátaival és kollégáival. És Ron, köszönöm szépen a mai idejét, mindig örülök, hogy részt vehetsz a show-ban - igazi szakember a területen, és nyilvánvaló, hogy ismered a cuccodat. Tehát, köszönöm, és köszönet az IDERA-nak, és természetesen Deznek és a mi saját Robin Bloor-nak.
És ezzel búcsút fogunk adni neked, emberek. Köszönöm újra időt és figyelmet. Nagyra értékeljük, hogy 75 percig ragaszkodsz, ez egy nagyon jó jel. Jó show srácok, legközelebb beszélünk veled. Viszlát.