Av Techopedia Staff, 21. juni 2017
Takeaway: Vert Eric Kavanagh diskuterer den mobile arbeidsstyrken med Dr. Robin Bloor og IDERAs Bill Ellis.
Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.
Eric Kavanagh: Ok, damer og herrer, det er onsdag 21. juni. Det er 4:00 østlig tid, og det betyr selvfølgelig at det er en tid for Hot Technologies! Ja absolutt. Jeg heter Eric Kavanagh, jeg vil være din vert og moderator for dagens arrangement. Det er et varmt tema folkens, det er et stort tema: “En Marche! Aktivering av den mobile arbeidsstyrken. ”Og jeg tok ikke med vilje taglinjen fra Mr. Macrons kandidatur i Frankrike. Det var ganske tilfeldig, jeg lover deg, men det er fremdeles ganske spennende. Så vi snakker alt om den mobile arbeidsstokken og hvordan du kan sørge for at disse menneskene får det de trenger, og de kan gjøre det de gjør godt. Mange utfordringer, mange problemer der ute. Vi arkiverer denne webcasten for senere visning, så hvis du savner noe kan du komme tilbake og sjekke det ut. Del det også med venner og kolleger.
Og jeg skal si ikke vær sjenert; den beste måten å få virkelig tilpasset innhold og informasjonen du trenger fra et arrangement som dette, er å stille spørsmål. Så kan du stille et spørsmål fra nettpratvinduet, eller fra spørsmål og svar-komponenten på webcast-konsollen. Når som helst under arrangementet, send det videre, og jeg vil være sikker på å ta tak i det og veve det inn i spørsmål og svar på slutten. Vi kommer til å ha et par presentasjoner, og så hører vi fra Bill Ellis fra IDERA Software. Vår egen Robin Bloor er selvfølgelig på banen i dag. Og med det, la oss dykke rett inn.
Så, jeg har fått noen gode statistikker fra RCR Wireless om hva som skjer, og egentlig er det ganske tankene å blåse. De sier at den globale mobile arbeidsstyrken vil ramme 1, 87 milliarder mennesker innen 2022. Det er over 40 prosent av den samlede arbeidsstyrken på planeten. Så hvis du tenker på det, så plutselig hvor du pleide å ha, med tanke på IT-evner, med tanke på funksjonalitet på enheter som datamaskiner, hvor du pleide å ha 99 prosent eller mer av det i lokalene i kontorer - det var jevnlig, la oss si for 15 år siden, for 10 år siden var det sannsynligvis 85-90 prosent, for fem år siden var det som 70 prosent? Noe sånt? Nå er det helt ned, nesten til 60 prosent. Og dette er en stor avtale. Så vi har sett dette enorme skiftet når det gjelder teknologien, de faktiske verktøyene som folk bruker flytter utenfor kontoret, inn i arbeidsstyrken.
Det er utallige fordeler med dette. Jeg mener, bokstavelig talt hvis du ser på skipsindustrien for eksempel, som UPS, eller hvis du ser på gutta som drar ut til riggene i oljefelt, hvis du ser på noen av de forskjellige jobbene der det hjelper å ha dyp funksjonalitet hos deg, på veien, endrer den mobile arbeidsstyrken alt. Nå, ett av problemene - og vi vil snakke om dette med noe større dybde - er at vi har et par forskjellige ting som skjer, hvorav det ene er mangfold av arbeidsstyrke. Så i 2020 - jeg så bare statistikken i dag - kommer det til å være fem generasjoner mennesker i arbeidsstyrken. Det betyr at du kommer til å ha bestemor og morfar og deretter mamma og pappa og også barna, men teoretisk sett kommer du til å ha egentlig oldemor og oldemor og oldemor der ute. Nå, tydeligvis er det ikke innenfor en bestemt familie, men poenget er generasjonsmessig, du har fem forskjellige kategorier av brede individer i arbeidsstyrken, hver av dem har sine egne tendenser, sine egne forutsetninger, sin egen tilbøyelighet til å jobbe med teknologi.
Det er klart, barn har en tendens til å være mobile først når det gjelder hvordan de samhandler med verden. Og tenk bare på kommunikasjonskanalene at det endret seg - vi snakket om dette på et annet show nylig; SnapChat er hvordan mange tenåringer kommuniserer, de ønsker ikke en gang å snakke med deg på telefonen, de vil bare sende små SnapChat-meldinger frem og tilbake. Det er bare et eksempel i forbrukerverdenen på hvordan ting endrer seg, og som kan spres over hele spekteret av teknologier, funksjonalitet, individ, selskap, forretningsmodell. Det er bare over hele kartet, men poenget er at den mobile arbeidsstyrken er ekte, den er der ute og med mindre selskapet ditt har et solid program for å forstå hvordan det påvirker forretningsprosessene dine - og jeg snakker veldig spesifikk teknologidrevet data- drevne prosesser - hvis du ikke forstår hva det er og ikke klarer det gjennom en IT-infrastruktur og en prosess og et styringsperspektiv, vil du få alle slags problemer.
Så, der er iPhone. Jeg husker da den sugeren kom ut, det virker som en million år siden. Men det var bare sånn, 2007 eller '08? Det var ikke så lenge siden at vi ikke hadde iPhones, og selvfølgelig formfaktoren bare endret teknologi fundamentalt, og virkelig muliggjorde den mobile arbeidsstyrken. Og jeg husker selvfølgelig den gangen iPad kom ut og deretter iPhone, omtrent på samme tid. Jeg kan ikke huske hvilken som var først, men iPad var egentlig en av de mest betydningsfulle endringskreftene for enterprise IT, muligens siden mainframe. Og årsaken er fordi ærlig talt, veldig mange ledende ansatte, C-suite-folk fra store organisasjoner, likte det rett utenfor flaggermusen. Og sa: “Jeg vil ha det. Jeg tar det med til å fungere. ”Vel, tenk på det - plutselig måtte IT snu og takle problemet som de sannsynligvis ikke ønsket å håndtere, som handlet om alle disse nye enhetene.
Så nå, hvis du hadde iPads - vel, hvordan vever du det inn i matrisen? Hvordan opprettholder du styresett over det? Dette er virkelig store utfordringer, og den gamle iPad og iPhone var virkelig en enorm forstyrrende styrke innen IT og IT-styring for mange store og små organisasjoner. Så vi har fortsatt dette spekteret av utfordringer og fordeler som spenner over så bredt utvalg som du kan forestille deg, med mobile enheter. Og selvfølgelig forandrer de seg, ikke sant? Så nå er det ikke bare BYOD, det er BYOA mange ganger, hvor ledere og fagpersoner tar med seg sitt eget apparat. Vel, vi pleide å kalle det "skygge IT", ikke sant? For de av dere i den eldre generasjonen husker du kanskje de gamle radioprogrammene, de hadde radiodrama, og en av dem var Skyggen - “Hvem vet hva ondt lurer i menneskers hjerter? Skyggen vet. ”Og det husker jeg fordi jeg var liten. Vel, skygge IT flirer overalt i disse dager; alle gjør det.
Så dette er en virkelig utfordring for IT-ledelse og forretningsprosessstyring, alle driftsfolk. Du vil kunne utnytte mobile enheter, men du vil kunne knytte det tilbake til systemene dine, og det er mange rare, små problemer som kommer inn. Ikke minst er den visuelle opplevelsen og den tilknyttede funksjonaliteten du får når du bruker en mobil enhet. Og alle dere som har brukt flere enheter som en iPad, kontra en bærbar PC, kontra et skrivebord, kontra noen av de nyere mobile smarttelefonene som kommer ut, etter å ha opplevd det faktum at funksjonaliteten ikke fungerer helt riktig, og dette er et reelt problem. Faktisk burde nettleserkrigene forberedt oss på dette, fordi nettleserne alle gjør ting litt annerledes, også. Og det er en annen stor utfordring for ikke bare design, ikke bare utseendet og preget og den slanke naturen til applikasjonen du bruker, men den faktiske funksjonaliteten. Hvordan får du rullegardinmenyen til å velge hva du vil ha på den enheten? Det er en stor avtale.
Så det er det vi skal snakke om litt i dag, og vi kommer til å høre fra Robin og Bill Ellis, som jeg nevnte, som er en ekte ekspert på dette feltet. Så dette er en av de store sakene folk har - det er bare at darn-variasjonen, og det er ingen metode for å kunne jobbe på tvers av plattformer. Du har fått Samsung og Apple stort sett til å lage disse tingene, men det er alle slags ting - det er så mange enheter! Jeg så nylig at iPhone vant i forhold til salg, og jeg ble sjokkert over hvor lavt antallet var - det var som om jeg ikke engang var 20 prosent! Og de var nummer én, noe som betyr at det bokstavelig talt er score - om ikke hundrevis - av enheter der ute som kan brukes. Vel, du kan bare forestille deg hvordan IT-avdelingen føler om det, og selvfølgelig endres det spekteret av teknologier; det blir mer mangfoldig av dagen.
Alt endrer seg, vi har alle slags ting som skjer - containere, bare for å kaste en annen skiftenøkkel i verkene her. Og så har vi selvfølgelig mangfoldet i arbeidsstyrken. Mange årtusener, de er bare veldig forskjellige når det gjelder preferanser, hvordan de bruker teknologi, hva de er villige til å vade gjennom, og hvor raskt de kan finne ut av ting. Vanligvis er det raskere enn med oss gamle tidtakere, men ikke desto mindre alt som må kartlegges til dine on-prem systemer, eller i det minste opp til skyen. Og det er en stor, stor utfordring.
Og med det skal jeg overlevere det til den uvurderlige Dr. Robin Bloor. Robin, ta den bort.
Robin Bloor: OK, takk for den korte introduksjonen. La oss snakke om mobil. Det var ikke spesielt opplagt - Eric refererte til introduksjonen av iPhone - det var ikke spesielt opplagt da iPhonen kom nøyaktig inn i det dette forkynte. Jeg tror det ble tydelig da iPad kom inn at vi faktisk skulle ha en ganske mangfoldig mobilverden. Jeg er en slags Apple bigot, egentlig, så jeg tenker ikke virkelig med tanke på Android, men selvfølgelig, selv om Apple gjør flertallet på lang vei, vil den store fortjenesten både fra putemarkedet og fra telefonmarkedet, den har ikke tallene lenger, noe som er litt interessant. Og det betyr at det vil være nye enheter, bortsett fra noe annet, folk kommer til å ta dem opp og de vil selge inn millionene. Så det skaper et veldig mangfoldig miljø, som du kanskje trenger å gå gjennom.
Vitsen her om "Jeg vil spørre Siri hvor faen vi er hvis jeg kunne få et signal." Det som gjør at mobile enheter er litt forskjellige, er at stasjonære PC-er er tilkoblet hele tiden. Og mobile enheter er ikke nødvendigvis tilkoblet, og de er ikke nødvendigvis døgnet rundt, fordi folk kan slå dem av. også kan du få dem til fly og sånt, og derfor er det en annen type enhet enn noe du noen gang har hatt før. Jeg vil påstå at mobiltelefonen faktisk er den virkelige personlige datamaskinen, for det er den du har med deg hele tiden. Det er den definerende menneskelige mobile enheten. Nettbrettet er litt annerledes; det er en slags rare situasjoner, at når du tenker på det, at det på en eller annen måte er mer enn en funksjonell type mobilenhet.
Uansett hva det vil si å være mobil. Internett endret seg. Vi la ikke merke til at det skjedde - jeg la ikke merke til at det skjedde - men i dag 80 prosent av internettaktiviteten kommer fra mobile enheter, og det er et ekstraordinært tall når du tenker på det. Men 47 prosent av de 80 prosentene er nettbretttrafikk. Det er mulig å tilby de fleste applikasjoner i en mobil innstilling. Med andre ord, hvis du har applikasjoner som allerede eksisterer, og du vet at de er tilgjengelige på skrivebordet, kan du sannsynligvis sette dem på en mobiltelefon, men det er åpenbart begrensende faktorer. Formfaktor og tastatur er ett av dem. Nettbrett i seg selv er, i følge Microsoft og Apple begge, gradvis til å erstatte mobile PC-er. Og de har spesielle bruksområder i visse områder, fordi de er mer robuste.
Noe av det jeg husker at jeg snakket med IT-folk i helsevesenet, var det faktum at før nettbrettet eksisterte, hvis du gikk inn i et miljø som var en isolasjonsavdeling, vet du, du måtte ha enhetene dine som du tok i du, måtte faktisk desinfiseres på en eller annen måte. Det er veldig enkelt å gjøre det med et nettbrett, det er slett ikke lett å gjøre det med det de pleide å ha, som var stasjonære maskiner som var mobile i kraft av å være på en tralle og plugget inn i miljøet. De pleide å være nødt til å holde seg i slike miljøer, eller gå gjennom en ekstraordinær type desinfeksjon som blir tatt ut av disse miljøene. Og vi tenker ikke mye på disse miljøene, med mindre vi jobber i disse miljøene. Men nettbrettene og mobiltelefonene har gjort det å jobbe i de miljøene egentlig ganske naturlig å være koblet sammen og jobbe i disse miljøene.
Og når statistikken som Eric satte inn 1, 7 milliarder, tror jeg det var, mobilarbeidere innen 2020. Er jeg en mobilarbeider? Jeg tenker sånn at det er, jeg er en mobilarbeider i den forstand at jeg noen ganger jobber utenfor kontoret, og når jeg gjør det, skal jeg jobbe på et nettbrett eller gjøre ting på en mobiltelefon. Så når du faktisk ser på det og tenker på det, er det sannsynligvis på grunn av folk som bare vil bruke mobile enheter for arbeidsstokken, så folk som faktisk beveger seg rundt. Uansett kan du tenke nå når det gjelder tre typer brukere: stasjonære brukere, nettbrettbrukere og telefonbrukere. Og de trenger forskjellige bruksområder. Og det er grunnen til å nevne det.
Kamera og stemme er nå en iboende del av mobile enheter, men de er også en iboende del av stasjonære maskiner. Men de brukes på forskjellige måter på mobile enheter, og de har forskjellige grensesnitt på mobile enheter. Og hele karakteren til hvorfor du bruker det, er forskjellig på en mobil enhet. Så hvis du bygger mobilapplikasjoner, bygger du ikke den typen applikasjoner du pleide å bygge, av mange grunner - mange av dem var på det lysbildet. Så hvis du var en virksomhet som allerede på en eller annen måte bygde applikasjoner som kjørte på nettsteder, er spørsmålet, bør de også være mobile applikasjoner? Og denne lysbilden ser på det. En webapplikasjon, du kan gjøre mer på det, ganske enkelt fordi de er bygget på en eller annen måte, de er bygget uten å bry seg om formfaktoren, så folk vil bygge en webside som du ikke kan bruke, eller du kan ikke lett bruke på en iPhone eller en Android-enhet, som kanskje bare kan brukes på et nettbrett, men selv på et nettbrett er kanskje ikke spesielt bra. Normalt vil det være OK.
Eller du kan bygge en mobilapp. Hvis du bygger mobilapper, er det et applikasjonsprogram på forskjellige nedlastingsbutikker, og den typen driver ned motstanden. Hvis du ser på min bestemte iPhone, er den bare full av applikasjoner som jeg ikke ser ut til å bli kvitt; Jeg sletter dem, men de ser alltid ut til å bli lastet ned igjen på en eller annen merkelig måte. Jeg vet tydeligvis ikke hvordan jeg skal administrere en iPhone ordentlig. Men du vet, du ender opp med bare en mengde applikasjoner, og det gir ingen mening. Jeg har mer, jeg mistenker at jeg har flere applikasjoner på iPhone-en enn jeg har fått på skrivebordet, noe som er bisart når du tenker på det. Mobilapper er en lakmus-test for å lykkes. Det er litt interessant at noen nettbedrifter - Yelp er en av dem - gjorde det veldig bra ved å lage en app og få folk til å laste den ned. Og det ser ut til at områdene der det var rimelig god suksess, faktisk var i finanssektoren; det er banker, men også e-handel og selskaper som det, fordi folk liker å kunne handle ting mens du er på farten. Matapplikasjoner, så ikke bare på jakt etter restauranter, men også lage oppskriftsider, de gjorde det veldig bra med tanke på apper.
Og mange mennesker gjorde det ikke spesielt bra i det hele tatt, og det er grunnen, jeg tror det meste er at det bare er så mange apper du noen gang blir vant til å bruke, og hvis du bare bruker en app en gang noen få dager eller så, så glemmer du det. Hvis det ikke har en stor personlig verdi for deg, glemmer du den slags. Så det er vanskelig å lage en mobilapp som er tilgjengelig i generell forstand, men tydeligvis kan du opprette dem for ditt eget personale og bruke dem i organisasjonen. Mobilapper har veldig store utviklingskostnader, og det er flere årsaker til det. En av grunnene til det er at du faktisk peker på et tydelig forskjellige antall enheter.
Og du kan få utviklingsmiljøer som vil målrette mot flere enheter, men noen applikasjoner, spesielt når du ser på sikkerhet, virkelig må du gjøre koding for selve enheten. Du ville skrevet annen kode for iPhone eller Android-miljøet. Kanskje annerledes. Noen ganger refererer du til maskinvarefunksjoner. Så den generelle mobilappen, ja, kanskje det er utviklingsprogramvare der ute som du kan bygge en som er slags hybrid og vil spasere over de fleste målmiljøene. HTML5 gjør det mye mer mulig enn det noen gang var før. Men du får også denne situasjonen der noen apper faktisk ikke kan gjøre det; det betyr at du faktisk gjør det samme arbeidet flere ganger for hver enhet du målretter mot, og det kommer ikke til å stoppe folk som påstår at de har rett til å ta med sin egen enhet; det kommer ikke til å gjøre noen forskjell for det, så du kan ikke virkelig komme deg rundt det.
Angivelig indikerer analyse av mobilapper at de driver mer salg, ikke sant? Og dette er en merkelig type nettsted og mobilappen som, om du vil, komplement. Appene driver mer salg. Nettstedene er flinkere til å hente nye kunder. Apper er flinkere til å beholde kunder som du allerede har hentet. Kunder bruker veldig mye mer på nettsteder enn de gjør på apper, men kundene bruker oftere på apper. Og det er en veldig merkelig ting, og som taler til det faktum at hvis du skal bygge noe, så trenger du sannsynligvis en nettinkarnasjon og en inkarnasjon av en mobilapp, hvis du forventer at den skal brukes mye. Og det er på en eller annen måte det er en dramatisk utgift å legge til et programvareprosjekt, som i alle fall kan gjøre ganske mye annet.
Som en generell idé er et nettsted en katalog, og en app er en lojalitetsmaskin. Utviklingen av mobilapper - og dette er bare for å slags bryte problemet ned - forskjellige utviklingsmiljøer, forskjellige problemer med tanke på maskinvare, forskjellige prinsipper for design av brukergrensesnitt og evne. Du må ha offlinefunksjonalitet - fordi en mange apper folk forventer å kunne bruke dem hvis de er koblet fra - de vil ikke miste dataene; noen av dataene må lagres lokalt. Du bygger en annen app enn du kanskje bygger, la oss si for skrivebordet. Og så har du det mobile back-end problemet, det vil trenge å være mellomvare der, det vil være sikkerhetsprosedyrer der. Det er sannsynlig at det kommer til å være en serviceorientert arkitektur i bakgrunnen, der du strikker sammen forskjellige ting. Og hva dette sier er at du ikke bare tar noen team som er vant til å utvikle applikasjoner på serveren og sånt. Kaster du en mobil, trenger du virkelig mobilutviklere. Og folk med mobilerfaring.
Uansett, etter å ha sagt det, er det bare en ting til å si - fremfor alt mobilapper er i de fleste tilfeller et kundepunkt, så de må være veldig gode, fordi en kunde vil dømme selskapet på bakgrunn av mobilen erfaring, eller det vil påvirke vurderingen deres. Og i noen tilfeller er mobilappen, som jeg nevnte, faktisk det som er bestemt av suksess; det kan være tingen som virkelig gjør en organisasjon. Og selvfølgelig kan det være en fuktig squib også.
Og når det er sagt, skal jeg føre ballen tilbake til Eric.
Eric Kavanagh: Fint, og jeg overlater det til Bill. Bill, hvis du vil gå til hurtigstart der og dele skjermen din?
Bill Ellis: Ja. Her?
Eric Kavanagh: Det øverste venstre hjørnet.
Bill Ellis: Ja. Takk for instruksjonene, jeg setter pris på det. Robin, jeg likte diskusjonen din, den var morsom. Jeg har jobbet i et virtuelt team i 18 år nå, så jeg tror jeg kan regne meg selv som en del av den mobile arbeidsstyrken. Noen ganger bekymrer jeg meg for at jeg kommer til å se, hvis jeg har en funksjon etter arbeid, må jeg ofte kle meg for å gå til den. (Ler) Og jeg begynner kanskje å miste perspektivet på hva “kledd” er, så i alle fall. (Ler) Med det, la oss gå i gang og komme i gang. Jeg vil bekrefte at kanskje Eric bare kunne kime inn og fortelle meg, kan du se skjermen min OK?
Eric Kavanagh: Ja, ser bra ut.
Bill Ellis: OK. Så jeg heter Bill Ellis, jeg jobber med IDERA på Precise-produktlinjen, og vi skal snakke om muliggjør mobilitet. Og vi snakker virkelig om å måle det, og sørge for at det fungerer til din tilfredshet. Et av de store poengene der, var at det er noe folk slags samhandler med, med selskapet ditt. På en måte er det veldig intimt - telefonen ligger rett i noen og så inntrykket, hastigheten, gjør stort inntrykk for alle brukerne.
Så dette var en kundeopplevelse jeg trodde jeg skulle dele. De hadde fått live, det gikk ikke bra. Og fordi den innledende belastningstesten ikke helt avslørte endringer i den underliggende applikasjonsinfrastrukturen, og det er noe av det jeg liker å understreke med mobil, enten applikasjon eller HTML5, det er også mye teknologi som er avhengig av. Fra og med nettverket, på webserveren, i forretningslogikken, i meldinger, og hvis de kjøper, vet du, en betydelig forretningstransaksjon, samhandler de med journalsystemet.
Og ironisk nok møtte vi på et par nettverksproblemer, da vi kom i gang, så alt dette er veldig relevant selv for å levere dette webinaret. Og så kan du ha ett program, minst seks teknologier, mange sluttbrukere, og det er veldig vanskelig å svare på selv de enkleste spørsmålene. Har en sluttbruker et problem? Hva er problemet med en applikasjonsstabel, hvilken kode forårsaker problemet? Og det er faktisk ikke trivielt å få tak i disse tingene.
Nå, hva vi skal gjøre, er at vi skal ta en titt på noen målinger som ble gjort på et sted, for å hjelpe deg med å forstå hvor problemer er innenfor applikasjonsstabelen. Og det vi ser på her er en graf, der Y-aksen er responstid, X-aksen er tid over dagen. Og stabellinjen er en måling av hvor sluttbrukertransaksjonene bruker tiden sin. Og slik at du på en måte får en fin trend her, og så går den opp og opp og opp. Og det er i utgangspunktet avgrensningen av overgangen, og så hvis du ser på stapeldiagrammet, kan du begynne å se at det er mange problemer i J2EE-nivået. Du ser også problemer i webserver-nivået, og så er det noen ganske store heiser, faktisk også i databasetrekket.
Og nå, når vi har identifisert at det er flere nivåer, med flere problemer, må vi gå litt lenger for å finne ut nøyaktig hva som skjer, for å få en intelligent respons på dette nye bruksmønsteret og dette veldig sakte, vi snakker om fire eller fem X tregere ytelse. Og en av de første tingene vi vil gjøre er å si: "Dette er en transaksjon, " og så har vi sett på omfanget på venstre side av alle transaksjonene, og de kan, rådgivning, det er veldig enkelt å se på svartidslinjen for svartid for å i utgangspunktet se at du ser i den samme klientwebserveren Java for visse transaksjoner mer enn andre, databasetid. Men det er virkelig over hele linjen når det gjelder alle transaksjoner.
Og dette ser på brukere, og så begynner du å få, dette er en global distribusjon, så du ser på de viktigste kontinentene i verden, så det er alle brukere, alle lokasjoner. Dette er et globalt problem, det skjer, så det begynner å isolere seg, det er ikke en eller en bestemt gruppe brukere - det er noe som mer skjer på datasenterets side. Og så begynner vi å diagnostisere, vel, hvor i dataene? Hvilke applikasjonsnivåer? Og så begynner vi å se på at gjennomsnittlig responstid bygger seg opp, også lagvis over det med antall henrettelser, for å få en ide om skalering. Dette er veldig interessant - den nedre halvdelen viser faktisk historien på lengre sikt, og du kan se veldig høye tilgangstall, men den andre siden av det er antallet samtidige forbindelser er relativt lavt. Etter at vi gikk over til en mobil HTML5-applikasjon, fordobles antall tilkoblinger mer enn mye mindre - vi snakker om størrelsesorden - det er 100 ganger mindre tilganger, så vi skaler ikke. har vi minst dobbelt så mange forbindelser til det vi hadde hatt tidligere. Så vi begynner å forstå hva som er de nye kravene som mobilapplikasjonen stiller til den underliggende infrastrukturen.
Så la oss gå enda lenger inn, fordi vi må isolere der problemer oppstår. Og så, her, ser du i utgangspunktet på slags ting som skal opp, og vi trengte virkelig ikke denne søylediagrammet her for å si at vi ikke møter SLA-ene våre, men vi kan lett se det i den øvre grafen. Men vi har fått en sekundær bekreftelse når det gjelder utførelsestelling for SLA-overholdelse. Nå, her, skal vi faktisk begynne å se på låsing, og dette er innenfor - dette skjer WebLogic, men innenfor forretningslogikknivået. Og du kan se her, og dette kan være litt vanskelig å lese, men du presser på 31 000 låserverv for en samlet låsetid på 12 timer, 30 minutter. Så dette er helt klart et enormt problem.
Nå viser låspåvirkningen at det alltid er noen avledning av 80/20 regelen. Det er virkelig en metode, en gruppe metoder som virkelig forårsaker problemene. Nå begynner vi å isolere problemer innenfor et bestemt nivå. Så vi kommer inn litt lenger, og her er meldingssystemet. Og vi begynner å se dette, over tid-grafen som jeg sirkler øverst til venstre, kan du se at den grove responstiden går opp, og den rosa, nøkkelen, dette viser faktisk kø og det er faktisk en veldig annen kø som skjer, som blir presset opp, på grunn av antall tilkoblinger. Og så gjør meldingssystemet mye mer arbeid; det er mye mer - hvis du lager en analogi med den dagligvaren, er det mye mer vogner i hver bane ved kassen - og det er det som presser køen, og du kan se det tydeligst i domenet. Hvert av domenene ser veldig, veldig høy kø.
Så langt har jeg identifisert låsing i WebLogic, jeg har identifisert kø i meldingssystemet, og dette er tilfeldigvis smoking. Og det, det vi ser på her, er en lignende type analyse, men vi ser på utførelsestilstander i journalsystemet. Og dette er tilfeldigvis henrettelsestilstander i Oracle. Grunnen til at vi fokuserer på tid er at tiden har to utmerkede egenskaper. Nummer én: det er slik sluttbrukere og applikasjoner opplever ytelse. Nummer to er at det måler ressursforbruk. Og slik vil den automatisk identifisere hvor flaskehalsene er. Og så kan jeg se her, i databasetrinnet, at jeg har ekstra I / O-tid, så jeg stresser lagringsundersystemet. Hver lag er avhengig av nedstrøms nivå, så databasen er avhengig av lagring. Jeg kan også se at innen databasetiden holder jeg på med låsing. Så jeg trenger å bli litt mer granulær før informasjonen blir litt mer brukbar. Og så, la oss gå inn, skrelle løken igjen.
Nå, dette er faktisk et blikk på utførelsestellingene, Y-aksen i dette antallet, dette er i tusenvis, du ser på 9000, ni millioner, og så utførelsesantallet går også opp og opp og opp. Så den nye mobilitetsapplikasjonen stresser applikasjonen på en rekke måter. Låsing, bare for å oppsummere: låsing på netttrinn, kø i meldingssystemet, ekstra utførelsesantall på databasesystemet, ekstra I / O, ytterligere låsing i databasetrekket. Så vi er, jeg påvirker faktisk hvert nivå innen applikasjonsspesifikasjonen. Og så er det veldig viktig å kunne ha beregninger fra alle nivåer i applikasjonsstabelen. Her deler jeg faktisk databaseaktiviteten i program, og jeg kan se at jeg virkelig har fått to programmer: den turkise fargen kartlegger applikasjonslåsen. Og så, denne, distribusjonsserveren som applikasjonslås, appen, dette er mobildelen, denne har også applikasjonslås. Og du kan se der en rekke av disse er flaskehals på selve lagringen.
Nå får jeg, skrelle løken tilbake for å se hva jeg kan gjøre på hvert eneste nivå. Og grunnen til at jeg gjør dette er at mange ser på dette fra et kapasitetsplanleggingssynspunkt. Og de fleste av skytjenestene, de snakker om utvidelse av servere, CPU og minne. Den andre siden av mynten er like viktig, det er å bruke programkode som utfører og driver forbruket av disse ressursene. Og når du vet om programkoden, kan du nå adressere kapasitet ved å behandle effektiviteten. Så, du har begge sider av den samme mynten, og den gir IT-fagfolk flere alternativer for å løse problemet. Det er ikke bare å legge til flere servere, det er også hva vi kan gjøre for å rydde opp i tingene og fungere mer effektivt? Den gamle "Jobb smartere, ikke hardere."
Så her kan vi faktisk, Oracle har en fin ting som heter Modules and Actions, der du faktisk kan begynne å dokumentere koden, og slik at du også kan undersøke ting på en annen måte, som her, applikasjonslåsen som vi så? Vel, det kom inn via utgiftsarkkoden, den kom også inn via distribusjonsserveren, og så dette er de to viktigste driverne for den nye låsen. Og den nye lagringen kommer gjennom online-systemet, og så begynner du å bygge en profil, der driverne er for dette ekstra ressursforbruket. Det er en annen ting å kunne identifisere driverne i den underliggende koden. Og så å gå inn på dette, tror jeg at vi så på dette utgiftsarket, og at vi går inn her.
Når du ser på de underliggende objektene som blir utøvd, begynner du å se denne meldingsloggen. Vel, hver gang de sender meldinger - og vi så at det går opp med flere - berører vi faktisk denne meldingsloggtabellen, og du kommer til å se om et øyeblikk at det faktisk forårsaker mye av låsen i database tier. Så disse nye bruksmønstrene har stor innvirkning opp og ned på applikasjonsbunken. Nå på høyre side er SQL-koden, og så dette er faktisk applikasjonskoden, og vi sporer hva SQL-setninger gjør etter utførelsesstatus. Og så er det veldig enkelt gjennom fargekodingen å se hvilke SQL-setninger som er involvert i disse låsene. Årsaken til at dette er veldig viktig, er at hvis du går til DBA, og du sier: "Hei, vi tror det er et problem på databasenivå." De kan bare se på databasen og det kan se ganske så ut det løp i går.
Men når de kan korrelere måten applikasjonen bruker databasen på, kan de identifisere de nøyaktige SQL-setningene de bør fokusere på, og så kan de komme inn på noen av de avanserte praksisene, se på utførelsesplaner og alle disse tingene at de kan finpusse, for å gjøre opptakssystemet kjørt mye raskere. Og så, den korrelerende tvilen til koden, er det veldig viktig for at teknologiekspertene skal kunne løse og avhjelpe underliggende problemer. Nå, her, snakket vi også om lagring - her ser du antall fysiske avlesninger, du kan se når det skjedde, og dette begynner å komme inn i maskinvarearkitekturen, fordi når du planlegger å utvikle et system, er en av tingene du kanskje velger å gjøre er at du kan velge forskjellige typer lagring, og de har en veldig annen utgiftsprofil. Og i visse tilfeller vil det være en god mening å oppgradere og betale for flash-lagring; hvis jeg gjør mye mer tilfeldig lesing, så vil flash-lagring virkelig lønne seg for meg.
Og det er den overordnede meldingen om at med en ny applikasjon stilles nye krav til systemet, og den underliggende applikasjonsstabelen må utvikles for å imøtekomme disse behovene. Og du vil også se på hva disse behovene er, og kan koden finjusteres for å gjøre den mer effektiv? Og til slutt, ned i CPU-en, kan du se på cutover-perioden, vi hadde kjørt på omtrent 10 prosent, og når vi en gang med den nye koden, er vi på 4X, nå er vi på 40 prosent, og dette er veldig viktig for fysiske så vel som virtualiserte omgivelser for å sikre at du har tilstrekkelige serverressurser til å oppfylle applikasjonens behov. Og så, her er bare et mer nærbilde, slik at du kan se noen av disse tallene litt på forhånd. Interessant på servernivå hadde ikke minneforbruket endret seg så mye, men antallet CPU-sykluser som kreves hadde bestemt.
Og dette er i utgangspunktet bare en oversikt over å se på utgiftsrapporten, se på skaleringen, det faktum at antall henrettelser faktisk gikk ned, men henrettelsestiden gikk opp. Og det viste at under mobiliteten hadde kostnadskomponenten i applikasjonen virkelig problemer. Og det vil definitivt ha en brukereffekt på ting, fordi hvis du ikke kan gjøre jobben din, vil folk i utgangspunktet bare slutte å bruke mobiliteten. Og det fine med mobilitet er at det virkelig styrker arbeidskraftens produktivitet, og det er veldig bra for lønnsslipper og så videre, så du vil definitivt at den skal rulle. Nå ser vi på det samme her, bare fra et stedssynspunkt, så det er Europa og Midt-Østen, Asia VPN-forbindelser og deretter hovedkvarteret. Og USA samlet. Så vi tror at en måte å få verdifull informasjon på hvert nivå av applikasjonsstabelen er gjennom den nøyaktige produktlinjen.
Jeg skal bare veldig raskt, Robin og Eric, jeg er ganske raskt bare for å gi en oversikt over hva Precise gjør, og hvorfor det er designet slik det er designet. Og hva skjer hvis sluttbruker prøver å gjøre noe, det er mye teknologi i datasenteret, sluttbrukeren virkelig ikke bryr seg om, de vil bare gjøre jobben sin. I mellomtiden har du mange mennesker innen IT, velment, veldig smarte, men de er ikke engang klar over et problem før denne sluttbrukeren rapporterer, hvis de rapporterer. Og så mange ganger dette kommer til å starte en veldig kostbar og til slutt frustrerende prosess, der folk ser på en delmengde av applikasjonsstabelen, men det er veldig vanskelig å svare på de grunnleggende spørsmålene om hvem, hva, når, hvor, hvorfor.
Så det vi tror er ved å måle sluttbrukertransaksjoner som starter i deres enhet, gjennom nettverket, på webserveren, i Java, og fange opp den informasjonen vi kan svare på spørsmålene til hvem, hva, når, hvor, hvorfor, gi anbefalinger, men sannsynligvis er det viktigste å fullføre tilbakemeldingssløyfen. Vi trenger alle tilbakemeldinger for å forbedre oss, det er den eneste måten du vet at noe går galt. Ved å ha historien satt inn i et sentralisert depot, gir det ett ark musikk for alle å lese fra. Og slik blir det veldig enkelt å finne ut hvor problemer er, så nok en gang handler designet om å måle sluttbrukertransaksjonen; dette kommer til å identifisere langsomme transaksjoner, segmentere det, dette kommer til å fortelle hva teknologien er et problem, og deretter gi et ekspert syn på hvert enkelt nivå, slik at du kan finne ut hva som skjer. Precise kommer til å gi både læring og rapportering og dashbord for alle interessenter, enten du bare vil ha oversikt, eller om du vil ha et dypt teknologisk syn på hva som skjer.
Hva kan skje, som en dag i livet, enten kan du som IT-spesialist ringe en sluttbruker, eller noen ganger kan en sluttbruker ringe deg. Logg deg på Presise, du kan fokusere igjen, 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 kjøretransaksjoner, du kan få opp en meny for å identifisere en bestemt sluttbruker, og på denne måten har IT muligheten til å adressere de spesielle sluttbrukernes problemer. Og slik at du kan se nøyaktig når de var opptatt, kan du se at de brukte innholdsstyring du kan fokusere på den transaksjonen, og deretter kommer Precise til å gi deg en analyse av den transaksjonen.
Prosenten på slutten er lagt til med prosent, Presis, og som forteller deg hvor mye tid, men en prosentandel av tiden, brukt på det individuelle trinnet, ned til individuelle SQL-setninger, dette er konteksten. Og en av tingene vi sier er at alle har verktøy, men få butikker har kontekst. Og kontekst gjør det mulig for Java-administratoren å fokusere på applikasjonskoden, DBA for å identifisere som i dette tilfellet den aktuelle SQL-setningen. Og med den informasjonen gir den dem mye mer synlighet på hvordan de kan løse den underliggende årsaken til den aktuelle transaksjonen som påvirket den aktuelle brukeren. Så, du virkelig laser fokusert på årsaken. Og du kan analysere SQL-setningen, hvor brukte den tiden sin, vel, utførelse? Og derimot mange verktøy som Enterprise Manager bare for å velge dem. De er store, de kan ta det. De ser på ting fra et forekomstperspektiv, og det er ikke nok fokus egentlig for å komme inn i disse applikasjonene.
Vanligvis vil dine OLTP-mobilitetsapplikasjoner være lite latens, høy gjennomstrømning, så det å fokusere på topp ti-listen, det er en start, men den er virkelig ikke god nok for denne typen applikasjoner. Og den andre tingen er at spesielt for internt vertsbaserte applikasjoner, er identifikasjon etter bruker-ID veldig viktig, fordi det ikke bare handler om applikasjonen og infrastrukturen, det handler også om hvordan sluttbrukerne bruker applikasjonen. Og sluttbrukerne har vanligvis mye bedre oppførsel når du er i stand til å identifisere dem. Og så er dette bare en slags skjerm med forskjellige transaksjoner og klientopplevelsen, og deretter delsegmentert, (ler) jeg antar at jeg har snakket litt lenge. Litt trøtt her ute; Jeg skal pløye fremover.
Her ser vi på et dashbord som vi har satt sammen som skulle vise varsler og deretter vise forskjellige nivåer av applikasjonsbunken. Her er webserverne dine, og du kan bekrefte utførelse av responstid at ting er belastningsbalansert. Du kan se på nettlesertilganger, du kan se på beholde bruk og søppelsamling, sørge for at du har det fine sagtannmønsteret, at du ikke har en minnelekkasje, etc. Og ideen med dette er å gi litt litt av et mer teknisk instrumentbord for hver av komponentene i applikasjonsbunken. Så den nøyaktige produktserien som tilbys av IDERA tilbyr produksjonsovervåking, 24 for 7, veldig detaljert informasjon. Det er ganske enkelt å distribuere dette; du trenger ikke å kartlegge transaksjoner, uansett hva sluttbrukerne gjør. Precise kobler automatisk punktene på tvers av applikasjonsbunken.
Hvis et downstream-nivå ikke er instrumentert, vil Precise gjenkjenne det og gi inn- og ut-tid og anbefale at du instrumenterer downstream-nivået. Og så, det er veldig enkelt slags tid å verdsette; Vi er veldig sterke på databasen, dette er IDERAs slags påstand om berømmelse. Og grunnen til at det er så viktig, er at alle viktige forretningstransaksjoner samhandler med journalsystemet, slik at databasen blir grunnleggende ytelse. Og så de andre verktøyene på markedet, de gjør en OK jobb, men OK er ikke veldig god; du trenger virkelig å vite nøyaktig hva som skjer med SQL-setningene. Og vi gjør mange avanserte ting, som er for mye for dette, som å holde en SQL-uttalelseshistorie og spore utførelsesplaner over tid. Og så, det er et område som vi kan utforske videre, hvis du kanskje er interessert.
Så med det, det er den nøyaktige applikasjonsytelsesplattformen, inviterer vi deg til å be om et ekstra møte gjennom nettstedet idera.com, hvis du har ytterligere interesse for løsningen og temaene vi diskuterte i dag.
Og Eric, med det tror jeg at vi fremdeles er under ledningen, jeg kommer til å gi stafettpinnen tilbake til deg og Robin. Takk skal du ha.
Eric Kavanagh: Nei, det er fantastisk, og jeg elsker innholdet du har satt sammen her, fordi du gjør en fantastisk jobb med å vise hvor komplekst miljøet er under panseret. Og selvfølgelig, hele jobben til Precise, er formålet med Precise å hjelpe deg med å navigere i den kompleksiteten og forstå hva som faktisk skjer og være i stand til å gjøre noen tiltak for å forbedre noe. Og jeg er bare litt forvirret over hvor kompleks det er. Jeg gjetter på at Precise også lar deg identifisere bestemte atferdsmønstre og deretter navngi dem, eller i det minste registrere dem eller bokmerke dem eller noe sånt, er det ikke sant?
Bill Ellis: Ja, en av tingene som kommer til å skje, er at du ikke vil gå etter jakten på halen; du vil ikke bare bruke mye tid på en engangs. Så du vil se på hva som er mønstrene, hva er trendene, fordi det er mye teknologi å administrere. Og en av tingene er å prioritere og kunne rangere, vite hvor du skal bruke tiden din, vite hva som må finslipes. Og du vil også ta en konservativ tilnærming med lavere risiko og lavere kostnader. Du ønsker ikke nødvendigvis å gjøre en kostbar global endring, uten å ha vurdert eller ha en veldig god følelse av å vite at det, dette vil faktisk hjelpe problemet. Så vet hva som skjer over tid, og denne trenden er avgjørende for å ta opp de underliggende problemene på en intelligent måte.
Eric Kavanagh: Det gir full mening. Og hvor stor avtale er virtualisering for å kunne se hva som skjer, og kommer du inn i organisasjoner som bruker containere - bruker du for eksempel Docker? Og hvordan vil det påvirke det Precise kan gjøre?
Bill Ellis: Ja, så ordet “container” kan bety forskjellige ting i henhold til forskjellige leverandører. Og så, vi jobber med VM, nesten alle bruker VMware - jeg anser det som de facto-standarden på dette tidspunktet; Jeg vet at det er konkurrenter der ute. Og vi utvider det vi støtter, men VMware er det dominerende innen Oracle-stabelen. Det er containerdatabaser, og alt dette er veldig viktig for å kunne utvikle systemet ditt veldig raskt. Det er også veldig viktig å vite i et virtualisert miljø når den fysiske verten ikke er i stand til å møte behovene til alle gjestenes containere, fordi hver av dem konkurrerer om ressurser.
Og en av tingene som faktisk skjedde internt jeg ble overrasket over, er at vi faktisk hadde innen IDERA så mange ledige VM-er, men hver av disse inaktive VM-ene bruker ressurser, at de begynte å forårsake et problem generelt for VM-ene som faktisk ble brukte det som var viktig for oss, for å drive vår virksomhet. Og så det var litt av en interessant ting. Nå støtter vi ikke all teknologi under solen; det er en støttematrise knyttet til denne løsningen, og det er noe av det vi ønsker å bore ned for, for et bestemt prospekt eller en bestemt kunde, bare for å sikre at vi kan imøtekomme teknologibehovene og de individuelle teknologiene som deres applikasjonsstabel kjører under.
Eric Kavanagh: Ja, det gir mye mening. Hva er erfaringer fra noen av de store kreftene nå som driver utfordringer på mobilen? Da du og jeg snakket før denne webcasten for et par måneder siden, gjorde du et veldig godt poeng om hvordan bare funksjonaliteten og utformingen av en iPhone eller en hvilken som helst mobil enhet kan være en virkelig utfordring for bedriften, fordi plutselig kan sluttbrukeren ikke finne ut hvordan du kan få en bestemt prosess i arbeidsflyten, ikke sant? Og det, til det punktet, det du muliggjør i utvikling av mobilapper, er at du viser utviklerne hvor problemene oppstår, og så kan du kartlegge det tilbake til hva appen gjør på denne spesielle enheten, eller den aktuelle enheten. Og det er veldig nyttig, ikke sant, for utvikleren, for nå kan de se hva som forårsaker problemet, de kan gjøre noen endringer i appen, for å løse det, ikke sant?
Bill Ellis: Ja, det er slags overlegg av utrolig høye forventninger - alle forventer at alt på en måte bare fungerer, men det er så mye variasjon der ute. Du har alle disse forskjellige smarttelefonene, de har forskjellige skjermdimensjoner, og så har du forskjellige leverandører av kommunikasjon, Verizons, AT & Ts, Sprints, de er bare de populære i USA. Og det er bare så mye variasjon der ute, det er som vel, hvordan pakker du armene rundt alt dette, for å begynne å forstå hvor problemene er? Og så, det er mange beregninger som er tilgjengelige, og en av tingene som produktadministrasjonsteamet vårt har gjort, er å prøve å trekke inn beregningene som er viktigst eller mest nødvendig av IT-teamet, for å kunne ta intelligente beslutninger .
Og så, det er litt av en utfordring, og vi gjør at produktet vårt er som markedet utvikler seg, og vi får tilbakemeldinger fra kundene våre, og det er alltid forespørsler om forbedringer, så "Hei, denne ekstra beregningen vil være veldig nyttig for oss." Så Produktet utvikler seg akkurat som markedet, men hvis jeg måtte si, faktisk Eric, det er virkelig interessant for meg, er det hele forventningene. Folk er som det pleide å være tilbake den dagen folk ventet fem, syv sekunder på at en skjerm skulle rute opp, nå er det som ett eller to sekunder, folk er som "Åh, dette programmet fungerer ikke i det hele tatt!" (Ler)
Eric Kavanagh: Det er morsomt. Det er så sant!
Bill Ellis: Det er sprøtt.
Eric Kavanagh: Ja, det er litt urealistisk. Og jeg tror at kanskje vi begynner å se litt mer realisme rundt det emnet, men det er likevel et faktum i livet at folk har veldig, veldig høye forventninger. Og jeg antar, Robin, jeg tar deg raskt tilbake de siste par minuttene her. Jeg elsket vurderingen din av nettstedet som en katalog og app som en lojalitetsmaskin. Og til det punktet, det vi har snakket om her, er hvordan du kan utviklere av disse appene forstå hva som skjer: Er det brukbart? Er det ikke brukbart? Og hva kan du endre for å justere det? Og til Bills poeng her, bare et sekund siden, har syklustiden for å fikse dette problemet virkelig forkortet seg, ikke sant? Det er bare ikke som det pleide å være - du må ordne det raskt. Eller du vil bare ha et stort frafall i bruk, ikke sant?
Robin Bloor: Ja, det er en hel haug med andre ting som spilles inn i dette, så du har fått denne smidige utviklingen og du har forventninger mange steder nå, at du kommer til å gi ut en ny versjon av noe som er i ferd med å bli utviklet, eller i ferd med å bli endret, hvert par uker. Og det betyr at det gjør når du tenker på det, hvis du tenker på distribusjonsmiljøene, og du tenker på hvor stor stabelen er når du kommer til mobil, har du faktisk flere potensielle enheter på sluttnoden, og så kommer du til å ha mellomvare i midten. Og du kan godt ha under og under det, du kan godt ha databaser. Så det kan hende du berører mange, mange applikasjoner; Det kan hende du berører flere databaser, og det kan hende du gjør veldig komplekse ting når det gjelder sikkerhet. Og det hele må fungere, og forventningen er at det vil fungere rimelig bra.
Og det fantastiske er noen ganger det, men jeg tenkte på dette, er at hvis du virkelig bygger mobile apper som virkelig er nøkkelen til suksessen for selskapet og mange av dem viser seg, er det mange av disse tingene virkelig er. Hvis du gjør mobilt vedlikehold på oljerigger og oljerørledninger og sånt, må det fungere. Konsekvensene av at det ikke fungerer er bare dystre. Og hvis du ikke har denne muligheten til å faktisk kutte applikasjonen og vite hvor ting går galt, fordi det meste er ytelse. Vi har veldig gode testsele i dag, så ja, det er feil og feil kommer seg gjennom. Men mest hvis noe går galt, er det ytelsesproblemet. Og hvis du ikke kan plassere stetoskopet på 18 forskjellige steder, så er det virkelig vanskelig å slå fast hva som går galt. Og du har også nettverket en faktor i dette, og du har også den virkeligheten at en gitt komponent i en applikasjon kan stresses til forskjellige tider av døgnet på grunn av den aktuelle applikasjonens art. Du må ha sofistikerte overvåkingsverktøy hvis du skal gjøre en sjanse med alt dette.
Eric Kavanagh: Ja, jeg må være enig og jeg tror det virkelig er styrken til Precise av IDERA i disse dager. Og Bill, antar jeg bare noen avsluttende kommentarer fra deg? Jeg synes at denne teknologien er fantastisk. Jeg er også klar over at du som bruker av denne teknologien virkelig trenger å forstå kompleksiteten i informasjonssystemer og avhengigheter og være i stand til å finne ut hvor, når og hvordan du syntetiserer all denne informasjonen for å vurdere hva som faktisk skjer. Og det krever et intelligent og trent menneske, og helt ærlig, det er en grunn til at jeg overhode ikke er opptatt av at maskinlæring tar bort jobber. Jeg tror maskinlæring kan være veldig nyttig under en teknologi som denne, for å identifisere vanlige mønstre og deretter komme med forslag til sluttbrukeren om hva som kan skje her. Men hva er noen avsluttende tanker fra deg om å virkelig få bedriften viktigheten av å ha denne typen feilsøkingsevner, og hva bør de vite om det, i tillegg til det du allerede sa?
Bill Ellis: Ja, så Eric, jeg er enig med deg at det er enormt mye kompleksitet. Jeg tror Precise produktlinje ved å fokusere på metrisk tid, at en bruker som kan lese en stabelstangdiagram kan bruke Precise med hell, og jeg vil bare si takk til deltakerne og til deg og Robin for å være vertskap for dagens webinar.
Eric Kavanagh: Du vedder! Og som jeg sa, vi vil være vertskap for dette arkivet i noen tid nå, så føl deg fri til å dele det med dine venner og kolleger; vi arkiverer alle disse webcastene. Jeg sendte en lenke til lysbildene for noen minutter siden, sjekk det gjerne, men god jobb igjen, Bill, i dag. Du kjenner virkelig tingene dine; det er alltid gøy å jobbe med en profesjonell som deg selv. Og jeg tror dette virkelig vil være de muliggjørende teknologiene for den mobile arbeidsstokken! Så takk for tiden din, folkens, vi får tak i deg neste gang, ta vare. Ha det.
