Huis Onderneming En marche! het mobiele personeel inschakelen

En marche! het mobiele personeel inschakelen

Anonim

Door Techopedia Staff, 21 juni 2017

Afhaalmaaltijd: gastheer Eric Kavanagh bespreekt het mobiele personeelsbestand met Dr. Robin Bloor en Bill Ellis van IDERA.

Je bent momenteel niet ingelogd. Log in of meld je aan om de video te bekijken.

Eric Kavanagh: Allemaal goed, dames en heren, het is woensdag 21 juni. Het is 4:00 oostelijke tijd en dat betekent natuurlijk in de wereld van de enterprise-technologie dat het tijd is voor Hot Technologies! Ja inderdaad. Mijn naam is Eric Kavanagh, ik zal je gastheer en moderator zijn voor het evenement van vandaag. Het is een hot topic, het is een grote: “En Marche! Enable the Mobile Workforce. ”En ik pakte niet met opzet de slogan uit de kandidatuur van de heer Macron in Frankrijk. Het was vrij toevallig, dat beloof ik je, maar het is nog steeds behoorlijk spannend. We zullen het daarom hebben over het mobiele personeel en hoe u ervoor kunt zorgen dat die mensen krijgen wat ze nodig hebben en dat ze kunnen doen wat ze goed doen. Veel uitdagingen, veel problemen die er zijn. We zullen deze webcast archiveren voor later bekijken, dus als je iets mist, kun je terugkomen en het bekijken. Deel het ook met je vrienden en collega's.

En ik zou moeten zeggen: wees niet verlegen; de beste manier om echt aangepaste inhoud te krijgen en de informatie die u nodig heeft voor een evenement als dit, is door vragen te stellen. U kunt dus een vraag stellen vanuit het chatvenster of vanuit de Q & A-component van uw webcastconsole. Stuur het op elk moment tijdens het evenement door en ik zal het zeker pakken en aan het einde weven in de Q&A. We gaan een paar presentaties houden en dan horen we van Bill Ellis van IDERA Software. Natuurlijk is onze eigen Robin Bloor vandaag aan de lijn. En daarmee gaan we er meteen in duiken.

Dus ik heb een aantal goede statistieken van RCR Wireless over wat er aan de hand is, en het is echt behoorlijk verbluffend. Ze zeggen dat het wereldwijde mobiele personeelsbestand 1, 87 miljard mensen zal treffen tegen 2022. Dat is meer dan 40 procent van het totale personeelsbestand op de planeet. Dus als je daarover nadenkt, nu ineens waar je vroeger was, in termen van IT-mogelijkheden, in termen van functionaliteit op apparaten zoals computers, waar je 99 procent of meer daarvan had op locatie in je kantoren - dat was zelfs, laten we zeggen 15 jaar geleden, 10 jaar geleden waarschijnlijk 85-90 procent, vijf jaar geleden was het 70 procent? Zoiets? Nu is het helemaal naar beneden, bijna tot 60 procent. En dit is een groot probleem. We hebben dus deze enorme verschuiving gezien in termen van de technologie, de feitelijke tools die mensen gebruiken buiten het kantoor, naar het personeelsbestand.

Nou, hier zijn talloze voordelen aan verbonden. Ik bedoel, letterlijk als je naar de scheepvaartindustrie kijkt, zoals UPS, of als je kijkt naar jongens die naar de booreilanden in olievelden gaan, als je naar een van de verschillende banen kijkt waar het helpt om diepe functionaliteit bij je te hebben onderweg verandert het mobiele personeel alles. Een van de problemen - en we zullen hier wat diepgaander over praten - is dat er een aantal verschillende dingen aan de hand zijn, waaronder diversiteit van het personeelsbestand. Dus in 2020 - ik zag zojuist de statistieken vandaag - zullen er vijf generaties mensen werken. Dat betekent dat je oma en opa krijgt en dan ook mama en papa en ook de kinderen, maar in theorie zul je in wezen overgrootvader en betovergrootvader en betovergrootmoeder hebben. Nu, het is duidelijk niet binnen een bepaalde familie, maar het punt is generatiewijs, je hebt vijf verschillende categorieën van brede individuen in het personeelsbestand, elk van hen heeft zijn eigen neigingen, hun eigen voorkeuren, hun eigen neiging om mee te werken technologie.

Uiteraard zijn kinderen meestal eerst mobiel in termen van hoe ze omgaan met de wereld. En denk eens aan de communicatiekanalen die het hebben veranderd - we hebben het hier onlangs over gehad in een andere show; SnapChat is hoe veel tieners communiceren, ze willen niet eens met je praten aan de telefoon, ze willen gewoon kleine SnapChat-berichten heen en weer sturen. Dat is slechts één voorbeeld in de consumentenwereld van hoe dingen veranderen, en dat zou kunnen worden verspreid over het hele spectrum van technologieën, van functionaliteit, van individu, van bedrijf, van bedrijfsmodel. Het komt allemaal over de hele kaart, maar het punt is dat het mobiele personeel echt is, het is er en tenzij uw bedrijf een solide programma heeft om te begrijpen hoe dat uw bedrijfsprocessen beïnvloedt - en ik heb het over zeer specifieke technologiegestuurde gegevens - van brandstof voorziene processen - als u niet begrijpt wat dat is en dat niet beheert via een IT-infrastructuur en een proces- en een governanceperspectief, zult u allerlei problemen hebben.

Dus er is de iPhone. Ik herinner me toen die sukkel uitkwam, het lijkt nu een miljoen jaar geleden. Maar het was maar wat, 2007 of '08? Het was nog niet zo lang geleden dat we geen iPhones hadden, en natuurlijk veranderde de vormfactor de technologie fundamenteel en zorgde echt voor mobiel personeel. En ik herinner me op dat moment natuurlijk dat de iPad uitkwam en vervolgens de iPhone, ongeveer tegelijkertijd. Ik kan me niet herinneren welke de eerste was, maar de iPad was echt een van de belangrijkste veranderingskrachten voor bedrijfs-IT, mogelijk sinds het mainframe. En de reden is dat, eerlijk gezegd, veel zeer senior executives, C-suite mensen van grote organisaties er meteen dol op waren. En zei: "Ik wil het. Ik breng het aan het werk. ”Denk daar eens over na - plotseling moest IT zich omdraaien en het probleem aanpakken waar ze waarschijnlijk niet mee wilden omgaan, namelijk al deze nieuwe apparaten.

Dus nu, als je iPads had - nou, hoe weef je dat in de matrix? Hoe beheer je dat? Dit zijn allemaal echt grote uitdagingen en die oude iPad en de iPhone waren echt een enorm verstorende factor in IT en IT-beheer voor veel organisaties, groot en klein. We hebben dus nog steeds dit spectrum van uitdagingen en voordelen die variëren van ongeveer een zo breed scala als u zich kunt voorstellen, met mobiele apparaten. En natuurlijk blijven ze veranderen, toch? Dus nu is het niet alleen BYOD, het is ook vaak BYOA, waar leidinggevenden en professionals hun eigen apparaat meenemen. Nou, we noemden dat altijd 'schaduw-IT', toch? Voor degenen onder u in die oudere generatie, herinnert u zich misschien de oude radioprogramma's, ze hadden radiodrama en een daarvan was The Shadow - "Wie weet welk kwaad in de harten van mensen schuilt? De schaduw weet het. 'En ik herinner me dat omdat ik een kind was. Welnu, schaduw IT vervaagt tegenwoordig overal; iedereen doet schaduw IT.

Dit is dus een echte uitdaging voor het IT-beheer en het beheer van bedrijfsprocessen, alle operationele mensen. U wilt mobiele apparaten kunnen benutten, maar u wilt dat kunnen koppelen aan uw systemen, en er zijn veel rare, kleine problemen die een rol spelen. Niet in het minst daarvan is de visuele ervaring en de bijbehorende functionaliteit die u krijgt wanneer u een mobiel apparaat gebruikt. En iedereen die meerdere apparaten heeft gebruikt, zoals een iPad, versus een laptop, versus een desktop, versus enkele van de nieuwere mobiele smartphones die uitkomen, hebben ervaren dat de functionaliteit niet helemaal goed werkt, en dit is een echt probleem. In feite hadden de browseroorlogen ons hierop moeten voorbereiden, omdat de browsers de dingen allemaal ook iets anders doen. En dat is een andere grote uitdaging voor niet alleen het ontwerp, niet alleen het uiterlijk en het slanke karakter van de applicatie die u gebruikt, maar ook de daadwerkelijke functionaliteit. Hoe krijg je het vervolgkeuzemenu om te selecteren wat je op dat apparaat wilt? Dat is een groot probleem.

Dus daar gaan we het vandaag een beetje over hebben, en we gaan horen van Robin en Bill Ellis, zoals ik al zei, die een echte expert op dit gebied is. Dus dit is een van de grote problemen die mensen hebben - het is gewoon de enorme variëteit en er is geen enkele methode om op verschillende platforms te kunnen werken. Samsung en Apple hebben deze dingen meestal gemaakt, maar er zijn allerlei soorten - er zijn zoveel apparaten! Ik zag onlangs dat de iPhone aan het winnen was in termen van verkoop, en ik was geschokt over hoe laag het aantal was - het was alsof, ik denk niet dat het zelfs 20 procent was! En ze waren nummer één, wat betekent dat er letterlijk scores - zo niet honderden - apparaten zijn die kunnen worden gebruikt. Nou, je kunt je gewoon voorstellen hoe de IT-afdeling daarover denkt, en natuurlijk verandert dat scala aan technologieën; het wordt met de dag diverser.

Alles is aan het veranderen, er gebeuren allerlei dingen - containers, gewoon om nog een sleutel in de fabriek te gooien. En dan hebben we natuurlijk de diversiteit van het personeelsbestand. Veel millennials, ze zijn gewoon heel anders in termen van hun voorkeuren, hoe ze technologie gebruiken, wat ze willen doorwaden, hoe snel ze dingen kunnen achterhalen. Meestal is het sneller dan bij ons oldtimers, maar desalniettemin moet alles worden teruggezet naar uw on-prem-systemen, of op zijn minst naar de cloud. En dat is een grote, grote uitdaging.

En daarmee ga ik het overhandigen aan de onnavolgbare Dr. Robin Bloor. Robin, haal het weg.

Robin Bloor: OK, bedankt voor die korte introductie. Laten we het over mobiel hebben. Het was niet bijzonder duidelijk - Eric verwees naar de introductie van de iPhone - het was niet bijzonder duidelijk toen de iPhone precies binnenkwam wat dit aankondigde. Ik denk dat het duidelijk werd toen de iPad binnenkwam dat we eigenlijk een vrij diverse mobiele wereld zouden hebben. Ik ben een soort Apple-fan, eigenlijk, dus ik denk niet echt in termen van Android, maar natuurlijk, hoewel Apple veruit de meerderheid haalt, de grote winst van zowel de padmarkt als de telefoonmarkt, het heeft geen cijfers meer, wat best interessant is. En dat betekent dat er - afgezien van iets anders - er nieuwe apparaten zullen zijn, mensen gaan ze opnemen en ze gaan met miljoenen verkopen. Het creëert dus een zeer diverse omgeving, die u wellicht moet doorlopen.

De grap hier van "Ik zou Siri willen vragen waar we in godsnaam zijn als ik een signaal zou kunnen krijgen." Het ding dat mobiele apparaten iets anders maakt, is dat desktops altijd zijn verbonden. En mobiele apparaten zijn niet noodzakelijkerwijs verbonden en zijn niet noodzakelijkerwijs 24/7 ingeschakeld, omdat mensen ze kunnen uitschakelen. ook kun je ze naar vliegtuigen en dergelijke brengen, en daarom is het een ander soort apparaat dan alles wat je ooit eerder had. Ik zou volhouden dat de mobiele telefoon eigenlijk de echte personal computer is, omdat hij degene is die je altijd bij je hebt. Het is het bepalende menselijke mobiele apparaat. De tablet is iets anders; het is een soort rare situatie, dat als je erover nadenkt, er op de een of andere manier meer dan één functioneel soort mobiel apparaat is.

Hoe dan ook, wat het betekent om mobiel te zijn. Het internet is veranderd. We hebben het niet gemerkt - ik heb het niet gemerkt - maar tegenwoordig is 80 procent van de internetactiviteit afkomstig van mobiele apparaten, en dat is een buitengewoon cijfer als je erover nadenkt. Maar 47 procent van die 80 procent is tabletverkeer. Het is mogelijk om de meeste applicaties in een mobiele omgeving aan te bieden. Met andere woorden, als u applicaties hebt die al bestaan ​​en u weet dat ze toegankelijk zijn op de desktop, kunt u ze waarschijnlijk op een mobiele telefoon plaatsen, maar er zijn duidelijk beperkende factoren. Vormfactor en toetsenbord zijn er een van. Tabletten zelf gaan volgens Microsoft en Apple allebei geleidelijk aan mobiele pc's vervangen. En ze hebben specifieke toepassingen in bepaalde gebieden, omdat ze robuuster zijn.

Een van de dingen waarvan ik me herinner dat ze met IT-mensen in de gezondheidszorg spraken, was het feit dat voordat je de tablet bestond, je naar een omgeving zou gaan die een isolatieafdeling was, weet je, je zou je apparaten moeten hebben die je mee hebt genomen zou je eigenlijk op de een of andere manier moeten worden gedesinfecteerd. Het is heel gemakkelijk om dat te doen met een tablet, het is helemaal niet gemakkelijk om dat te doen met wat ze vroeger hadden, dat waren desktops die mobiel waren dankzij het feit dat ze op een trolley zaten en aangesloten waren op de omgeving. Vroeger moesten ze soort van verblijf in dat soort omgevingen, of een buitengewone vorm van desinfectie ondergaan die uit die omgevingen werd gehaald. En we denken niet veel na over die omgevingen, tenzij we in die omgevingen werken. Maar de tablets en de mobiele telefoons hebben het werken in die omgevingen echt heel natuurlijk gemaakt om verbonden te zijn en in die omgevingen te werken.

En toen de statistiek die Eric 1, 7 miljard noemde, denk ik dat het mobiele werknemers tegen 2020 waren. Ben ik een mobiele werknemer? Ik denk dat het zo is, ik ben een mobiele werker in de zin dat ik af en toe buiten kantoor werk en als ik dat doe, ik op een tablet werk of dingen op een mobiele telefoon doe. Dus, als je daar echt naar kijkt, en daarover nadenkt, is het waarschijnlijk vanwege mensen die alleen mobiele apparaten voor hun personeel zullen gebruiken, dus mensen die zich fundamenteel verplaatsen. Hoe dan ook, je kunt nu denken in termen van drie soorten gebruikers: desktopgebruikers, tabletgebruikers en telefoongebruikers. En ze hebben verschillende toepassingen nodig. En dat is de reden om het te noemen.

Camera en spraak zijn nu een inherent onderdeel van mobiele apparaten, maar ze zijn ook een inherent onderdeel van desktops. Maar ze worden op verschillende manieren op mobiele apparaten gebruikt en ze hebben verschillende interfaces op mobiele apparaten. En het hele karakter van waarom je dat gebruikt, is anders op een mobiel apparaat. Dus, als je mobiele applicaties bouwt, bouw je niet het soort applicaties dat je vroeger bouwde, om een ​​hele reeks redenen - waarvan er veel op die dia stonden. Dus als u een bedrijf was dat al op de een of andere manier applicaties bouwde die op websites draaiden, is de vraag of dit ook mobiele applicaties moeten zijn? En deze dia kijkt daar een beetje naar. Een webapplicatie, je kunt er meer aan doen, simpelweg omdat ze op de een of andere manier zijn gebouwd, ze zijn gebouwd zonder echt om de vormfactor te geven, dus mensen zullen een webpagina bouwen die je redelijkerwijs niet kunt gebruiken, of je kunt het niet gemakkelijk gebruiken op een iPhone of een Android-apparaat, dat misschien alleen bruikbaar is op een tablet, maar zelfs op een tablet is het misschien niet zo goed. Normaal zou het OK zijn.

Of u kunt een mobiele app bouwen. Als je mobiele apps bouwt, dan is er een app-overvloed in verschillende downloadwinkels, en dat soort drijft hun weerstand af. Als je naar mijn specifieke iPhone kijkt, zit deze vol met applicaties die ik niet kwijt kan; Ik verwijder ze, maar ze lijken altijd weer op een vreemde manier te worden gedownload. Ik weet duidelijk niet hoe ik een iPhone goed moet beheren. Maar weet je, je eindigt met een overvloed aan applicaties en het slaat nergens op. Ik heb meer, ik vermoed dat ik meer applicaties op mijn iPhone heb dan op mijn bureaublad, wat bizar is als je erover nadenkt. Mobiele apps zijn een lakmoesproef voor succes. Het is een beetje interessant dat sommige webbedrijven - Yelp is er een van - het buitengewoon goed hebben gedaan door een app te maken en mensen deze te laten downloaden. En het lijkt erop dat de gebieden waar er redelijk goed succes was eigenlijk in de financiële sector waren; dat zijn banken, maar ook E-Trade en dergelijke bedrijven, omdat mensen graag dingen onderweg kunnen verhandelen. Voedselapplicaties, dus niet alleen op zoek naar restaurants, maar ook receptenwebsites maken, deden ze echt, echt goed qua apps.

En veel mensen deden het helemaal niet zo goed, en dat is volgens mij vooral de reden dat er maar zo veel apps zijn waaraan je ooit gewend raakt, en of je maar één keer in de paar dagen een app gebruikt of zo, dan vergeet je het. Als het geen grote persoonlijke waarde voor u heeft, vergeet u het een beetje. Het is dus moeilijk om een ​​mobiele app te maken die in algemene zin toegankelijk is, maar u kunt ze natuurlijk voor uw eigen personeel maken en binnen de organisatie gebruiken. Mobiele apps hebben echt grote ontwikkelingskosten, en dat is een aantal redenen. Een van de redenen daarvoor is dat je eigenlijk op een duidelijk ander aantal apparaten wijst.

En u kunt ontwikkelomgevingen krijgen die op meerdere apparaten zijn gericht, maar sommige toepassingen, vooral als u naar beveiliging kijkt, moeten echt coderen voor het apparaat zelf. U schrijft een andere code voor de iPhone of de Android-omgeving. Misschien anders. Soms verwijst u naar hardwaremogelijkheden. Dus de algemene mobiele app, ja, misschien is er ontwikkelingssoftware die je kunt bouwen die een soort hybride is en de meeste doelomgevingen overstijgt. HTML5 maakt dat veel meer mogelijk dan ooit tevoren. Maar je krijgt ook deze situatie waarin sommige apps dat eigenlijk niet kunnen; dat betekent dat je eigenlijk meerdere keren hetzelfde werk doet voor elk apparaat waarop je je richt, en dat zal niet voorkomen dat mensen beweren dat ze het recht hebben om hun eigen apparaat mee te nemen; het gaat daar geen verschil maken, dus je kunt er niet echt omheen.

Blijkbaar geeft analyse van mobiele apps aan dat ze meer verkopen genereren, toch? En dit is een vreemd soort van de website en de mobiele app, als je wilt, als aanvulling. De apps zorgen voor meer verkopen. De websites zijn beter in het aantrekken van nieuwe klanten. Apps zijn beter in het behouden van klanten die u al hebt opgehaald. Klanten geven veel meer uit aan websites dan aan apps, maar klanten geven vaker uit aan apps. En dat is echt raar, en dat spreekt over het feit dat als je iets gaat bouwen, je waarschijnlijk een website-incarnatie en een mobiele app-incarnatie nodig hebt, als je verwacht dat het op grote schaal wordt gebruikt. En dat is, op de een of andere manier, dat is nogal een dramatische uitgave om toe te voegen aan een softwareproject, dat in elk geval heel wat andere dingen kan doen.

Over het algemeen is een website een catalogus en is een app een loyaliteitsmachine. Mobiele app-ontwikkelingen - en dit is gewoon om het probleem op te lossen - verschillende ontwikkelomgeving, verschillende problemen op het gebied van hardware, verschillende ontwerpprincipes van gebruikersinterfaces en mogelijkheden, je moet offline mogelijkheden hebben - omdat veel apps die mensen verwachten te kunnen gebruiken als ze geen verbinding hebben - ze willen de gegevens niet verliezen; sommige gegevens moeten lokaal worden opgeslagen. Je bouwt een andere app dan je zou kunnen bouwen, laten we zeggen voor de desktop. En dan heb je het mobiele back-end-probleem, daar moet middleware zijn, daar zullen beveiligingsprocedures zijn. Hoogstwaarschijnlijk komt er een servicegeoriënteerde architectuur op de achtergrond, waar je verschillende dingen samenvoegt. En wat dit zegt, is dat je niet zomaar een team neemt dat gewend is applicaties op de server te ontwikkelen en zo. Door ze mobiel te maken, heb je echt mobiele ontwikkelaars nodig. En mensen met mobiele ervaring.

Hoe dan ook, dat gezegd hebbende, nog een ding om te zeggen - vooral mobiele apps zijn in de meeste gevallen een klantcontactpunt, dus ze moeten echt goed zijn, omdat een klant het bedrijf zal beoordelen op basis van de mobiele telefoon ervaring, of het zal hun oordeel beïnvloeden. En in sommige gevallen, zoals ik al zei, is de mobiele app eigenlijk wat bepalend zakelijk succes is; het kan iets zijn dat echt een organisatie maakt. En natuurlijk kan het ook een vochtige squib zijn.

En dat gezegd hebbende, zal ik de bal teruggeven aan Eric.

Eric Kavanagh: Goed, en ik geef het meteen aan Bill. Bill, wil je daar naar Quick Start gaan en je scherm delen?

Bill Ellis: Ja. Hier?

Eric Kavanagh: Die linkerbovenhoek.

Bill Ellis: Ja. Bedankt voor de instructies, ik waardeer het. Robin, ik vond je discussie echt leuk, het was grappig. Ik werk nu 18 jaar in een virtueel team, dus ik denk dat ik mezelf als een deel van het mobiele personeel kan rekenen. Soms maak ik me zorgen dat ik het ga zien, als ik na het werk een functie heb, moet ik me vaak aankleden om er naartoe te gaan. (Lacht) En ik begin misschien het perspectief te verliezen op wat 'gekleed' is, dus hoe dan ook. (Lacht) Laten we daarmee beginnen en aan de slag gaan. Ik wil bevestigen dat Eric misschien gewoon kan bellen om me te vertellen dat je mijn scherm kunt zien. OK?

Eric Kavanagh: Ja, ziet er goed uit.

Bill Ellis: Oké. Dus, mijn naam is Bill Ellis, ik werk met IDERA aan de Precise-productlijn en we zullen praten over het mogelijk maken van mobiliteit. En we hebben het echt over meten en ervoor zorgen dat het naar tevredenheid werkt. Een van de grote punten daar was dat het iets is waar mensen een soort van interactie mee hebben, met jouw bedrijf. In zekere zin is het heel intiem - de telefoon ligt in iemands hand en dus maakt de indruk, de snelheid, grote indruk op alle gebruikers.

Dus dit was een klantervaring waarvan ik dacht dat ik die zou delen. Ze gingen live, het ging niet goed. En omdat de initiële laadtest niet volledig veranderingen aan het licht bracht in de onderliggende applicatie-infrastructuur, en dus een van de dingen die ik graag benadruk, is mobiel, of het nu applicatie of HTML5 is, er is ook veel technologie die daarvan afhankelijk is. Beginnend met het netwerk, in de webserver, in bedrijfslogica, in berichten, en als ze een aankoop doen, weet u, een belangrijke zakelijke transactie, ze communiceren met het recordsysteem.

En ironisch genoeg, toen we aan de slag gingen, kwamen we een aantal netwerkproblemen tegen, dus al deze dingen zijn zeer relevant, zelfs voor het leveren van dit webinar zelf. En dus zou u één applicatie kunnen hebben, ten minste zes technologieën, talloze eindgebruikers, en zelfs het beantwoorden van zelfs de eenvoudigste vragen is erg moeilijk. Heeft een eindgebruiker een probleem? Wat is het probleem met een applicatiestack, welke code veroorzaakt het probleem? En dus is het inderdaad niet triviaal om grip op die dingen te krijgen.

Wat we nu gaan doen, is een kijkje nemen op enkele metingen die op een site zijn gedaan, om te helpen vaststellen waar problemen zich in de applicatiestack bevinden. En we kijken hier naar een grafiek, waarbij de Y-as de reactietijd is, de X-as de tijd gedurende de dag. En het stapelstaafdiagram is een meting van waar de eindgebruikerstransacties hun tijd doorbrengen. En dus krijg je hier een leuke trend, en dan gaat het omhoog en omhoog en omhoog. En het is eigenlijk de afbakening van de omschakeling, en dus, als je de stapelbalkgrafiek raadpleegt, kun je beginnen te zien dat er veel problemen zijn in de J2EE-laag. Je ziet ook problemen in de webserverlaag, en dan zijn er een aantal behoorlijk grote liften, eigenlijk ook in de databaselaag.

En dus, nu we hebben vastgesteld dat er meerdere niveaus zijn, met meerdere problemen, moeten we een beetje verder gaan om precies te weten te komen wat er aan de hand is, om een ​​intelligente reactie te hebben op dit nieuwe gebruikspatroon en dit zeer traag, we hebben het over vier of vijf X tragere prestaties. En dus is een van de eerste dingen die we willen doen zeggen: "Dit is één transactie", en dus hebben we gekeken naar de reikwijdte aan de linkerkant van alle transacties en ze kunnen, raadplegen, heel gemakkelijk zijn om de staafdiagram van de responstijd te bekijken om in feite te zien dat u in dezelfde clientwebserver Java voor bepaalde transacties meer ziet dan andere, databasetijd. Maar het is echt over de hele linie in termen van alle transacties.

En dit kijkt naar gebruikers, en je begint het te krijgen, dit is een wereldwijde implementatie, dus je kijkt naar de primaire continenten in de wereld, dus het zijn alle gebruikers, alle locaties. Dit is een wereldwijd probleem, het gebeurt, dus dat begint te isoleren, het is niet een of een bepaalde groep gebruikers - het is iets dat meer gebeurt aan de kant van het datacenter. En dus beginnen we te diagnosticeren, wel, waar in de gegevens? Welke toepassingslagen? En dus beginnen we te kijken naar de gemiddelde responstijd die aan het opbouwen is, ook gelaagd daarover met het aantal uitvoeringen, om een ​​soort idee te krijgen over schaling. Dit is zeer interessant - de onderste helft toont feitelijk de lange-termijngeschiedenis en u kunt zeer hoge toegangstellingen zien, maar de andere kant daarvan is dat het aantal gelijktijdige verbindingen relatief laag is. Nadat we zijn overgeschakeld naar een mobiele HTML5-toepassing, is het aantal verbindingen meer dan verdubbeld bij een veel kleinere - we hebben het over orden van grootte - het is 100 keer minder toegangen, dus we schalen niet; we hebben minstens het dubbele aantal verbindingen met wat we eerder hadden. We beginnen dus te onderscheiden wat de nieuwe eisen zijn die de mobiele applicatie stelt aan de onderliggende infrastructuren.

Dus laten we nog verder ingaan, omdat we moeten isoleren waar problemen zich voordoen. En dus, hier, kijk je eigenlijk naar dingen die oplopen en we hadden deze staafgrafiek hier echt niet nodig om te zeggen dat we niet aan onze SLA's voldoen, maar we kunnen dat gemakkelijk zien in de bovenste grafiek. Maar we hebben een secundaire bevestiging in termen van uitvoeringstellingen voor niet-naleving van SLA. Nu gaan we hier eigenlijk kijken naar vergrendeling, en dit is binnen - dit is WebLogic, maar binnen de bedrijfslogica. En u kunt hier zien, en dit is misschien een beetje moeilijk te lezen, maar u zet 31.000 sluisaanwinsten in voor een totale sluistijd van 12 uur en 30 minuten. Dus dit is duidelijk een enorm probleem.

Nu laat de slotimpact zien dat er altijd een afleiding is van de 80/20-regel. Het komt echt neer op één methode, één groep methoden die de problemen echt veroorzaakt. Nu beginnen we problemen binnen een bepaalde laag te isoleren. Dus we gaan een beetje verder, en hier is het berichtensysteem. En we beginnen dit te zien, de grafiek in de loop van de tijd links bovenaan, je kunt zien dat de ruwe responstijd omhoog gaat, en het roze, de sleutel, dit is eigenlijk een wachtrij en er is eigenlijk een heel andere wachtrijen die gebeuren, die worden opgeduwd, vanwege het aantal verbindingen. En dus doet het berichtensysteem veel meer werk; er is veel meer - als je een vergelijking maakt met die supermarkt, zijn er veel meer winkelwagentjes in elke rij bij de kassa - en dat is wat de wachtrij omhoog duwt, en dat zie je het duidelijkst in het domein. Elk van de domeinen ziet een zeer, zeer hoge wachtrij.

Tot nu toe heb ik vergrendeling binnen WebLogic geïdentificeerd, ik heb wachtrijen binnen het berichtensysteem geïdentificeerd en dit is toevallig Tuxedo. En dan, waar we hier naar kijken is een soortgelijk type analyse, maar we kijken naar de uitvoeringstoestanden binnen het recordsysteem. En dit zijn uitvoeringsstaten binnen Oracle. De reden waarom we ons op tijd concentreren is dat tijd twee uitstekende eigenschappen heeft. Nummer één: het is de manier waarop eindgebruikers en applicaties prestaties ervaren. Nummer twee is dat het het verbruik van hulpbronnen meet. En dus zal het automatisch identificeren waar de knelpunten zijn. En dus zie ik hier, op de databaselaag, dat ik extra I / O-tijd heb, dus ik benadruk het opslagsubsysteem. Elke laag is afhankelijk van de stroomafwaartse laag, dus de database is afhankelijk van opslag. Ik zie ook dat ik binnen de databasetijd vergrendeling aan het doen ben. Ik moet dus een beetje korreliger worden voordat die informatie een beetje actiever wordt. En dus, laten we naar binnen gaan, de ui er nog een laagje afpellen.

Nu, dit is eigenlijk een blik op uitvoeringstellingen, de Y-as in deze telling, dit is in duizenden, je kijkt naar 9.000, negen miljoen, en dus gaat de uitvoeringstelling ook omhoog en omhoog en omhoog. Dus de nieuwe mobiliteitstoepassing benadrukt de toepassing op een heleboel manieren. Vergrendeling, gewoon om te herhalen: vergrendeling op de weblaag, wachtrijen in het berichtensysteem, extra uitvoering rekenen op de databaselaag, extra I / O, extra vergrendeling binnen de databaselaag. Dus we zijn eigenlijk van invloed op elke laag binnen de toepassingsspecificatie. En dus is het erg belangrijk om statistieken van elke laag in de applicatiestack te hebben. Hier onderverdeel ik de database-activiteit eigenlijk in het programma, en ik zie dat ik echt twee programma's heb: de turkooise kleur brengt de toepassingsvergrendeling in kaart. En dus, deze, de distributieserver als applicatieslot, de app, dit is het mobiele gedeelte, dit heeft ook applicatieslot. En je kunt zien dat een aantal van deze knelpunten zijn bij opslag zelf.

Nu haal ik de ui eruit om te zien wat ik op elke laag kan doen. En de reden dat ik dit doe, is dat veel mensen dit bekijken vanuit het oogpunt van capaciteitsplanning. En de meeste cloudservices hebben het over het uitbreiden van servers, CPU en geheugen. De andere kant van de medaille is net zo belangrijk, is de applicatiecode die het gebruik van die bronnen uitvoert en stimuleert. En als u op de hoogte bent van de applicatiecode, kunt u nu capaciteit aanpakken door efficiëntie te verwerken. Je hebt dus beide kanten van dezelfde medaille en het geeft IT-professionals extra opties om het probleem op te lossen. Het is niet alleen om meer servers toe te voegen, het is ook wat we kunnen doen om dingen op te ruimen en efficiënter te werken? Het oude "Werk slimmer, niet harder."

Dus hier kunnen we eigenlijk, Oracle heeft een nette zaak genaamd Modules en Acties, waar u de code daadwerkelijk kunt beginnen te documenteren, en u kunt dus ook op een andere manier naar dingen kijken, zoals hier, de applicatieslot die we zagen? Nou, dat kwam binnen via de kostenstaatcode, het kwam ook binnen via de distributieserver, en dus dat zijn de twee primaire stuurprogramma's van die nieuwe vergrendeling. En de nieuwe opslag komt via het online systeem, en dus begin je echt een profiel te bouwen, waar de stuurprogramma's zijn voor dit extra bronnenverbruik. Het is een ander ding om de stuurprogramma's in de onderliggende code te kunnen lokaliseren. En dus als ik hier verder op inga, denk ik dat we dit uitgavenblad hebben bekeken, en dus gaan we hier naar binnen.

Als u nu naar de onderliggende objecten kijkt die worden uitgeoefend, ziet u dit berichtenlogboek. Nou, elke keer dat ze berichten versturen - en we zagen dat het met een veelvoud omhoog ging - raken we eigenlijk deze berichtentabel aan en je zult in een minuut zien dat dat eigenlijk veel van de vergrendeling veroorzaakt binnen de databaselaag. Dus deze nieuwe gebruikspatronen hebben een grote impact op en neer in de applicatiestack. Nu is aan de rechterkant de SQL-code, en dus is dit eigenlijk de applicatiecode en we volgen wat SQL-instructies doen per uitvoeringsstatus. En dus is het heel eenvoudig door de kleurcodering om te zien welke SQL-instructies bij die vergrendelingen zijn betrokken. De reden dat dit echt van vitaal belang is, is dat als je naar je DBA gaat en je zegt: "Hé, we denken dat er een probleem is op databaseniveau." Ze kijken misschien gewoon naar de database en het ziet er ongeveer zo uit het liep gisteren.

Maar in staat zijn om de manier waarop de applicatie de database gebruikt, te correleren, kunnen ze de exacte SQL-instructies identificeren waarop ze zich moeten concentreren, en dan kunnen ze ingaan op enkele van deze geavanceerde praktijken, kijkend naar uitvoeringsplannen en al die dingen dat ze kunnen tweaken, om het recordsysteem veel sneller te laten werken. En dus, de bijbehorende twijfels van de code, is het echt van vitaal belang om de technologie-experts in staat te stellen onderliggende problemen op te lossen en op te lossen. Nu, hier hebben we het ook gehad over opslag - hier zie je het aantal fysieke reads, je kunt zien wanneer dat is gebeurd, en dit begint in de hardware-architectuur te komen, omdat wanneer je van plan bent een systeem te ontwikkelen, een van de dingen die u misschien kiest om te doen, is dat u verschillende soorten opslag kunt kiezen, en ze hebben een heel ander kostenprofiel. En in bepaalde gevallen is het verstandig om te upgraden en te betalen voor flash-opslag; als ik veel meer willekeurige reads doe, dan zal die flash-opslag echt zijn vruchten afwerpen.

En dus is de overkoepelende boodschap hiervan dat met een nieuwe applicatie nieuwe eisen aan het systeem worden gesteld en de onderliggende applicatiestapel moet evolueren om aan die behoeften te voldoen. En u wilt ook kijken naar wat die behoeften zijn en kan de code worden aangepast om het efficiënter te maken? En tot slot, tot in de CPU, zie je tijdens de overgangsperiode dat we op ongeveer 10 procent hadden gewerkt en toen, eenmaal met de nieuwe code, we op 4X zijn, nu zijn we op 40 procent, en dit is erg belangrijk voor zowel fysieke als gevirtualiseerde omgevingen om ervoor te zorgen dat u over voldoende serverbronnen beschikt om aan de behoeften van de toepassing te voldoen. En dus is hier een meer van dichtbij, zodat je sommige van die nummers een beetje van tevoren kunt zien. Interessant op serverniveau, was het geheugenverbruik niet zo veel veranderd, maar zeker het aantal vereiste CPU-cycli.

En dit is eigenlijk gewoon een samenvatting van kijken naar het onkostendeclaratie, kijken naar de schaal, het feit dat het aantal executies daadwerkelijk is gedaald, maar de uitvoeringstijd is gestegen. En dus bleek dat onder de mobiliteit de kostencomponent van de applicatie echt problemen had. En dat zal zeker een gebruikerseffect op dingen hebben, omdat als je je werk niet kunt doen, mensen in feite gewoon stoppen met het gebruik van de mobiliteit. En het mooie van mobiliteit is dat het de productiviteit van het personeel echt verhoogt, en dat is heel goed voor loonstrookjes, enzovoort, dus u wilt absoluut dat het gaat. Nu bekijken we hier hetzelfde, alleen vanuit het oogpunt van de locatie, dus dat zijn Europa en het Midden-Oosten, Azië VPN-verbindingen en vervolgens het hoofdkantoor zelf. En de Verenigde Staten in het algemeen. Dus we geloven dat een manier om die waardevolle informatie op elk niveau van de applicatiestapel te krijgen, is via de precieze productlijn.

Ik ga gewoon heel snel, Robin en Eric, ik geef gewoon snel een soort overzicht van wat Precise doet, en waarom het is ontworpen zoals het is ontworpen. En wat gebeurt er als de eindgebruiker iets probeert te doen, er is veel technologie in het datacenter, waar de eindgebruiker echt niets om geeft, ze willen gewoon hun werk doen. Ondertussen heb je veel IT-mensen, goedbedoeld, heel slim, maar ze zijn zich niet eens bewust van een probleem totdat deze eindgebruiker rapporteert, als ze rapporteren. En dan gaat dit vaak een heel duur, tijdrovend, uiteindelijk frustrerend proces in gang zetten, waarbij mensen naar een subset van de applicatiestack kijken, maar het is heel moeilijk om die basisvragen te beantwoorden over wie, wat, wanneer, waar Waarom.

Dus, wat we geloven is door het meten van de eindgebruikerstransacties beginnend in hun apparaat, via het netwerk, in de webserver, in de Java, door die informatie vast te leggen kunnen we de vragen beantwoorden van wie, wat, wanneer, waar, waarom, bieden aanbevelingen, maar het belangrijkste is waarschijnlijk het voltooien van de feedbacklus. We hebben allemaal feedback nodig om te verbeteren, het is de enige manier waarop je weet dat er iets misgaat. Door de geschiedenis in een gecentraliseerde repository te plaatsen, biedt het één blad muziek voor iedereen om van te lezen. En zo wordt het heel gemakkelijk om erachter te komen waar problemen zijn, dus nogmaals, het ontwerp gaat over het meten van de eindgebruikerstransactie; dit gaat trage transacties identificeren, segmenteren, dit gaat vertellen welke technologie een probleem is en geeft vervolgens een deskundig beeld van elk van de afzonderlijke niveaus, zodat u kunt achterhalen wat er gebeurt. Nauwkeurig gaat leren en rapportage en dashboards bieden voor alle belanghebbenden, of u nu alleen een overzicht wilt hebben of een diepgaand technologisch beeld wilt hebben van wat er gaande is.

Wat kan er gebeuren, een soort van een dag in het leven, of u als IT-specialist zou een eindgebruiker kunnen bellen, of soms zou een eindgebruiker u kunnen bellen. Log in op Precise, u kunt opnieuw scherpstellen, de Y-as is respons, de X-as is tijd gedurende de dag. Hier zijn we elke substaat, dus je hebt klanttijd, webservertijd, Java, smoking, databasetijd. Hier beneden hebt u de drijvende transacties, u kunt een menu oproepen om een ​​bepaalde eindgebruiker te identificeren, en op deze manier kan IT de problemen van die eindgebruikers oplossen. En dus kun je precies zien wanneer ze bezig waren, je zou kunnen zien dat ze content management gebruikten, je kunt focussen op die transactie en dan zal Precise je een analyse van die transactie geven.

Het percentage aan het einde wordt toegevoegd door procent, Precieze, en dat vertelt u hoeveel tijd, maar een percentage van de tijd, besteed aan die individuele stap, tot individuele SQL-instructies, dit is de context. En een van de dingen die we zeggen is dat iedereen tools heeft, maar weinig winkels hebben context. En context stelt de Java-beheerder in staat zich te concentreren op de toepassingscode, de DBA om zoals in dit geval de specifieke SQL-instructie te identificeren. En dus, met die informatie, geeft het hen veel meer zichtbaarheid over hoe de onderliggende oorzaak van de specifieke transactie die de specifieke gebruiker beïnvloedde, moet worden aangepakt. Dus jij bent echt laser gericht op de oorzaak. En u kunt SQL-instructies analyseren, waar heeft het zijn tijd doorgebracht, nou ja, uitvoeren? En juist, veel tools zoals Enterprise Manager, gewoon om ze te kiezen. Ze zijn groot, ze kunnen het aan. Ze kijken naar dingen vanuit een instantieperspectief en dat is niet genoeg focus om echt in deze applicaties te komen.

Normaal gesproken hebben uw OLTP-mobiliteitstoepassingen een lage latentie, hoge doorvoersnelheid, dus focussen op de top tien-lijst, dat is een begin, maar het is echt niet goed genoeg voor dit type toepassing. En dan is het andere dat, met name voor intern gehoste applicaties, identificatie door gebruikers-ID echt van vitaal belang is, omdat het niet alleen om de applicatie en de infrastructuur gaat, maar ook om hoe de eindgebruikers de applicatie gebruiken. En de eindgebruikers gedragen zich doorgaans veel beter wanneer u ze kunt identificeren. En dus is dit gewoon een soort scherm van verschillende transacties en de klantervaring, en vervolgens gesegmenteerd, (lacht) Ik denk dat ik al een tijdje spreek. Beetje moe hier buiten; Ik ga vooruit ploegen.

Hier kijken we naar een dashboard dat we samenstellen dat waarschuwingen zou tonen en vervolgens verschillende lagen van de applicatiestapel zou tonen. Hier zijn uw webservers en u kunt controleren door de uitvoeringstijd van de responstijd te controleren of alles evenwichtig is verdeeld. Je kunt kijken naar browsertoegangen, je kunt kijken naar gebruiks- en afvalverzamelingen, zorg ervoor dat je dat mooie zaagtandpatroon hebt, dat je geen geheugenlek hebt, enz. En het idee hiervan is om een ​​beetje beetje een meer technisch dashboard van elk van de componenten in de applicatiestack. De Precise-productlijn die IDERA biedt, biedt dus productiebewaking, 24 bij 7, zeer gedetailleerde informatie. Het is vrij eenvoudig om dit in te zetten; u hoeft geen transacties in kaart te brengen, wat de eindgebruikers ook doen, Precise verbindt automatisch de punten over de applicatiestapel.

Als een stroomafwaartse laag niet is geïnstrumenteerd, zal Precise dat herkennen en de in- en uitlooptijd geven en aanbevelen dat u de stroomafwaartse laag instrumenteert. En dus is het heel gemakkelijk om tijd te waarderen; we zijn erg sterk in de database, dit is een soort claim van IDERA. En de reden dat het zo belangrijk is, is dat elke belangrijke zakelijke transactie een interactie aangaat met het recordsysteem, zodat de database de basisprestaties wordt. En dus doen de andere tools op de markt het goed, maar OK is niet echt goed genoeg; je moet echt precies weten wat er gebeurt met de SQL-instructies. En we doen veel geavanceerde dingen, die hiervoor te veel zijn, zoals het bijhouden van een SQL-instructie geschiedenis en het bijhouden van uitvoeringsplannen in de loop van de tijd. En dus, dat is een gebied dat we verder kunnen verkennen, als je misschien geïnteresseerd bent.

Dus daarmee, dat is het Precieze applicatieprestatieplatform, nodigen we u uit om een ​​extra vergadering aan te vragen via de idera.com-website, als u extra interesse hebt in de oplossing en de onderwerpen die we vandaag hebben besproken.

En, Eric, daarmee denk ik dat we nog steeds onder de draad zijn, ik ga het stokje teruggeven aan jou en Robin. Dank je.

Eric Kavanagh: Nee, dat is fantastisch en ik ben dol op de inhoud die je hier hebt samengesteld, omdat je fantastisch kunt laten zien hoe complex de omgeving onder de motorkap is. En natuurlijk, de hele taak van Precise, het doel van Precise is om te helpen die complexiteit te navigeren en te begrijpen wat er feitelijk gebeurt en in staat zijn om enkele acties te ondernemen om iets te verbeteren. En ik ben gewoon een beetje verbijsterd over hoe complex het is. Ik gok dat Precise je ook toelaat om bepaalde gedragspatronen te identificeren en ze vervolgens te benoemen, of tenminste op te nemen of er een bladwijzer van te maken of zoiets, klopt dat?

Bill Ellis: Ja, een van de dingen die gaat gebeuren, is dat je niet achter je staart aan wilt gaan; je wilt niet gewoon veel tijd besteden aan een eenmalige. Dus je zou willen kijken naar wat de patronen zijn, wat de trends zijn, want er is veel te beheren technologie. En dus is een van de dingen prioriteit geven en in staat zijn om te rangschikken, weten waar je je tijd kunt doorbrengen, weten wat moet worden aangescherpt. En u wilt ook een conservatieve benadering hanteren met minder risico en lagere kosten. U wilt niet noodzakelijkerwijs een dure wereldwijde verandering aanbrengen, zonder dat u een beoordeling heeft of een heel goed gevoel heeft dat u weet dat dit inderdaad het probleem zal helpen. Weet dus wat er na verloop van tijd gebeurt en deze trend is van vitaal belang om de onderliggende problemen op een intelligente manier aan te pakken.

Eric Kavanagh: Dat is volkomen logisch. En hoe belangrijk is virtualisatie om te kunnen zien wat er gebeurt, en kom je dan organisaties tegen die containers gebruiken - bijvoorbeeld met Docker? En hoe zou dat invloed hebben op wat Precise kan doen?

Bill Ellis: Ja, dus het woord 'container' kan volgens verschillende leveranciers verschillende dingen betekenen. En dus werken we met VM, bijna iedereen gebruikt VMware - ik beschouw het op dit moment de de facto standaard; Ik weet dat er concurrenten zijn. En we breiden uit wat we ondersteunen, maar VMware is de dominante, binnen de Oracle-stack. Er zijn databases in containers en dat alles is dus erg belangrijk om uw systeem zeer snel te kunnen ontwikkelen. Het is ook heel belangrijk om in een gevirtualiseerde omgeving te weten wanneer de fysieke host niet in staat is om aan de behoeften van alle containers van de gasten te voldoen, omdat elk van hen om middelen strijdt.

En een van de dingen die feitelijk intern gebeurde, was dat ik verrast was, dat we binnen IDERA zoveel niet-actieve VM's hadden, maar elk van die niet-actieve VM's middelen verbruikt, dat ze in het algemeen een probleem begonnen te veroorzaken voor de VM's die feitelijk werden gebruikt. gebruikt die belangrijk voor ons waren, en die ons bedrijf voerden. En dus dat was best interessant. Nu ondersteunen we niet elke technologie onder de zon; er is een ondersteuningsmatrix verbonden aan deze oplossing, en dat is een van de dingen die we voor een bepaalde potentiële klant of klant willen onderzoeken, gewoon om ervoor te zorgen dat we kunnen voldoen aan de technologische behoeften en de individuele technologieën die hun applicatiestack loopt onder.

Eric Kavanagh: Ja, dat is heel logisch. Wat zijn volgens uw ervaring nu enkele van de belangrijkste krachten die uitdagingen op mobiel veroorzaken? Toen u en ik een paar maanden geleden voor deze webcast spraken, maakte u een heel goed punt over hoe alleen de functionaliteit en de lay-out van een iPhone of een mobiel apparaat een echte uitdaging voor het bedrijf kan zijn, omdat plotseling de eindgebruiker niet uitzoeken hoe een specifiek proces in de workflow gedaan kan worden, toch? En dus, tot dat punt, wat je inschakelt bij de ontwikkeling van mobiele apps, is dat je de ontwikkelaars laat zien waar de problemen optreden en dat je dat vervolgens kunt terugverwijzen naar wat de app doet op dit specifieke apparaat of dat specifieke apparaat. En dat is zeer nuttig, toch, voor de ontwikkelaar, omdat ze nu kunnen zien wat het probleem veroorzaakt, kunnen ze wat wijzigingen aanbrengen in de app, om dat op te lossen, toch?

Bill Ellis: Ja, het is een soort overlapping van ongelooflijk hoge verwachtingen - iedereen verwacht dat alles in zekere zin gewoon werkt, maar er is zoveel variatie. Je hebt al deze verschillende smartphones, ze hebben verschillende schermafmetingen, en dan heb je verschillende leveranciers van communicatie, de Verizons, de AT & Ts, de Sprints, dat zijn gewoon de populaire in de Verenigde Staten. En er is gewoon zoveel variatie, het is net zo goed, hoe sla je je armen om dit alles heen, om een ​​soort van onderscheid te maken tussen de problemen? En dus zijn er veel metrieken beschikbaar en een van de dingen die ons productbeheerteam heeft gedaan, is proberen de metrieken te verzamelen die het belangrijkst of het meest nodig zijn door het IT-team, om intelligente beslissingen te kunnen nemen .

En dus is het een beetje een uitdaging en we doen ons product is als de markt evolueert en dus krijgen we feedback van onze klanten en er zijn altijd verbeteringsverzoeken, dus "Hé, deze extra statistiek zou ons super behulpzaam zijn." Dus, onze product evolueert net als de markt, maar als ik zou moeten zeggen, eigenlijk Eric, het is echt interessant voor mij, is dat hele verwachtingen ding. Mensen zijn zoals, vroeger was het vroeger dat mensen vijf, zeven seconden wachtten tot een scherm zou verschijnen, nu is het als één of twee seconden, mensen zijn als "Oh, deze applicatie werkt helemaal niet!" (lacht)

Eric Kavanagh: Dat is grappig. Het is zo waar!

Bill Ellis: Het is gek.

Eric Kavanagh: Ja, het is een beetje onrealistisch, eerlijk gezegd. En ik denk dat we misschien wat meer realisme rond dat onderwerp gaan zien, maar desalniettemin is het een feit in het leven dat mensen zeer, zeer hoge verwachtingen hebben. En ik neem aan, Robin, dat ik je hier de laatste paar minuten snel weer terug zal brengen. Ik hield van je beoordeling van de website als catalogus en app als loyaliteitsmachine. En tot zover hebben we het hier gehad over hoe we de ontwikkelaars van deze apps kunnen laten begrijpen wat er gebeurt: is het bruikbaar? Is het niet bruikbaar? En wat kun je veranderen om dat aan te passen? En tot Bill's punt hier, zojuist, is de cyclustijd bij het oplossen van dat probleem echt korter geworden, toch? Het is gewoon niet meer zoals vroeger - je moet dat snel oplossen. Of je gaat gewoon een enorme drop-off in gebruik hebben, toch?

Robin Bloor: Ja, er zijn een heleboel andere dingen die hierin worden gespeeld, dus je hebt deze behendige ontwikkeling en je hebt nu verwachtingen op veel plaatsen, dat je een nieuwe versie gaat uitbrengen van iets dat om de paar weken wordt ontwikkeld of wordt veranderd. En dat betekent, het maakt wanneer je erover nadenkt, als je denkt aan de implementatieomgevingen, en je denkt aan hoe groot de stapel is wanneer je mobiel wordt, je hebt eigenlijk meerdere potentiële apparaten op het eindknooppunt, en dan heb je middleware in het midden. En misschien heb je er wel onder en onder de databanken. Het kan dus zijn dat je vele, vele applicaties aanraakt; u raakt mogelijk meerdere databases aan en u doet mogelijk zeer complexe dingen op het gebied van beveiliging. En het moet allemaal werken, en de verwachting is dat het redelijk goed gaat werken.

En het verbazingwekkende is soms dat het dat doet, maar mijn gedachte hierover is of je echt, als je mobiele apps bouwt die echt belangrijk zijn voor het succes van het bedrijf en veel van hen blijken, veel van deze dingen echt waar. Als je mobiel onderhoud doet aan boorplatforms en oliepijpleidingen en dergelijke dingen, dan is het een beetje werken. De gevolgen van het niet werken zijn gewoon een beetje verschrikkelijk. En als u niet over deze mogelijkheid beschikt om de toepassing daadwerkelijk op te splitsen en weet waar dingen misgaan, omdat het grootste deel van de prestaties bestaat. We hebben tegenwoordig echt goede testharnassen, dus ja, er zijn bugs en bugs komen er wel doorheen. Maar meestal als er iets misgaat, is het prestatieprobleem. En als u de stethoscoop niet op 18 verschillende plaatsen kunt plaatsen, is het echt moeilijk om vast te stellen wat er misgaat. En u speelt ook een rol in het netwerk, en u hebt ook de realiteit dat een bepaald onderdeel in een applicatie op verschillende tijdstippen van de dag kan worden benadrukt, vanwege de aard van die specifieke applicatie. Je moet geavanceerde monitoringtools hebben als je daar een kans op wilt hebben.

Eric Kavanagh: Ja, ik zou het ermee eens moeten zijn en ik denk dat dat tegenwoordig echt de kracht is van Precise by IDERA. En Bill, ik neem aan dat je nog enkele slotopmerkingen van je hebt? Ik denk dat deze technologie fantastisch is. Ik realiseer me ook dat je als gebruiker van deze technologie echt de complexiteit van informatiesystemen en de afhankelijkheden moet begrijpen en moet kunnen achterhalen waar, wanneer en hoe je al deze informatie synthetiseert om te beoordelen wat er feitelijk gebeurt. En dat vereist een intelligent en getraind mens, en eerlijk gezegd, het is een reden waarom ik me helemaal niet druk maak over machine learning die banen wegneemt. Ik denk dat machine learning erg handig kan zijn onder een technologie als deze, om gemeenschappelijke patronen te identificeren en vervolgens suggesties te doen aan de eindgebruiker over wat hier zou kunnen gebeuren. Maar wat zijn enkele slotideeën van u om de onderneming echt het belang te geven van het hebben van dit soort probleemoplossingsmogelijkheden en wat moeten zij daarover weten, naast wat u al zei?

Bill Ellis: Ja, dus Eric, ik ben het met je eens dat er een enorme hoeveelheid complexiteit is. Ik geloof in de Precise-productlijn door zich te concentreren op de metrische tijd, dat een gebruiker die een stapelbalkgrafiek kan lezen Precise met succes kan gebruiken en ik wil alleen maar de deelnemers en Robin en u bedanken voor het hosten van het webinar van vandaag.

Eric Kavanagh: Reken maar! En zoals ik al zei, we zullen dit archief nu al een tijdje hosten, dus deel het gerust met je vrienden en collega's; we archiveren al deze webcasts. Ik heb een paar minuten geleden een link naar de dia's gestuurd, voel je vrij om dat eens te bekijken, maar geweldig weer vandaag, Bill. Je kent je spullen echt; het is altijd leuk om met een professional als jij te werken. En ik denk dat dit echt de ondersteunende technologieën voor mobiel personeel zal zijn! Dus bedankt voor je tijd, mensen, we zullen je de volgende keer inhalen, wees voorzichtig. Tot ziens.

En marche! het mobiele personeel inschakelen