PAAS & de toekomst van programmeren (2)

PAAS, programmeren en crowdsourcing

Het eerste deel van PAAS & de toekomst van programmeren sloot ik af met het idee dat in de toekomst eindgebruikers (hun) applicaties zouden kunnen schrijven. Als we dit combineren met de technologische mogelijkheden van internet zoals PAAS en wereldwijd bereik van potentiele ontwikkelaars, komen we bij een interessante optie: crowdsourcing.

Conform Wikipedia verstaan we onder crowdsourcing:

…gebruikt om een recente ontwikkeling aan te duiden, waarin organisaties (overheid, bedrijven, instituten) of personen gebruikmaken van een grote groep niet vooraf gespecificeerde individuen (professionals, vrijwilligers, geïnteresseerden) voor consultancy, innovatie, beleidsvorming en onderzoek.

Hierbij is dus het idee om (groepen) mensen aan het werk te zetten om voor jou organisatie applicaties te gaan bouwen. Dit kunnen eigen personeels leden zijn die applicaties bouwen om hun werk beter te kunnen uitvoeren, maar kunnen ook andere mensen zijn. De verleiding tot het bouwen van een applicatie komt vaak in de vorm van een wedstrijd met een (geld) prijs. Daarnaast is het veel deelnemende ontwikkelaars te doen om de eer en de status.

Een aantal ontwikkelingen in de afgelopen jaren maken het bovenstaande echt mogelijk;

Kennis

In 2007 concludeerde de Yankee Group al dat eind gebruikers steeds meer technische kennis bezitten en steeds meer ‘tech-savvy’ worden. Dit beeld werd versterkt met het feit dat steeds meer thuis elektronica zijn intrede deed binnen bedrijven. Dit begon met het zelf mee brengen van een laptop en telefoon/smartphone en de komst van de iPad heeft dit alleen nog maar versterkt. We kunnen niet ontkennen dat generaties die na ons volgen ook vele malen handiger zijn met bijvoorbeeld de PC dan wij zelf.

Platform As A Service

Zoals in het eerste deel vermeld geeft een PAAS omgeving zoals Force.com of Google App Engine, de ontwikkelaar de mogelijkheid om zijn applicatie te bouwen zonder zich druk te maken over de onderliggende technische infrastructuur. Mocht zijn applicatie een succes worden, dan hoeft hij zich ook niet druk te maken over het opschalen van die infrastructuur. Succesvolle diensten kunnen heel snel groeien, denk bijvoorbeeld aan Playfish; Zij bouwde een aantal succesvolle games voor Facebook en iPhone en schoten binnen enkele maanden naar 50 miljoen gebruikers (en werden gekocht voor $300 miljoen door EA). Zonder een flexibel cloud platform was dat niet mogelijk geweest.

Nieuwe programmeer technieken

De manier van applicatie ontwikkeling is veranderd in de afgelopen jaren. Daarnaast zijn er veel tools en frameworks beschikbaar gekomen die het ‘kloppen van code’ makkelijker hebben gemaakt. Er komen ook steeds meer SDK’s beschikbaar die het schrijven van een applicatie voor bijvoorbeeld de iPad makkelijker maken.

(In het vorige deel van de blog is hier voor een deel ook al naar gekeken.)

API’s

API staat voor Application Programming Interface en is een verzameling definities op basis waarvan een computerprogramma kan communiceren met een ander programma of onderdeel. Het vormt zeg maar het onafhankelijke koppelvlak tussen aanbieder en afnemer.

Applicaties zijn leuk, maar het gaat uiteindelijk om de data en informatie die er mee bewerkt, bekeken en geproduceerd kan worden. Als een applicatie ontwikkelaar een applicatie gaat bouwen, dient deze wel te weten op welke manier hij de data kan benaderen en welke opmaak deze data heeft. Hierbij komen API’s in beeld; een API definieert de toegang tot de functionaliteit die er achter de API schuil gaat. De buitenwereld kent geen details van de functionaliteit of implementatie, maar weet dankzij de API wel hoe deze kan worden aangesproken.

Steeds meer organisaties en bedrijven publiceren hun data via een API op internet. Door middel van het combineren van API’s kunnen applicatie bouwers hun applicaties verrijken met deze informatie bronnen. Denk hierbij aan de combinatie van Google Maps en foto’s op Flicker via hun API’s. (Dit worden ook wel Mashups genoemd).

Er zijn inmiddels diverse producten op de markt voor de bouw, publicatie en beheer van API’s. Voorbeeld: Apigee (waar je ook uitgebreide kennis over API’s kunt vinden.)

(O ja, en als je die API(’s) dan gaat bouwen… dan graag een RESTfull API…)

Opensource

Over opensource kunnen we lang discussiëren, maar in een model waarbij crowdsourcing voor applicatie bouw word toegepast word de meeste winst behaald door de applicatie onder een opensource model te ontwikkelen. Het beschikbaar hebben van de broncode, levert inspiratie voor andere ontwikkelaars, levert snellere ontwikkeling door hergebruik van code en veiligere applicaties door dat 10 ontwikkelaars meer zien dan 1.

Uiteraard bestaan hier hele, bijna religieuze, debatten over… maar uiteindelijk past dit gewoon goed bij elkaar. Luister maar naar Simon Wardley. (opensource na +/-20min)

Versie- en broncodebeheer

Goed versie- en broncodebeheer is noodzakelijk voor het beheer en onderhoud van de gebouwde applicatie. Het zorgt voor betere onderlinge samenwerking tussen ontwikkelaars, goede registratie en opvolging van software fouten en betere documentatie. In combinatie met opensource geeft het deelnemers aan een competitie ook de mogelijkheid om code en applicatie delen te hergebruiken en sneller een applicatie te kunnen leveren.

Men kan een eigen systeem selecteren en opzetten of gebruik maken van de vele systemen die op internet al beschikbaar zijn. (Tip: gebruik GitHub… het is 1 van de betere op dit moment… en ja deze draait ook ‘in de cloud’, maar is ook geschikt voor closed-source)

Wedstrijdplatform

Om de competitie voor de applicatie ontwikkeling te houden, dient men een wedstrijdplatform te creëren. Hier bij gaat het in de basis om een systeem waarbij
alle benodigde informatie rond de competitie te vinden is en men zich kan inschrijven. Het is nog beter om dit systeem te verrijken team omgevingen die samenwerking bevorderen en verbeteren en met ranglijsten die het spel en uitdagingselement versterken. Voorbeeld: http://www.challengepost.com/

Laten we na al deze theorie en benodigdheden enkele voorbeelden bekijken van crowdsourcing en app ontwikkeling:

Enkele voorbeeld scenario’s

Scenario 1; basic

(klik voor groter formaat)

De organisatie heeft een probleem (of liever ‘een uitdaging’). Ze organiseren een competitie op internet. Deze word opgepakt door tientallen ontwikkelaars. Zij gebruiken alle beschikbare middelen op internet zoals Public PAAS en data die vrij aangeboden word via API’s, om de uitdaging op te lossen voor de organisatie. De winnende applicatie worden beschikbaar gesteld aan de organisatie en zijn eindgebruikers. Dit werkt voor organisaties die nog niet klaar zijn om zelf hun informatie te delen, maar wel kansen zien met de reeds beschikbare data op internet.

Scenario 2; in-huis ontwikkeling

(klik voor groter formaat)

In dit scenario is de competitie binnen de eigen organisatie georganiseerd. De eigen organisatie geeft (alle) medewerkers toegang tot de benodigde middelen zoals een PAAS omgeving, API’s, ontwikkel tools. De winnende applicaties worden via de interne App Store aangeboden aan de eindgebruikers.

Hierbij is het voordeel dat eigen mensen worden uitgedaagd om een applicatie te bouwen die ze in staat stelt zelf beter hun werk te doen (of die van hun collega’s). Dit werkt echter alleen als de organisatie groot genoeg is om ook voldoende ontwikkel potentieel te hebben binnen de zittende medewerkers. Voordeel: veel kennis over eigen werk en processen. Nadeel: hoe minder potentiele deelnemers, hoe lager de kans op kwaliteit en kwantiteit.

Scenario 3; ontsluiting via API

(klik voor groter formaat)

Als de organisatie zijn informatie bronnen ontsluit via API(‘s) geeft dit de mogelijkheid om een competitie op internet te organiseren. Willekeurige ontwikkelaars op internet hebben de mogelijkheid om slimme dingen te doen met de aangeboden data en deze eventueel te combineren met andere data op internet (van andere aanbieders). De deelnemende ontwikkelaars kunnen natuurlijk ook eigen medewerkers zijn. De gemaakte applicaties en apps kunnen via de organisatie eigen App Store aangeboden worden aan de medewerkers.

Uiteraard zijn er diverse variaties op deze scenario’s te bedenken, maar het gaat even om het idee en een voorbeeld.

En beheer dan ?

Zodra de competitie afgelopen is, moeten er misschien bepaalde applicaties in beheer genomen worden. Hierbij willen we uiteraard niet in het klassieke probleem stappen dat beheer bij de uitvoeringen van een project vergeten word.

Het ontwikkelen op basis van opensource en het beschikbaar hebben van de bron code, maakt het in beheer nemen makkelijker. Sommige organisaties laten bugfixes en door ontwikkeling van de applicatie geheel aan de gemeenschap op internet over. Sommige nemen de applicatie in eigen beheer, of een mix van deze twee.

Bij elke competitie of wedstrijd gelden regels. Het toepassen van regels en kaders voor een applicatie ontwikkel competitie maken het mogelijk om het beheer in goede banen te leiden;

• Indien de applicatie zelf in beheer genomen word, moet er wel kennis zijn van de gebruikte frameworks en programma talen. Hier kunnen dus regels en kaders voor gesteld worden.
• Applicaties die in een PAAS omgeving draaien, kunnen daar gewoon blijven. De omgeving voor ontwikkeling in een Google App Engine omgeving is niet anders dan de productie omgeving. Afhankelijk van gekozen frameworks en programma talen kunnen applicaties uiteraard ook verhuisd worden. Hier kunnen kaders voor gesteld worden.
• Ook kan er van de bouwer van de winnende applicatie bepaald onderhoud verwacht worden. Een goed versiebeheer systeem en software bibliotheek kan hier een goede rol bij spelen.

De vraag is echter wel of alle (winnende) applicaties in beheer genomen moeten worden. In een wereld met veel, zelf gebouwde, applicaties met micro functionaliteit zal de levensduur van deze applicaties ook korter zijn. Deze denkwijze zit in de zelfde lijn als de Bring Your Own Device (BYOD) gedachte.

Via een enterprise App Store kan de organisatie hierbij applicaties aanbieden die onder de ondersteuning vallen van de ICT afdeling en nodig zijn voor de core business processen van de organisatie. Overige applicaties vallen onder eigen verantwoordelijkheid zoals bij de BYOD gedachte.

Voorbeelden in de praktijk

Dat deze voorbeeld scenario’s niet eens zo ver gezocht zijn, bewijst de Amerikaanse overheid. Het leger draaide daar in 2010 een Apps4Army project waarbij ze applicatie ontwikkeling en interne crowdsourcing combineerde. De stad New York draait voor de tweedemaal in 2011 zijn succesvolle NYC BigApps Competition. Twee succesvolle voorbeelden:

Apps for the Amry

Op 1 maart 2010 kondigde het Amerikaanse leger het Apps4 Army project aan:

Omdat de competitie intern gehouden werd, is er niet heel veel bekend over de gebruikte techniek. Wel is bekend dat de US Army een eigen PAAS omgeving beschikbaar stelde genaamd RACE:

The service, provided by the Defense Information Systems Agency and known as the Rapid Access Computing Environment (RACE), offers access to on-demand virtual Windows and Li
nux development environments. Participants will be able to pursue Web application development using all available programming languages supported by Windows Server and the Linux, Apache, MYSQL and PHP (LAMP) frameworks. They also will be able to build emulated Blackberry, iPhone and Android applications.

Forge.mil will serve as the collaborative software repository for competing teams. The tools inherent in milBook and AKO will facilitate the cross-pollination of ideas, problems and solutions relevant to the Apps for the Army initiative.

Naast de RACE omgeving was er ook toegang tot standaard data sets. Daarnaast leverde men een softwarebibliotheek (&versie beheer systeem), voor de opslag en beheer van de gemaakte bron code (Forge.mil).

Meer achtergrond over Apps4Army werd tijdens O’reilly Gov 2.0 Expo 2010 gegeven:

Nadat deze eerste ronde succes vol is afsloten met enkele tientallen bruikbare applicaties in zeer korte tijd, is men nu bezig te kijken hoe er een openbare competitie gehouden kan worden om meer en betere applicaties voor het Amerikaanse leger te krijgen. Deze zal in 2011 van start gaan.

NYC Big Apps

De stad New York organiseert voor de tweede maal hun NYC BigApps Competition;

For the second year, the City of New York is improving the way it provides information and transparency to citizens. But delivering great information requires great tools. The NYC BigApps Competition will reward the developers of the most creative, best implemented, and impactful applications for delivering information from the City of New York’s NYC.gov Data Mine to interested users. Software developers will compete for $20,000 in cash, wide exposure for their work, and a meeting with the Mayor. Submissions may be any kind of software application, be it for the web, a personal computer, a mobile handheld device, SMS, or any software platform broadly available to the public.

Ze laten het ontwikkelplatform open en daarmee de keuze aan de ontwikkelaar. Deze kan er voor kiezen een website, een Apple App of bijvoorbeeld een Andriod App te bouwen. Deze bouw en het opschalen daar van kan uiteraard gedaan worden op een PAAS platform zoals Google’s App Engine. De stad New York beidt enkel een koppelvlak voor hun data in de form van NYC.gov Data Mine. Hier leveren ze rauwe data catalogussen in diverse formaten zoals XML, CSV en RSS.

Recent heeft de landelijke overheid in de US dit idee uit New York overgenomen en http://challenge.gov/ gelanceerd.

Toekomst?

Dit zijn slechts twee bewezen voorbeelden van applicatie ontwikkeling via crowdsourcing. Deze manier van ontwikkelen lijkt een aantal uitdagingen aan te pakken waar grote organisaties al langer mee worstelen:

• Doorlooptijd voor applicatie ontwikkeling; opgelost via micro-functionaliteit die in korte tijd geleverd word uit een grootte ontwikkelaar gemeenschap.
• Kennis; met name bijhouden van leading-edge kennis (talen, frameworks, nieuwe devices).
• Innovatie; de internet gemeenschap kan altijd veel meer (en mogelijk betere) ideeën genereren dat enkel de eigen organisatie
• Beter beantwoorden van de wens van de eindgebruiker; de werkvloer laten bepalen wat er nodig is om hun werk goed uit te voeren. Bij de overheid levert dit potentieel ook het beter bedienen van de burger.
• En uiteindelijk ook de reductie van kosten…

Het is duidelijk dat de mogelijkheden die PAAS biedt en de ontwikkelingen die op dat vlak plaats vinden op dit moment, hier een belangrijke rol bij spelen.

Met de technisch beter onderlegde eindgebruikers (die meer en meer de arbeidsmarkt betreden), met de technologie die het makkelijker maakt om eigen applicaties te bouwen en steeds meer organisaties die hun data ontsluiten, lijkt er een goede toekomst weggelegd voor deze manier van ontwikkelen.

Wie neemt de eerste stap binnen de Nederlandse overheid ? meneer Hillenaar ?

Meer:

• Waar gaat dit alles heen?: Challenges: Crowd-sourcing Apps & Gov Innovation. Een inspirerende video.
• Meer API: 5 Predictions for APIs in 2011