Hämtmat: Värd Eric Kavanagh diskuterar vikten av datamodellering i smidig utveckling med Robin Bloor, Dez Blanchfield och IDERAs Ron Huizenga.
Du är för närvarande inte inloggad. Logga in eller registrera dig för att se videon.
Eric Kavanagh: Okej, mina damer och herrar. Välkommen tillbaka igen. Det är onsdag klockan 4:00 EST. Det betyder att det är dags för Hot Technologies. Ja verkligen. Jag heter Eric Kavanagh, jag kommer att vara din värd.
För dagens ämne är det en oldie men en goodie. Det blir bättre varje dag eftersom det formar vår datahanteringsvärld, "Datamodellering i en smidig miljö." Det finns en bild om din verkligen, slog mig upp på @eric_kavanagh. Vi borde verkligen sätta den på den bilden. Jag måste komma på det.
Så åren varma. Datamodellering har funnits för alltid. Det har verkligen varit hjärtat och själen i informationshanteringsverksamheten, utformat datamodeller, försökt förstå affärsmodeller och anpassa dem till dina datamodeller. Det är verkligen vad du försöker göra, eller hur?
Datamodell representerar verksamheten på ett grundläggande sätt, så hur förändrar alla dessa nya datakällor spelet? Vi skulle ta reda på det. Skulle ta reda på hur du kan hålla dig uppe på saker på ett smidigt sätt. Och naturligtvis är det årets ord.
Robin Bloors med oss, vår chefanalytiker, Dez Blanchfield som kallar in från Sydney, Australien och Ron Huizenga, Senior Product Manager från IDERA - min vän, utmärkt talare i det här utrymmet, känner till hans grejer, så var inte blyg, fråga honom svåra frågor, folk, de svåra. Med det kommer jag att göra Robin till presentatören och ta bort den.
Dr. Robin Bloor: Okej. Tack för det, Eric. Jag måste säga om modellering som jag tror, jag var faktiskt i en värld av IT innan den fanns, i den meningen att jag minns i det försäkringsbolag som jag arbetade för, att vi fick en kille att komma in och ge oss alla ett slags av workshop om hur man modellerar data. Så tittade på cirka 30 år, är det 30 år? Kanske till och med längre än så, kanske för 35 år sedan. En lång, lång tidmodellering har faktiskt varit en del av branschen och har naturligtvis ingenting att göra med damer på catwalks.
Det jag ville säga, för vad vi normalt gör är att jag och Dez pratar om olika saker och jag tänkte bara att Id ger den allmänna översikten till modellering, men det finns en verklighet till detta, det blir nu uppenbart.
Vi har, du vet, big data-verkligheten, vi har mer data, fler datakällor, vi har dataströmmar som har gått in i ekvationen under de senaste tre eller fyra åren och börjar få en större del av det, och det är ett större behov av att förstå data och en ökning av förändringsgraden som är mer data som läggs till och också fler datastrukturer som används.
Det är en svår värld. Här är en bild av det, som faktiskt är något vi ritade för cirka tre år sedan, men i grund och botten, när du inkluderar strömmande in i mixen och du får den här idén om dataraffinaderi, datahub, datalänk eller vad som helst, ser du att det finns data som är verkligen i vila, i den meningen att det inte rör sig mycket. Och sedan finns data, strömmarna och du har alla transaktionsapplikationer, plus nuförtiden har du händelser, händelsedataflöden som händer i applikationer och kan behöva, och nuförtiden med lambda-arkitekturerna som alla talar om, har verkligen påverkan på bara hela datafältet.
Och nuförtiden tror att det finns ett dataskikt. Dataskiktet finns på ett slags virtuellt sätt, i den meningen att en bra bit av det kan vara i molnet och det kan spridas över datacentra, det kan existera på arbetsstationer. Dataskiktet är till viss del överallt och i den meningen finns det processer överallt som försöker på ett eller annat sätt bearbeta uppgifterna och flytta informationen om. Men att veta vad det är när du flyttar det är en stor sak.
Om vi tittar på datamodellering i den mest allmänna meningen, har du filer och databaser längst ner i denna typ av stack. Du har dataelement, som har nycklar, elementdefinitioner, alias, synonymer, specifika fysiska format och sedan har vi detta metadataskikt.
Det intressanta med metadata är att metadata helt och hållet är hur data får sin mening. Om du faktiskt inte har metadata, kan du i bästa fall gissa betydelsen av uppgifterna, men du kommer att ha väldigt många svårigheter. Metadata måste vara där, men betydelsen har struktur. Jag vill inte gå in i filosofin om meningen, men även i det sätt vi hanterar data finns det en hel del sofistikering i mänsklig tanke och mänskligt språk, som inte lätt uttrycker sig i data. Men även när det gäller de uppgifter som vi faktiskt bearbetar i världen har metadata betydelse och strukturen för metadata - en bit data i förhållande till en annan och vad det betyder när de är sammansatta och vad det betyder när de har gått med andra data kräver att vi modellerar dem. Det är inte tillräckligt bra för att bara spela in metadatataggar på saker, du måste faktiskt registrera betydelse per strukturer och förhållandet mellan strukturerna.
Sedan har vi i det översta lagret, affärsdefinitionerna, som normalt är ett lager som försöker överföra mening mellan metadata, som är en form av datadefinition som passar det sätt som data är organiserade på datorn och människans betydelse. Så du har affärsuttryck, definitioner, relationer, begrepp på enhetlig nivå som finns i det lagret. Och om vi skulle ha en inkonsekvens mellan dessa lager, måste vi ha datamodellering. Det är inte riktigt valfritt. Ju mer du faktiskt kan göra det när det gäller att automatisera det, desto bättre. Men eftersom det har med mening att göra, är det verkligen svårt att växla. Det är tillräckligt lätt att fånga metadata i en post och kunna hämta det från en serie betydelser, men det säger inte strukturen för postarna eller vad posten betyder eller nackdelar med posten.
Så det är vad datamodellering, enligt min mening, handlar om. Pekar att notera: ju mer komplex dataan universum blir, desto mer behöver du modellera det. Med andra ord, det var lite som att lägga till inte bara fler instanser av saker till världen, som skulle motsvara dataregister, men faktiskt lägger till mer mening till världen genom att fånga data om fler och fler saker. Det blir en mer och mer komplex känsla som vi måste förstå.
I teorin finns ett dataunivers och vi behöver en syn på det. I praktiken är den faktiska metadata en del av datauniverset. Så det är inte en enkel situation. Början av modellering är top-down och bottom-up. Du måste bygga i båda riktningarna och orsaken till det är att data har betydelse för datorn och processen, som måste bearbeta det, men det har mening i sin egen rätt. Så du behöver en bottom-up-betydelse, som tillfredsställer programvaran som behöver åtkomst till informationen och du behöver uppifrån och ner-betydelsen så att människor kan förstå det. Byggandet av metadatamodeller är inte och kan aldrig vara ett projekt; det är en pågående verksamhet - bör vara en pågående aktivitet i alla miljöer de existerar. Lyckligtvis finns det en hel del miljöer, där det faktiskt inte är fallet och saker spinner ur kontroll därefter.
Framöver ökar modelleringen med betydelse när tekniken går framåt. Det är min åsikt. Men om du tittar på IoT kan vi förstå mobilen mer än vi brukade, även om det infördes nya dimensioner: dimensionen av plats med mobil. När du väl kommit till IoT tittade vi på extraordinära dataproblem som vi faktiskt aldrig var tvungna att göra förut och vi måste på ett eller annat sätt förstå exakt vad vi har fått, exakt hur vi kan aggregera det, vad vi kan göra när det gäller att få mening från aggregering och naturligtvis vad vi kan göra med det när vi har bearbetat det.
Jag tror att jag har sagt nog. Jag ska vidarebefordra till Dez Blanchfield och säga något helt annat.
Dez Blanchfield: Tack. Alltid en tuff handling att följa, men detta är ett ämne som vi enades om och pratade om detta kort i preshowbanter, och om du ringde in tidigt, skulle du antagligen fånga en hel massa fantastiska ädelstenar. En av takeaways, och jag vill inte stjäla åskan från just den här, men en av takeaways från vår preshowbanter som jag vill dela, om du inte fångade det, var precis kring ämnet för dataintressen , och det slog mig att faktiskt skriva ner det genom att tänka på resan som uppgifterna tar i en annorlunda situation kring generationens livslängd - år, månader, vecka, dag, timme, minut, sekund - och nackdelarna kring data är placerade inom det . Oavsett om jag är en utvecklare som kör kod, eller om jag är en dataspecialist och jag tänker på strukturen och formatet och metadata runt var och en av elementen, eller hur systemen och företaget interagerar med det.
Det är en intressant liten takeaway bara för att notera, men ändå, låt mig dyka in. Datadesign, i synnerhet, är en fras som jag använder för att prata om allt saker och specifikt utveckling av antingen applikationer eller databasinfrastruktur. Jag tror att datadesign är en term som bara fångar allt mycket bra i mitt sinne. I dessa dagar när vi pratar om datadesign talar vi om modern agil datadesign, och min uppfattning är att det inte var så länge sedan att utvecklare och dataexperter arbetade ensamma; de var i sina egna silon och designstycken gick från en silo till en annan. Men jag är väldigt mycket av åsikten i dag, att det inte bara är fallet som har förändrats, utan det måste ändras; det är en typ av nödvändighet och det är den applikationen - utvecklare och allt att göra kring utveckling som handlar om data, designarna som gör relevanta designelement i scheman och fält och poster och plats- och databassystem och infrastrukturer, modellering och hela hanteringen utmaning kring det. Det är en lagsport nu och därmed min bild av ett gäng människor som hoppar ut från ett flygplan som fungerar som ett lag för att spela ut den visuellt intressanta bilden av människor som faller genom himlen.
För det tredje, vad har hänt för att åstadkomma detta? Tja, det finns en artikel 1986 skriven av ett par herrar vars namn jag försökte desperat göra rättvisa mot, Hirotaka Takeuchi och Ikujiro Nonaka, jag tror det är uttalat, producerade en artikel som de betitlade ”Moving the Scrum Downfield.” De introducerade den här idén om en metod för att vinna en omgång rugby som kommer från denna scrumaktivitet, där alla tar sig runt på ett ställe och två lag väsentligen låser huvuden i något som kallas en scrum för att försöka få kontroll över bollen och spela den på fältet för att komma till provlinjen och röra marken med bollen och få en poäng, kallad en trine, och du upprepar denna process och du får fler poäng för laget.
Denna artikel publicerades 1986 i Harvard Business Review, och märkligt fick den faktiskt mycket uppmärksamhet. Det fick mycket uppmärksamhet eftersom det introducerade fantastiska nya koncept och här är en skärmdump av framsidan. Så de tog detta koncept av scrum ur spelrugby och de förde det till affärer och särskilt i spelet design och projektleverans, särskilt projektleverans.
Vad scrum gjorde gav oss en ny metodik jämfört med PRINCE2 eller PMBOK som vi tidigare använde i vad vi kallade vattenfallsmetoden, du vet, gör den här och den här saken och den här saken och följ dem i följd och anslut alla prickar runt, vilket beror på vad du hade, eller gör inte del två förrän du har gjort del ett eftersom det beror på del ett. Vad det gav oss är en ny metodik för att vara lite smidigare, det är där termen kommer från, om hur vi levererar saker, och specifikt kring design och utveckling av gräsrotsprojektleverans.
Några av de viktigaste hyresgästerna - bara så att jag går vidare med detta - är runt de viktigaste hyresgästerna på scrum.Det introducerade idén om att bygga instabilitet, att om man tänker på rädslan för kaos, finns världen i ett kaosläge, men planeten bildades, vilket är intressant, så att bygga instabilitet, förmågan att studsa runt lite och fortfarande få saker att fungera, självorganiserande projektgrupper, överlappande gynnar genom mycket ansvarsfull utveckling, olika typer av lärande och kontroll genom resan till projektleveransen, organisatorisk överföring av lärande. Så hur tar vi information från en del av verksamheten och överför den till en annan från personer som har en idé men inte utvecklar kod eller inte utvecklar databaser och infrastrukturer, men data till dessa människor? Och speciellt tidsboxade resultat. Med andra ord, låt oss göra detta under en tid, antingen en dag som om 24 timmar, eller en vecka eller ett par veckor och se vad vi kan göra och sedan gå tillbaka och titta på det.
Och så, om du förlåter ordspillet, är detta verkligen ett nytt spel i projektleverans och de tre kärnkomponenterna till det som kommer att vara vettigt när vi kommer lite längre här - det finns produkten: alla dessa människor har idén och har ett behov av att göra något och historien som omger dem. Utvecklare som arbetar i den smidiga modellen att få sina berättelser och genom dagliga standups med scrummetodiken för att diskutera det och förstå vad de behöver göra, och sedan bara gå vidare och göra det. Då människor, vi har hört talas om skrummästare som övervakar hela saken och förstår metodiken tillräckligt för att driva den. Vi har alla sett dessa bilder som jag fick på höger sida här av väggar och whiteboards full av Post-It-anteckningar och de tjänade som Kanban-väggar. Om du inte vet vem Kanban är, inbjuder jag dig till Google vem Mr. Kanban var och varför det var en förändring i hur vi flyttar saker från ena sidan till den andra i en vägg bokstavligen men i ett projekt.
På ett ögonblick gör scrum-arbetsflödet detta: det tar en lista över saker som en organisation vill göra, köra dem genom en serie saker vi kallar ss som är uppdelade i 24-timmarsperioder, månadslånga perioder och vi få denna inkrementella serie output. Det är en betydande förändring av hur projekt levereras, levererades upp till det stadiet eftersom en del av det flyter som den amerikanska armén som hade en stor del av att utveckla något som kallas PMBOK, som idén som inte tar tanken in i fältet tills du sätter kulor i saken för om en tank i fältet inte har kulor, är det värdelös. Så därför del 1 läggs kulor i tanken, del två läggs tanken i fältet. Tyvärr fick det som hände med utvecklare i utvecklingsvärlden på något sätt grepp om denna smidiga metodik och sprang med den platt, om du förlåter ordspillet, på ett sätt.
Ofta är det som hände när vi tänker på smidiga vi vanligtvis tänker på utvecklare och inte databaser och något att göra med databasvärlden. Det var ett olyckligt resultat eftersom verkligheten är att smidig inte är begränsad till utvecklare. I själva verket är begreppet smidig enligt min åsikt ofta felaktigt associerad med mjukvaruutvecklare och inte databasdesignare och arkitekter. Allmänt står samma utmaningar som du står inför i program- och applikationsutveckling i allt att göra med design och utveckling och drift och underhåll och därför av datainfrastruktur och särskilt databaser. Skådespelarna i detta specifika datautbud inkluderar sådana som arkitekter, formare, administratörer, förvaltare av databasinfrastrukturen och själva databaserna hela vägen till affärs- och systemanalytiker och arkitekter, människor som sitter och tänker på hur systemen och affärsverksamhet och hur vi har fått flöda data genom dessa.
Det är ett ämne som jag regelbundet tar upp eftersom det är en ständig frustration för mig i och med att jag är mycket av den uppfattningen att dataspecialister måste - inte borde - nu måste vara intimt involverade i varje del av projektleverans, verkligen, särskilt utveckling. För att vi inte ska göra det, ger vi oss inte den bästa chansen för ett bra resultat. Vi måste ofta slå tillbaka och tänka igenom dessa saker eftersom det finns ett scenario, vi kommer till en applikation som byggs och vi upptäcker att utvecklarna inte alltid är dataexperter. Att arbeta med databaser kräver mycket specialiserade färdigheter, särskilt kring data, och bygger en upplevelse. Du blir inte bara en databasguru eller expert på datakunskaper över en natt; detta är ofta något som kommer från en livstidserfaring och säkert med Dr. Robin Bloor på Code Today, som ganska rikt skrev boken.
I många fall - och det är olyckligt men det är en verklighet - att det finns två delar av detta mynt, det vill säga mjukvaruutvecklare har sin egen blackout när det gäller databasspecialist och byggde de färdigheter du behöver för modellering av databasdesign, modellutveckling är bara grundläggande för guruskonstruktion av hur data kommer in och hur organisationen av resan den tar och hur den ska eller inte ska se ut, eller utan tvekan den intagna och förståelse för att den vanligtvis har fått i inhemska färdigheter för programutvecklare. Och några av de gemensamma utmaningarna vi står inför, bara för att sätta detta i besvär, inkluderar sådana som bara grundläggande skapande och underhåll och hantering av själva kärndatabasdesignen, dokumentera data och databasinfrastrukturen och sedan återanvända dessa datatillgångar, schemat design schema generationer, administration och underhåll av schema och användningen av dem, dela kunskapen kring varför detta schema är utformat på ett särskilt sätt och styrkorna och svagheterna som följer med det med tiden orsakar dataförändringar över tid, datamodellering och typer av modeller vi använder på systemen och data vi flyter genom dem. Generering av databaskoder och det går vidare med integration och sedan modellerade data runt dem och sedan snabbare åtkomst till kontroll av säkerhet runt data, integriteten hos data flyttar vi data när vi behåller sin integritet, finns det tillräckligt med metadata runt borde försäljningen se alla poster i tabellen eller ska de bara se adressen, förnamnet, efternamnet som du är med i inlägget? Och så är naturligtvis den största utmaningen av alla att modellera databasplattformar som helt och hållet är en annan konversation i sig.
Jag anser mycket att med allt detta i åtanke för att möjliggöra något av denna nirvana är det absolut viktigt att både dataspecialisterna och utvecklarna har lämpliga verktyg och att dessa verktyg kan leverera team-fokuserade projektleveranser, design, utveckling och löpande driftunderhåll. Du vet, saker som att samarbeta över projekt mellan dataexperter och mjukvaruutvecklare, en enda sanningspunkt eller en enda källa för sanning för allting kring dokumentation av själva databaserna, data, scheman, var posterna kommer från, ägarna av dessa poster . Jag tror att det är helt kritiskt i denna dag och ålder, vi kommer att få denna nirvana av data att vara kung, att rätt verktyg måste vara på plats eftersom utmaningen är för stor nu för oss att göra det manuellt, och om människor flytta in och ut från en organisation är det för lätt för oss att inte följa samma process eller metod som en person kan skapa som är bra och inte nödvändigtvis överföra dessa färdigheter och förmågor framöver.
Med det i åtanke ska jag gå över till vår goda vän på IDERA och höra om det verktyget och hur det hanterar just dessa saker.
Ron Huizenga: Tack så mycket och tack till både Robin och Dez för att du verkligen ställer in scenen bra, och du kommer att se lite överlappning i ett par saker som jag har pratat om. Men de har verkligen lagt en mycket solid grund för några av de koncept som jag kommer att prata om ur ett datamodelleringsperspektiv. Och mycket av de saker som de har sagt är en eko av min egen erfarenhet när jag var en konsult som arbetade inom datamodellering och dataarkitektur, tillsammans med team - både vattenfall i början och utvecklas till modernare produkter med projekt där vi använde smidiga metoder för att leverera lösningar.
Så det jag ska prata om idag är baserat på dessa erfarenheter såväl som en syn på verktygen och några av funktionerna i de verktyg som vi använder för att hjälpa oss på den resan. Det jag kommer att täcka mycket kort är att jag inte kommer att gå in i scrum i mycket detalj; vi hade bara en riktigt bra överblick över vad det är. Jag kommer att prata om det i termer av, vad är en datamodell och vad betyder det egentligen för oss? Och hur möjliggör vi konceptet för den smidiga datamodelleren i våra organisationer, i termer av, hur engagerar vi datamodellerna, vad är deltagande av modellerare och arkitekter under s, vilka typer av aktiviteter de borde bedriva och, som en bakgrund av detta, vad är några av de viktiga modelleringsverktygets funktioner som vi använder för att verkligen hjälpa till att göra det jobbet enklare? Sedan ska jag gå in i en liten uppsättning och bara prata lite om några affärsvärden och fördelar med att ha en datamodeller involverad, eller hur jag faktiskt ska berätta historien är, problemen med att inte ha en datamodeller helt engagerad i projekten och jag ska visa er att baserat på erfarenhet och ett defektdiagram över en före och efter bild av ett faktiskt projekt som jag var involverad i för många år sedan. Och sedan sammanfattar vi några punkter till och sedan har vi frågor och svar utöver det.
Mycket kort är ER Studio en mycket kraftfull svit som har många olika komponenter till den. Dataarkitekten, som är där datamodellerna och arkitekterna tillbringar större delen av sin tid på att göra sin datamodellering. Det finns andra komponenter också som vi inte kommer att prata om alls idag, till exempel affärsarkitekt, där vi gör processmodellering och mjukvaruarkitekt, för några av UML-modellerna. Sedan finns det förvaret, där vi checkar in och vi delar modellerna och vi tillåter lagen att samarbeta om dem och publicera dem ut på teamservern så att flera intressentgrupper som är engagerade i ett projekt faktiskt kan se de artefakter som vi " skapar ur ett dataperspektiv såväl som de andra saker som vi gör i själva projektleveransen.
Det jag kommer att fokusera på idag kommer att vara några saker som vi kommer att se med Data Architect och för att det är verkligen viktigt att vi har samarbete med databasbaserade aspekter av det. Särskilt när vi börjar prata om begrepp som förändringshantering som är nödvändiga för, inte bara smidiga utvecklingsprojekt, utan alla typer av utveckling framöver.
Så låt oss prata om Agile Data Modeler ett ögonblick. Som vi har gjort, typ av, tidigare hänvisat till i presentationen, är det att det är absolut nödvändigt att vi har datamodeller och / eller arkitekter helt engagerade i de smidiga utvecklingsprocesserna. Nu, vad som historiskt har hänt är, ja, vi har verkligen tänkt på smidiga ur ett utvecklingsperspektiv, och det är ett par saker som har pågått som verkligen har orsakat det. En del av det berodde bara på hur utvecklingen i sig utvecklades. När den smidiga utvecklingen började och vi började med detta koncept med självorganiserande team, om du drack Kool-Aid lite för rent och du var på den extrema programmeringssidan av saker, fanns det en mycket bokstavlig tolkning av saker som självorganiserande team, som många tolkade betyda, allt vi behöver är en grupp utvecklare som kan bygga en hel lösning. Oavsett om det innebär att utveckla koden, databaserna eller datastores bakom den och allt hänvisades till utvecklarna. Men vad som händer med det är att du tappar bort de speciella förmågor som människor har. Jag har funnit att de starkaste lagen är de som består av människor med olika bakgrund. Som en kombination av starka programvaruutvecklare, dataarkitekter, datamodeller, affärsanalytiker och affärsaktörer som alla samarbetar för att driva ut en slutlösning.
Det jag också pratar om idag är att jag ska göra detta i samband med ett utvecklingsprojekt där vi utvecklar en applikation som uppenbarligen kommer att ha datakomponenten också kopplad till den. Vi måste dock ta ett steg bakåt innan vi gör det, för vi måste inse att det finns väldigt få Greenfield-utvecklingsprojekt där vi har total fokus på skapandet och konsumtionen av data som endast är begränsade inom det utvecklingsprojektet självt . Vi måste ta ett steg bakåt och titta på den övergripande organisationssynpunkt från ett dataperspektiv och ett processperspektiv. Eftersom det vi finner ut är den information som vi använder kanske redan finns någonstans i organisationerna. Som modellerare och arkitekter tar vi det fram så vi vet var vi ska hämta informationen från själva projekten. Vi känner också till de datastrukturer som är involverade eftersom vi har designmönster precis som utvecklare har designmönster för sin kod. Och vi måste också ta det övergripande organisatoriska perspektivet. Vi kan inte bara titta på data i applikationen som vi bygger. Vi måste modellera uppgifterna och se till att vi dokumenterar dem eftersom de lever länge bortom själva applikationerna. Dessa applikationer kommer och går, men vi måste kunna titta på uppgifterna och se till att de är robusta och välstrukturerade, inte bara för applikationer utan också för beslut som rapporterar aktiviteter, BI-rapportering och integration till andra applikationer, interna och externt för våra organisationer också. Så vi måste titta på hela den stora bilden av uppgifterna och vad livscykeln för dessa data är och förstå resan med informationsbitar över hela organisationen från vagga till grav.
Nu tillbaka till själva lagen och hur vi faktiskt behöver arbeta, upplevdes vattenfallsmetodiken som för långsam för att ge resultat. Eftersom, som påpekats med tankexemplet, var det ett steg efter det andra och det tog ofta för lång tid att leverera ett genomförbart slutresultat. Det vi gör nu är att vi måste ha en iterativ arbetsstil där vi stegvis utvecklar delar av den och utarbetar den genom tiden där vi producerar användbar kod eller användbara artefakter, jag kommer att säga, för alla saker. Det viktiga är samarbete mellan de tekniska intressenterna i teamet och företagens intressenter, eftersom vi samarbetar för att driva ut användarberättelserna till en implementerbar vision av koden och de data som också stöder den koden. Och Agile Data Modeler själv kommer ofta att upptäcka att vi inte har tillräckligt med modellerare i organisationer så en datamodeller eller arkitekt kan samtidigt stödja flera team.
Och den andra aspekten av detta är, även om vi har flera modellerare, måste vi se till att vi har en verktygssats som vi använder som möjliggör samarbete mellan flera projekt som är på flykt samtidigt och delar av dem dataartefakter och möjligheterna för incheckning och utcheckning. Jag kommer att gå igenom detta mycket snabbt eftersom vi redan har täckt det i föregående avsnitt. Den verkliga förutsättningen för smidiga är att du baserar saker och ting på orderstock, berättelser eller krav. Inom iterationerna samarbetar vi som en grupp. Vanligtvis är två veckor eller en månad beroende på organisation mycket vanligt. Och också dagliga granskningar och standupmöten så att vi eliminerar blockerare och ser till att vi flyttar alla aspekter framåt utan att stoppas på olika områden när vi går igenom. Och i de här vill vi se till att vi producerar användbara leveranser som en del av varje s.
Bara något annorlunda tag på det, att utöka det ytterligare, scrum är den metod som jag kommer att prata om mer specifikt här och vi har bara i grund och botten förstärkt den tidigare bilden med några andra aspekter. Det finns vanligtvis en produktåtergång och sedan finns en eftersläpning. Så vi har en övergripande eftersläpning som vi i början av varje upprepning tar oss ner för att säga: "Vad ska vi bygga ut det här?" Och det görs i ett planeringsmöte. Sedan bryter vi upp de uppgifter som är förknippade med det och vi utför de en till fyra veckor med de dagliga recensionerna. När vi gör att vi spårar våra framsteg genom nedbrända diagram och nedbrända diagram för att spåra vad som finns kvar för att bygga kontra vad vi bygger för att fastställa saker som vad som är vår utvecklingshastighet, ska vi göra våra schema, alla dessa typer av saker. Alla dessa utarbetas kontinuerligt under s i stället för att gå några månader på vägen och ta reda på att du kommer att komma kort och att du måste förlänga projektplanen. Och mycket viktigt, som en del av det, hela lagen, det finns en recension i slutet och som retrospektiv, så innan du startar nästa iteration granskar du vad du gjorde och du letar efter sätt du kan förbättra på nästa gång igenom.
När det gäller leveranser är detta i grund och botten en bild som sammanfattar de typiska typerna av saker som pågår i ss. Och det är väldigt utvecklingscentriskt, så mycket av det vi ser här, till exempel, funktionell design och användningsfall, gör designkodtester, när vi tittar på dessa rutor här, och jag tänker inte gå igenom dem i alla detaljnivåer är de väldigt utvecklingsorienterade. Och nedgrävd nedanför är det faktum att vi också måste ha de dataleveranser som går hand i hand med detta för att stödja denna insats. Så varje gång vi ser saker som eftersläpningar, krav och användarhistorier, när vi går igenom, måste vi titta på vad är utvecklingsbitarna vi måste göra, vad är de analysbitar vi behöver göra, hur är det datadesign eller datamodellen, hur är det med saker som affärsordlistor så att vi kan associera affärsinnehåll till alla artefakter som vi producerar? Eftersom vi måste producera dessa användbara leveranser på alla sätt.
Vissa människor kommer att säga att vi måste producera användbar kod i slutet av varje s. Det är inte nödvändigtvis fallet, det är i ett renaste utvecklingsperspektiv, men ganska ofta - speciellt i början - kan vi ha något som nollet där vi fokuserar enbart på att stå upp, göra saker som att få våra teststrategier i plats.En design på hög nivå för att komma igång innan vi börjar fylla i detaljerna och se till att vi har en ren uppsättning starthistorier eller krav innan vi börjar engagera andra målgrupper och sedan bygga fram som ett team när vi går framåt. Det finns alltid lite förberedelsetid, så ganska ofta kommer vi att ha en noll eller till och med s noll och en. Kan vara lite av en uppstartsfas innan vi slår full flyg när vi levererar lösningen.
Låt oss prata om datamodeller i det här mycket kort. När människor tänker på datamodeller tänker de ofta på en datamodell som en bild av hur de olika informationsdelarna binds samman - det är bara toppen av isberget. För att fullständigt förkroppsliga andan i hur du verkligen vill närma sig datamodellering - oavsett om det är i smidig utveckling och andra saker - måste du inse att datamodellen, om den görs korrekt, blir din fulla specifikation för vad den informationen betyder i organisationen och hur det distribueras i back-end-databaser. När jag säger databaser menar jag inte bara de relationsdatabaser som vi kanske använder, utan i dagens arkitekturer där vi har big data eller NoSQL-plattformar, som jag föredrar att kalla dem. Även de stora datalagrarna eftersom vi kanske kombinerar många olika datalagrar när det gäller att konsumera information och ta med den i våra lösningar såväl som hur vi fortsätter eller sparar informationen från våra lösningar också.
Vi kanske arbetar med flera databaser eller datakällor samtidigt i facket för en given applikation. Det som är väldigt viktigt är att vi vill ha en fullständig specifikation, så en logisk specifikation av vad detta betyder för som organisatoriskt perspektiv, vad de fysiska konstruktionerna är i termer av hur vi faktiskt definierar data, förhållandena mellan dem i din databaser, dina referensintegritetsbegränsningar, kontrollbegränsningar, alla de valideringsdelar som du vanligtvis tänker på. De beskrivande metadata är oerhört viktiga. Hur vet du hur du använder data i dina applikationer? Om du inte kan definiera det och veta vad det betyder eller veta var det kom ifrån för att se till att du konsumerar rätt data i dessa applikationer - se till att vi har korrekta namnkonventioner, fullständiga definitioner, vilket betyder en fullständig dataordbok för inte bara tabellerna men kolumnerna som består av dessa tabeller - och noter om detaljdistribution om hur vi använder det eftersom vi behöver bygga upp denna kunskapsbas eftersom även den här applikationen kommer att användas för andra initiativ så vi måste se till att vi har allt som dokumenterats för framtida implementeringar.
Återigen kommer vi ner på saker som datatyper, nycklar, index, själva datamodellen förkroppsligar många affärsregler som spelar in. Förhållandena är inte bara begränsningar mellan olika tabeller; de hjälper oss ofta att beskriva de verkliga affärsreglerna kring hur informationen beter sig och hur de fungerar tillsammans som en sammanhängande enhet. Och naturligtvis är värdebegränsningar mycket viktiga. Nu är naturligtvis en av de saker vi ständigt hanterar, och det blir mer och mer utbredda, saker som datahantering. Så ur ett datastyringsperspektiv måste vi också titta på vad vi definierar här? Vi vill definiera saker som säkerhetsklassificeringar. Vilka typer av data har vi att göra med? Vad kommer att betraktas som masterdatahantering? Vilka är de transaktionsbutiker som vi skapar? Vilka referensdata använder vi i dessa applikationer? Vi måste se till att det fångas ordentligt i våra modeller. Och även överväganden av datakvalitet, det finns vissa uppgifter som är viktigare för en organisation än andra.
Jag har varit involverad i projekt där vi ersatte över ett dussin gamla system med nya affärsprocesser och designade nya applikationer och datalager för att ersätta dem. Vi behövde veta var informationen kom ifrån. Vilket för de viktigaste uppgifterna ur ett affärsperspektiv, om du tittar på den specifika datamodell-bilden som jag har här, kommer du att se att de nedre rutorna i dessa specifika enheter, som bara är en liten delmängd, jag har faktiskt kunnat fånga affärsvärdet. Oavsett om det är högt, medium eller lågt för dessa typer av saker för dessa olika konstruktioner inom organisationen. Och jag har också fångat saker som masterdataklasserna, om de är mastertabeller, om de är referens, om de var transaktioner. Så vi kan utöka våra metadata i våra modeller för att ge oss en hel del andra egenskaper utanför själva uppgifterna, vilket verkligen hjälpte oss med andra initiativ utanför de ursprungliga projekten och föra dem framåt. Nu var det mycket i en bild, jag kommer att gå igenom resten av dessa ganska snabbt.
Jag kommer nu att prata väldigt snabbt om vad som gör en datamodeller när vi går igenom dessa olika ss. Först och främst en fullständig deltagare i planeringssessionerna, där vi tar användarhistorierna, förbinder oss till det vi kommer att leverera i det, och ta reda på hur vi ska strukturera det och leverera det. Vad jag också gör som datamodeller är att jag vet att jag kommer att arbeta i separata områden med olika utvecklare eller med olika människor. Så en av de viktiga egenskaperna som vi kan ha är när vi gör en datamodell, vi kan dela upp den datamodellen i olika vyer, oavsett om du kallar dem ämnesområden eller delmodeller, är vår terminologi. Så när vi bygger upp modellen visar vi den också i dessa olika undermodellperspektiv så att de olika målgrupperna bara ser vad som är relevant för dem så att de kan koncentrera sig på vad de utvecklar och lägger fram. Så jag kanske har någon som arbetar med en schemaläggningsdel i en applikation, jag kanske har någon annan som arbetar med en orderpost där vi gör alla dessa saker på en enda, men jag kan ge dem synpunkter genom de undermodeller som bara gäller för det område som de arbetar med. Och sedan rullar de upp till den övergripande modellen och hela strukturen för undermodeller för att ge olika publikvisningar vad de behöver se.
Grundläggande ur ett datamodelleringsperspektiv som vi vill ha är alltid att ha en baslinje som vi kan gå tillbaka till eftersom en av de saker vi behöver kunna göra är, oavsett om det är i slutet av eller i slutet av flera ss, vi vill veta var vi började och alltid ha en baslinje för att veta vad som var deltaet eller skillnaden mellan vad vi producerade i en given s. Vi måste också se till att vi kan få en snabb vändning. Om du kommer in på det som en datamodeller men i den traditionella gatekeeperrollen att säga "Nej, nej, du kan inte göra det, vi måste göra allt det här först", du kommer att uteslutas från teamet när du verkligen behöver att vara en aktiv deltagare i alla dessa agila utvecklingsteam. Det betyder att vissa saker faller ur vagnen och gör en given s och du plockar upp dem i senare ss.
Som ett exempel kanske du fokuserar på datastrukturerna bara för att få utvecklingen igång för att säga, den orderingång som jag pratade om. I ett senare tillfälle kan du komma tillbaka och fylla i uppgifterna som en del av dokumentationen för dataarklistan runt några av de artefakter som du har skapat. Du kommer inte att slutföra den definitionen allt på en; du kommer att fortsätta med dina leveranser stegvis eftersom det kommer att finnas tider som du kan fylla i den information som arbetar med affärsanalytiker när utvecklarna är upptagna med att bygga applikationerna och uthålligheten runt dessa datalagrar. Du vill underlätta och inte vara flaskhalsen. Det finns olika sätt vi arbetar med utvecklare. För vissa saker har vi designmönster så vi är en fullständig deltagare framför, så vi kan ha ett designmönster där vi säger att vi kommer att lägga in det i modellen, vi kommer att driva det ut till utvecklarens sandlådedatabaser och sedan kan de börja arbeta med det och begära ändringar i det.
Det kan finnas andra områden som utvecklare har arbetat med, de har något de arbetar med och de prototyper vissa saker så de provar några saker i sin egen utvecklingsmiljö. Vi tar den databasen som de har arbetat med, tar den med i vårt modelleringsverktyg, jämför med de modeller vi har och löser sedan och skjuter tillbaka ändringarna till dem så att de kan refaktorera sina koder så att de följer de korrekta datastrukturerna som vi behöver. Eftersom de kan ha skapat några saker som vi redan hade någon annanstans, så vi ser till att de arbetar med rätt datakällor. Vi fortsätter bara att upprepa hela vägen igenom detta till våra så att vi får de fullständiga data som kan levereras, full dokumentation och definitionen av alla de datastrukturer som vi producerar.
De mest framgångsrika smidiga projekten som jag har varit involverade i när det gäller mycket bra leveranser är, vi hade en filosofi, modellerar alla förändringar i den fullständiga fysiska databasspecifikationen. I huvudsak blir datamodellen de distribuerade databaserna som du arbetar med för något nytt som vi skapar och har fullständiga referenser till de andra datalagren om vi konsumerar från andra externa databaser. Som en del av detta producerar vi stegvisa skript kontra att göra en hel generation varje gång. Och vi använder våra designmönster för att ge oss den snabba lyften när det gäller att få saker att gå i ss med de olika utvecklingsgrupperna som vi arbetar med.
Även i s-aktiviteter är det igen baslinjen för jämförelse / sammanslagning, så låt oss ta tanken att modellera varje förändring. Varje gång vi gör en förändring, vad vi vill göra är att vi vill modellera förändringen och vad som är mycket viktigt, vad som saknats i datamodellering tills nyligen, i själva verket, tills vi återinfört den, är förmågan att associera modelleringen uppgifter och dina leveranser med användarhistorier och uppgifter som faktiskt får dessa förändringar att ske. Vi vill kunna kolla in våra modelländringar, på samma sätt som utvecklare checkar in sina koder, med hänvisning till de användarhistorier som vi har så att vi vet varför vi gjorde förändringar i första hand, det är något vi gör. När vi gör det genererar vi våra inkrementella DDL-skript och lägger upp dem så att de kan plockas upp med andra utvecklingsleveranser och kontrolleras i vår build-lösning. Återigen kan vi ha en modell eller arbeta med flera team. Och som jag har pratat om, vissa saker kommer från datamodelleren, andra saker kommer från utvecklarna och vi träffas i mitten för att komma fram till den övergripande bästa designen och driva den framåt och se till att den är rätt utformad i vår övergripande datastrukturer. Vi måste upprätthålla disciplinen för att se till att vi har alla de rätta konstruktionerna i vår datamodell när vi går framåt, inklusive saker som null och inte nollvärden, referensbegränsningar, i princip kontrollbegränsningar, alla de saker som vi vanligtvis skulle tänka på .
Låt oss prata om bara några skärmdumpar av några av verktygen som hjälper oss att göra detta. Det jag tycker är viktigt är att ha det samarbetslagret, så det vi kan göra som datamodeller - och detta är ett utdrag av en del av en datamodell i bakgrunden - är när vi arbetar med saker vi vill se till att vi kan arbeta med bara de objekt som vi behöver för att kunna ändra, göra ändringar, generera våra DDL-skript för de ändringar som vi har gjort när vi kontrollerar saker och ting igen. Så vad vi kan göra är att i ER Studio är ett exempel, vi kan kolla in objekt eller grupper av objekt att arbeta med, vi behöver inte kolla in en hel modell eller delmodell, vi kan kolla in just de saker som är intressanta för oss. Det vi vill göra efter det är antingen utcheckning eller incheckning - vi gör det båda sätten eftersom olika utvecklingsgrupper arbetar på olika sätt. Vi vill se till att vi kopplar det till användarhistorien eller uppgiften som driver kraven för detta och det kommer att vara samma användarhistoria eller uppgift som utvecklarna kommer att utveckla och kontrollera sin kod för.
Så här är ett mycket snabbt utdrag av ett par skärmar i ett av våra förändringshanteringscentra. Vad detta gör, jag kommer inte att gå igenom i detalj här, men det du ser är användarhistorien eller uppgiften och intryckt under var och en av de du ser faktiska ändringsposter - vi har skapat en automatiserad ändringspost när vi gör incheckningen och utcheckningen och vi kan också lägga mer beskrivning på den ändringsposten. Det är associerat med uppgiften, vi kan ha flera ändringar per uppgift, som du kan förvänta dig. Och när vi går in i den förändringsrekorden kan vi titta på den och ännu viktigare se, vad ändrade vi faktiskt? För just den här, den markerade historien där hade jag en typ av förändring som gjordes och när jag tittade på själva förändringsposten, har den identifierat de enskilda bitarna i modellen som har förändrats. Jag ändrade ett par attribut här, åtskiljade dem igen och det medförde för turen de vyer som behövde ändras som var beroende av de också så att de skulle genereras i den inkrementella DLL. Det är inte bara modellering på basobjekten, utan ett högdrivet modelleringsverktyg som detta upptäcker också de ändringar som måste rippas genom de beroende objekten i databasen eller datamodellen också.
Om vi arbetar med utvecklare, och vi gör detta i ett par olika saker, det gör något i deras sandlåda och vi vill jämföra och se var skillnaderna är, vi använder jämför / sammanslagningsfunktioner där till höger och vänster sida. Vi kan säga, "Här är vår modell på vänster sida, här är deras databas på höger sida, visa mig skillnaderna." Vi kan sedan välja och välja hur vi löser dessa skillnader, oavsett om vi skjuter saker in i databasen eller om det finns några saker de har i databasen som vi tar tillbaka till modellen. Vi kan gå i två riktningar så att vi kan gå båda riktningarna samtidigt uppdatera både källa och mål och sedan producera inkrementella DDL-skript för att distribuera dessa ändringar i databasmiljön själv, vilket är oerhört viktigt. Vad vi också kan göra är att vi också kan använda denna jämförelse och slå samman kapacitet vid en viss tidpunkt, om vi tar ögonblicksbilder på väg igenom, kan vi alltid jämföra början på en s att börja eller slut på en annan så att vi kan se den fullständiga stegvisa förändringen av vad som gjordes i en given utveckling eller över en serie ss.
Detta är ett mycket snabbt exempel på ett alter script, var och en av er som har arbetat med databaser har sett den här typen av saker, det här är vad vi kan skjuta ut från koden som ett alter script så att vi ser till att vi behålla saker här. Det jag drog härifrån, bara för att minska röran, är vad vi också gör med dessa alter-skript är att vi antar att det finns data i dessa tabeller också, så vi kommer också att generera DML som kommer att dra informationen om de temporära tabellerna och tryck tillbaka den in i de nya datastrukturerna så att vi inte bara tittar på strukturerna utan också de data som vi kanske redan har innehållit i dessa strukturer.
Kommer att prata väldigt snabbt om automatiserade build-system eftersom när vi gör ett smidigt projekt ganska ofta arbetar vi med automatiserade build-system där vi måste kolla in de olika leveranserna tillsammans för att se till att vi inte bryter våra byggnader. Vad det innebär är att vi synkroniserar leveranserna, de ändringsskript som jag talade om med DDL-skriptet måste kontrolleras, motsvarande applikationskod måste kontrolleras samtidigt och en hel del utvecklare av utvecklingen nu är naturligtvis inte görs med direkt SQL mot databaserna och den typen av saker. Ofta använder vi uthållighetsramar eller bygger datatjänster. Vi måste se till att ändringarna för dessa ramar eller tjänster checkas in exakt samtidigt. De går in i ett automatiserat build-system i vissa organisationer och om byggandet går sönder, i en smidig metod, är det alla händer på däckfästning som byggs innan vi går framåt så att vi vet att vi har en fungerande lösning innan vi går vidare. Och ett av projekten som jag var involverad i, vi tog detta till ett extremt - om byggnaden brast vi faktiskt hade kopplat till ett antal datorer i vårt område där vi samlades med företagets användare, hade vi röda blinkande lampor bara som toppen av polisbilar. Och om byggnaden brast började de röda blinkande lamporna att slockna och vi visste att det var alla händer på däck: fixa byggnaden och fortsätt sedan med det vi gjorde.
Jag vill prata om andra saker, och detta är en unik kapacitet för ER Studio, det hjälper verkligen när vi försöker bygga dessa artefakter som utvecklare för dessa uthållighetsgränser, vi har ett koncept som heter affärsdataobjekt och vad som tillåter oss att gör är om du tittar på den här mycket förenklade datamodellen som ett exempel, tillåter den oss att kapsla enheter eller grupper av enheter för var persistensgränserna är. Där vi som datamodeller kanske tänker på något som en inköpsorderhuvud och orderinriktningen och andra detaljerade tabeller som skulle binda till det på det sätt vi bygger ut det och våra utvecklare av datatjänster behöver veta hur saker och ting fortsätter till dessa olika data strukturer. Våra utvecklare tänker på saker som inköpsorder som ett övergripande objekt och vad är deras kontrakt med hur de skapar de specifika föremålen. Vi kan avslöja den tekniska detaljerna så att de som bygger dataservrarna kan se vad som ligger under den och vi kan skydda de andra målgrupperna från komplexiteten så att de bara ser olika objekt på högre nivå, som också fungerar mycket bra för att kommunicera med företag analytiker och affärsintressenter när vi talar också om interaktion mellan olika affärsidéer.
Det trevliga med det också är att vi konstruktivt utvidgar och kollapsar dessa så att vi kan bibehålla förhållandena mellan objekt med högre ordning även om de härstammar från konstruktioner som finns i dessa affärsdataobjekt själva. Nu som modellerare, komma till slutet av s, i slutet av s wrap-up, jag har en hel del saker som jag behöver göra, som jag kallar min hushållning för nästa s. Varje gång jag skapar det jag kallar Named Release - som ger mig min baslinje för vad jag nu har i slutet av utgivningen. Så det betyder att det är min baslinje framöver, alla dessa baslinjer eller Namngivna releaser som jag skapar och sparar i mitt arkiv som jag kan använda för att göra en jämförelse / sammanslagning så att jag alltid kan jämföra med varje givet slut på alla andra, är mycket viktigt att veta vilka förändringar som gjordes i din datamodell på vägen genom sin resa.
Jag skapar också ett delta DDL-skript med jämför / sammanslagning igen från början till slutet av s. Jag kanske har checkat in en hel massa stegvisa skript, men om jag behöver det har jag nu ett skript som jag kan distribuera för att stå upp andra sandlådor så jag kan bara säga att det här var vad vi hade i början av det, tryck det igenom, bygga en databas som en sandlåda för att börja med nästa s och vi kan också använda de sakerna för att göra saker som standup QA-instanser och i slutändan vill vi naturligtvis driva våra förändringar till produktion så att vi har flera saker på gång på samma gång. Återigen deltar vi helt och hållet i planering och retrospektiv, retrospektiven är verkligen lärdomarna och det är oerhört viktigt, eftersom du kan komma igång väldigt snabbt under agile, måste du stoppa och fira framgångarna, som nu. Ta reda på vad som är fel, gör det bättre nästa gång, men fira också de saker som gick rätt och bygg vidare på dem när du fortsätter framåt i nästa ss framöver.
Jag kommer nu mycket snabbt att prata om affärsvärde. Det var ett projekt som jag engagerade mig för för många år sedan som startade som ett smidigt projekt, och det var ett extremt projekt, så det var ett rent självorganiserande team där det bara var utvecklare som gjorde allt. För att göra en lång historia kort var det här projektet fastnat och de upptäckte att de spenderade mer och mer gånger på att sanera och fixa de fel som identifierades än de pressade på mer funktionalitet och i själva verket när de tittade på det baserat på nedbrutna diagram måste de förlänga projektet sex månader till en enorm kostnad. Och när vi tittade på det var sättet att åtgärda problemet genom att använda ett ordentligt datamodelleringsverktyg med en skicklig datamodeller involverad i själva projektet.
Om du tittar på det här vertikala fältet i det här specifika diagrammet visar detta kumulativa defekter kontra kumulativa objekt, och jag talar om dataobjekt eller konstruktioner som skapades, till exempel tabellerna med begränsningarna och de typer av saker, om du tittade på innan datamodelleren introducerades var antalet defekter faktiskt överskridande och började bygga lite av ett gap över det faktiska antalet objekt som producerades fram till den tidpunkten. Efter vecka 21, det är när datamodelleren kom in, refakturerade datamodellen baserat på vad det fanns för att fixa ett antal saker och började sedan modellera som en del av projektgruppen framöver, förändringarna när projektet pressades framåt . Och du såg en mycket snabb vändning att inom ungefär ett och ett halvt halvår såg vi en enorm upptagning i antalet objekt och datakonstruktioner som genererades och konstruerades eftersom vi genererade av ett datamodelleringsverktyg snarare än ett utvecklingssticksbyggnad dem i en miljö, och de var korrekta eftersom de hade rätt referensintegritet och de andra konstruktionerna det borde ha. Nivån på defekter mot de nästan flatline. Genom att vidta lämpliga åtgärder och se till att datamodelleringen var fullt engagerad levererades projektet i tid med en mycket högre kvalitetsnivå, och i själva verket skulle det inte alls ha levererats om dessa steg inte hade ägt rum. Det finns en hel del smidiga misslyckanden där ute, det finns också många smidiga framgångar om du skulle få rätt personer i rätt inblandade roller. Jag är en enorm förespråkare av agile som en operationell disciplin, men du måste se till att du har färdigheterna för alla rätt grupper som är involverade som dina projektgrupper när du går framåt på en smidig typ av strävan.
För att sammanfatta måste dataarkitekter och modellerare vara involverade i alla utvecklingsprojekt; de är verkligen limet som håller samman allt eftersom vi som datamodeller och arkitekter förstår, inte bara datakonstruktionerna i det givna utvecklingsprojektet, utan också var informationen finns i organisationen och var vi kan källa till data från och hur de kommer att användas och användas utanför själva applikationen som vi arbetar med. Vi förstår de komplexa dataförhållandena och det är av största vikt att kunna gå framåt och även från ett styrningsperspektiv för att kartlägga dokument och förstå hur ditt fulla datalandskap ser ut.
Det är som tillverkning; Jag kom från en tillverkningsbakgrund. Du kan inte inspektera kvalitet till något i slutet - du måste bygga kvalitet i din design på förhand och på väg igenom, och datamodellering är ett sätt att bygga den kvaliteten in i designen på ett effektivt och kostnadseffektivt sätt hela vägen genom . Och igen, något att komma ihåg - och detta är inte att vara trite, men det är sanningen - applikationer kommer och går, data är den viktigaste företagstillgången och den överskrider alla dessa applikationsgränser. Varje gång du lägger in en applikation blir du förmodligen ombedd att bevara informationen från andra applikationer som kom tidigare, så vi behöver bara komma ihåg att det är en viktig företagstillgång som vi fortsätter att upprätthålla över tiden.
Och det är allt! Härifrån tar vi fler frågor.
Eric Kavanagh: Okej, bra, låt mig först släppa till Robin. Och sedan, Dez, jag är säker på att du har några frågor. Ta bort det, Robin.
Dr. Robin Bloor: Okej. För att vara ärlig har jag aldrig haft några problem med smidiga utvecklingsmetoder och det verkar för mig att det du gör här är framstående. Jag minns att jag tittade på någonting på 1980-talet som verkligen indikerade att problemet som du faktiskt stöter på när det gäller ett projekt som snurrar ut ur kontrollen normalt är om du låter ett misstag kvarstå utanför ett visst stadium. Det blir bara mer och mer svårt att fixa om du inte får det steget rätt, så en av de saker du gör här - och jag tror att detta är bilden - men en av de saker du gör här i noll är enligt min åsikt absolut viktigt eftersom du verkligen försöker få de varor som är fästa där. Och om du inte får fastade leveranser, ändrar leveranser form.
Det är, typ av, min åsikt. Det är också min åsikt - jag har verkligen inget argument med tanken på att du måste få datamodelleringen rätt till en viss detaljnivå innan du går igenom. Vad jag vill att du ska försöka göra för att jag inte fick en fullständig känsla av det, är bara att beskriva ett av dessa projekt när det gäller dess storlek, i termer av hur det flödade, i termer av vem, du vet, var problemen uppstod, löstes de? Eftersom jag tycker att den här bilden är ganska mycket hjärtat av den och om du kunde utarbeta lite mer om det, skulle jag vara mycket tacksam.
Ron Huizenga: Visst, och jag kommer att använda ett par exempelprojekt. Den som, typ av, gick från rälsen som fördes tillbaka genom att faktiskt få rätt personer involverade och göra datamodelleringen och allt var verkligen ett sätt att se till att designen förstås bättre och vi uppenbarligen hade bättre implementeringsdesign på väg igenom genom att modellera det. För när du modellerar det, vet du, kan du generera din DDL och allt utifrån och ut ur verktyget snarare än att behöva hålla fast detta, som folk vanligtvis kan göra genom att gå direkt in i en databasmiljö. Och typiska saker som kommer att hända med utvecklare är att de kommer in där och de kommer att säga, okej, jag behöver dessa tabeller. Låt oss säga att vi gör orderposter. Så de kan skapa ordningsrubriken och tabellerna för beställningsdetaljer och sådana saker. Men de kommer ofta att glömma eller försumma att se till att begränsningarna finns för att representera de utländska nyckelförhållandena. De kanske inte har nycklarna korrekta. Namnkonventionerna kan också vara misstänkta. Jag vet inte hur många gånger jag har gått in i en miljö, till exempel där du ser ett gäng olika tabeller med olika namn, men då är kolumnnamnen i dessa tabeller som ID, Namn eller vad som helst, så de har verkligen tappat nackdelarna utan tabellen över exakt vad det är.
Så, vanligtvis när vi modellerar data, kommer vi att se till att vi tillämpar riktiga namnkonventioner för alla artefakter som också genereras i DDL. Men för att vara mer specifik om själva projektenas karaktär är jag i allmänhet talar om ganska stora initiativ. En av dem var $ 150 miljoner företagsomvandlingsprojekt där vi ersatte över ett dussin gamla system. Vi hade fem olika smidiga lag på gång samtidigt. Jag hade ett fullständigt dataarkitekturteam, så jag hade datamodeller från mitt team inbäddade i vart och ett av de andra applikationsområdesteamen, och vi arbetade med en kombination av interna företagsexperter som visste ämnet, som gjorde det användarhistorier för själva kraven. Vi hade affärsanalytiker i vart och ett av de lagen som faktiskt modellerade affärsprocessen, med aktivitetsdiagram eller affärsprocessdiagram, vilket hjälpte till att utarbeta användarberättelserna mer med användarna innan de också konsumerades av resten av teamet.
Och så, naturligtvis, utvecklarna som byggde applikationskoden ovanpå det. Och vi arbetade också med, jag tror att det var fyra olika systemintegrationsleverantörer som byggde olika delar av applikationen samt där ett team byggde datatjänsterna, det andra byggde applikationslogik inom ett område, ett annat som hade expertis i ett annat affärsområde byggde applikationslogiken i det området. Så vi hade ett helt samarbete med människor som arbetade med detta projekt. Speciellt på den där hade vi 150 personer på land i teamet och ytterligare 150 resurser offshore på teamet som samarbetade två veckor för att driva ut den här saken. Och för att göra det måste du se till att du skjuter på alla cylindrar, och alla är väl synkroniserade med avseende på vad deras leveranser är, och du hade dessa ofta återställningar för att se till att vi slutförde våra leveranser av alla nödvändiga artefakter i slutet av varje s.
Dr. Robin Bloor: Det är väl imponerande. Och bara för lite mer information om det - slutade du med en komplett, vad jag skulle kalla, MDM-karta över hela dataområdet i slutet av projektet?
Ron Huizenga: Vi hade en komplett datamodell som var uppdelad med nedbrytningen mellan alla olika affärsområden. Själva datagränssnittet i termer av fullständiga definitioner föll lite kort. Vi hade de flesta av tabellerna definierade; vi hade de flesta kolumnerna definierade som exakt vad de betydde. Det fanns några som inte fanns där, och intressant nog, många av dem var informationsdelar som kom från de äldre systemen, som efter slutet av själva projektomfånget, som fortfarande dokumenterades som en framförande uppsättning av artefakter, som det var, utanför själva projektet, eftersom det var något som behövde upprätthållas av organisationen framöver. Så samtidigt ansåg organisationen en mycket ökad syn på vikten av datastyring eftersom vi såg många brister i dessa äldre system och de gamla datakällor som vi försökte konsumera för att de inte var dokumenterade. I många fall hade vi bara databaser som vi var tvungna att omvända och försöka ta reda på vad som fanns där och vad informationen var till för.
Dr. Robin Bloor: Det förvånar mig inte, den specifika aspekten av det. Datastyring är, låt oss kalla det, en mycket modern oro och jag tror verkligen att det finns mycket arbete som, låt oss säga, borde ha gjorts historiskt på datastyrning. Det berodde aldrig på att du, till exempel, kunde komma undan med att inte göra det. Men eftersom dataresursen bara växte och växte, så kunde du så småningom inte göra det.
Hur som helst, jag ska övergå till Dez eftersom jag tror att jag har haft min tilldelade tid. Dez?
Dez Blanchfield: Ja tack. Genom hela saken tittar jag och tänker för mig själv att vi talar om att se agile används i ilska på många sätt. Även om det har negativa konnotationer; Jag menade det på ett positivt sätt. Kan du kanske bara ge oss ett scenario med, det menar jag, det finns två platser som jag kan se att detta är en perfekt uppsättning: ett är nya projekt som bara behöver göras från dag ett, men jag tror alltid att det enligt min erfarenhet ofta är fallet att när projekt blir tillräckligt stora för att detta är nödvändigt på många sätt finns det en intressant utmaning mellan att limma de två världarna, eller hur? Kan du ge oss någon form av insikt i några framgångshistorier som du har sett där du har gått in i en organisation, har det blivit tydligt att de har fått en liten kollision mellan de två världarna och du har lyckats sätta fram detta på plats och föra samman stora projekt där de annars skulle ha gått på rälsen? Jag vet att det är en mycket bred fråga, men jag undrar bara om det finns en särskild fallstudie som du kan, till exempel, peka på det du sa, du vet, vi sätter allt detta på plats och det samlade hela utvecklingsgruppen med Datateamet och vi har, till exempel, adresserat något som annars kan ha sjunkit båten?
Ron Huizenga: Visst, och faktiskt det projekt som råkade vara ett pipeline-projekt var det som jag hänvisade till där jag visade det diagrammet med defekterna före och efter att datamodelleringen var inblandad. Ganska ofta, och det finns förutfattade föreställningar, särskilt om sakerna spinnas upp där det görs ur ett rent utvecklingsperspektiv av, det är bara utvecklare som är involverade i dessa smidiga projekt för att leverera applikationerna. Så vad som hände där, givetvis, är att de tog av sig rälsen och deras dataartefakter i synnerhet, eller att de leveranser av data som de producerade, underskrev märket när det gäller kvaliteten och verkligen hantera saker övergripande. Och det finns ganska ofta denna missuppfattning att datamodeller kommer att bromsa projekt, och de kommer att göra om datamodelleren inte har rätt inställning. Som jag säger, du måste tappa - ibland finns det datamodeller som har den traditionella portvaktens inställning där, "Vi är här för att kontrollera hur datastrukturerna ser ut," och att mentaliteten måste försvinna. Alla som är engagerade i smidig utveckling, särskilt datamodellerna, måste ta en roll som underlättare för att verkligen hjälpa lagen att gå framåt. Och det bästa sättet att illustrera det är att mycket snabbt visa team hur produktiva de kan vara genom att modellera förändringarna först. Och igen, det var därför jag pratade om samarbetet.
Det finns några saker som vi kan modellera först och generera DDL för att driva ut till utvecklarna. Vi vill också se till att de inte känner sig begränsade. Så om det finns saker som de arbetar med, låt dem fortsätta arbeta i deras utvecklingssandlådor, för det är där utvecklarna arbetar på sina egna stationära datorer eller andra databaser för att göra några förändringar där de testar saker. Och samarbeta med dem och säga, "Okej, arbeta med det." Vi tar det in i verktyget, vi löser det och sedan kommer vi att driva det framåt och ge dig skript som du kan distribuera det för att uppdatera din databaser för att uppgradera dem till vad den verkliga sanktionerade verkliga produktionsvyen av det kommer att bli när vi fortsätter att gå framåt. Och du kan vända det på ett mycket snabbt sätt. Jag upptäckte att mina dagar var fyllda där jag bara gick fram och tillbaka iterera med olika utvecklingsteam, tittade på förändringar, jämföra, generera skript, få dem igång, och jag kunde hålla mig själv med fyra utvecklingslag ganska enkelt när vi uppnått en fart.
Dez Blanchfield: En av de saker som jag tänker på det är att, du vet, många samtal jag dagligen handlar om att detta godståg kommer till oss, typ av, maskin-till-maskin och IoT. Och om vi tror att vi har mycket data nu om våra nuvarande miljöer i företag, vet du, om vi tar enhörningarna åt sidan för ett ögonblick där vi vet att Googles och s och Ubers har petabytes data, men i ett traditionellt företag talar vi om fortfarande hundratals terabyte och mycket data. Men det är detta godståg som kommer till organisationer, enligt min åsikt, och Dr. Robin Bloor hänvisade till det tidigare, av IoT. Du vet, vi har mycket webbtrafik, vi har social trafik, vi har nu mobilitet och mobila enheter, molnet har, liksom, exploderat, men nu har vi smart infrastruktur, smarta städer och det finns hela denna värld av data som bara exploderade.
För en vardaglig organisation, en mellanstor till stor organisation som sitter där och ser denna värld av smärta kommer på dem och inte har en omedelbar plan i åtanke, vad är några av takeaways, bara i några få meningar, som du skulle sätta för dem när och när de behöver börja tänka konversativt på att sätta några av dessa metoder på plats. Hur tidigt behöver de börja planera att nästan sitta upp och uppmärksamma och säga att det är rätt tid att få några verktyg på plats och få teamet tränat upp och få en konversation av vocab som går runt denna utmaning? Hur sent i historien är för sent eller när är för tidigt? Hur ser det ut för några av de organisationer du ser?
Ron Huizenga: Jag skulle säga för de flesta organisationer att om de inte redan har gjort det och anpassat datamodelleringen och dataarkitekturen med kraftfulla verktyg som detta, är tiden de behöver göra det igår. Eftersom det är intressant att även i dag, när du tittar på data i organisationer, har vi så mycket data i våra organisationer och generellt sett, baserat på några undersökningar som vi har sett, använder vi mindre än fem procent av dessa data effektivt när vi tittar över organisationer. Och med IoT eller till och med NoSQL, big data - även om det inte bara är IoT, utan bara big data i allmänhet - där vi nu börjar konsumera ännu mer information som kommer från våra organisationer utanför, blir den utmaningen större och större hela tiden. Och det enda sättet vi har en chans att kunna hantera det är att hjälpa oss att förstå vad den informationen handlar om.
Så användningsfallet är lite annorlunda. Vad vi befinner oss gör är när vi tittar på den informationen, vi fångar upp dem, vi måste omvända den, se vad som finns i dessa, oavsett om det finns i våra dataljöer eller till och med i våra interna databaser, syntetisera vad data är, tillämpa betydelser på det och definitioner på det så att vi kan förstå vad uppgifterna är. För tills vi förstår vad det är, kan vi inte säkerställa att vi använder det korrekt eller tillräckligt. Så vi måste verkligen ta hand om vad informationen är.Och den andra delen av det är att du inte gör det för att du kan konsumera alla externa data för att se till att du har ett användningsfall som stöder konsumtion av dessa externa data. Fokusera på de saker du behöver snarare än att bara försöka dra och använda saker du kan behöva senare. Fokusera på de viktiga sakerna först och när du arbetar dig igenom den, kommer du sedan att konsumera och försöka förstå den andra informationen utanför.
Ett perfekt exempel på det är att jag vet att vi pratar om IoT och sensorer, men samma typ av problem har faktiskt varit i många organisationer i många år, redan innan IoT. Alla som har ett produktionsstyrningssystem, oavsett om de är ett pipeline-företag, tillverkning, alla processbaserade företag som har saker där de gör mycket automatisering med kontroller och de använder dataströmmar och liknande saker, har dessa brandslangar med data som de försöker dricka ut för att ta reda på, vad är händelserna som har inträffat i min produktionsutrustning för att signalera - vad har hänt och när? Och bland den enorma dataströmmen finns det bara specifika uppgifter eller taggar som de är intresserade av att de behöver för att ta bort, syntetisera, modellera och förstå. Och de kan ignorera resten av det tills det är dags att verkligen förstå det, och sedan kan de utöka sitt räckvidd för att dra mer och mer av det till räckvidd, om det är meningsfullt.
Dez Blanchfield: Det gör det verkligen. Det är en fråga som jag kommer att leda till som kom från en gentleman som heter Eric, och vi har pratat om det privat. Jag har precis bett hans tillåtelse, som han har gett, för att be det om dig. För det leder fint till detta, bara för att packa upp, för vi kommer lite över tiden nu, och jag kommer att lämna tillbaka till Eric. Men frågan från en annan Eric var, är det rimligt att anta att ägare av en nystart är bekanta med och förstår de unika utmaningarna kring modelleringsterminologi, eller så, eller ska det överlämnas till någon annan för tolkning? Så med andra ord, bör en startup vara kapabel och redo och villig och kunna fokusera på och leverera på detta? Eller är det något de förmodligen borde shoppa ut och ta med experter ombord med?
Ron Huizenga: Jag antar att det korta svaret är att det verkligen beror. Om det är en start som inte har någon internt som är en dataarkitekt eller -modeller som verkligen förstår databasen, är det snabbaste sättet att starta att få någon med en konsultbakgrund som är mycket välbevandrad i det här utrymmet och kan få dem går. För vad du hittar - och faktiskt gjorde jag det på många engagemang som jag gjorde innan jag kom till den mörka sidan inom produkthantering - är att jag skulle gå in i organisationer som konsult, leda deras dataarkitekturteam, så att de på ett sätt kunde fokusera på sig själva och utbilda sina människor i hur man gör dessa typer av saker så att de upprätthåller det och bär uppdraget framöver. Och sedan skulle jag gå vidare till mitt nästa engagemang, om det är meningsfullt. Det finns många människor där ute som gör det, som har mycket god dataupplevelse som kan få dem igång.
Dez Blanchfield: Det är en bra takeaway-punkt och jag håller helt med om det och jag är säker på att Dr. Robin Bloor också skulle göra det. Särskilt i en nystartning är du fokuserad på att vara en små och medelstora företag på det speciella värdet av förslag som du vill bygga som en del av själva uppstartsverksamheten och du borde förmodligen inte behöva vara expert på allt, så bra råd. Men tack så mycket, en fantastisk presentation. Riktigt bra svar och frågor. Eric, jag kommer att lämna tillbaka till dig eftersom jag vet att vi förmodligen har gått tio minuter över tiden och jag vet att du gillar att hålla dig fast vid våra tidsfönster.
Eric Kavanagh: Det är okej. Vi har åtminstone ett par bra frågor. Låt mig kasta en till dig. Jag tror att du har svarat på några av de andra. Men en mycket intressant observation och fråga från en deltagare som skriver, ibland smidiga projekt har datamodelleren inte har hela den långsiktiga bilden och så avslutar de att utforma något i ett och sedan måste göra om i tre eller fyra. Verkar inte detta kontraproduktivt? Hur kan du undvika den typen?
Ron Huizenga: Det är bara den smidiga naturen att du inte kommer att få allt helt rätt i en given. Och det är faktiskt en del av den smidiga andan, är: arbeta med det - du kommer att göra prototyper där du arbetar med kod i en given sekvens, och du kommer att göra förbättringar av det. Och en del av den processen är när du levererar saker som slutanvändaren ser det och säger, "Ja det är nära, men jag måste verkligen få det att göra det här lite extra också." Så att det inte bara påverkar den funktionella designen av själva koden men ganska ofta måste vi ändra eller lägga till mer datastruktur under dessa vissa saker för att leverera vad användaren vill ha. Och det är allt bra spel och det är därför du verkligen vill använda de högdrivna verktygen eftersom du mycket snabbt kan modellera och göra den förändringen i ett modelleringsverktyg och sedan generera DDL för databasen som utvecklarna sedan kan arbeta mot för att leverera det ändras ännu snabbare. Du sparar dem från att behöva göra den handkodningen, som den var, av datastrukturerna och låter dem koncentrera sig på den programmering eller applikationslogik som de är mest skickliga på.
Eric Kavanagh: Det är fullständigt vettigt. Vi hade ett par andra människor som bara ställde specifika frågor kring hur det här binder tillbaka till verktyget. Jag vet att du tillbringade lite tid på att gå igenom exempel och att du har visat några skärmdumpar om hur du faktiskt rullar ut några av det här. När det gäller hela processen, hur ofta ser du att det i spel i organisationer och hur ofta ser du mer traditionella processer där saker bara, typ av, ploddar med och tar mer tid? Hur utbredd är s-stilmetoden ur ditt perspektiv?
Ron Huizenga: Jag tror att vi ser det mer och mer. Jag vet att jag, förmodligen, i synnerhet under de senaste 15 åren, har sett mycket mer av en adoption av människor som erkänner att de verkligen behöver anta en snabbare leverans. Så jag har sett fler och fler organisationer hoppa på den smidiga bandvagnen. Inte nödvändigtvis helt; de kan börja med ett par pilotprojekt för att bevisa att det fungerar, men det finns några som fortfarande är mycket traditionella och de håller sig med vattenfallsmetoden. De goda nyheterna är naturligtvis att verktygen fungerar mycket bra i dessa organisationer också för den typen av metodik, men vi har anpassningsbarheten i verktyget så att de som hoppar ombord har verktygen i verktygslådan på deras fingertoppar. Saker som jämför och smälter, saker som omvänd teknik, så att de kan se vad de befintliga datakällorna är, så att de faktiskt kan jämföra och generera de inkrementella DDL-skript mycket snabbt. Och när de börjar omfamna det och ser att de kan ha produktivitet, ökar deras benägenhet att omfamna smidiga ännu mer.
Eric Kavanagh: Det här är bra saker, folkens. Jag har precis lagt ut en länk till bilderna där i chattfönstret, så kolla in det; det är lite av det här för dig. Vi har alla dessa webbsändningar för senare visning. Dela dem gärna med dina vänner och kollegor. Och Ron, tack så mycket för din tid idag, du är alltid trevlig att ha på showen - en riktig expert på området och det är uppenbart att du känner till dina saker. Så tack till dig och tack till IDERA och naturligtvis Dez och vår helt egen Robin Bloor.
Och med det kommer vi att hälsa dig, folkens. Tack igen för din tid och uppmärksamhet. Vi uppskattar att du håller dig fast i 75 minuter, det är ett ganska bra tecken. Bra show killar, vi pratar med dig nästa gång. Hejdå.