Delen via

Aanbevelingen voor ontwerpen met het oog op eenvoud en efficiëntie

  • Artikel

Van toepassing op deze aanbeveling voor de Power Platform Well-Architected-controlelijst voor betrouwbaarheid:

RE:01 Uw workload zo ontwerpen dat deze aansluit bij de bedrijfsdoelstellingen en onnodige complexiteit of overhead vermijden. Gebruik een praktische en evenwichtige aanpak om ontwerpbeslissingen te nemen die de gewenste resultaten opleveren. Zorg ervoor dat uw ontwerp voldoet aan de vereisten om inefficiënties en potentiële problemen te beperken.

In deze guide worden de aanbevelingen beschreven om onnodige complexiteit en overhead tot een minimum te beperken om uw workloads eenvoudig en efficiënt te houden. Kies de beste onderdelen om de noodzakelijke workloadtaken uit te voeren om de betrouwbaarheid van uw workload te optimaliseren. Om de lasten op het gebied van ontwikkeling en beheer te beperken, kunt u de efficiëntie die platformdiensten bieden benutten. Met dit ontwerp kunt u een workloadarchitectuur creëren die tolerant, herhaalbaar, schaalbaar en beheersbaar is.

Definities

Term Definitie
Workload Een afzonderlijke capaciteit of rekentaak die u logisch kunt scheiden van andere taken.

Belangrijke ontwerpstrategieën

Een belangrijk principe bij het ontwerpen voor betrouwbaarheid is om de zaken simpel en efficiënt te houden. Focus u met uw workloadontwerp op het voldoen aan de bedrijfsvereisten om het risico op onnodige complexiteit of overmatige overhead te beperken. Houd rekening met de aanbevelingen in dit artikel als leidraad bij het nemen van beslissingen over uw ontwerp, zodat u een lean, efficiënte en betrouwbare workload kunt creëren. Verschillende workloads hebben mogelijk verschillende vereisten op het gebied van beschikbaarheid, schaalbaarheid, gegevensconsistentie en herstel na noodgevallen.

U moet elke ontwerpbeslissing rechtvaardigen met een zakelijke vereiste. Dit ontwerpprincipe lijkt misschien voor de hand liggend, maar is van cruciaal belang voor workloadontwerp. Ondersteunt uw workload miljoenen gebruikers of een paar duizend? Zijn er grote verkeerspieken of een constante workload? Welk niveau van uitval is acceptabel? Zakelijke vereisten zijn de drijvende kracht achter deze ontwerpoverwegingen.

Afweging: een complexe oplossing biedt misschien meer functies en flexibiliteit, maar kan van invloed zijn op de betrouwbaarheid van de workload omdat er meer coördinatie, communicatie en beheer van onderdelen nodig is. Daartegenover staat dat een eenvoudigere oplossing mogelijk niet volledig voldoet aan de verwachtingen van de gebruiker of dat deze een negatief effect heeft op de uitbreidbaarheid naarmate de workload groeit.

Gezamenlijke ontwerpoefeningen

Ga samen met belanghebbenden aan de slag om:

  • Een kritikaliteitsniveau definiëren voor en toewijzen aan uw workload en bijbehorende onderdelen. Deze oefening helpt u bij het bepalen van de vereiste onderdelen en de beste aanpak om het vereiste tolerantieniveau te bereiken. Zie Toepassingsniveaus definiëren voor meer informatie.

  • Definieer functionele en niet-functionele vereisten. Functionele vereisten bepalen de kenmerken en het gedrag van het systeem. Ze worden door de gebruiker gespecificeerd en vastgelegd in gebruiksscenario's. Niet-functionele vereisten bepalen de prestatie- en kwaliteitskenmerken van het systeem. Zorg ervoor dat u inzicht hebt in niet-functionele vereisten, zoals beschikbaarheid, naleving, gegevensretentie/-locatie, prestaties, privacy, hersteltijd, beveiliging en schaalbaarheid. Deze vereisten beïnvloeden ontwerpbeslissingen en technologiekeuzes.

    Hieronder vindt u enkele voorbeelden van functionele en niet-functionele vereisten, in de context van een workloads die onkostendeclaraties verwerkt:

    Functionele vereisten Niet-functionele vereisten
    De workload moet gebruikers in staat stellen in te loggen met hun referenties en alleen toegang te krijgen tot hun persoonlijke gegevens. De workload moet ten minste 99,9% van de tijd beschikbaar zijn.
    De workload moet een dashboard omvatten dat een overzicht biedt van openstaande, goedgekeurde en afgewezen onkostendeclaraties. De workload moet voldoen aan de relevante regelgeving en normen voor gegevensbescherming en privacy.
    De workload moet back-up- en herstelbewerkingen voor de workloadgegevens ondersteunen. De workload moet voor de meeste aanvragen van gebruikers een reactietijd van minder dan 5 seconden hebben.
    De workload moet meldingen versturen naar gebruikers en beheerders wanneer bepaalde gebeurtenissen of drempelwaarden worden geactiveerd. De workload moet een hoog niveau van beveiliging en versleuteling hebben voor de gegevens die onderweg en in rust zijn.

    Voor meer informatie zie de trainingsmodule met de naam Werken met vereisten voor Microsoft Power Platform en Dynamics 365.

  • Verdeel de workload in onderdelen. Tijdens verkenning en het verzamelen van vereisten zullen enkele oplossingsideeën helder worden. Identificeer oplossingsonderdelen waaruit de voorgestelde oplossing zou kunnen bestaan om aan uw zakelijke vereisten te voldoen. Geef de voorkeur aan eenvoud, efficiëntie en betrouwbaarheid in uw ontwerp. Bepaal welke onderdelen u nodig hebt om uw workload te ondersteunen. Benadruk waar kant-en-klare mogelijkheden kunnen worden gebruikt en waar maatwerkontwikkeling nodig kan zijn.

  • Gebruik analyse van foutmodus om de afzonderlijke points-of-failure en potentiële risico's te identificeren. Zorg dat u goed inzicht hebt in de risicotolerantie van uw bedrijf. Voor meer informatie, zie Aanbevelingen voor het uitvoeren van analyses van foutmodus.

  • Definieer doelstellingen voor beschikbaarheid en herstel voor uw workload als leidraad voor architectuurbeslissingen. Zakelijke metrische gegevens omvatten serviceniveaudoelstellingen (SLO's), dienstverleningsovereenkomsten (SLA's), gemiddelde hersteltijd (MTTR), gemiddelde tijd tussen fouten (MTBF), hersteltijddoelstellingen (RTO's) en herstelpuntdoelstellingen (RPO's). Definieer doelwaarden voor deze metrische gegevens. Tijdens deze oefening zullen de technologie- en bedrijfsteams compromissen moeten sluiten en tot wederzijds begrip moeten komen om ervoor te zorgen dat de doelstellingen van elk team overeenkomen met de bedrijfsdoelstellingen en realistisch zijn. Zie Aanbevelingen voor het definiëren van betrouwbaarheidsdoelstellingen. Power Platform SLA's bieden de Microsoft-toezeggingen voor uptime en connectiviteit. Verschillende services hebben verschillende SLA's, en soms hebben SKU's binnen een service verschillende SLA's. Zie Dienstverleningsovereenkomsten voor onlineservices.

Aanvullende ontwerpaanbevelingen

U kunt de volgende aanbevelingen uitvoeren zonder betrokkenheid van belanghebbenden:

  • Streef naar eenvoud en duidelijkheid in het ontwerp. Gebruik het juiste abstractie- en granulariteitsniveau voor uw onderdelen en services. Vermijd te complexe of onvoldoende complexe technologische ontwikkeling van uw oplossing. Bijvoorbeeld:

    • Als u een vereiste voor procesautomatisering oplost met Power Automate, kan het opdelen van een groot proces in meerdere kleinere cloudstromen het moeilijker maken om deze te begrijpen, te testen en te onderhouden. Aan de andere kant kan het in één grote stroom houden een negatieve invloed hebben op de prestaties en het aantal API-aanroepen.

    • Als u een gebruikersgerichte vereiste oplost met Power Apps, kan een grote monolithische canvas-app met veel besturingselementen een negatieve invloed hebben op de prestaties. Het opsplitsen in afzonderlijke apps of aangepaste pagina's kan het testen moeilijker maken, maar wel een aanzienlijk positief effect hebben op de prestaties.

  • Anticipeer op veranderingen in de loop der tijd, of het nu gaat om het oplossen van bugs, het implementeren van nieuwe functies of technologieën, of het schaalbaarder en veerkrachtiger maken van bestaande systemen.

  • Verplaats overstijgende problemen naar een aparte service. Minimaliseer de noodzaak om code voor verschillende functies te dupliceren. Geef de voorkeur aan hergebruik van services met goed gedefinieerde interfaces die gemakkelijk door verschillende onderdelen kunnen worden gebruikt. Als er bijvoorbeeld een set gegevensbewerkingen vanaf verschillende plekken moet worden uitgevoerd, kunt u deze functionaliteit verplaatsen naar een invoegtoepassing met weinig code.

  • Evalueer de geschiktheid van algemene patronen en praktijken voor uw behoeften. Vermijd het volgen van trends of aanbevelingen die mogelijk niet optimaal geschikt zijn voor uw context of vereisten. Het implementeren van aangepaste codeonderdelen is bijvoorbeeld mogelijk niet voor elke toepassing de beste optie, omdat deze problemen met complexiteit, overhead en afhankelijkheid met zich mee kunnen brengen.

Precies voldoende code ontwikkelen

De principes van eenvoud, efficiëntie en betrouwbaarheid zijn ook van toepassing op uw ontwikkelprocedures. Bekijk deze aanbevelingen:

  • Gebruik platformmogelijkheden wanneer deze voldoen aan uw zakelijke vereisten. Bijvoorbeeld:

    • Gebruik moderne besturingselementen in plaats van het ontwikkelen van uw eigen codeonderdelen om een Fluent 2-ontwerpstandaard te bereiken.
    • Gebruik native connectoren in plaats van aangepaste connectoren te ontwikkelen om de hoeveelheid aangepaste code te beperken.
    • Gebruik generatieve antwoorden in Microsoft Copilot Studio om uw agent in staat te stellen om informatie uit meerdere bronnen (intern of extern) te vinden en weer te geven zonder dat u handmatig onderwerpen moet maken.

  • Introduceer speciale codebeoordelingssessies als ontwikkelingsprocedure.

  • Implementeer een aanpak voor het identificeren van dode code. Wees op uw hoede bij code die niet door uw geautomatiseerde tests wordt gedekt.

  • Houd rekening met de vaardigheden van uw ontwikkelteam. Het kost tijd om een nieuwe vaardigheid te leren of een nieuwe technologie te gaan gebruiken.

Nadenken over waar uw gegevens zich bevinden

Als onderdeel van uw architectuurontwerp moet u nadenken over hoe u uw gegevens wilt opslaan of hoe u uw gegevens kunt ophalen voor leesactiviteiten. Gegevens kunnen op verschillende manieren worden opgehaald en opgeslagen:

  • Nieuwe gegevens: als uw app gegevens maakt die nog niet bestaan, zoals wanneer het bestaande bedrijfsproces op papier is uitgevoerd, raden we aan de gegevens op te slaan in Microsoft Dataverse.

  • Lezen/schrijven van een bestaand systeem: als uw app gegevens moet ophalen uit een bestaande database of bestaand systeem, moet u evalueren wat de beste manier is om verbinding te maken met de database of het systeem: met behulp van een kant-en-klare connector, een aangepaste connector of virtuele tabellen.

  • Een kopie maken van de gegevens: in situaties waarin originele gegevens niet mogen worden gewijzigd of overschreven, kunt u de gegevens kopiëren naar een andere gegevensopslag zoals Dataverse. Met deze strategie blijven de gegevens van het oorspronkelijke systeem ongewijzigd, maar kan uw app er toch mee werken. Dit scenario komt veel voor bij het werken met gegevens in boekhoudkundige en omzetgerelateerde systemen. Denk ook na over hoe gegevens worden gekopieerd, hoe vaak deze worden bijgewerkt en of er tweerichtingssynchronisatie moet plaatsvinden.

Power Platform-facilitering

Voor praktisch ontwerpadvies kunt u de volgende artikelen raadplegen:

Controlelijst voor betrouwbaarheid

Raadpleeg de volledige reeks aanbevelingen.

Controlelijst voor betrouwbaarheid