Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Startups hebben vaak herkenbare problemen

 

Computable Expert

drs. Marc van Neerven
CTO, Neerventure B.V.. Expert van Computable voor het topic Start-ups.

Start-ups komen door de manier waarop ze hun propositie in de markt willen zetten vaak technisch in de problemen. Dit stuk beschrijft enkele van de problemen en hoe ze te voorkomen.

Als Interim cto raak ik vaak betrokken bij start-ups die al redelijk onderweg zijn met een outsourced bedrijf dat een mvp (minimum viable product - zie 'The Lean Startup' - Eric Ries) voor hen bouwt.

In mijn ervaring hebben veel start-ups een geweldig idee, maar maken ze vaak de fout om te snel naar een outsourced partner te zoeken die de mvp wel eventjes voor ze bouwt. Op zichzelf niet erg, maar er kunnen wel problemen optreden. Hier zijn er een paar, en hoe je ze voorkomt.

1. Gebrek aan wederzijds begrip (ook wel bekend als 'lost in Translation').
Je hebt als start-up veelvuldig overleg gehad met de bouwer, maar de opgeleverde software is niet echt volgens verwachting. Hoezeer je de eisen ook probeerde over te brengen, het blijkt dat de bouwer het niet goed genoeg begrepen heeft, of dat er blijkbaar iets is 'blijven steken' bij de overdracht. Het resultaat is een langer traject tot lancering, en hogere kosten.

2. Onvoldoende schaalbaarheid.
Je komt er bij de lancering achter dat het ontwikkelde product, hoe leuk het ook werkt, onvoldoende schaalt bij die plotselinge belasting na je succesvolle marketingcampagne. Hoogst frustrerend om op die manier slachtoffer van je eigen succes te worden.

Hoe is dat zo gekomen? Misschien heeft het ermee te maken dat de bouwer jouw mvp niet echt ziet als product, maar als project. Ze kijken simpelweg niet naar een lange termijn levenscyclus en zijn daarom niet gefocust op het bouwen van een solide, flexibele en duurzame architectuur die bovendien meeschaalt met je groei, omdat ze geen eigenaar zijn.

Deze situatie is zo mogelijk nog erger, want de kern van je software zou wel eens inherent ongeschikt kunnen zijn.

3. Onvoldoende platform omarming.
Cloudplatform-selectie is niet altijd een volledig objectief proces. Het kan bijvoorbeeld zijn dat je bestaande commitments hebt, of op de één of andere manier gesponsord wordt. Of je partnert met bedrijven die aan een bepaalde cloud gelieerd zijn, of er een persoonlijke connectie mee hebben.

Bij de keuze van een bedrijf dat je apps gaat bouwen zijn er echter vaak andere krachten aan het werk. Het vreemde hierbij is dat deze vaak volledig onafhankelijk blijken te zijn van de cloud selectie. Raar maar waar.

Ervaring

Een ontwikkelbedrijf dat geen of weinig ervaring heeft met de specifieke aspecten van de gekozen cloud is niet in staat om de volledige rijkdom van dat cloudplatform te omarmen. Of ze zijn zo gewend om dingen op een bepaalde manier te doen dat ze 'vergeten' te kijken naar de native cloud alternatieve aanpak. Als dat vervolgens betekent dat ze daarvoor een 'non-managed' dienst moeten gebruiken en zo dus niet optimaal van de kracht van de cloud profiteren, nemen ze dat op de koop toe. Tco is immers niet hun probleem.

Het eindresultaat is dan een oplossing die niet ideaal is, met componenten die niet automatisch schalen en waar je zelf onderhoud aan hebt (non-managed). Of met componenten die 'buiten' die cloud staan, waardoor je extra 'egress'-kosten hebt (data transfers naar buiten de cloud kosten vaak veel extra).

Tenslotte is het nog zo dat, wanneer je bijvoorbeeld profiteert van sponsoring zoals geboden wordt via Microsoft BizSpark, de verkregen sponsoring niet geldt voor services buiten die cloud. Wéér extra operationele kosten dus, maar wéér niet zo spannend voor de bouwer....

Conclusie

Je mvp vormt de eerste indruk die je doelgroep van je product krijgt. Je weet wat ze zeggen van eerste indrukken...

Het is cruciaal dat start-ups een ervaren cto (chief technical officer) in de beginfase van een mvp bij de plannen betrekken, om dit soort fouten te voorkomen. Een cto kan de intermediair zijn die je functionele eisen kan vertalen, zodat een ontwikkelbedrijf veel minder ruimte heeft voor eigen interpretatie, de architectuur gebouwd wordt met schaalbaarheid in gedachten, en modulair en duurzaam is. Daarnaast kan de cto ervoor zorgen dat native cloud features goed gebruikt worden.

Over het algemeen leidt gebrek aan kennis van een cloud ecosysteem tot hogere servicekosten, dus investeren in een optimaal performante kosten-efficiënte infrastructuur is zeer gewenst.

(Dit artikel is vertaald uit het Engels en is eerder verschenen in LinkedIn Pulse, op 23 mei 2017)

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/6045863). © Jaarbeurs IT Media.

?


Lees meer over


Partnerinformatie
 

Jouw reactie


Je bent niet ingelogd. Je kunt als gast reageren, maar dan wordt je reactie pas zichtbaar na goedkeuring door de redactie. Om je reactie direct geplaatst te krijgen, moet je eerst rechtsboven inloggen of je registreren

Je naam ontbreekt
Je e-mailadres ontbreekt
Je reactie ontbreekt
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×