Het runnen van een laadplatform in uw eigen cloudtenancy in plaats van die van een leverancier wordt meestal gedreven door datalocatie, inkoopbeleid of de wens om de exit-optie vast te houden, en niet door iets technischs.
Het is haalbaar en het verandert wie de operationele last draagt, wat het onderdeel is waar vaak niet over is nagedacht voordat de eis in een aanbesteding wordt geschreven.
Wat de eis feitelijk drijft
De kosten zijn zelden de bepalende factor, en waar dat wel het geval is, wordt er doorgaans verkeerd geredeneerd. Particuliere inzet kost doorgaans meer per lader, en niet minder, omdat de operationele inspanning niet wordt gedeeld.
- Verplichtingen op het gebied van datalocatie waaraan een gedeeld multi-tenantplatform niet kan voldoen.
- Inkoop- of beveiligingsbeleid waarvoor werklasten binnen een gecontroleerde huurovereenkomst vereist zijn.
- Een verlangen om het platform te behouden als de commerciële relatie eindigt.
- Integratie met interne systemen die niet extern zichtbaar zijn.
De operationele grens moet expliciet zijn
Wie repareert de infrastructuur, wie reageert als een onderdeel om twee uur 's nachts uitvalt, wie beschikt over de inloggegevens en wie is verantwoordelijk als een oplader geen verbinding kan maken vanwege een netwerkwijziging waar niemand de leverancier over heeft verteld.
Bij een door een leverancier gehoste regeling zijn deze antwoorden impliciet. In uw huurovereenkomst is dat niet het geval, en een ongedefinieerde grens leidt tot incidenten waarbij beide partijen redelijkerwijs menen dat de ander verantwoordelijk is.
Opladers moeten het bereiken
Een platform binnen een beperkt netwerk is een platform waar opladers op openbare mobiele verbindingen geen verbinding mee kunnen maken. Het ingangspad moet doelbewust worden ontworpen, beveiligd en bewaakt, en het is vaak het deel dat een particuliere implementatie vertraagt.
Dit is geen moeilijk probleem. Het is een probleem dat pas laat aan de oppervlakte komt, omdat het pas zichtbaar wordt als echte laders verbinding proberen te maken.
Updates worden uw planning
Op een gehost platform komen er voortdurend verbeteringen binnen en ben je een van de velen die dezelfde versie gebruiken. Bij een privé-implementatie vinden updates plaats wanneer u ze accepteert, wat controle en tevens verplichting is.
Vloten die updates uitstellen, accumuleren een versiekloof, en de kloof maakt uiteindelijk de ondersteuning voor beide partijen moeilijker. Door vanaf het begin een updatefrequentie af te spreken, wordt dit vermeden.
Wat je daadwerkelijk krijgt bij het verlaten
Dit is voor veel kopers het punt van de regeling, en het verdient het om opgeschreven te worden. Het uitvoeren van uw huurovereenkomst betekent op zichzelf niet dat u eigenaar bent van de software, deze mag blijven gebruiken of wijzigen. Dat zijn licentievoorwaarden.
Bepaal of de uitgangspositie brontoegang, een eeuwigdurende licentie voor de actieve versie, een escrow-regeling of eenvoudigweg het bezit van de gegevens is. Ze zijn alle vier verschillend en slechts één ervan is wat de meeste kopers aannemen.
Wanneer het het verkeerde antwoord is
Een klein netwerk zonder infrastructuurfunctie zal een privé-implementatie slechter uitvoeren dan een leverancier dat zou doen, en de fouten zullen beschikbaarheidsfouten zijn die van invloed zijn op de stuurprogramma's.
Wanneer de bestuurder uitreisbescherming is in plaats van ingezetenschap, wordt met een escrow-regeling of een contractuele verplichting tot gegevensexport doorgaans hetzelfde doel bereikt, zonder de operationele kosten.