Dela via


Överväganden för klientorganisationens livscykel i en lösning för flera klientorganisationer

När du överväger en arkitektur för flera klientorganisationer är det viktigt att tänka på alla de olika faserna i en klientorganisations livscykel. På den här sidan ger vi vägledning för tekniska beslutsfattare om faserna i livscykeln och viktiga överväganden för varje steg.

Utvärderingsklienter

När du skapar en SaaS-lösning bör du tänka på att många kunder begär eller kräver utvärderingsversioner innan de förbinder sig att köpa en lösning.

Utvärderingsversioner medför följande unika överväganden:

  • Tjänstkrav: Bör utvärderingsversioner omfattas av samma krav på datasäkerhet, prestanda och tjänstnivå som data för fullständiga kunder?
  • Infrastruktur: Ska du använda samma infrastruktur för utvärderingsklientorganisationer som för fullständiga kunder, eller ska du ha dedikerad infrastruktur för utvärderingsklienter?
  • Migration: Hur migrerar kunderna data från sina utvärderingsklienter till sina betalda klienter om kunderna köper din tjänst efter en utvärderingsversion?
  • Process för begäran: Finns det gränser kring vem som kan begära en utvärderingsversion? Hur kan du förhindra missbruk av din lösning? Tillåter du att klientorganisationer för utvärderingsversionen skapas automatiskt eller deltar ditt team i varje begäran?
  • Gränser: Vilka begränsningar vill du ha eller behöver du använda för utvärderingskunder, till exempel tidsgränser, funktionsbegränsningar eller begränsningar kring prestanda?

I vissa situationer kan en prismodell för freemium vara ett alternativ till att tillhandahålla utvärderingsversioner.

Registrera nya klienter

Tänk på följande när du registrerar en ny klientorganisation:

  • Process: Kommer registrering att vara en självbetjäning, automatiserad eller manuell process?
  • Datahemvist: Har klientorganisationen några specifika krav för datahemvist? Gäller till exempel regler för datasuveränitet?
  • Överensstämmelse: Måste klientorganisationen uppfylla några efterlevnadsstandarder (till exempel PCI DSS, HIPAA och så vidare)?
  • Katastrofåterställning: Har klientorganisationen några specifika krav för haveriberedskap, till exempel ett mål för återställningstid (RTO) eller ett mål för återställningspunkt (RPO)? Skiljer du dig från de garantier som du ger andra klienter?
  • Information: Vilken information behöver du för att kunna registrera klientorganisationen fullt ut? Behöver du till exempel känna till organisationens juridiska namn? Behöver du deras företagslogotyp för att märka programmet, och i så fall vilken filstorlek och vilket format behöver du?
  • Fakturering: Tillhandahåller plattformen olika prisalternativ och faktureringsmodeller?
  • Miljöer: Kräver klientorganisationen förproduktionsmiljöer? Och finns det förväntningar på tillgänglighet för den miljön? Är det tillfälligt (på begäran) eller alltid tillgängligt?

När klienter har registrerats övergår de till ett "business as usual"-tillstånd. Det finns dock fortfarande flera viktiga livscykelhändelser som kan inträffa, även när de är i det här tillståndet.

Uppdatera klientorganisationens infrastruktur

Du måste fundera på hur du ska tillämpa uppdateringar på klientorganisationens infrastruktur. Olika klientorganisationer kan ha uppdateringar som tillämpas vid olika tidpunkter.

Se Uppdateringar för andra överväganden om att uppdatera klienternas distributioner.

Skala klientorganisationens infrastruktur

Överväg om dina klienter kan ha säsongsbaserade affärsmönster eller på annat sätt ändra förbrukningsnivån för din lösning.

Om du till exempel tillhandahåller en lösning till återförsäljare kan du förvänta dig att vissa tider på året kommer att vara särskilt upptagna i vissa geografiska regioner och tysta vid andra tillfällen. Överväg om den här säsongsvariationen påverkar hur du utformar och skalar din lösning. Tänk på hur säsongsvariationer kan påverka störningar i närliggande problem, till exempel när en delmängd av klientorganisationer upplever en plötslig och oväntad ökning av belastningen som minskar prestandan för andra klienter. Du kan överväga att tillämpa åtgärder, som kan omfatta skalning av enskilda klientorganisationers infrastruktur, flytt av klienter mellan distributioner och etablering av en tillräcklig kapacitetsnivå för att hantera toppar och dalar i trafiken.

Flytta klienter mellan infrastruktur

Du kan behöva flytta klienter mellan infrastrukturer av flera olika orsaker, bland annat följande:

  • Omfördelning: Du följer en vertikalt partitionerad metod för att mappa dina klienter till infrastrukturen, och du måste flytta en klientorganisation till en annan distribution för att balansera om belastningen.
  • Uppgraderingar: En klientorganisation uppgraderar sin SKU eller prisnivå och måste flyttas till en dedikerad distribution med en enda klientorganisation med högre isolering från andra klienter.
  • Migreringar: En klientorganisation begär att deras data flyttas till ett dedikerat datalager.
  • Regionflyttningar: En klientorganisation kräver att deras data flyttas till en ny geografisk region. Detta kan inträffa under ett företagsförvärv, eller när lagar eller geopolitiska situationer ändras.

Överväg hur du flyttar klientorganisationens data, samt omdirigeringsbegäranden till den nya infrastrukturuppsättningen som är värd för deras instans. Du bör också överväga om en flytt av en klientorganisation kan leda till driftstopp och se till att klienterna är fullt medvetna om risken.

Sammanfoga och dela klientorganisationer

Det är frestande att betrakta klienter eller kunder som statiska, oförändrade entiteter. Men i verkligheten är detta ofta inte sant. Exempel:

  • I affärsscenarier kan företag förvärvas eller slås samman, inklusive företag som finns i olika geografiska regioner.
  • På samma sätt kan företag i affärsscenarier dela upp eller avyttra.
  • I konsumentscenarier kan enskilda användare ansluta sig till eller lämna familjer.

Överväg om du behöver tillhandahålla funktioner för att hantera sammanslagning och separation av data, användaridentiteter och resurser. Tänk också på hur dataägarskap påverkar din hantering av sammanslagnings- och delningsåtgärder. Tänk dig till exempel ett konsumentfotograferingsprogram som skapats för familjer att dela foton med varandra. Ägs bilderna av de enskilda familjemedlemmarna som bidrog med dem, eller av familjen som helhet? Om användarna lämnar familjen, ska deras data tas bort eller finnas kvar i familjens datauppsättning? Om användarna går med i en annan familj, bör deras gamla foton flyttas med dem?

Avregistrera klienter

Det är också oundvikligt att klienter ibland behöver tas bort från din lösning. I en lösning med flera klientorganisationer medför detta några viktiga överväganden, bland annat följande:

  • Djurhållningsperioden: Hur länge ska du underhålla kunddata? Finns det juridiska krav på att förstöra data efter en viss tidsperiod?
  • Återregistrering: Bör du ge kunderna möjlighet att bli återregistrerade?
  • Omfördelning: Om du kör delad infrastruktur, behöver du balansera om allokeringen av klienter till infrastruktur?

Inaktivera och återaktivera klientorganisationer

Det finns situationer där en kunds konto kan behöva inaktiveras eller återaktiveras. Exempel:

  • Kunden har begärt inaktivering. I ett konsumentsystem kan en kund välja att avbryta prenumerationen.
  • Kunden kan inte faktureras och du måste inaktivera prenumerationen.

Inaktiveringen är separat från avregistrering eftersom den är avsedd att vara ett tillfälligt tillstånd. Men efter en viss tidsperiod kan du välja att avregistrera en inaktiverad klientorganisation.

Deltagare

Den här artikeln underhålls av Microsoft. Den skrevs ursprungligen av följande deltagare.

Huvudförfattare:

  • John Downs | Huvudkundstekniker, FastTrack för Azure

Andra deltagare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

Överväg de prismodeller som du kommer att använda för din lösning.