In het hedendaagse it-landschap is de komst van 'de app' één van de grootste aanstichters van onze veranderende manier van werken met informatie en processen. Aangesticht door de iPad, is iedereen nu ineens apps aan het ontwikkelen en moet ook alles wat voorheen nog anders heette nu app heten. SharePoint List? Nee List app! Maar, als we allemaal even ons hoofd erbij houden (architecten, bemoei u ermee!) zal het allemaal wel weer loslopen…
Als ik kijk naar de toepassingsgebieden van apps, zie ik voornamelijk mogelijkheden om, zeker voor mobiel gebruik, door middel van aanraakschermen gemakkelijk en snel informatie op te vragen en processen te starten. Met de iPad, Windows Phone of een ander 'touch friendly'-apparaat is het snel kunnen reserveren van een bioscoopticket, opzoeken van de dichtstbijzijnde sushibar of veranderen van je Facebookstatus erg gemakkelijk geworden. Voor zakelijk gebruik zijn er legio toepassingen te bedenken, van het opvragen en bijwerken van de status van een patiënt in een ziekenhuis door een arts of verpleegkundige met behulp van een Windows Surface, tot het uitschrijven van een boete door een politieagent met een iPhone.
Toch wordt het installeren en gebruiken van allerlei apps, die ieder hun microtoepassingsgebied hebben, op een gegeven moment een onbeheersbaar iets. Als ik naar m’n eigen smartphone kijk, zie ik een bonte verzameling van allerlei losstaande apps die op geen enkele manier met elkaar verbonden kunnen worden. De 'terugknop' lijkt in deze user interfaces ook telkens een andere betekenis te hebben en al snel ben je de weg kwijt. Aan de 'achterkant' zal dit ook niet bevordelijk zijn voor de performance en schaalbaarheid van de systemen die deze informatie ophoesten.
Om een coherent geheel te creëren van allerlei losse informatie uit verschillende bronnen en dit hapklaar aan te bieden aan eindgebruikers, wordt vaak gebruik gemaakt van portal technologie. Door bijvoorbeeld in Microsoft SharePoint de 'connected webparts'-functionaliteit te gebruiken wordt enterprise mashup mogelijk gemaakt en kan het selecteren van een klant in het éne webpart het tonen van alle offertes (opgehaald uit het crm-systeem) tot nu toe gemaakt voor deze klant in het andere webpart op het zelfde scherm tot gevolg hebben. Maar volgens sommigen, met name de mensen die lid zijn van de 'dead portal society', is dit achterhaalde technologie en moet het allemaal anders; apps.
Ik voorzie dat we, zoals gebruikelijk is in onze wereld, veelal terug zullen grijpen op hybride modellen, waarbij rijke, samengestelde informatie via portals wordt ontsloten richting html5 compatibele browsers die op elk willekeurig platform (Android, Windows, iOS, hé waar is Linux gebleven?) en schermformaat hetzelfde bruikbare resultaat tonen. Soms (omdat html5 tekort schiet) zal dit moeten gebeuren in combinatie met een apparaatspecieke app, die dan een gedeelte van de presentatie- en interactie logica voor zijn rekening neemt. Maar we moeten er wel voor waken dat zo’n app niet uiteindelijk een monolotisch app…licatie gaat woren die ook weer apart beheerd en ondersteund moet gaan worden op elk device, want dan zijn we verder van huis en herleven de client-server tijden weer, met alle bijkomende narigheid die bij een thick client hoort.
Tot slot: Integratie zal zoals altijd een belangrijke rol spelen. Of de integratie nu achter het portaal tot stand komt door middel van een service laag (bijvoorbeeld esb) om composite services te kunnen ontwikkelen en ontsluiten óf dat een gedeelte van de compositie plaatsvindt door middel van enterprise mashup in de portal óf dat de app rechtstreeks aansluit op zo’n service laag, dat maakt niet zo heel veel uit. Als we maar niet wéér in de valkuil van onbeheersbare spaghetti integratie vallen, waarbij elke app zelf rechtstreeks zijn eigen data ophaalt uit de bron, want dan gaan we weer terug in de tijd. We zullen allemaal gebaat zijn bij een goede op soa gebaseerde integratiearchitectuur met on-premise, cloud of hybride integratie oplossingen die goed beschikbaar, schaalbaar en beheersbaar zijn en die ook goed te monitoren zijn, zodat altijd het juiste inzicht te verkrijgen is voor zowel de supportafdeling als de business. Laat de corporate app store dan maar komen!
Beste Gijs,
Je schrijft: “Door bijvoorbeeld in Microsoft SharePoint de ‘connected webparts’-functionaliteit te gebruiken wordt enterprise mashup mogelijk gemaakt en kan het selecteren van een klant in het éne webpart het tonen van alle offertes (opgehaald uit het crm-systeem) tot nu toe gemaakt voor deze klant in het andere webpart op het zelfde scherm tot gevolg hebben.”
Nu vraag ik mij altijd af wie deze functionaliteit bedenkt en welke klant dit specificeert of is het juiste een technische mogelijkheid? Het probleem is namelijk dat er technisch van alles mogelijk is en dat dit ook wordt gebouwd en in organisatie wordt geïntroduceerd. Maar na een tijdje gebruikt niemand het meer omdat het te ingewikkeld is en daarom zijn Apps zo gewild. Die doen heel simpel iets waarvoor belangstelling is, niets meer en niets minder. Vaak is een App een functie om een deel van een website te tonen of een verzameling van gegevens van een website, maar dan anders gepresenteerd.
Ik zou Apps ook altijd als aanvulling op de portal bouwen en zo wordt er in de praktijk ook mee omgegaan, dus zorg dat de portal multifunctioneel is en zo ervoor dat de App single functioneel is.
Integratie tussen Apps gaat vanzelf komen en als je goed kijkt is die er al. Twitter, Facebook en allerlei andere applicaties bewegen zich horizontaal (generiek) over de verticale (specifieke) Apps.
Leuk artikel met terechte opmerkingen.
Dank voor je goede wensen (veel apps) maar wens me erbij ook een goede architect toe om dit te kunnen realiseren!
“Veel apps” kan enorme belasting op mijn back-end betekenen. Daarom heb ik een architect nodig om te weten hoe en waar ik de offloading van deze belasting kan realiseren (bijvoorbeeld met ESB, Mobile Platform, Point Connection etc )
Een toepassing zoals SharePoint kan niet altijd een oplossing bieden voor elk soort applicatie. Als bedrijf ben je goed bezig wanneer je aan Apps gaat beginnen ook de scope van het project vergroten door het opnemen van HNW en BYO daarin. Dan ben je in een keer grondig iets aan het veranderen.
De presentatielaag zal in de toekomst veranderen in HTML. Er zijn een aantal leveranciers die rond Q4 van dit jaar met hun HTML5 oplossing komen. Zou dit voor bedrijven de behoefte aan apps(infrastructuur) elimineren? Ik denk dat na een verdere ontwikkelingsfase kunnen ze ingezet worden om de bedrijfsapplicaties binnen een HTML5-frame aan te bieden.
Mobiele apps zijn zeker geen “silver bullet”, maar kennen zeker wel hun toepassingsgebieden. Welbeschouwd geldt dat voor alle presentatie-oplossingen, voor zover het niet voor alle onderdelen binnen (IT-)oplossingen geldt. Je zult per geval, of per categorie, moeten kijken wat de behoefte is en of een mobiele applicatie, al dan niet in de vorm van een native app, daar de best passende oplossing voor is.
Omdat de beschikbare presentatie-oplossingen en hun mogelijkheden, zowel voor mobiele als meer traditionele platformen, veranderen is het het beste dat je zorgt dat je flexibel bent. Het “publiceren” van je logica in de vorm van services is daarvoor een prima oplossing, wat al dan niet door een ESB kan worden gefaciliteerd. Daarbij is ook flexibiliteit aangaande de publicatietechnologie van de services na te streven; of dit het beste door SOAP, RESTful services, OData of de technologie van volgende maand kan gebeuren zal ook van de situatie afhangen.
Onderaan de streep is lastig te voorspellen wat voor de langere termijn nu concreet de “juiste” keuze is. Door het toepassen van bepaalde architecturale principes kun je er echter voor zorgen dat je die keuze voor een bepaalde situatie pas hoeft te maken op het moment dat die zich voordoet.