Information radiator

Van de nieuwe concepten die ik de laatste jaren heb leren kennen is één van mijn favorieten dat van de "information radiator".

Een information radiator heeft als kenmerken dat hij informatie weergeeft die verandert over tijd en dat deze informatie met zo min mogelijk moeite kan worden waargenomen.

Een voorbeeld is een muur met post-its. Als je daar langs loopt, vallen de post-its direct op. Verondersteld dat het aantal post-its beperkt is en de informatie op de post-its duidelijk leesbaar, up-to-date, etc. zal iedereen die er langs loopt met heel weinig moeite op de hoogte zijn van hetgene dat via deze muur gecommuniceerd wordt.

Het tegenovergestelde concept is dat van de "information refrigerator", waarbij informatie dusdanig wordt gepresenteerd dat het praktisch onbruikbaar is als communicatiekanaal. Hierbij kun je denken aan dezelfde muur als hiervoor, maar dan met een zeer groot aantal post-its, onleesbare post-its, overmatig veel data of achterhaalde informatie. Dit zal leiden tot het in onbruik raken van het communicatiekanaal, waardoor de informatie niet aankomt.

Een ander voorbeeld is een complex systeem waarin de gebruiker moet inloggen en dan via een aantal handelingen of zoekopdrachten pas terecht komt bij de informatie. Dergelijke systemen hebben ook de neiging om in onbruik te raken, indien het gebruik niet actief wordt aangemoedigd of verplicht (en dat is verspilling van energie die ook positief kan worden ingezet).

Klinkt waarschijnlijk heel logisch allemaal, maar kijk nu nog maar eens rond, thuis of op kantoor, en constateer het grote aantal (onbedoelde) information refrigerators. Vervang deze door information radiators en zie de communicatie verbeteren.

Ontwerp je organisatie met SOA

Als software engineer hoor je regelmatig dingen als TDD, DDD en SOA, vaak ook wel de TLA's (Three-Letter Abbreviations) genoemd. In context kun je die vaak wel plaatsen. Voor wie er niet bekend mee is, we hebben het hier over Test Driven Development, Domain Driven Development en Service Oriented Architecture.

Bij softwareontwikkeling is het vaak verstandig om tests te schrijven. Dat zijn kleine stukjes code die een heel specifiek stukje van het programma testen op correct functioneren. Dit is handig wanneer je met veel mensen aan dezelfde sourcecode werkt, omdat een wijziging op de ene plek vaak de functionaliteit van een totaal ander stuk code beïnvloed. Daarnaast is het lastig om te zien wat een bepaalde wijziging in de code precies voor gevolgen heeft, dus worden tests ingezet om voor alle gespecificeerde use cases (manieren waarop de applicatie kan worden gebruikt) te testen of alles nog in orde is.

Een manier om minder van dit soort effecten te hoeven testen, is ervoor te zorgen dat er minder lange-afstandseffecten zijn. Dit kan door het scheiden van de code in stricte brokken, die elkaar op geen enkele manier mogen beïnvloeden, behalve door communicatie via strict omschreven protocollen, meestal via internet. Door dit te doen, hoeven alleen de communicatievlakken (API's) nog maar te worden getest op correct functioneren.

Als dit gebeurt door binnen de software dergelijke brokken te maken, dan heet dat vaak OOP, ofwel Object Oriented Programming en de tests van deze brokken Unit Tests. Als deze brokken over verschillende programma's worden uitgespreid, die vaak ook nog op totaal verschillende servers draaien, dan wordt dat vaak SOA, ofwel Service Oriented Architecture genoemd, en de tests Functional Tests. Iedere service krijgt een bepaalde verantwoordelijkheid toegewezen en de ontwikkelaars van de service zijn verantwoordelijk voor het correct functioneren van de service.

Naast de stricte scheiding van verantwoordelijkheden heeft SOA ook nog wat andere voordelen: iedere service kan zelf bepalen welke technieken het meest geschikt zijn voor die service of de programmeurs die hem onderhouden en iedere service kan zich focussen op het zo effectief mogelijk leveren van die service. Daarnaast zijn de services door meerdere clients te gebruiken.

Dit is natuurlijk vergelijkbaar met de "Service Oriented Architecture" die veel bedrijven impliciet al implementeren. De marketingafdeling specialiseert zich in X, de ontwikkelafdeling in Y en de klantenservice op Z. Verzoeken van de klantenservice worden in veel gevallen volgens een bepaalde procedure gecommuniceerd naar marketing.

Daarom sluit Domain Driven Development ook voor goed aan op SOA. In DDD probeert de ontwikkelaar de structuren, processen, functies en terminologie die binnen een bedrijf aanwezig zijn 1-op-1 over te nemen in de software. Dit zorgt voor meer duidelijkheid bij de communicatie tussen de ontwikkelaar en de gebruikers en geeft een natuurlijke structuur aan de codebase.

Voor veel developers is DDD de vanzelfsprekende aanpak die ze intuïtief volgen. Dit maakt dat getrainde developers vaak een goede analyse kunnen maken van bedrijfsstructuren en -processen en snel de onlogische indelingen of bottlenecks kunnen spotten.

Dus, wanneer u de volgende keer met een ontwikkelaar spreekt over het bouwen van een bedrijfsapplicatie, bedenk dan dat het ontwerpen van de applicatiestructuur misschien ook wel een goede gelegenheid biedt om de bedrijfsstructuur mee onder de loep te nemen.

Van apps naar wapps

Sinds de introductie van de iPhone in 2007 zijn smartphones en de daarbij behorende apps niet meer weg te denken uit ons leven. Overal lijkt een app voor te zijn, van het spelen van een spelletje tot het checken van je saldo tot het kopen van een huis. Ieder consumentenmerk lijkt ook één of meer apps te hebben, bijvoorbeeld om de consument in staat te stellen om het laatste nieuws te volgen over hun producten, deze te bekijken of te bestellen. Een parallel universum van apps dat onze wereld verbindt en verrijkt. En dat alles vanuit één appstore, bewaakt door Apple.

Na de iPhone met iOS als operating system, kwam Google met een eigen O.S. voor de mobiele telefoon: Android. Met eigen apps. Native apps, alleen voor Android. En een eigen appstore. En ineens was er een verdeling. Sommige apps waren niet beschikbaar voor Android. Andere waren niet beschikbaar voor iPhone. Sommige waren niet op beide systemen hetzelfde. En ontwikkeling van een app was opeens dubbel zoveel werk. En dubbel zo duur.

Ook Windows wilde met Windows Mobile meevissen in de vijver van de mobiele apps. Maar driedubbele ontwikkelingskosten is toch net te veel gevraagd van veel bedrijven, zeker wanneer de hoge extra kosten slechts een klein, opkomend marktaandeel bedienen. Het daaruit voortvloeiende gebrek aan native apps zorgde ervoor dat zelfs deze reus niet de adem had om in te lopen op Apple en Google. Three is a crowd.

Maar de barbaren staan aan de poort.

De populairste Open Source Linux-distributie Ubuntu lanceerde recentelijk ook een telefoon met hun eigen mobiele Linux operating system. De insteek van Ubuntu is echter om de kloof tussen de "normale" programma's van de PC en de mobiele telefoon te dichten.

Ook webbrowserbouwer Firefox lanceerde een eigen mobiele systeem, Firefox OS, vooral gericht op de gigantische opkomende markt van de goedkope, low-end smartphones. Als browserbouwer zet Firefox in op de in de afgelopen jaren enorm toegenomen capaciteit van de webbrowser. Het verschil tussen webapplicaties, zoals je die in een browser gebruikt, en apps wordt tot 0 gereduceerd, door hun hele systeem te laten werken als één grote browser.

Google, de andere grote browserleverancier, doet ongeveer hetzelfde met zijn Chromebook, een "cloud georiënteerde" laptop. Ook daar worden web apps gebruikt in plaats van native apps. Geen installatie nodig, alleen een bookmark.

Manieren om offline en online werken naadloos in elkaar over te laten lopen worden op hoog tempo ontwikkeld door zowel Google als Firefox, in samenwerking met standaardiseringsorganisaties zodat ze niet tegen elkaar in werken. Daarnaast worden er meer en meer API's opgenomen in de browsers, die de gebruiker de mogelijkheid geven een web app toe te staan gebruik te maken van de mogelijkheden van de telefoon, zoals de camera, het adresboek, de locatiesensor, de bewegingssensor, etc.

Ook wordt er hard gewerkt aan het sneller maken van de JavaScript Engines. Dit zorgt voor extra rekenkracht voor de web apps, waardoor de gebruikerservaring bij veel toepassingen haast niet meer te onderscheiden is van die van native apps.

Wat zien we dus gebeuren: de grootste spelers op het gebied van mobiel en browser werken samen aan het creëren van een platform voor web apps die niet onderdoen voor native apps, die maar één keer hoeven worden ontwikkeld en die zonder installatie beschikbaar zijn.

Dat is het einde van de native app. Lang leve de wapp.

Steden nemen het voortouw in appontwikkeling

Origineel / original version: "Cities Take Lead On App Development"
 http://techcrunch.com/2015/03/24/cities-take-lead-on-app-development/
Origineel door / original by: Brooks Rainwater (@BrooksRainwater), David Maloney (@david_j_maloney)
Vertaling / translated by: Johan Groenen (@jpagroenen)

Wat voor apps hebben steden nodig? Dit is de kernvraag die steden zichzelf stellen en de antwoorden erop lopen de laatste jaren zeer uiteen. Voordat we deze vraag goed kunnen beantwoorden is het echter belangrijk om te begrijpen welke belangrijke rol steden vervullen in het dagelijks leven.

We worden wakker in ons huis in een stad, lopen door de stad, fietsen door de stad, reizen naar werk en school door de stad, bezoeken de lokale horeca voor een lunch in de stad en gaan 's avonds uit in de stad. Centrale overheden hebben een cruciale rol bij hoe we de stad daarbij ervaren.

Net als hun tegenhangers in de private sector, willen leiders in de publieke sector de beste gebruikerservaring realiseren. Leiders in steden door het hele land willen fantastische plaatsen creëren, waar bewoners kunnen leven, werken en spelen. Technologie kan steden verheffen en verbreden, en apps spelen daarbij een fundamentele rol.

De techniek verandert in sneltreinvaart de beleving van de stad, door deze te onderbreken, te vervormen en in het algemeen verbeteren. Naast de vanzelfsprekende consumentenapps (Foursquare, Yelp, Uber, etc.) zoeken gemeenschappen steeds vaker naar technologische oplossingen die erbij helpen bewoners te bereiken "waar ze zijn".

Betalen voor parkeren? De stad heeft er waarschijnlijk al een app voor. Betalen voor de taxi of je kind opgeven voor vakantiekamp? Meer en meer heeft de stad een app om ervoor te zorgen dat je niet op en neer naar het gemeentehuis hoeft. Deze kleine technische ingrepen in de gemeenschappelijke serviceverlening hebben de stedelijke gebruikerservaring - nationaal en globaal - fundamenteel veranderd.

Deze technieken maken de alledaagse zaken zeker simpeler, maar hoe zit dat met de wat meer ambitieuze dingen? Kunnen we de zorgproblematiek ermee aanpakken, of verandering brengen in hoe inwoners omgaan met de publieke veiligheid?

Dit is de vraag die een grote groep samenwerkende [Amerikaanse] steden wil beantwoorden. De Multi-City Innovation Campaign is een programma dat helpt innovatie te bevorderen door heel het land [de Verenigde Staten]. Het vormt een platform voor steden en regio's om samen te werken met developers, creatievelingen en ondernemers die werken op het raakvlak tussen innovatie en steden.

De Challenge van 2015 richt zich op volksgezondheid, gemeenschap, gezondheidszorg en geneeskundige technologie. Wij hebben behoefte aan innovators die zich focussen op de problemen in deze gebieden. Voorbeelden van uitdagingen waarop zij zich zouden kunnen richten zijn onder andere: het realiseren van fietsveilige steden, transparantie van de zorgkosten en het in kaart brengen van stedelijke vervuiling.

De door informatiespecialisten geleide groep groeide in het afgelopen jaar van 4 naar 23 steden en werkt op het voorfront van stedelijke technology. Deze National League of Cities werkt daarnaast ook samen met Jumpstart Foundry.

De campagne zal diverse vastgelegde aandachtsgebieden adresseren. Het programma voor 2015 poogt het creatieve inzicht van bedrijven en ondernemers te richten op het aanpakken van uitdagingen in de volksgezondheid, op het snijvlak tussen technologie en overheidsdienstverlening.

Daarbij is er daadwerkelijk geld vrijgemaakt om de zaken in gang te zetten, meer dan 200.000 dollar. De leidende groep steden neemt een actieve rol op zich. In plaats van wachten tot bedrijven uit zichzelf iets maken dat (toevallig) iets oplevert voor de stad, willen de steden helpen deze programma's vorm te geven en te financieren.

De oprichtende steden (Palo Alto, Boston, Nashville en Raleigh) begonnen de MCIC voornamelijk om het zogenaamde "Maandagochtend"-probleem tegen te gaan. Oftewel: wat doe je als een hackathon is afgelopen? Want alhoewel hackathons vaak een goede manier zijn om burgers (met name de technologie-geïnteresseerde millennials) te betrekken, zijn de oplossingen die ze voortbrengen vaak ongefocust en onhoudbaar op de lange termijn.

Dit maakt de Multi-City Innovation Campaign zo uniek. Door specifiek in te zetten op urgente lokale problemen vormen de steden een actieve partner in de ontwikkeling van de oplossingen en technologiën die hun gemeenschap potentiëel kunnen veranderen.

Een van de belangrijkste ingrediënten hierbij is de Open Data beweging die in opkomst is in veel Amerikaanse steden. Open Data dient als de ruggegraat van de technologische ontwikkeling rondom de overheid. Het zorgt niet alleen voor transparantie en openheid, maar ook voor kansen om overheid, burgers en belanghebbenden samen te laten werken.

Buiten het functionele karakter binnen een steeds meer van apps afhankelijke samenleving stuwt datavergaring en -analyse ook het proces van verandering van de manier waarop we over onszelf denken en hoe we met elkaar omgaan.

Door de toegang tot zinvolle en bruikbare informatie ontstaat een compleet nieuwe wereld, en steden vormen voorfront van deze veranderende omgeving. Open Data is fundamenteel voor de centrale rol die steden vervullen als leiders van innovatie in de 21ste eeuw.

De Multi-City Innovation Campaign van dit jaar zal deze data aanboren, met een focus op een bredere inzet voor volksgezondheid en gezonde leefomgeving. Om te helpen bij het Open Data vraagstuk wordt er samengewerkt met Esri en Socrata om de datasets, die noodzakelijke zijn voor de ontwikkeling, aan te leveren.

Toevoeging van de vertaler: Johan Groenen is data services en app ontwikkelaar bij APItecture Rotterdam.
Toevoegin van de schrijver: BrooksRainwater is directeur van het Center for City Solutions and Applied Research van de National League of Cities. David Maloney is de Manager of Strategic Partnerships van de National League of Cities.

Service oriented design

Webontwikkeling, je komt er niet meer omheen als modern bedrijf. Of het nu gaat om de bedrijfswebsite, een app waarmee klanten de beschikbaarheid van een product kunnen opzoeken of een online urenregistratie voor personeel, vaak zijn bedrijven bij het laten maken van een webapplicatie overgeleverd aan het technisch inzicht van ontwikkelaars.

Toch is het belangrijk om eisen te stellen aan de manier waarop deze producten worden gebouwd. Deze zogenaamde "software architectuur" is bepalend voor de mate waarin de software kan meeveranderen met de ontwikkelingen van zowel het bedrijf als de gebruiker.

Om dit te verduidelijken wil ik drie software architecturen uitlichten: monolitisch, modulair en service georiënteerd.

Monolitische software

In de meest basale situatie is er weinig structuur te herkennen in de code waaruit de software is opgebouwd. Dit klinkt slecht, en dat is het ook. Maar de praktijk leert dat er veel slechte code is. Enerzijds omdat niet ieder project een goede architect heeft. Anderzijds omdat het veel tijd en moeite kost om bij iedere update de architectuur in het oog te houden.

In dit soort situaties wordt vaak het woord "monolitisch" gebruikt, of "spagetti code", omdat de code dusdanig ongeordend door elkaar loopt dat het een bord spagetti lijkt. Vaak is de opbouw zo slecht te lezen dat zelfs de programmeur die de code geschreven heeft na een tijdje niet meer weet welk stukje code wat doet.

Monolitisch is wat we noemen een "anti-patroon". Maar de meeste services beginnen monolitisch, omdat een prototype zo snel te bouwen is en herbruikbaarheid of leesbaarheid van de code in eerste instantie vaak van ondergeschikt belang is. De meeste services eindigen ook monolitisch, omdat naar mate de verwachte levensduur van de service korter wordt, het belang van onderhoudbaarheid kleiner wordt. Helaas blijkt maar al te vaak dat monolitische services langer gebruikt blijven worden dan de verwachte levensduur en dat onderhoud een zeer tijdrovend en daarmee duur proces wordt.

Modulaire service

In een modulair ontwerp wordt de code opgebouwd uit onafhankelijke brokken, die modules worden genoemd, of libraries, of plugins, of bundles, of nog anders. Deze modules zorgen voor een duidelijke opsplitsing van de code in functionele brokken, dat wil zeggen: iedere module is verantwoordelijk voor een bepaalde functionaliteit.

Het voordeel van modulair programmeren is dat modules kunnen worden hergebruikt in volgende projecten, onafhankelijk van elkaar kunnen worden getest en dat een module, mits de werking ervan goed is gespecificeerd (bijvoorbeeld door een gedefinieerde interface), eenvoudig kan worden vervangen door een andere module die dezelfde werking heeft.

Daarnaast maakt een modulaire opzet duidelijk welk deel van de code verantwoordelijk is voor welke functionaliteit en kan de module onafhankelijk van de rest van de code worden aangepast of vervangen, zo lang de interface maar hetzelfde blijft.

Modules worden vaak gedeeld tussen ontwikkelaars, zodat niet iedereen voor zich weer opnieuw dezelfde functionaliteit hoeft te programmeren. Het voordeel hiervan is duidelijk, maar één van de nadelen is dat er hierdoor ook veel code wordt gebruikt waarvan het vaak niet helemaal duidelijk is wat de code precies doet en wie de code beheert. Dit geldt dubbel voor closed source code (en software).

De meest recente ontwikkeling is dat modules als producten worden gebrand: er wordt zorgvuldig een merk gebouwd om ontwikkelaars ervan te overtuigen dat A dé module is om X te doen. Dit heeft vaak te maken met de interface: de meeste modules voor dezelfde functies zijn namelijk niet precies hetzelfde (vaak simpelweg uit esthetische overwegingen van de programmeur), waardoor degene met de meeste aanhang bepaalt wat de standaard wordt.

Service georiënteerd

In plaats van dezelfde modules voor ieder project weer opnieuw te installeren en te gebruiken, kan er ook worden gekozen voor een andere route, namelijk die van service oriented design. In plaats van een lokale module die functie X uitvoert, wordt een service aangeroepen die functie X uitvoert.

Dit zorgt wel voor meer communicatie over het netwerk, omdat er voor iedere functie berichten heen en weer gaan tussen de services. Vaak kost dit heen en weer sturen ook meer tijd dan een lokale module aanroepen en kan het wel eens mis gaan, bijvoorbeeld omdat de service voor functie X onbereikbaar is.

Het voordeel is wel dat iedere programmeur zich kan focussen op de werking van zijn eigen service en dat iemand anders verantwoordelijk is voor de service die wordt aangeroepen. Ook is het duidelijk wie de aanbieder van de service is en kunnen er dus afspraken gemaakt worden over verantwoordelijkheden.

Daarnaast kunnen meerdere projecten gebruik maken van dezelfde dedicated service, waardoor onderhoud en optimalisatie daarvan de moeite waard kan worden (bijvoorbeeld omdat er per project voor de service betaald wordt) en informatie tussen projecten of producten via de service kan worden uitgewisseld.

Combineren en integreren

Een ander voordeel van service oriented design is dat een services elkaars data kunnen gebruiken en combineren. Denk hierbij bijvoorbeeld aan het analyseren van Twitterberichten om te zien wat trending topics zijn voor een bepaald bedrijf, of het combineren van weerinformatie en verkoopcijfers om daar relaties tussen te vinden.

Er zijn veel services beschikbaar, sommige gratis, anderen op abonnement. Weerinformatie, verkeersdrukte, social media berichten, adresinformatie, etc. En deze lijst wordt groter en groter, naar mate meer personen en bedrijven hun data beschikbaar stellen middels web services.

De mogelijkheden zijn onbegrensd. Bij APItecture helpen we bedrijven deze mogelijkheden te verkennen en optimaal te benutten.

Ontkoppeling gebruikersinterface

Omdat de functionaliteit geen onderdeel meer is van de applicatie, maar een op zichzelfstaande service, kunnen meerdere applicaties dezelfde service gebruiken. Dat wil bijvoorbeeld zeggen dat het eenvoudig is om een single purpose web app te maken voor een hele specifieke toepassing, zonder dat dit invloed heeft op bestaande apps.

Zo ontwikkelde APItecture Vertrek van Treinen, een mobiele web app die op basis van NS reisinformatie, de tijd en de mobiele locatie van de gebruiker de meest relevante treininformatie laat zien, zonder dat een app gedownload hoeft te worden of er informatie moet worden ingevoerd door de gebruiker.

Businessmodel

Het service oriented design model is niet alleen bruikbaar in webontwikkeling. Steeds meer bedrijven zien in dat ook hun services en interne processen volgens dezelfde principes kunnen werken. Hierdoor kunnen ze een noodzakelijk deel van hun bedrijfsproces ook aanbieden als een dedicated service aan andere bedrijven of deze services outsourcen naar een bedrijf dat zich daarin gespecialiseerd (= geoptimaliseerd) heeft.

(c) 2015 www.apitecture.nl