De laatste decennia volgen technologische ontwikkelingen, en daarmee veranderende wensen van uw klanten, elkaar steeds sneller op. In diverse industrieën zijn het juist de ondernemingen die hun voordeel weten te halen uit het gebruik van platform-concepten het meest succesvol. Een nog relatief nieuw toepassingsgebied van dit concept, it-platformen, kan ook voor jouw onderneming beslissend zijn!
Buiten de it zijn ontwikkelplatformen al geruime tijd in gebruik. Fabrikanten voegen nieuwe toepassingen vaak toe aan bestaande producten. Denk hierbij bijvoorbeeld aan de ontwikkeling van de mobiele telefoon, waaraan in de laatste jaren steeds meer nieuwe functies zijn toegevoegd. De eerste modellen konden uitsluitend bellen en sms’en, maar tegenwoordig worden smartphones ingezet als mp3-speler, navigatiesysteem en camera. Nieuwe modellen bouwen hierbij steeds voort op de bestaande modellen.
Zo kan er met kleine aanpassingen (bijvoorbeeld een betere camera) een totaal nieuw product worden gelanceerd. Hergebruik van bestaande componenten leidt in dit geval tot een veel kortere time-to-market en lagere kosten, dan wanneer er een geheel nieuw toestel ontwikkeld zou moeten worden. Dit maakt het mogelijk om snel in te spelen op nieuwe trends in de markt, en een betere aansluiting te hebben met klantenwensen, met een verbeterde concurrentiepositie tot gevolg.
Kosten besparing
In de auto-industrie is het gebruik van platformen ook duidelijk zichtbaar. Een goed voorbeeld is de Volkswagen Groep. Zij gebruiken vergelijkbare componenten in meerdere merken en modellen. Denk hierbij aan de overeenkomsten tussen Skoda, Volkswagen en Audi, die technisch grotendeels identiek aan elkaar zijn. Ook daar ligt de focus op het verlagen van kosten, versnellen van time-to-market en verbeteren van de concurrentiepositie.
Modular Transverse Matrix (MQB) is de belichaming van de filosofie van de Volkswagen Groep om auto’s te produceren als een platform.
De opkomst van Platform-as-a-Service
Met de opkomst van PaaS kunnen deze principes nu ook worden toegepast door een it-organisatie in het ontwikkelen van nieuwe producten. Bij het ontwikkelen van applicaties voor bedrijfsspecifieke processen is het daardoor niet langer nodig om de it-infrastructuur en programmatuur steeds opnieuw te ontwikkelen. Door gebruik te maken van een volwassen ontwikkelplatform zijn standaard applicatie componenten (bijvoorbeeld voor workflow, autorisatiemodel, user interface, et cetera), data en interfaces herbruikbaar om nieuwe functionaliteit te ontwikkelen. Je hoeft daardoor niet voor elke applicatie ‘het wiel opnieuw uit te vinden’.
Dit heeft een enorm positief effect op de snelheid en kwaliteit waarmee nieuwe it-applicaties ontwikkeld, getest, en geïmplementeerd kunnen worden. Snellere (en dus goedkopere) levering van nieuwe functionaliteit door it-organisaties heeft een positief effect op de tevredenheid van de klanten en daarmee heeft platform-technologie de potentie om it-organisaties te transformeren van ‘cost center’ naar ‘strategische business partner’.
Kortom, it-platformen bouwen voort op beproefde industriële ideeën en het is tijd om de potentie hiervan voor jouw organisatie te begrijpen en te verwezenlijken.
Elmer de Valk, eigenaar en managing consultant bij Plat4mation
Leen, standaardisatie is een zeer krachtig iets met een enorme hefboom.
Maar laat me even een paar ideeën delen: Uit het Euro songfestival zal nooit veel innovatie voortkomen als de winnaar wordt gekozen door de massa. De standaard ligt altijd in het midden.
Stel dat micro USB de standaard wordt om telefoons op te laden… Micro USB en een crime om aan te sluiten, is niet waterdicht heeft beperkte functionaliteit. Dus als dat de standaard word remt dit de ontwikkeling van de telefoon.
Windows is de de facto standaard op de Desktop. We weten wat dit qua innovatie allemaal gebracht heeft… Handig is het wel, als je software maakte hoefde dat alleen maar op Windows te draaien.
Als je een software pakket hebt wat je als “standaard” neer kunt zetten omdat het met alle databases babbelt dan mis je alle specifieke voordelen van alle database systemen aangezien deze niet gebruikt kunnen worden omdat het anders geen standaard meer is.
XML wilde ze ook de standaard maken… brrrrr.
Dat wisselstroom op 230V een standaard is heeft veel goeds gebracht met een enorme hefboom, maar dit is wel legacy waar we nog heel lang aan vast zullen zitten.
X86 architectuur is de standaard maar hoeveel innovatie het tegen heeft gehouden kunnen we alleen maar van dromen!
Als platformen, API’s, NoSQL, SAML methoden nu al een standaard worden terwijl we de fundamenten nog niet goed begrijpen dan kan de standaard niet anders zijn dan iets wat je niet wilt hebben.
Maar goed, dit zijn mijn gedachten.
Uiteraard kun je wel weer verder bouwen op standaarden en verhoog je uitwisselbaarheid, maar een goede standaard is in mijn ogen pas goed als de kennis erachter wat volwassener is.
Stel dat Edison gewonnen had van Tesla, dan waren we nu wellicht zo ver geweest als in de jaren 80 van vorige eeuw…. Maar dat het imperial system vermoord zou moeten worden ten behoeve van een wereldwijde standaard (metric), daar ben ik het heel erg mee eens 🙂
Henri,
Bekijk je de innovatie en standaardisatie vanuit positie van de klant of ontwikkelaar?
Ik kan me voorstellen dat de standaardisatie voor een enthousiasme ontwikkelaar remmend kan zijn maar dat geeft je klant best duidelijkheid en houvast voor het bedenken en implementeren van haar innovatieve ideeen of plannen.
Bovendien ik vind dat de verdere ontwikkelingen van een product en hieraan gerelateerde sub producten snel en in goede banen geleid kunnen worden als het product op een gestandaardiseerd fundamen gebouwd is.
Kun je je voorstellen als standaardisatie binnen cloud computing ingevoerd wordt hoe snel de ontwikkelingen zullen gaan en hoe snel de adoptie door klanten gaat gebeuren.
Ik heb je al (2 weken geleden) in mijn reactie op een eerder artikel gewezen op de voordelen van standaardisatie in de wereld van automotive.
Maar goed, ik vind dat dit total een andere discussie is dan het onderwerp van dit artikel.
Als ik bovenstaande commentaren lees wordt ik bevestigd in mijn mening dat PaaS vele gezichten kent. Afhankelijk van de achtergrond van de beschouwer komt er een bepaald beeld (en mening) naar voren. Mijn beeld is dat PaaS high level in 2 smaken verdeeld kan worden.
1) PaaS als een infrastructurele dienst om applicaties te deployen (denk aan bijvoorbeeld Azure, GoogleAppEngine)
2) PaaS als een middel om applicaties te bouwen én deployen (denk aan bijvoorbeeld Mendix, OutSystems of Force.com).
Beide typen PaaS bieden voordelen voor een IT organisatie. Denk hierbij aan snelheid, kwaliteit en kosten. Welke behoefte er door PaaS kan worden afgedekt, welke PaaS leveranciers hierbij passen en hoe de Business Case er dan uitziet blijft een klant specifieke vraag. PaaS is helaas geen one-size-fits all…
Elmer,
Bij optie 2 moet je niet snel voorbij een onderwerp gaan waardoor je extra tijd en budget voor je project nodig hebt:
Het gebruiken van PaaS als middle om je applicatie te bouwen en later in een andere omgeving of platform implementeren vereist extra tijd en budget voor het fine tunen van je product in een andere omgeving.
Maw, het is niet kopieren van wat je in een (PaaS) omgeving gemaakt hebt en neerzetten in een andere (PaaS) omgeving.
Bereken de kosten die je hierdoor maakt en vergelijk deze met een modulaire werkwijze (building blocks) zoals ik eerder heb opgemerkt.
Het grappige van definities is dat ze altijd vroeg of laat zodanig gebogen worden dat ze passen in het straatje van een leverancier. Het is dus jammer dat cloud heksen weer bezig zijn met allerlei abracadabra waardoor juist die knelpunten met de datakoppelingen ontstaan waar ik het in eerste reactie over had. Ik vraag mij namelijk af hoe efficient het is om MEAP laag in de cloud te zetten maar je data on-premises en of zo’n ‘backdoor’ ook wenselijk is.
Tenslotte zou je deployment probleem ook op kunnen lossen met een appliance waarbij applicatie stack gecombineerd wordt in een geoptimaliseerde infrastructurele bouwsteen waarbij het onderhoud via een abonnementsvorm afgenomen kan worden. Er zijn tenslotte 56+ meer of minder bekende oplossingen en sommige op basis van open source want dat het hier om Mendix/Force.com had ik al begrepen, de gebruikelijke hamertje tik dus.
Want als ik dit soort verhalen lees krijg ik een ESB/ERP deja vu gevoel waardoor we in de back-office met die vertikaal schaalbare databases zitten die we alleen met een steekkarretje kunnen verplaatsen. Volgens mij kun je uit snelheid, kwaliteit en kosten dan ook uiteindelijk maar 2 kiezen.
Leuk verhaal maar … waarom zou ik dit op PAAS doen en niet lokaal in een eigen omgeving?
Het artikel overtuigd mij niet dat PAAS zoveel goedkoper is, maar geeft (terecht) aan dat een volwassen ontwikkelplatform en een architectuur welke onafhankelijke componenten mogelijk maakt efficiënt is.
Reza, “Maw, het is niet kopieren van wat je in een (PaaS) omgeving gemaakt hebt en neerzetten in een andere (PaaS) omgeving.”
Waarom blijf je maar hameren op portabiliteit? Als een bedrijf voor SAP kiest weet deze ook wel dat het niet portable is. Ideeen afschieten op portabiliteit is zo dood als een pier. Natuurlijk moet je een exit strategie hebben, maar kiezen voor portabiliteit is gewoon een uiting van onzekerheid en kiezen voor schijnzekerheid.
Je kunt een MS SQL database prima verplaatsen naar een andere leverancier, maar als deze de complexe business rules die uitgevoerd worden in procedures niet begrijpt is dit nog steeds zinloos.
Ewout, jouw knelpunten zijn uitingen van slecht ontwerp, die zullen je hard raken ongeacht of je voor een platform kiest of voor gedegen traditionele systemen. Spaghetti maken is niet exclusief voor cloud diensten.
PaVaKe, ik ben deze week begonnen met een artikel die precies jouw vraag zou moeten beantwoorden. 1 van de cruxen is dat lokaal deployen het lokaal denken uitlokt. Men maakt oplossing vaak hard gecodeerd waardoor ze beperkt bruikbaar zijn en niet doorontwikkeld (kunnen) worden.
Reza, er staat me iets van bij dat ik je automotive voorbeeld niet sterk vond, maar ik kijk niet alleen vanuit ontwikkelaar, maar juist ook vanuit een business perspectief. Beide zijn namelijk belangrijk en zouden ook in lijn met elkaar moeten zijn.
@Henri … ik ben benieuwd
Volgens mij is het verschil tussen lokaal en globaal denken niet zozeer tool afhankelijk, maar meer een mentaliteitskwestie.
Ik heb afgelopen jaren wel vaker tunnelvisies meegemaakt binnen ontwikkelgroepen. Dat los je niet (alleen maar) op met een andere tool, maar is vooral een stukje bewustwording kweken volgens mij.
Henri,
” Waarom blijf je maar hameren op portabiliteit?”
Ik snap niet wat je met deze vraag bedoelde.
Ik probeer het nog een keer:
Als je je applicatie in een PaaS omgeving gemaakt hebt dan weet je niet welke middleware je PaaS-leverancier precies gebruikt heeft.
Deze wetendheid heb je nodig voor het verhuizen van je applicatie naar een andere omgeving in de cloud of intern in je eigen datacenter.
Om dit probleem op te lossen heb je meer tijd en ook geld nodig om je applicatie na de ontwikkeling in je PaaS omgeving geschikt te maken voor andere omgeving.
Dit is en belangrijk punt waar Elmer snel voorbij gaat.
Ik hoop dat deze laatste uitleg wat meer duidelijkheid verschaft.
Reza,
“Deze wetendheid heb je nodig voor het verhuizen van je applicatie naar een andere omgeving in de cloud of intern in je eigen datacenter.”
Dat bedoel ik met portabiliteit. Dus de mogelijkheid om naar een andere applicatie / platform / leverancier te gaan als je niet meer blij bent met de eerder gekozen “applicatie / platform / leverancier”. Ik ontken niet dat portabiliteit niet belangrijk is, maar veel keuzes uitsluiten omdat je volledig vrij wilt zijn in het kiezen van leverancier of applicatie platform is een utopische gedachte. Met andere woorden: Als je een keuze maakt voor een platform en je deze echt in gebruik neemt kun je niet zomaar switchen.
Een fout die veel Open Source denkers ook maken. Als je een open source product bij een leverancier draait betekent dit niet dat je deze zonder pijn kunt verplaatsen naar een andere leverancier.
Als je bijvoorbeeld kies voor Windows Azure als PaaS en specifieke zaken van dit platform gebruikt betekent dit dat je niet zomaar hiervan af kunt stappen, en dat is okee als je er goed over hebt nagedacht. Maar ik krijg het idee dat jij veel keuzes afkeurt omdat de portabiliteit niet goed is. Dat is een keuze en een visie en die van mij is ietswat anders 🙂
PaVaKe: Bewustwording en de menselijke kant is zeker belangrijk, maar ik heb nu meerdere trajecten meegemaakt waarbij het moven naar de (publieke) cloud echt een nieuwe bewustzijn creëerde. Als je in de comfort zone van je ontwikkelaars blijft zullen ze ontwikkelen zoals ze dit altijd al gedaan hebben. In de cloud zullen ze dit ook wellicht proberen maar komen ze er snel achter dat dit voor geen meter werkt. Bezit versus gebruik werkt echt verhelderend.
Als je iemand zijn boeken, boekenkasten en DVD spelers afneemt gaat de adoptie van streaming en digitaal veel sneller als dat je probeert hem of haar bewust te maken.