Checklist - Verdere verwijzing

Deze pagina bevat verdere details voor het uitwerken en/of vergroten van de documenten en beginselen die worden behandeld in de Controlelijst voor beste praktijken voor het beheren van projecten.

AEM - Wat gaat u gebruiken?

Functies binnen AEM

Wanneer het uitvoeren van AEM (in het bijzonder voor de eerste keer) zult u mogelijkheden en werkschema's van AEM moeten herzien om zeker te zijn van welke gebieden u wilt/nodig hebt.

Houd rekening met de functies van AEM die u gebruikt en met de invloed op uw ontwerp. bijvoorbeeld:

• Handel
• Schermen
• Assets
• Tags
• Beheer en vertaling van meerdere sites
• Forms
• Gemeenschappen
• Livefyre

Controleer bovendien de Release-aantekeningen voor de verschillende versies van AEM om te zien wanneer er nieuwe functies zijn toegevoegd.

Integrations

AEM kunnen worden geïntegreerd met andere producten van de Adobe en/of diensten van derden. Deze kunnen de macht en de functionaliteit verhogen tot uw beschikking.

Zie Solutions Integration voor volledige informatie.

Migreren of upgraden?

Een belangrijke overweging is of u:

• De bestaande installatie upgraden.
• De inhoud van het huidige systeem migreren naar een nieuwe, nieuwe installatie.

Bij de overgang van een vorige versie naar de huidige versie zijn er twee opties:

• Gebruik Pakketbeheer om alle inhoud en toepassingscode van het oude systeem naar het nieuwe te exporteren.
• Het oude systeem upgraden. Dit is in de meeste gevallen de aanbevolen keuze.

Basisgrondregels

Net als bij elk project is het van cruciaal belang dat er zo snel mogelijk grondregels worden opgesteld. Deze omvatten:

• Rollen

  Deze moeten duidelijk worden omschreven en aan alle bij het project betrokken partijen worden meegedeeld. Daarnaast is het raadzaam de aandacht te vestigen op:

  • Beslissingsmakers
  • Contactpunten

• Verantwoordelijkheden

  • Voor elke rol helpt een duidelijke definitie van de verantwoordelijkheden met betrekking tot uw project verwarring te voorkomen.

• Betrokkenheid

  Door de betrokken partijen zo snel mogelijk bij het project te betrekken, kunt u hen aanmoedigen om stakeholders in het project te worden, zodat zij zich meer inzetten voor het welslagen ervan.

  • Aan de kant van de klant staan onder andere de auteurs - die dagelijks met het systeem moeten werken.
  • Binnen uw eigen projectteam omvat dit ook de personen die verantwoordelijk zijn voor kwaliteitsborging. Hoe meer zij de vereisten van de klant begrijpen, hoe beter zij de tests kunnen plannen.

• Paden van communicatie

  • Hoewel deze niet buitensporig moeten worden geformaliseerd, moeten specifieke definities ervoor zorgen dat de belangrijkste personen altijd op de hoogte worden gebracht en dus worden bijgewerkt. Er moet bijzondere aandacht worden besteed aan de communicatie met externe partijen.

• Processen

  De te bepalen processen zullen van uw individueel project afhangen. Probeer deze nog eens eenvoudig te houden, waarbij u rekening moet houden met:

  • het definiëren van processen (en communicatiepaden) voor interactie met derden; bijvoorbeeld ontwerpbureaus en andere softwareleveranciers.
  • Vaak heeft de klant zijn eigen procedures en tools voor projectbeheer en -rapportage.

• Trackinggereedschappen

  Er zijn vele hulpmiddelen beschikbaar voor het volgen van informatie over insecten, taken, en andere aspecten van uw project - zie Overzicht van Potentiële Hulpmiddelen voor meer details.

  • Het belangrijkste punt om hier nota van te nemen is slechts één exemplaar van de informatie te houden en de informatie (en daarom toegang tot het hulpmiddel te delen dat wordt gebruikt) te delen. Hierdoor wordt onderhoud eenvoudiger en kunnen verschillen worden voorkomen.

• Scope

  Duidelijk bepalen wat op verschillende niveaus onder het project moet vallen:

  • de individuele versies (als een iteratief versieproces wordt gebruikt, en ongeacht of zij aan klanten of uw intern testteam worden geleverd).
  • het AEM project.
  • het gehele project; met inbegrip van software van derden, de gevolgen ervan voor tests, organisatorische problemen en vele andere.
  • Voor bepaalde aspecten kan het ook nuttig zijn om te verklaren wat not binnen het werkingsgebied van het project is. Dit kan helpen verwarring en onjuiste veronderstellingen te voorkomen, maar moet beperkt blijven tot essentiële kwesties.

• Rapportage

  Duidelijk bepalen welke informatie u zult melden, in welke vorm, hoe vaak en aan wie.

• Terminologie

  • Bepaal om het even welke te gebruiken afkortingen en/of klant-specifieke terminologie.

• Aannames

  • Bepaal om het even welke veronderstellingen die worden gemaakt.

Deze informatie kan binnen een Handboek van het Project worden bepaald; het gebruik van een Wiki kan er ook toe bijdragen dat lopende veranderingen efficiënt worden afgehandeld. Waar deze worden gedefinieerd, zijn de belangrijkste factoren:

• Informatie wordt gedefinieerd en onderhouden
• De informatie wordt duidelijk meegedeeld aan alle betrokken personen. Hoewel de standaardpraktijk van het Projectbeheer, het niet vaak genoeg kan worden herhaald dat de duidelijke roldefinitie en de goede mededeling een project kunnen maken of breken.
• Er wordt slechts één versie bijgehouden van informatie die wordt bijgehouden; bijvoorbeeld het bijhouden van fouten, het bijhouden van problemen, enz.

Belangrijkste prestatie-indicatoren en streefcijfers

Organisaties gebruiken de Belangrijkste Indicatoren van Prestaties (KPIs) om hun succes bij het bereiken van doelstellingen te evalueren. Deze indicatoren zijn meetbare waarden die kunnen worden gebruikt om aan te tonen hoe effectief specifieke doelstellingen worden verwezenlijkt.

Deze indicatoren kunnen zijn:

• Zakelijk:

  • Wordt gebruikt om belangrijke bedrijfsdoelstellingen te meten.
  • Het is belangrijk om KPIs te kiezen aangewezen aan uw zaken/scenario met duidelijke definities van wat zij zijn, hoe zij zullen worden gemeten, hoe zij zullen worden gebruikt en door wie.

• Prestaties:

  • Bepaal hoe u de prestaties van het systeem kunt meten.
  • Voorbeelden hiervan zijn laadtijd van de pagina, responstijd van de server en queryprestaties van de database.

Sommige, maar niet alle, indicatoren kunnen op de doelmetriek worden gebaseerd die u identificeert en bepaalt.

Doelwaarden

Metrisch worden gebruikt om kwantitatieve metingen voor de kwaliteit van uw website te bepalen - zij zijn fundamenteel een definitie van de prestatiesdoelstellingen die u wilt bereiken en kunnen worden gebruikt om uw KPIs (Zeer belangrijke Indicatoren van Prestaties) te bepalen.

Veel metriek kunnen worden gedefinieerd, maar vaak worden de meeteenheden die u definieert, gebruikt voor uw doelstellingen op het gebied van prestaties en gelijktijdige uitvoering. Met name factoren die moeilijk te kwantificeren kunnen zijn en die vaak gevoelig zijn voor emotionele-evaluatie:

• "onze website is veel te langzaam vandaag" - wanneer komt slow in aanmerking?

• "alles breidt zich aan een halt wanneer mijn collega zich binnen"registreert - hoeveel gezamenlijke gebruikers kan het systeem steunen?

• "wanneer ik zoek, breidt het systeem zich aan een halt " - welke soort onderzoeksverzoeken beïnvloeden het systeem?

• "het downloaden van het bestand duurt ages" - wat zijn acceptabele downloadtijden (onder normale netwerkomstandigheden)?

De Metriek van het doel worden bepaald bij het begin van een project aan:

• Geef de verwachte afmetingen van de website aan die u wilt aanbieden
• geeft de minimale kwaliteit aan die u wilt bereiken
• bepalen hoe deze factoren daadwerkelijk zullen worden gemeten
• worden gebruikt als basis voor de Belangrijke prestatie-indicatoren

Zoals altijd zorgvuldig moet worden omgesprongen met de definitie van de doelwaarden:

• als ze te hoog zijn , kunnen ze totaal onbereikbaar zijn
• indien te lage fluctuaties zijn ingesteld, wordt deze mogelijk niet gemarkeerd
• om ervoor te zorgen dat zij herhaaldelijk en consequent kunnen worden gemeten
• om een evenwicht te verschaffen tussen de verschillende factoren die worden gemeten
• bepaalde meetwaarden hebben betrekking op een testomgeving, maar sommige moeten levensechte scenario's weerspiegelen omdat ze meetbaar en reproduceerbaar moeten zijn op uw productiewebsite
• de metriek prioriteren op basis van hun betekenis voor de website
• de meetgegevens beperken tot een set die op realistische wijze kan worden bewaakt

Tijdens de ontwikkeling van het project kunnen zij waar nodig worden bijgewerkt en aangepast. Nadat het project met succes is uitgevoerd, kunnen zij worden gebruikt om u te helpen uw installatie controleren en de vereiste niveaus van de dienst voor aan de gang zijnde verrichting controleren/handhaven.

Als deze gegevens correct worden gebruikt, kunnen ze een nuttig hulpmiddel zijn; als ze onverantwoord worden gebruikt, kunnen ze een tijdverspillende afleiding zijn. Zoals altijd moet u begrijpen wat u meet, hoe u het meet en waarom.

Alles rust op uw projectontwerp

Alle meetgegevens die moeten worden gemeten, worden op een of andere manier beïnvloed door het ontwerp van uw project. Omgekeerd kunnen veel problemen het best worden opgelost door ontwerpwijzigingen.

Daarom zou u uw doelmetriek vóór moeten bepalen bepalend op uw ontwerp. Op deze manier kunt u uw ontwerp optimaliseren op basis van deze factoren. Als uw project eenmaal is ontwikkeld, zal het moeilijk zijn om wijzigingen aan te brengen in de basisontwerpbeginselen.

Wanneer u de structuur voor de website maakt, volgt u de aanbevolen structuur voor AEM websites. Zorg ervoor dat u de volgende problemen en/of principes begrijpt:

• Inhoud van websites structureren.
• Hoe sjablonen en componenten werken.
• Hoe caching werkt.
• De effecten van gepersonaliseerde inhoud.
• Hoe de zoekfunctie werkt.
• Hoe u CSS en verwante technologieën kunt gebruiken om compacte, niet-overtollige code van HTML tot stand te brengen.

Als u van mening bent dat uw ontwerp de richtlijnen niet volgt, of als u over sommige implicaties onzeker bent, verheldeer deze kwesties alvorens u of de programmeringsfase begint of de inhoud vult.

Infrastructuur

Om de infrastructuur te bepalen of te beoordelen zal het helpen doelwaarden zoals bepalen:

• bezoekers/dag; zowel gemiddelde als piekwaarde
• treffers/dag; zowel gemiddelde als piekwaarde
• aantal webpagina's dat beschikbaar wordt gesteld
• volume van webinhoud

Afhankelijk van uw situatie en de strategische betekenis van de website, helpt dit u om uw infrastructuur te beoordelen en te kiezen:

• aantal servers
• aantal AEM (auteur en publicatie)

Prestaties

Er zijn verschillende prestatiefactoren die kunnen worden geëvalueerd:

• responstijden voor afzonderlijke pagina's, rekening houdend met:

  • reactietijden voor een auteursomgeving
  • responstijden voor de publicatieomgeving

• antwoordtijden voor zoekverzoeken

Deze sectie kan worden gelezen in combinatie met Prestaties optimaliseren die de technische details van het daadwerkelijk meten van de prestaties uitbreidt.

Responstijden voor afzonderlijke pagina's

Een belangrijk probleem is de tijd die uw website nodig heeft om te reageren op bezoekersverzoeken.

Hoewel deze waarde voor elke aanvraag zal variëren, kan een gemiddelde doelwaarde worden bepaald. Zodra deze waarde zowel haalbaar als houdbaar is, kan deze worden gebruikt om de prestaties van de website te controleren en de ontwikkeling van potentiële problemen aan te geven

Verschillende doelen voor auteur- en publicatieomgevingen

De responstijden die u wilt bepalen, verschillen per auteur- en publicatieomgeving en weerspiegelen het doelpubliek:

• Auteursomgeving

  Deze omgeving wordt gebruikt door auteurs die inhoud invoeren en bijwerken, zodat deze:

  • Zorg voor een klein aantal gebruikers die een groot aantal verzoeken genereren bij het bijwerken van inhoudspagina's en de afzonderlijke elementen op die pagina's
  • zo snel mogelijk zijn om hun productiviteit te maximaliseren voor het ophalen van uw inhoud op uw website

• Publicatie-omgeving

  Deze omgeving bevat inhoud die u beschikbaar maakt voor uw gebruikers:

  • snelheid is nog steeds van vitaal belang , maar is vaak trager dan een auteursomgeving

  • er worden vaak aanvullende mechanismen voor prestatieverbetering toegepast :

    • de inhoud is in cache geplaatst
    • taakverdeling wordt toegepast

Doelresponstijden instellen

Dus hoe kan je beslissen over haalbare (gemiddelde) responstijden? Dit is vaak een kwestie van ervaring:

• ervaring met uw website
• ervaring met AEM
• complexe pagina's herkennen die boven de gemiddelde responstijden liggen (deze moeten zo mogelijk individueel worden geoptimaliseerd)

Onder gecontroleerde omstandigheden kunnen echter de volgende richtsnoeren worden toegepast:

• 70% van de aanvragen voor pagina's moet in minder dan 100 ms reageren.
• 25% van de aanvragen voor pagina's moet in minder dan 100 ms-300 ms reageren.
• 4% van de aanvragen voor pagina's moet in minder dan 300 ms-500 ms reageren.
• 1% van de aanvragen voor pagina's moet in minder dan 500 ms-1000 ms reageren.
• Geen pagina's mogen langzamer reageren dan 1 seconde.

De bovenstaande getallen voldoen aan de volgende voorwaarden:

• gemeten bij publicatie (geen ontwerpomgeving en/of CFC-overhead)
• gemeten op de server (geen netwerkoverhead)
• niet in cache geplaatst (geen AEM-uitvoercache, geen Dispatcher-cache)
• alleen voor complexe items met veel afhankelijkheden (HTML, JS, PDF, …)
• geen andere belasting op het systeem

U kunt de reactietijden op verschillende manieren controleren:

• De reactietijden van de controle met AEM request.log

  Een goed uitgangspunt voor prestatiesanalyse is het verzoeklogboek. U kunt dit bijvoorbeeld gebruiken om de responstijden van afzonderlijke aanvragen te zien. Zie Prestaties optimaliseren voor meer informatie.

• Reactietijden controleren met HTML-opmerkingen

  *HTML comments* can be used to include response time information within the source of each page:

  </body> </html>v <-- Page took 58 milliseconds to be rendered by the server --> Response times for search requests

Zoekverzoeken

Zoekverzoeken kunnen een aanzienlijke invloed hebben op uw website, zowel wat betreft:

• Responstijd van de eigenlijke zoekopdracht

  • Een snelle zoekfunctie is een kwaliteitsdoel voor uw website

• Gevolgen voor de algemene prestaties

  • Aangezien een zoekfunctie (potentieel grote) gedeelten van de inhoud moet scannen, of een speciaal uitgenomen index, kan dit de prestaties van het gehele systeem beïnvloeden als dit niet wordt geoptimaliseerd

Het vaststellen van doelen voor zoekverzoeken is ook hier een kwestie van ervaring, afhankelijk van:

• AEM
• een beoordeling van de frequentie waarmee de zoekopdracht zal worden gebruikt in vergelijking met andere doelstellingen
• uw persistentiemanager
• uw zoekindex
• de complexiteit van uw zoekfunctie; een basiszoekfunctie waarmee slechts één zoekterm kan worden ingevoerd, is sneller dan een geavanceerd zoeken waarmee de gebruiker complexe zoekinstructies kan opbouwen met behulp van AND/OR/NOT.

Deze moeten vanaf het begin van uw project worden gepland en geïntegreerd. De volgende controlemechanismen zijn beschikbaar:

• De zoekreactietijden van de controle met AEM request.log

  Nogmaals kan request.log worden gebruikt om de reactietijden voor onderzoeksverzoeken te controleren; zie Prestaties optimaliseren voor meer informatie.

• Geprogrammeerde mechanismen voor het meten van zoekresponstijden

  Om de informatie aan te passen u over onderzoeksverzoeken, en hun prestaties verzamelt, adviseert men om informatieinzameling in uw projectbroncode te omvatten; zie Prestaties optimaliseren voor meer informatie.

Gelijktijdige

Uw website wordt beschikbaar gesteld aan een aantal gebruikers/bezoekers, zowel in de auteur- als in de publicatieomgeving. De getallen zijn vaak hoger dan bij het testen, maar ook fluctuerend en moeilijk te voorspellen. Uw website moet worden ontworpen voor een gemiddeld aantal gelijktijdige gebruikers/bezoekers zonder dat dit negatieve gevolgen heeft voor de prestaties. Ook hier kan request.log worden gebruikt om valutatietests uit te voeren; Zie Prestaties optimaliseren voor meer informatie.

De doelstellingen voor het aantal gelijktijdige gebruikers zijn afhankelijk van het milieutype:

• Auteursomgeving

  • Gewoonlijk kan het aantal gelijktijdige gebruikers nauwkeurig worden geschat. U weet hoeveel auteurs u in totaal hebt, hoewel (waarschijnlijk) niet alle tegelijkertijd actief zullen zijn.

• Publicatie-omgeving

  • Dit is moeilijker te voorspellen, zodat moet u een doelwaarde selecteren. Ook dit moet gebaseerd zijn op de ervaring van uw huidige website en realistische verwachtingen ten aanzien van uw nieuwe website.
  • Speciale evenementen (bijvoorbeeld wanneer u nieuwe, zeer populaire inhoud publiceert) kunnen de verwachtingen of zelfs de mogelijkheden overtreffen (zoals soms in de pers wordt gemeld wanneer tickets voor bepaalde evenementen te koop worden aangeboden).

Capaciteit en volume

Voordat u de gerelateerde metriek gaat bespreken, geeft u een snelle definitie van de termen:

• Volume

  • De hoeveelheid output die door het systeem wordt verwerkt en geleverd.

• Capaciteit

  • De capaciteit van het systeem om het volume te leveren.
  • Bij elke stap worden de capaciteit en het volume anders gemeten, zoals in de onderstaande tabel wordt aangegeven. Voor de beste prestaties, zorg ervoor dat de capaciteit het volume bij elke stap aanpast, en dat zowel capaciteit als volume over alle stappen worden gedeeld. U kunt bijvoorbeeld de navigatie op de clientcomputer berekenen of in het cachegeheugen plaatsen, in plaats van deze voor elke aanvraag op de server te berekenen.

• Capaciteit en volume

  Wat/waar	Capaciteit	Volume
  Client	Rekeningvermogen van de computer van de gebruiker.	Complexiteit van de pagina-indeling.
  Netwerk	Netwerkbandbreedte.	Grootte van de pagina (code, afbeeldingen enzovoort).
  Verzendcache	Servergeheugen van de webserver (hoofdgeheugen en vaste schijf).	Webserver (hoofdgeheugen en vaste schijf). Aantal en formaat van de pagina's in de cache.
  Uitvoercache	Servergeheugen van de AEM (hoofdgeheugen en vaste schijf).	Aantal en grootte van de pagina's in de uitvoercache, het aantal afhankelijkheden per pagina. Dit volume wordt verlaagd door de verzendercache.
  Webserver	De computermacht van de server van het Web.	Hoeveelheid verzoeken. Dit volume wordt verlaagd door caching.
  Sjabloonmodel	De computermacht van de server van het Web.	Complexiteit van de sjablonen.
  Bewaarplaats	Prestaties van de opslagplaats.	Aantal pagina's dat vanuit de gegevensopslagruimte is geladen.

Overige cijfers

In de voorgaande secties worden de belangrijkste metriek beschreven die moet worden gedefinieerd.

Afhankelijk van uw specifieke vereisten kan het handig zijn om extra maatstaven te definiëren, afzonderlijk of met inachtneming van de bovenstaande classificaties.

Het is echter aan te raden om een kleine set nauwkeurige, basismeetgegevens te hebben die eenvoudig en betrouwbaar werken, in plaats van te proberen elk aspect van uw website te meten en te definiëren. Door zijn aard, zal uw website beginnen te veranderen en zich te ontwikkelen zodra het aan uw gebruikers wordt overgedragen.

Beveiliging

Veiligheid is cruciaal en een steeds groter wordende uitdaging. Het must moet van de vroegste stadia van uw project worden overwogen en worden gepland.

In Beveiligingschecklist worden de stappen beschreven die u moet uitvoeren om ervoor te zorgen dat uw AEM-installatie veilig is wanneer deze wordt geïmplementeerd. Andere veiligheidsaspecten worden behandeld onder Beveiliging (bij ontwikkeling) en Gebruikersbeheer en Beveiliging.

Parallelle en interactieve taken

Voor een nieuwe implementatie van een standaard AEM project zult u taken zoals moeten overwegen:

• Overhandigen van het verkoopproces.
• Implementatie van de klanttoepassing (Ontwikkeling).
• Installatie en configuratie van de infrastructuur (en bijbehorende processen) op de locatie van de klant (Infrastructuur).
• Creation (or migration) of the content (Content).
• Overdracht aan bewerkingen (Onderhoud/ondersteuning).
• Follow-upreleases.

Voor alle aspecten wordt aanbevolen een iteratieve benadering te gebruiken:

Voor elke categorie zijn enkele punten die moeten worden vermeld:

• Ontwikkeling

  • Definieer eerst de basisarchitectuur.

  • Verschillende herhalingen (sprints) gebruiken voor ontwikkeling:

    • Eerste sprint komt overeen met de eerste volledige ontwikkelingscyclus.
    • Eerste sprint resulteert in de eerste implementatie in uw testomgeving.
    • Elke sprint heeft een runable resultaat.
    • Elke sprint krijgt een klantentekens (minimum van gestructureerde test met terugkoppelen).

  • Plan voor de eventualiteit van een update van de beschikbare AEM versie tijdens het project.

  • Plan voor tests en optimalisatie tijdens sprints.

  • Plan voor stabilisatie- en optimalisatiefasen.

  • Maak een logboek met items die u wilt plannen voor verdere releases.

  • Plan voor partnerbetrokkenheid en overdracht.

• Infrastructuur

  • Definieer eerst de basisarchitectuur:

    • Geef prestatievereisten op.
    • Bepaal prestatiedoelstellingen (dat wil zeggen duidelijk verwachtingen bepalen).
    • Vaststellen van hardware- en infrastructuurarchitectuur; inclusief grootte.
    • Implementatie definiëren.

  • Gebruik verschillende herhalingen; voor de eerste sprint en de eerste configuratie:

    • Ontwikkelomgeving.
    • Ontwikkelingsproces.
    • Testomgeving.
    • Implementatieproces (inclusief configuratiebeheer).

  • Plan voor verschillende belastingstests.

  • Plan voor tests en optimalisatie tijdens sprints.

  • Plan voor een stabilisatie- en optimalisatiefase.

  • Implementeer zo vroeg mogelijk naar de productieomgeving (laat het bewerkingsteam het systeem instellen om ervaring op te doen).

  • Gebruik benoemde gebruikers en gedefinieerde rollen zo vroeg mogelijk.

  • Plan voor opleiding (bijvoorbeeld, beheerder opleiding).

  • Overdracht naar bewerkingen is gepland.

• Inhoud

  • De basisarchitectuur:
    • Hiermee wordt de inhoudshiërarchie geactiveerd.
    • Hiermee kunt u het inhoudsconcept definiëren.
    • Bepaalt het gebruik MSM en lay-out.
    • Definieert rollen, groepen, workflows en machtigingen.
  • Overweeg of het maken van offlinepagina nuttig is.
  • Plan voor de vroege verwezenlijking van eerste pagina's en inhoud (voor gebruik in tests en terugkoppelen).
  • Plan voor de migratie van bestaande inhoud.
  • Plan voor "in-sprint-migratie" na refactoring.
  • Plan 'content burndown' (sitemap voor go-live content).

Schatting van tijd en inspanning

Afhankelijk van uw resulterende takenlijst kunt u dan eerste schattingen maken van tijd en moeite voor (high-level) taakdefinities. Deze zouden een aanwijzing moeten omvatten van wie (klant of partner) zal doen wat en wanneer.

De volgende lijst bevat standaardbenaderingen en onderlinge relaties van de betrokken inspanningen, en dus kosten:

De gedetailleerde planning kan dan beschikbare of vereiste middelen met termijnen en kosten in verband brengen.

Referentiearchitectuur

De verwijzingsarchitectuur wordt gegeven om een malplaatjeoplossing voor de AEM architectuur te verstrekken. De referentiearchitectuur biedt oplossingen voor problemen die veel voorkomen bij bedrijfssystemen, zoals schalen, betrouwbaarheid en beveiliging.

De volgende sitemetriek moet worden gedefinieerd:

Overzicht van mogelijke gereedschappen

De volgende lijst bevat informatie over de gereedschappen die u kunt gebruiken. Het is bedoeld als inleiding, niet als een uitgebreide lijst met aanbevelingen, en mag u zeker niet ervan weerhouden andere instrumenten te gebruiken die u liever hebt.

Meer informatie

Daarnaast zijn de volgende punten van bijzonder belang:

• Aan de slag
• Technische vereisten
• Uw exemplaar controleren en onderhouden

Best practices voor

Adobe verstrekt verdere Beste praktijken voor alle fasen en publiek:

• Implementeren
• Authoring
• Beheer
• Ontwikkeling
• Projectbeheer