Af Techopedia Staff, 21. juni 2017
Takeaway: Værten Eric Kavanagh diskuterer den mobile arbejdsstyrke med Dr. Robin Bloor og IDERAs Bill Ellis.
Du er ikke logget ind. Log ind eller tilmeld dig for at se videoen.
Eric Kavanagh: Okay, mine damer og herrer, det er onsdag den 21. juni. Det er 4:00 østlig tid, og det betyder selvfølgelig i verden af virksomhedsteknologi, at det er tid for Hot Technologies! Ja bestemt. Mit navn er Eric Kavanagh, jeg vil være din vært og moderator for dagens begivenhed. Det er et varmt emne folk, det er et stort emne: “En Marche! Aktivering af den mobile arbejdsstyrke. ”Og jeg tog ikke med vilje taglinien fra Mr. Macrons kandidatur i Frankrig. Det var helt tilfældigt, jeg lover dig, men det er stadig ret spændende. Så vi taler alt om den mobile arbejdsstyrke, og hvordan du kan sikre dig, at disse mennesker får det, de har brug for, og de kan gøre, hvad de gør godt. Masser af udfordringer, masser af problemer derude. Vi arkiverer denne webcast til senere visning, så hvis du går glip af noget, kan du vende tilbage og tjekke det ud. Del det også med dine venner og kolleger.
Og jeg skal sige, ikke vær genert; den bedste måde at få virkelig tilpasset indhold og de oplysninger, du har brug for fra en begivenhed som denne, er at stille spørgsmål. Så du kan stille et spørgsmål fra chatvinduet eller fra spørgsmål og svar på din webcast-konsol. Når som helst under arrangementet, send den videre, og jeg vil være sikker på at gribe det og væve det i spørgsmål og svar i slutningen. Vi vil have et par præsentationer, og så hører vi fra Bill Ellis fra IDERA Software. Naturligvis er vores egen Robin Bloor på banen i dag. Og med det, lad os dykke lige ind.
Så jeg har fået nogle gode statistikker fra RCR Wireless om, hvad der foregår, og det er virkelig et sjovt blæser. De siger, at den globale mobile arbejdsstyrke vil ramme 1, 87 milliarder mennesker i 2022. Det er over 40 procent af den samlede arbejdsstyrke på planeten. Så hvis du tænker over det, pludselig hvor du plejede at have, hvad angår it-kapaciteter, med hensyn til funktionalitet på enheder som computere, hvor du plejede at have 99 procent eller mere af det i lokaler i din kontorer - det var lige, lad os sige for 15 år siden, for 10 år siden var det sandsynligvis 85-90 procent, for fem år siden var det ligesom 70 procent? Noget i den stil? Nu er det hele vejen ned, næsten til 60 procent. Og det er meget. Så vi har set dette enorme skift med hensyn til teknologien, de faktiske værktøjer, som folk bruger, bevæger sig uden for kontoret, ind i arbejdsstyrken.
Der er utallige fordele ved dette. Jeg mener, bogstaveligt talt, hvis du f.eks. Ser på skibsfartsindustrien, som UPS, eller hvis du ser på fyre, der går ud til riggene i oliefelter, hvis du ser på et af de forskellige job, hvor det hjælper med at have dyb funktionalitet med dig på vejen ændrer den mobile arbejdsstyrke alt. Nu er et af problemerne - og vi vil tale om dette en større dybde - at vi har et par forskellige ting, der sker, hvoraf den ene er mangfoldighed af arbejdsstyrke. Så i 2020 - jeg lige så statistikken i dag - vil der være fem generationer af mennesker i arbejdsstyrken. Det betyder, at du får bedstemor og bedstefar og derefter mor og far og også børnene, men teoretisk set har du stort set bedstemor og bedstemor-bedstefor og bedstemor derude. Nu er det åbenbart ikke inden for en bestemt familie, men pointen er generationsmæssig, du har fem forskellige kategorier af brede individer i arbejdsstyrken, hver af dem har deres egne tendenser, deres egne forudsætninger, deres egen tilbøjelighed til at arbejde med teknologi.
Det er klart, børnene har en tendens til at være mobile først med hensyn til, hvordan de interagerer med verden. Og bare tænk på de kommunikationskanaler, det ændrede - vi talte om dette på et andet show for nylig; SnapChat er, hvordan en masse teenagere kommunikerer, de ønsker ikke engang at tale med dig på telefonen, de vil bare sende små SnapChat-meddelelser frem og tilbage. Det er kun et eksempel i forbrugerverdenen på, hvordan tingene ændrer sig, og det kan spredes over hele spektret af teknologier, funktionalitet, individuel, virksomhed, forretningsmodel. Det er bare overalt på kortet, men pointen er, at den mobile arbejdsstyrke er reel, den er derude, og medmindre din virksomhed har et solidt program til at forstå, hvordan det påvirker dine forretningsforløb - og jeg taler meget specifik teknologidrevet data- drevne processer - hvis du ikke forstår, hvad det er, og ikke styrer det gennem en IT-infrastruktur og en proces og et regeringsperspektiv, vil du have alle slags problemer.
Så der er iPhone. Jeg kan huske, da denne sucker kom ud, det ser ud til for en million år siden nu. Men det var kun som hvad, 2007 eller '08? Det var ikke så længe siden, at vi ikke havde iPhones, og naturligvis formfaktoren bare grundlæggende ændret teknologi, og virkelig aktiveret den mobile arbejdsstyrke. Og jeg husker selvfølgelig på det tidspunkt, iPad kom ud og derefter iPhone, lige omkring samme tid. Jeg kan ikke huske, hvad der var først, men iPad var virkelig en af de mest betydningsfulde forandringskræfter for enterprise IT, muligvis siden mainframe. Og årsagen er fordi ærligt talt, mange meget seniorledere, C-suite-folk fra store organisationer elskede det lige ud af flagermus. Og sagde: ”Jeg vil have det. Jeg bringer det til at fungere. ”Nå, tænk over det - pludselig måtte IT vende sig om og håndtere det problem, som de sandsynligvis ikke ville tackle, hvilket handlede om alle disse nye enheder.
Så nu, hvis du havde iPads - ja, hvordan væver du det ind i matrixen? Hvordan opretholder du regeringsførelse over det? Disse er alle virkelig store udfordringer, og den gamle iPad og iPhone var virkelig en enormt forstyrrende styrke inden for it og i IT-styring for mange organisationer, store og små. Så vi har stadig dette spektrum af udfordringer og fordele, der spænder over en så bred vifte, som du kan forestille dig, med mobile enheder. Og selvfølgelig forandrer de sig stadig, ikke? Så nu er det ikke kun BYOD, det er BYOA mange gange, hvor ledere og fagfolk bringer deres eget udstyr. Vi kaldte det ”skygge-it”, ikke? For dem af jer i den ældre generation husker du måske de gamle radioprogrammer, de havde radiodrama, og en af dem var Skyggen - ”Hvem ved hvad onde lurer i menneskers hjerter? Skyggen ved. ”Og det kan jeg huske, fordi jeg var barn. Nå, skygge IT flirer overalt i disse dage; alle laver skygge IT.
Så dette er en reel udfordring for IT-styring og forretningsprocessestyring, alle driftsfolk. Du vil være i stand til at udnytte mobile enheder, men du vil være i stand til at binde det tilbage til dine systemer, og der er masser af underlige, små problemer, der kommer i spil. Ikke mindst er den visuelle oplevelse og den tilknyttede funktionalitet, du får, når du bruger en mobilenhed. Og enhver af jer, der har brugt flere enheder som en iPad, kontra en bærbar computer, mod et skrivebord, kontra nogle af de nyere mobile smartphones, der kommer ud, efter at have oplevet, at funktionaliteten ikke fungerer helt rigtigt, og dette er et reelt problem. Faktisk burde browserkrigene have forberedt os på dette, fordi browsere alle også gør tingene lidt anderledes. Og det er en anden stor udfordring for ikke kun design, ikke kun udseende og fornemmelse og den slanke natur af det program, du bruger, men den faktiske funktionalitet. Hvordan får du rullemenuen til at vælge, hvad du vil have på den enhed? Det er en stor aftale.
Så det er det, vi skal tale om lidt i dag, og vi vil høre fra Robin og Bill Ellis, som jeg nævnte, som er en rigtig ekspert på dette område. Så dette er et af de store problemer, som folk har - det er bare at darn-sorten, og der er ingen enkelt metode til at kunne arbejde på tværs af platforme. Du har fået Samsung og Apple for det meste til at lave disse ting, men der er alle slags - der er så mange enheder! Jeg så for nylig, at iPhone vandt med hensyn til salg, og jeg var chokeret over hvor lavt antallet var - det var som om jeg ikke engang var 20 procent! Og de var nummer et, hvilket betyder, at der bogstaveligt talt er scoringer - hvis ikke hundreder - af enheder derude, der kan bruges. Du kan bare forestille dig, hvordan IT-afdelingen føler det, og selvfølgelig ændrer den række teknologier sig; det bliver mere forskelligartet med dagen.
Alt ændrer sig, vi har fået alle slags ting - containere, bare for at kaste en anden skruenøgle i værkerne her. Og så har vi selvfølgelig mangfoldigheden i arbejdsstyrken. En masse årtusinder, de er bare meget forskellige med hensyn til deres præferencer, hvordan de bruger teknologi, hvad de er villige til at vade igennem, hvor hurtigt de kan finde ud af ting. Typisk er det hurtigere end med os gamle timere, men ikke desto mindre skal alt, hvad der skal kortlægges tilbage til dine on-prem systemer, eller i det mindste op til skyen. Og det er en stor, stor udfordring.
Og med det overlader jeg det til den uforlignelige Dr. Robin Bloor. Robin, tag det væk.
Robin Bloor: OK, tak for den korte introduktion. Lad os tale om mobil. Det var ikke særlig åbenlyst - Eric henviste til introduktionen af iPhone - det var ikke særlig åbenlyst, når iPhonen kom nøjagtigt i det, dette indbød. Jeg tror, det blev tydeligt, når iPad trådte ind, at vi faktisk skulle have en ret forskelligartet mobil verden. Jeg er virkelig en slags Apple bigot, så jeg tror ikke rigtig hvad angår Android, men selvfølgelig, selvom Apple skaffer størstedelen langt, er den store fortjeneste fra både pad-markedet og telefonmarkedet, det har ikke numrene længere, hvilket er en slags interessant ting. Og det betyder, at der - bortset fra alt andet - der vil være nye enheder, folk vil tage dem op, og de vil sælge millioner. Så det skaber et meget mangfoldigt miljø, som du muligvis skal gennem.
Vittigheden her om "Jeg vil spørge Siri, hvor fanden er vi, hvis jeg kunne få et signal." Det, der gør mobiltelefoner lidt anderledes, er, at desktops er tilsluttet hele tiden. Og mobile enheder er ikke nødvendigvis tilsluttet, og de er ikke nødvendigvis døgnet rundt, fordi folk kan slukke dem. også kan du få dem til fly og lignende ting, og derfor er det en anden slags enhed end noget, du nogensinde har haft før. Jeg vil fastholde, at mobiltelefonen faktisk er den rigtige personlige computer, for det er den, du har med dig hele tiden. Det er den definerende menneskelige mobile enhed. Tabletten er lidt anderledes; det er en slags underlig situation, at når du tænker over det, at der på en eller anden måde er der mere end en funktionel type mobilenhed.
Uanset hvad det betyder at være mobil. Internettet ændrede sig. Vi har ikke slags bemærket, at det skete - jeg bemærkede ikke, at det skete - men i dag 80 procent af internetaktiviteten er fra mobile enheder, og det er en ekstraordinær figur, når du tænker over det. Men 47 procent af disse 80 procent er tablettrafik. Det er muligt at levere de fleste applikationer i en mobil indstilling. Med andre ord, hvis du har applikationer, der allerede findes, og du ved, de er tilgængelige på skrivebordet, kan du sandsynligvis sætte dem på en mobiltelefon, men der er åbenbart begrænsende faktorer. Formfaktor og tastatur er en af dem. Tabletterne i sig selv skal ifølge Microsoft og Apple gradvist erstatte mobile pc'er. Og de har særlige applikationer i visse områder, fordi de er mere robuste.
En af de ting, som jeg kan huske at have talt med IT-folk i sundhedsvæsenet, var det faktum, at før tabletten eksisterede, hvis du gik ind i et miljø, der var en isolationsafdeling, ved du, du skulle have dine enheder, som du tog i med du, skulle faktisk desinficeres på en eller anden måde. Det er virkelig let at gøre det med en tablet, det er slet ikke let at gøre det med det, de plejede at have, som var desktops, der var mobile i kraft af at være på en vogn og tilsluttet miljøet. De plejede at være for en slags ophold i den slags miljøer eller gennemgå en ekstraordinær slags desinfektion, der bliver taget ud af disse miljøer. Og vi tænker ikke så meget på disse miljøer, medmindre vi arbejder i disse miljøer. Men tablets og mobiltelefoner har gjort det muligt at arbejde i disse miljøer virkelig ret naturligt at være forbundet og arbejde i disse miljøer.
Og når den stat, som Eric satte 1, 7 milliarder, tror jeg, det var, mobilarbejdere i 2020. Er jeg mobilarbejder? Jeg tænker sådan, at det er, jeg er en mobil arbejdstager i den forstand, at jeg lejlighedsvis arbejder uden for kontoret, og når jeg gør det, skal jeg arbejde på en tablet eller lave ting på en mobiltelefon. Så når du faktisk ser på det, og du tænker over det, skyldes det sandsynligvis mennesker, der kun bruger mobile enheder til deres arbejdsstyrke, så folk, der rent faktisk bevæger sig rundt. I hvert fald kan du tænke nu i form af tre slags brugere: desktopbrugere, tabletbrugere og telefonbrugere. Og de har brug for forskellige applikationer. Og det er grunden til at nævne det.
Kamera og stemme er nu en iboende del af mobile enheder, men de er også en iboende del af desktops. Men de bruges på forskellige måder på mobile enheder, og de har forskellige grænseflader på mobile enheder. Og hele karakteren af hvorfor du bruger det er anderledes på en mobilenhed. Så det er, hvis du bygger mobile applikationer, du ikke bygger den slags applikationer, som du plejede at opbygge af en hel række grunde - hvoraf mange var på det lysbillede. Så hvis du var en virksomhed, der allerede på en eller anden måde bygger applikationer, der kørte på websteder, er spørgsmålet, skal de også være mobile applikationer? Og denne dias ser slags på det. En webapplikation, du kan gøre mere ved det, simpelthen fordi de er bygget på en eller anden måde, de er bygget uden egentlig at bekymre sig om formfaktoren, så folk vil opbygge en webside, som du ikke med rimelighed kan bruge, eller du kan ikke let bruge på en iPhone eller en Android-enhed, som måske bare kan bruges på en tablet, men selv på en tablet er måske ikke særlig god. Normalt ville det være OK.
Eller du kan oprette en mobilapp. Hvis du bygger mobile apps, er der et applikationsudstyr på forskellige downloadbutikker, og den slags drev deres modstand ned. Hvis du ser på min bestemte iPhone, er den bare fyldt med applikationer, som jeg ikke ser ud til at slippe af med; Jeg sletter dem, men de ser altid ud til at blive downloadet igen på en mærkelig måde. Jeg ved tydeligvis ikke, hvordan man administrerer en iPhone korrekt. Men du ved, du ender med bare en række applikationer, og det giver ingen mening. Jeg har mere, jeg formoder, at jeg har flere applikationer på min iPhone, end jeg har fået på mit skrivebord, hvilket er bisarr, når du tænker over det. Mobile apps er en lakmus-test for succes. Det er slags interessant, at nogle webvirksomheder - Yelp er en af dem - gjorde det meget godt ved at oprette en app og få folk til at downloade den. Og det ser ud til, at de områder, hvor der var rimelig god succes, faktisk var i den finansielle sektor; det er banker, men også e-handel og virksomheder som sådan, fordi folk gerne til tider kan handle ting, mens du er på farten. Mad applikationer, så ikke kun på udkig efter restauranter, men også lave opskriftssider, de gjorde det virkelig, virkelig godt med hensyn til apps.
Og mange mennesker gjorde det ikke særligt godt overhovedet, og det er grunden, jeg tror mest er, at der kun er så mange apps, du nogensinde bliver vant til at bruge, og hvis du kun bruger en app en gang hver par dage eller så, så glemmer du det. Hvis det ikke har en stor personlig værdi for dig, glemmer du den slags. Så det er vanskeligt at oprette en mobilapp, der er tilgængelig i generel forstand, men du kan naturligvis oprette dem til dit eget personale og bruge dem i organisationen. Mobilapps har virkelig store udviklingsomkostninger, og det er en række grunde til det. En af grundene hertil er, at du faktisk peger på et tydeligt forskelligt antal enheder.
Og du kan få udviklingsmiljøer, der er målrettet mod flere enheder, men nogle applikationer, især når du ser på sikkerhed, er du virkelig nødt til at lave kodning for selve enheden. Du skriver en anden kode til iPhone eller Android-miljøet. Måske anderledes. Nogle gange refererer du til hardware kapaciteter. Så den generelle mobilapp, ja, måske er der udviklingssoftware derude, som du kan opbygge en, der er slags hybrid, og som vil stramme de fleste af målmiljøerne. HTML5 gør det meget mere muligt, end det nogensinde var før. Men du får også denne situation, hvor nogle apps faktisk ikke kan gøre det; det betyder, at du faktisk udfører det samme arbejde flere gange for hver enhed, du målretter mod, og det vil ikke stoppe folk med at hævde, at de har ret til at medbringe deres egen enhed; det vil ikke gøre nogen forskel for det, så du kan ikke rigtig komme omkring det.
Tilsyneladende viser analyse af mobile apps, at de får større salg, ikke? Og dette er en mærkelig slags hjemmeside og mobilappen som, hvis du vil, komplement. Apperne får mere salg. Websiderne er bedre til at hente nye kunder. Apps er bedre til at bevare kunder, som du allerede har hentet. Kunder bruger meget mere på websteder end på apps, men kunderne bruger oftere på apps. Og det er en virkelig underlig ting, og det taler til det faktum, at hvis du skal bygge noget, så har du sandsynligvis brug for en webside-inkarnation og en mobil-app-inkarnation, hvis du forventer, at det skal bruges i vid udstrækning. Og det er på en eller anden måde det er en dramatisk udgift at tilføje et softwareprojekt, som under alle omstændigheder muligvis gør en hel del andre ting.
Som en generel idé er et websted et katalog, og en app er en loyalitetsmaskine. Udvikling af mobilapper - og det er bare for at slags nedbryde problemet - forskellige udviklingsmiljøer, forskellige problemer med hensyn til hardware, forskellige brugergrænseflades designprincipper og evne. Du bliver nødt til at have offline kapacitet - fordi en mange apps, folk forventer at kunne bruge dem, hvis de er frakoblet - de vil ikke miste dataene; nogle af dataene skal gemmes lokalt. Du bygger en anden app, end du måske bygger, lad os sige til skrivebordet. Og så har du det mobile back-end problem, der bliver brug for mellemware der, der vil være sikkerhedsprocedurer der. Der vil sandsynligvis være en serviceorienteret arkitektur i baggrunden, hvor du strikker forskellige ting sammen. Og hvad det siger, er at du ikke bare tager et team, der er vant til at udvikle applikationer på serveren og sånt. Når du kaster dem en mobil, har du virkelig brug for mobiludviklere. Og folk med mobiloplevelse.
Under alle omstændigheder er det kun en ting at sige - først og fremmest - mobile apps er i de fleste tilfælde et kundepunkt, så de skal være rigtig gode, fordi en kunde bedømmer virksomheden på baggrund af mobilen erfaring, ellers påvirker det deres dømmekraft. Og i nogle tilfælde er mobilappen, som jeg nævnte, faktisk det, der er bestemt af forretningsmæssig succes; det kan være den ting, der virkelig gør en organisation. Og selvfølgelig kan det også være en fugtig squib.
Og når det er sagt, skal jeg give bolden tilbage til Eric.
Eric Kavanagh: Fint, og jeg overleverer det lige til Bill. Bill, hvis du vil gå til hurtigstart der og dele din skærm?
Bill Ellis: Ja. Her?
Eric Kavanagh: Det øverste venstre hjørne.
Bill Ellis: Ja. Tak for instruktionerne, jeg sætter pris på det. Robin, jeg kunne virkelig godt lide din diskussion, det var sjovt. Jeg har arbejdet på et virtuelt hold i 18 år nu, så jeg tror, jeg kan regne mig selv som en del af den mobile arbejdsstyrke. Nogle gange er jeg bekymret for, at jeg vil se, hvis jeg har en funktion efter arbejdet, må jeg ofte klæde mig for at gå til den. (Griner) Og jeg begynder måske at miste perspektivet på, hvad "klædt" er, så under alle omstændigheder. (Ler) Med det, lad os gå videre og komme i gang. Jeg vil gerne bekræfte, at Eric måske bare kunne ringe ind og fortælle mig, du kan se min skærm OK?
Eric Kavanagh: Ja, ser godt ud.
Bill Ellis: Okay. Så jeg hedder Bill Ellis, jeg arbejder med IDERA på den præcise produktlinje, og vi vil tale om at muliggøre mobilitet. Og vi taler virkelig om at måle det og sørge for, at det fungerer til din tilfredshed. Et af de store punkter der var, at det er noget, som folk slags interagerer med, med din virksomhed. På en måde er det meget intimt - telefonen er lige i en persons hånd, så indtrykket, hastigheden, gør stort indtryk på alle brugerne.
Så dette var en kundeoplevelse, som jeg troede, jeg ville dele. De havde et live spil, det gik ikke godt. Og fordi den indledende belastningstest ikke fuldstændigt afslørede ændringer i den underliggende applikationsinfrastruktur, og derfor er en af de ting, som jeg gerne understrege, med mobil, hvad enten applikation eller HTML5, der er også en masse teknologi, der er afhængig af. Start med netværket, på webserveren, i forretningslogik, i messaging, og hvis de foretager et køb, ved du, en betydelig forretningstransaktion, interagerer de med postsystemet.
Og ironisk nok stødte vi på et par netværksproblemer, da vi kom i gang, så alt dette er meget relevant selv for at levere selve dette webinar. Og så kan du have en applikation, mindst seks teknologier, mange slutbrugere, og det er meget vanskeligt at besvare selv de enkleste spørgsmål. Har en slutbruger et problem? Hvad er problemet med en applikationsstabel, hvilken kode forårsager problemet? Og det er faktisk ikke trivielt at få fat på disse ting.
Hvad vi nu skal gøre, er, at vi skal tage et kig på nogle målinger, der blev foretaget på et sted, for at hjælpe med at skelne hvor problemer er inden for applikationsstakken. Og hvad vi ser på her er en graf, hvor Y-aksen er responstid, X-aksen er tid over dagen. Og stabelbjælken er en måling af, hvor slutbrugertransaktionerne bruger deres tid. Og så får du slags en dejlig trend her, og så går den op og op og op. Og det er dybest set afgrænsningen af udskæringen, og så ved at se stabelbjælken, kan du begynde at se, at der er mange problemer i J2EE-niveauet. Du ser også problemer i webserver-niveauet, og så er der nogle temmelig store elevatorer, faktisk også i databasesystemet.
Og nu, nu hvor vi har identificeret, at der er flere lag, med flere problemer, er vi nødt til at gå lidt videre for at finde ud af, hvad der sker, for at få et intelligent svar på dette nye brugsmønster og dette meget langsomt, vi taler om fire eller fem X langsommere ydelse. Og så en af de første ting, vi gerne vil gøre, er at sige, "Dette er en transaktion, " og så vi har set på omfanget i venstre side af alle transaktioner, og de kan, rådgivning, det er virkelig let at se på svaret søjlediagram for dybest set at se, at du ser på den samme klientwebserver Java for visse transaktioner mere end andre, databasetid. Men det er virkelig overalt i forhold til alle transaktioner.
Og dette ser på brugere, og så begynder du at få, dette er en global implementering, så du ser på de primære kontinenter i verden, så det er alle brugere, alle lokationer. Dette er et globalt problem, det sker, så det begynder at isolere, det er ikke en eller en bestemt gruppe af brugere - det er noget, der mere sker på datacentersiden. Og så begynder vi at diagnosticere, hvor i dataene? Hvilke applikationsniveauer? Og så vi begynder at se på, at den gennemsnitlige responstid er ved at opbygges, også lagvis over det med antallet af henrettelser, for at få en idé om skalering. Dette er meget interessant - den nedre halvdel viser faktisk historien på længere sigt, og du kan se meget høje adgangstællinger, men den anden side af det er antallet af samtidige forbindelser er relativt lavt. Efter at vi skiftede over til en mobil HTML5-applikation, fordobles antallet af forbindelser mere end et meget mindre - vi taler om størrelsesordener - det er 100 gange mindre adgang, så vi skalererer ikke; vi har mindst det dobbelte af antallet af forbindelser til det, vi havde haft tidligere. Så vi begynder at skelne, hvad der er de nye krav, som mobilapplikationen stiller til de underliggende infrastrukturer.
Så lad os gå endnu længere ind, fordi vi er nødt til at isolere, hvor problemer opstår. Og så her ser du dybest set på slags ting, der skal ud, og vi har virkelig ikke brug for denne søjlediagram her for at sige, at vi ikke møder vores SLA'er, men vi kan let se det i den øverste graf. Men vi har en sekundær bekræftelse med hensyn til eksekveringstællinger for manglende overholdelse af SLA. Nu, her, vil vi faktisk begynde at se på låsning, og det er inden for - dette er tilfældet WebLogic, men inden for forretningslogik-niveauet. Og du kan se her, og dette er måske lidt svært at læse, men du presser på 31.000 låsekøb i en samlet låsetid på 12 timer, 30 minutter. Så dette er helt klart et enormt problem.
Nu viser låspåvirkningen os, at der altid er en vis afledning af 80/20-reglen. Det er virkelig ned til en metode, en gruppe af metoder, der virkelig forårsager problemerne. Nu begynder vi at isolere problemer inden for et bestemt niveau. Så vi går lidt længere ind, og her er meddelelsessystemet. Og vi begynder at se dette, den over tid graf, som jeg cirkler øverst til venstre, du kan se, at den uslebne responstid går op, og den lyserøde, nøglen, dette viser faktisk kø og der er faktisk en meget anderledes i kø, der sker, bliver det skubbet op på grund af antallet af forbindelser. Så messaging-systemet udfører meget mere arbejde; der er meget mere - hvis du laver en analogi med den købmand, er der meget flere vogne i hver bane ved kassetælleren - og det er det, der skubber køen op, og du kan se det tydeligst i domænet. Hvert af domænerne ser meget, meget høj kø.
Indtil videre har jeg identificeret låsning inden for WebLogic, jeg har identificeret kø i meddelelsessystemet, og dette er tilfældigvis Tuxedo. Og så, hvad vi ser på her er en lignende type analyse, men vi ser på eksekveringstilstande inden for registreringssystemet. Og dette sker som henrettelsestilstander i Oracle. Årsagen til, at vi fokuserer på tid, er, at tiden har to fremragende egenskaber. Nummer én: det er den måde, slutbrugere og applikationer oplever ydeevne. Nummer to er det måler ressourceforbrug. Og så identificerer den automatisk, hvor flaskehalserne er. Og så kan jeg her på databasesystemet se, at jeg har ekstra I / O-tid, så jeg understreger lagersubsystemet. Hvert niveau er afhængigt af downstream-niveauet, så databasen er afhængig af lagring. Jeg kan også se, at inden databasetiden låser jeg. Så jeg er nødt til at blive lidt mere granulær, før disse oplysninger bliver lidt mere handlingsdygtige. Og så lad os gå ind, skræl løgen endnu et lag tilbage.
Nu er dette faktisk et kig på eksekveringstællinger, Y-aksen i dette antal, dette er i tusinder, du ser på 9.000, ni millioner, og så eksekveringstællingen går også op og op og op. Så den nye mobilitetsapplikation understreger applikationen en hel masse måder. Låsning, bare for at sammenfatte: låsning ved nettet, kø i meddelelsessystemet, yderligere eksekveringstælling på databasesystemet, yderligere I / O, yderligere låsning inden for databasesystemet. Så vi er, jeg påvirker faktisk hvert niveau inden for applikationsspecifikationen. Og så er det meget vigtigt at kunne have målinger fra alle niveauer i applikationsstakken. Her deler jeg faktisk databaseaktiviteten i program, og jeg kan se, at jeg virkelig har to programmer: den turkise farve kortlægger applikationslåsen. Og så, denne, distributionsserveren som applikationslås, appen, dette er den mobile del, dette har også applikationslås. Og du kan se, at der er en række af disse flaskehals på selve lageret.
Nu får jeg, skrælning af løgen for at se, hvad jeg kan gøre på hvert enkelt niveau. Og grunden til, at jeg gør det, er at mange mennesker ser på dette fra et kapacitetsplanlægningssynspunkt. Og de fleste af skytjenesterne taler de om at udvide servere, CPU og hukommelse. Den anden side af mønten er lige så vigtig, er at applikationskoden, der udfører og driver forbruget af disse ressourcer. Og når du ved om applikationskoden, kan du nu adressere kapacitet ved at behandle effektiviteten. Så du har begge sider af den samme mønt, og det giver IT-fagfolk yderligere muligheder for at løse problemet. Det er ikke bare at tilføje flere servere, det er også, hvad kan vi gøre for at rydde op og fungere mere effektivt? Den gamle "Arbejd smartere, ikke hårdere."
Så her kan vi faktisk, Oracle har en pæn ting, der hedder Moduler og handlinger, hvor du faktisk kan begynde at dokumentere koden, og så kan du også undersøge tingene på en anden måde, som her, applikationslåsen, som vi så? Det kom godt igennem udgiftsarkkoden, det kom også ind via distributionsserveren, og det er de to primære drivere for den nye låsning. Og den nye lagerplads kommer gennem onlinesystemet, og derfor begynder du virkelig at opbygge en profil, hvor driverne er til dette ekstra ressourceforbrug. Det er en anden ting at være i stand til at præcisere driverne i den underliggende kode. Og så at gå ind på dette, tror jeg, vi kiggede på dette udgiftsark, og så går vi ind her.
Ser du nu på de underliggende objekter, der udøves, begynder du at se denne meddelelseslog. Nå, hver gang de sender beskeder - og vi så, at det går op med et multiplum - berører vi faktisk denne meddelelsesloggtabel, og du vil faktisk se om et øjeblik, at det faktisk forårsager meget af låsningen inden for database niveau. Så disse nye brugsmønstre har stor indflydelse op og ned af applikationsstakken. Nu til højre er SQL-koden, og så dette er faktisk applikationskoden, og vi sporer, hvad SQL-udsagn gør ved udførelsestilstand. Og så er det meget let gennem farvekodningen at se, hvilke SQL-sætninger der er involveret i disse låse. Årsagen til at dette er virkelig vigtigt er, at hvis du går til din DBA, og du siger: ”Hej, vi tror, der er et problem på databaseniveau.” De ser måske bare på databasen, og det ser måske ret meget ud som det løb i går.
Men når de er i stand til at sammenhænge, hvordan applikationen bruger databasen, kan de derefter præcisere de nøjagtige SQL-udsagn, som de skal fokusere på, og så kan de komme ind på nogle af disse avancerede fremgangsmåder, se på udførelsesplaner og alle disse ting at de kan finjusteres for at få systemet til at køre meget hurtigere. Og så, den korrelerende tvivl om koden, er det virkelig vigtigt at give teknologieksperterne mulighed for at kunne løse og afhjælpe underliggende problemer. Nu, her, talte vi også om opbevaring - her ser du antallet af fysiske læsninger, du kan se, hvornår det skete, og dette begynder at komme ind i hardwarearkitekturen, fordi når du planlægger at udvikle et system, er en af de ting, du muligvis vælger at gøre, er at du kan vælge forskellige typer lagring, og de har en meget anden udgiftsprofil. Og i visse tilfælde vil det give en god mening at opgradere og betale for flashlagring; hvis jeg laver meget mere tilfældige læsninger, vil flashopbevaringen virkelig betale sig for mig.
Og så er den overordnede meddelelse om dette, at med en ny applikation stilles nye krav til systemet, og den underliggende applikationsstabel skal udvikles for at imødekomme disse behov. Og du vil også se på, hvad disse behov er, og kan koden justeres for at gøre den mere effektiv? Og endelig, ned i CPU'en, kan du se på cutover-perioden, vi havde kørt på cirka 10 procent, og så, når vi en gang med den nye kode, var vi på 4X, nu er vi på 40 procent, og dette er virkelig vigtigt for fysiske såvel som virtualiserede miljøer for at sikre dig, at du har tilstrækkelige serverressourcer til at opfylde applikationens behov. Og så, her er bare et mere tæt på, så du kan se nogle af disse numre lidt på forhånd. Interessant på serverniveau havde hukommelsesforbruget ikke ændret sig så meget, men bestemt havde antallet af krævede CPU-cyklusser haft.
Og dette er grundlæggende bare en sammenfattelse af at se på udgiftsrapporten, se på skaleringen, det faktum, at antallet af henrettelser faktisk faldt, men henrettelsestiden gik op. Og så viste det, at under mobiliteten var udgiftskomponenten i applikationen virkelig problemer. Og det vil bestemt have en brugereffekt på tingene, fordi hvis du ikke kan udføre dit job, vil folk stort set bare stoppe med at bruge mobiliteten. Og det dejlige ved mobilitet er, at det virkelig giver arbejdsstyrken produktivitet, og det er meget godt til lønchecks og så videre, så du vil bestemt have, at det skal rulle. Nu ser vi på det samme her, lige fra et stedssynspunkt, så det er Europa og Mellemøsten, Asien VPN-forbindelser og derefter hovedkvarteret. Og USA generelt. Så vi tror, at en måde at få denne værdifulde information på hvert niveau af applikationsstakken er gennem den nøjagtige produktlinje.
Jeg vil bare meget hurtigt, Robin og Eric, jeg er bare hurtigt form for bare at give et overblik over, hvad Precise gør, og hvorfor det er designet, som det er designet. Og hvad sker der, hvis slutbrugeren prøver at gøre noget, der er en masse teknologi i datacenteret, slutbrugeren virkelig ikke er interesseret i, de vil bare gøre deres job. I mellemtiden har du en masse mennesker inden for it, velmenende, meget smarte, men de er ikke engang klar over et problem, før denne slutbruger rapporterer, hvis de rapporterer. Og så, mange gange dette vil starte en meget dyre tidskrævende i sidste ende frustrerende proces, hvor folk ser på en delmængde af applikationsstakken, men det er meget vanskeligt at besvare de grundlæggende spørgsmål om hvem, hvad, hvornår, hvor, hvorfor.
Så hvad vi tror er ved at måle slutbrugertransaktioner, der starter i deres enhed, gennem netværket, på webserveren, i Java, ved at fange disse oplysninger, kan vi besvare spørgsmålene om, hvem, hvad, hvornår, hvorfor, hvorfor anbefalinger, men sandsynligvis den vigtigste ting er at udfylde feedback loop. Vi har alle brug for feedback for at forbedre det, det er den eneste måde, du ved, at noget går galt. Ved at få historien sat i et centraliseret arkiv, giver det et ark musik for alle at læse fra. Og så bliver det meget let at finde ud af, hvor problemer er, så endnu en gang handler designet om at måle slutbrugertransaktionen; dette vil identificere langsomme transaktioner, segmentere det, dette vil fortælle, hvad teknologi er et problem og derefter give et ekspert syn på hver af de individuelle niveauer, så du kan finde ud af, hvad der sker. Precise vil give både indlæring og rapportering og betjeningspaneler til alle interessenter, uanset om du bare vil have et overblik, eller hvis du vil have et dybtgående teknologisk overblik over, hvad der foregår.
Hvad der nu kan ske, som en dag i livet, enten kan du som IT-specialist kalde en slutbruger, eller nogle gange kan en slutbruger ringe til dig. Log ind på Præcist, du kan fokusere igen, Y-aksen er respons, X-aksen er tid over dagen. Her er vi hver delstat, så du har klienttid, webservertid, Java, smoking, databasetid. Her nede har du kørselstransaktioner, du kan åbne en menu til at identificere en bestemt slutbruger, og på denne måde har IT muligheden for at tackle de bestemte slutbrugers problemer. Og så kan du se nøjagtigt, hvornår de havde travlt, du kunne se, at de brugte indholdsstyring, som du kan fokusere på den transaktion, og derefter vil Precise give dig en analyse af den transaktion.
Procentdelen i slutningen tilføjes med procent, Præcis, og det fortæller dig, hvor meget tid, men en procentdel af tiden, der er brugt på det individuelle trin, ned til individuelle SQL-udsagn, dette er konteksten. Og en af de ting, som vi siger, er, at alle har værktøjer, men få butikker har sammenhæng. Og kontekst giver Java-administratoren mulighed for at fokusere på applikationskoden, DBA til at identificere som i dette tilfælde den bestemte SQL-sætning. Og så med disse oplysninger giver det dem meget mere synlighed for, hvordan man løser den underliggende grundårsag til den bestemte transaktion, der påvirkede den bestemte bruger. Så du laser virkelig fokuseret på grunden. Og du kan analysere SQL-sætning, hvor brugte den sin tid, ja, henrettelse? Og bare derimod en masse værktøjer som Enterprise Manager bare for at vælge dem. De er store, de kan tage det. De ser på ting fra et instansperspektiv, og det er ikke nok fokus virkelig til at komme ind i disse applikationer.
Typisk vil dine OLTP-mobilitetsapplikationer være lav latens, høj gennemstrømning, så det er en start, at fokusere på top ti-listen, men det er virkelig ikke godt nok til denne type applikation. Og så er den anden ting, at især for internt hostede applikationer er identifikation ved hjælp af bruger-id virkelig vigtig, fordi det ikke kun handler om applikationen og infrastrukturen, det handler også om, hvordan slutbrugerne bruger applikationen. Og slutbrugerne har typisk meget bedre opførsel, når du er i stand til at identificere dem. Og så dette er bare en slags skærm med forskellige transaktioner og klientoplevelsen og derefter sub-segmenteret, (griner), jeg har nok talt i lidt længe. Lidt træt herude; Jeg vil pløje forude.
Her ser vi på et instrumentbræt, som vi har sammensat, der viser advarsler og derefter viser forskellige niveauer af applikationsstakken. Her er dine webservere, og du kan verificere med udførelse af responstid, at tingene er belastningsbalanceret. Du kan se på browsertilgang, du kan se på holde brug og samling af skrald, sørge for, at du har det pæne savtandmønster, at du ikke har en hukommelseslækage osv. Og tanken med dette er at give lidt lidt af et mere teknisk instrumentbræt for hver af komponenterne i applikationsstakken. Så den præcise produktlinje, der tilbydes af IDERA, tilbyder produktionsovervågning, 24 af 7, meget detaljerede oplysninger. Det er temmelig let at implementere dette; du behøver ikke at kortlægge transaktioner, uanset hvad slutbrugerne gør, Precise forbinder automatisk prikkerne på tværs af applikationsstakken.
Hvis et downstream-niveau ikke er instrumenteret, genkender Precise det og giver ind- og ud-tiden og anbefaler, at du instrumenterer downstream-niveauet. Og så er det meget let slags tid at værdsætte; Vi er meget stærke på databasen, dette er IDERAs slags krav på berømmelse. Og grunden til, at det er så vigtigt, er, at enhver væsentlig forretningstransaktion interagerer med registreringssystemet, så databasen bliver grundlæggende præstation. Og så de andre værktøjer på markedet, de gør et OK stykke arbejde, men OK er ikke rigtig godt nok; du har virkelig brug for at vide nøjagtigt, hvad der sker med SQL-udsagnene. Og vi gør en masse avancerede ting, der er for meget til dette, som at holde en SQL-erklæringshistorie og spore udførelsesplaner over tid. Og så er det et område, som vi kan udforske videre, hvis du måske er interesseret.
Så med det, det er den præcise applikationspræstationsplatform, inviterer vi dig til at anmode om et ekstra møde gennem idera.com-webstedet, hvis du har yderligere interesse for løsningen og de emner, vi diskuterede i dag.
Og Eric, med det tror jeg, vi stadig er under ledningen, jeg vil sende stafettpinnen tilbage til dig og Robin. Tak skal du have.
Eric Kavanagh: Nej, det er fantastisk, og jeg elsker det indhold, som du har sammensat her, fordi du gør et fantastisk stykke arbejde med at vise, hvor kompliceret miljøet er under hætten. Og naturligvis, hele jobbet med Precise, er formålet med Precise at hjælpe med at navigere i den kompleksitet og forstå, hvad der faktisk sker, og være i stand til at tage nogle handlinger for at forbedre noget. Og jeg er bare forvirret over, hvor kompliceret det er. Jeg gætter på, at Precise også giver dig mulighed for at identificere bestemte adfærdsmønstre og derefter navngive dem, eller i det mindste registrere dem eller bogmærke dem eller noget lignende, er det ikke?
Bill Ellis: Ja, en af de ting, der vil ske, er, at du ikke ønsker at gå efter din hale; du ønsker ikke bare at gå meget tid på en engangs. Så du vil gerne se på, hvad der er mønstre, hvad er tendenser, fordi der er en masse teknologi at styre. Og en af tingene er at prioritere og være i stand til at rangere, vide, hvor du skal bruge din tid, vide, hvad der skal klemmes. Og du vil også tage en konservativ tilgang med lavere risiko og lavere omkostninger. Du ønsker ikke nødvendigvis at foretage en dyre global ændring, uden at have vurderet eller har en meget god fornemmelse af at vide, at det, dette vil virkelig hjælpe problemet. Så ved hvad der sker over tid, og denne tendens er afgørende for intelligent at tackle de underliggende problemer.
Eric Kavanagh: Det giver fuld mening. Og hvor stor en del er virtualisering for at være i stand til at se, hvad der sker, og kommer du så ind i organisationer, der bruger containere - bruger du f.eks. Docker? Og hvordan ville det påvirke, hvad Precise er i stand til at gøre?
Bill Ellis: Ja, så ordet “container” kan betyde forskellige ting i henhold til forskellige leverandører. Og så arbejder vi med VM, næsten alle bruger VMware - jeg betragter det som de facto-standarden på dette tidspunkt; Jeg ved, at der er konkurrenter derude. Og vi udvider det, vi understøtter, men VMware er det dominerende inden for Oracle-stakken. Der er containerdatabaser, og alt dette er meget vigtigt for at kunne udvikle dit system meget hurtigt. Det er også meget vigtigt at vide i et virtualiseret miljø, når den fysiske vært ikke er i stand til at imødekomme behovene i alle gæsters containere, fordi hver af dem konkurrerer om ressourcer.
Og en af de ting, der faktisk skete internt, jeg var overrasket over, er, at vi faktisk inden for IDERA havde så mange inaktive VM'er, men hver af disse inaktive VM'er bruger ressourcer, at de begyndte at forårsage et problem generelt for de VM'er, der faktisk blev brugte, der var vigtige for os, når vi udførte vores forretning. Og det var sådan en interessant ting. Nu understøtter vi ikke enhver teknologi under Solen; der er en supportmatrix forbundet med denne løsning, og det er en af de ting, som vi gerne vil bore ned på, for et bestemt kunde eller en bestemt kunde, bare for at sikre os, at vi kan imødekomme teknologibehovene og de individuelle teknologier, som deres applikationsstakke kører under.
Eric Kavanagh: Ja, det giver en masse mening. Fra din oplevelse, hvad er nogle af de største kræfter nu, der driver udfordringer på mobil? Da du og jeg talte før denne webcast for et par måneder siden, lavede du et rigtig godt punkt om, hvordan bare funktionaliteten og opstillingen af en iPhone eller en mobilenhed kan være en reel udfordring for virksomheden, fordi pludselig slutbrugeren kan kan jeg ikke finde ud af, hvordan man får en bestemt proces i arbejdsgangen, ikke? Og så, til det punkt, hvad du muliggør ved udvikling af mobilapp er, at du viser udviklerne, hvor problemerne opstår, og så kan du kortlægge det tilbage til, hvad appen laver på denne enhed eller den pågældende enhed. Og det er meget nyttigt, rigtigt, for udvikleren, for nu kan de se, hvad der forårsager problemet, de kan foretage nogle ændringer i appen, for at løse det, ikke?
Bill Ellis: Ja, det er slags overlejring af utroligt høje forventninger - alle forventer, at alt fungerer på en måde bare, men der er så meget variation derude. Du har alle disse forskellige smartphones, de har forskellige skærmdimensioner, og så har du forskellige leverandører af kommunikation, Verizons, AT & Ts, Sprints, disse er bare de populære i USA. Og der er lige så meget variation derude, det er ligesom godt, hvordan vikler du dine arme rundt om alt dette for at begynde at finde ud af, hvor problemerne er? Og så er der en masse metrics, der er tilgængelige, og en af de ting, som vores produktstyringsteam har gjort, er at forsøge at trække de metrics ind, som er mest vigtige eller mest nødvendige af IT-teamet, for at være i stand til at tage intelligente beslutninger .
Og så er det en slags udfordring, og vi gør, at vores produkt er som markedspladsen udvikler sig, og så vi får feedback fra vores kunder, og der er altid anmodninger om forbedring, så "Hej, denne ekstra metrisk ville være meget nyttig for os." Så vores produkt udvikler sig ligesom markedet, men hvis jeg havde sagt, Eric, det er virkelig interessant for mig, er det hele forventningens ting. Mennesker er som, det plejede at være tilbage i den dag, folk ville vente fem, syv sekunder på, at en skærm rude op, nu er det som et eller to sekunder, folk er som ”Åh, dette program fungerer overhovedet ikke!” (Griner)
Eric Kavanagh: Det er sjovt. Det er så sandt!
Bill Ellis: Det er skørt.
Eric Kavanagh: Ja, det er lidt urealistisk, ærligt. Og jeg tror, at vi måske begynder at se lidt mere realisme omkring dette emne, men det er ikke desto mindre en kendsgerning i livet, at folk har meget, meget høje forventninger. Og jeg gætter, Robin, jeg bringer dig hurtigt tilbage inden for de sidste par minutter her. Jeg elskede din vurdering af webstedet som et katalog og en app som en loyalitetsmaskine. Og til det punkt, hvad vi har talt om her, er, hvordan man gør det muligt for udviklerne af disse apps at forstå, hvad der sker: Kan det bruges? Kan den ikke bruges? Og hvad kan du ændre for at justere det? Og til Bills punkt her, for kun et sekund siden, er cyklustiden for at løse dette problem virkelig forkortet, ikke? Det er bare ikke som det plejede at være - du er nødt til at løse det hurtigt. Eller du har bare et stort drop-off i brug, ikke?
Robin Bloor: Ja, der er en hel masse andre ting, der spilles ind i dette, så du har denne smidige udvikling, og du har forventninger mange steder nu, at du vil frigive en ny version af noget, der er i færd med at blive udviklet eller i færd med at blive ændret, hvert par uger. Og det giver det, når du tænker over det, hvis du tænker på implementeringsmiljøer, og du tænker på, hvor stor stakken er, når du kommer ind på en mobil, har du faktisk flere potentielle enheder på slutnoden, og så skal du have middleware i midten. Og du kan godt have under og under, du kan godt have databaser. Så du rører muligvis mange, mange applikationer; du rører muligvis flere databaser, og du gør muligvis meget komplekse ting med hensyn til sikkerhed. Og det hele skal arbejde, og forventningen er, at det vil fungere rimeligt godt.
Og det fantastiske er nogle gange, det gør det, men min tanke herom er, hvis du virkelig, hvis du bygger mobile apps, der virkelig er nøglen til virksomhedens succes, og mange af dem viser sig, er mange af disse ting virkelig er. Hvis du laver mobil vedligeholdelse på olierigge og olierørledninger og lignende ting, skal det slags arbejde. Konsekvenserne af, at det ikke fungerer, er bare lidt uhyggelige. Og hvis du ikke har denne mulighed for faktisk at skive applikationen op og vide, hvor tingene går galt, fordi det meste af det er ydelse. Vi har virkelig gode testsele i dag, så ja, der er fejl og fejl der kommer igennem. Men mest hvis noget går galt, er det præstationsproblemet. Og hvis du ikke kan placere stetoskopet på 18 forskellige steder, er det virkelig svært at fastlægge, hvad der går galt. Og du har også netværket en faktor i dette, og du har også den virkelighed, at enhver given komponent i en applikation kan stresses på forskellige tidspunkter af dagen på grund af arten af den bestemte applikation. Du skal have sofistikerede overvågningsværktøjer, hvis du vil have en chance med alt dette.
Eric Kavanagh: Ja, jeg ville være enig, og jeg tror, det er virkelig styrken ved Precise af IDERA, i disse dage. Og Bill, jeg gætte bare nogen afsluttende kommentarer fra dig? Jeg synes, at denne teknologi er fantastisk. Jeg er også klar over, at du som bruger af denne teknologi virkelig har brug for at forstå kompleksiteten af informationssystemer og afhængigheder og være i stand til at finde ud af, hvor, hvornår og hvordan du syntetiserer alle disse oplysninger for at vurdere, hvad der faktisk sker. Og det kræver et intelligent og trænet menneske, og helt ærligt er det en af grundene til, at jeg overhovedet ikke er bekymret for, at maskinlæring fjerner job. Jeg tror, maskinlæring kunne være meget nyttigt under en teknologi som denne, til at identificere fælles mønstre og derefter komme med forslag til slutbrugeren om, hvad der måtte ske her. Men hvad er nogle afsluttende tanker fra dig om virkelig at få virksomheden vigtigheden af at have denne form for fejlfindingskapacitet, og hvad skal de vide om det, udover det, du allerede sagde?
Bill Ellis: Ja, så Eric, jeg er enig med dig, at der er en enorm mængde kompleksitet. Jeg tror på den præcise produktlinje ved at fokusere på den metriske tid, at en bruger, der kan læse en stakstangdiagram, kan bruge Precise med succes, og jeg vil bare sige tak til deltagerne og til dig og Robin for at være vært for dagens webinar.
Eric Kavanagh: Du satser! Og som jeg sagde, vi vil være vært for dette arkiv i nogen tid nu, så føl dig fri til at dele det med dine venner og kolleger; vi arkiverer alle disse webcasts. Jeg sendte et link til lysbillederne for et par minutter siden, så prøv det gerne, men godt job igen, Bill, i dag. Du kender virkelig dine ting; det er altid sjovt at arbejde med en professionel som dig selv. Og jeg tror, dette virkelig vil være de aktiverende teknologier for den mobile arbejdsstyrke! Så tak for din tid folkens, vi fanger dig op næste gang, pas på. Hej hej.
