SharePoint

SharePoint 2013 – Een nieuwe manier van denken

28 november 2012

De afgelopen dagen was ik, zoals velen van jullie waarschijnlijk, aanwezig in Amsterdam op de SharePoint Connections dagen. Goed, het is geen Vegas, maar het was nog steeds erg leuk. Uiteraard ging het weer veel over de cloud, Office 365, het app model en nog meer van hetgeen we al eerder uit Vegas hadden gehoord.

thinking

Een applicatie platform

Een belangrijk statement werd gemaakt door meerdere sprekers. In het begin was SharePoint een applicatie die je installeerde, de mogelijkheden om maatwerk te ontwikkelen waren beperkt. Later begon het product zich te ontwikkelen als platform. Vooral de versies 2007 en 2010 worden meer gezien als applicatie platforms dan applicaties an sich. Wij ontwikkelaars maakten ons maatwerk op en in SharePoint. En hoewel dat niet altijd even goed uitpakte (of uitpakt eigenlijk), zo gingen we te werk.

Dat maakte “de SharePoint ontwikkelaar” een ras apart. Een echte “je moet ervan houden” kwestie. Vanwege de leercurve,  de workarounds die je soms moet toepassen, vanwege het feit dat het gewoonweg niet altijd zo makkelijk is. Aan de ene kant is dat prima, want daardoor komen wij als SharePoint ontwikkelaars aardig makkelijk aan werk. Zelfs in dit soort moeilijke tijden. Aan de andere kant is het jammer dat er daardoor vaak een gat ontstaat tussen “de SharePoint wereld” en de rest van het applicatie landschap wanneer het gaat om zaken als architectuur, ontwikkeling en beheer.

Een applicatie

Vanaf versie 2013 komt daar verandering in. Want SharePoint wordt niet meer gezien als een platform. We zijn weer terug bij af: SharePoint is een applicatie. Een applicatie met een erg uitgebreide API weliswaar, maar toch: een applicatie. Dat klinkt misschien niet heel erg schokkend, toch heeft dat best wat impact.

In het oude model (de WSP’s) deden ontwikkelaars hun best om een oplossing zoveel mogelijk in SharePoint onder te brengen. We gebruiken SharePoint lijsten om gegevens in op te slaan, haken in op event handlers en voerden allerlei interessante bewerkingen uit op een site om onze oplossing erin te integreren. Dat leverde soms hele interessante oplossing op, in iedere mogelijke betekenis van het woord. Mijn punt is: oplossingen integreerden echt in SharePoint.

Met het nieuwe app model worden we juist verzocht om oplossingen te maken die los staan van SharePoint. Je code draait buiten SharePoint om. En hoewel je nog steeds de mogelijkheid hebt om lijstjes e.d. aan te maken, doe je dat in een speciaal app web,  niet meer in de site waar je gebruiker je app heeft toegevoegd. Ik zeg niet dat het onmogelijk is; ik zeg dat het model het zo voorschrijft. Het hoe en waarom is inmiddels wel duidelijk denk ik (zie anders mijn vorige blogs).

Architectuur vraagstukken

Dit betekent dus dat apps weer los komen te staan van SharePoint. De integratie waar we inmiddels aan gewend waren verdwijnt weer, voornamelijk om cloud oplossingen zo stabiel mogelijk te kunnen maken. Ontwikkelaars en architecten krijgen daarmee nieuwe dillema’s. Stel dat je een app oplevert, gehost in Windows Azure. Ga je dan je data nog opslaan in een SharePoint lijst, of gebruik je een Windows Azure SQL database? Microsoft hoopt dat normale web ontwikkelaars ook apps voor SharePoint gaan bouwen. Die zullen er zeer waarschijnlijk niet voor kiezen om met SharePoint lijstjes te gaan experimenteren. Ik kan me daar ook wel iets bij voorstellen. Klets je liever met je eigen datalaag, of met een API die je niet zo goed kent?

App of webapp?

In een van de sessies die ik heb gezien liet de spreker zien hoe eenvoudig het is om een webshop, draaiende in Windows Azure, te koppelen aan SharePoint. Die koppeling bestond uit het automatisch inloggen van de gebruiker. Bij het bestelproces automatisch het e-mail adres invullen en naderhand een post op de activity feed plaatsen. Op zich heel aardig, maar feitelijke is het gewoon een webshop. En deze webshop post een berichtje naar SharePoint in plaats van Twitter.

Mijn punt is: een SharePoint app is al snel een web applicatie. Het installeren van een app is niet veel meer dan een URL koppelen aan een plaatje waar de gebruiker op kan klikken. Goed, je krijgt er wat gratis single sign-on code bij en kunt chrome toevoegen waardoor het nog enigszins lijkt alsof je app in SharePoint hangt. Maar het loosely coupled karakter van deze oplossingen maakt het dat je app niet meer afhankelijk is van SharePoint, en andersom. Ik zeg niet dat ik dat model slecht vind (of minder goed). Ik zeg ook niet dat de oude manier mijn voorkeur heeft; die had ook zeker z’n nadelen. Wat ik wel wil meegeven is dat architecten en ontwikkelaars hun denkwijze echt compleet om zullen moeten gooien.

To app, or not to app

En dan zijn er nog de bestaande WSP oplossingen. Wat ga je daar mee doen? Ombouwen is vaak een kostbare oplossing, want feitelijk betekent dat voor een groot deel opnieuw beginnen. En ja; die oplossingen werken ook in 2013 nog als het goed is. Maar uiteindelijk moet je waarschijnlijk toch een keer om, ik verwacht niet dat WSP support nog jarenlang aangehouden gaat worden. Laat staan dat er nog ontwikkeling gaat plaatsvinden op dat gebied. En ga je apps met WSP’s mixen, kun je dan nog wel een consistente gebruikerservaring maken?

Wat zeg jij tegen de volgende klant die een nieuwe SharePoint oplossing wil hebben in zijn bestaande omgeving? Ga je ‘m aanraden om op 2013 over te stappen en apps te bouwen, of ga je toch nog met WSP’s aan de slag?

Kortom: een hoop vragen. Vragen waar in de komende maanden antwoorden op gaan komen. Doordat we aan de slag gaan met SharePoint 2013, bestaande omgevingen en migraties. En de eerste apps worden al richting de store gerold. Een ding is in ieder geval duidelijk: er is verandering op komst!

You Might Also Like

Geen reacties

Plaats een reactie