\chapter{Conclusie}

Ten eerste kunnen de volgende primaire knelpunten worden gedefinieerd voor het implementeren van netwerkautomatisering in de praktijk:

\begin{enumerate}
    \item Reeds gerealiseerde en op Powershell gebaseerde automatiseringen die niet volledig overdragen naar het implementeren van Ansible in de praktijk. Dit maakt investeringen in het realiseren van Ansible op de kortere termijn minder waardevol omdat deze functionaliteiten al mogelijk waren met de oude tools. Hiernaast zijn deze investeringen hoger omdat het nu in een nog relatief onbekende manier moet worden geimplementeerd.
    \item De reeds bestaande kennis over PowerShell in het netwerking team is niet of minder relevant bij het in gebruik nemen van Ansible. Dit presenteerd weer op de kortere termijn een extra drempel voor het in gebruik nemen van Ansible omdat het nu meer tijd kost om even effectief te zijn met de bestaande powershell tools en/of kennis.
    \item \label{knelpunt:am_useability} Een relatief complexe API van Asset Management (voornamelijk veroorzaakt door de  meta-modeleer functionaliteit). Dit verhoogd de vereiste tijdsinvestering en minimale complexiteit om tools te maken die integreren met deze API
    \item Geen bestaande integraties met Asset Management. Terwijl het gebruik maken van deze API (direct of indirect) een vereiste is voor het toepassen van Ansible in productie netwerken voor het genereren van een ansible inventory. Dit in combinatie met punt \ref{knelpunt:am_useability} veroorzaakt dat het niet mogelijk is om Ansible te gebruiken en het een hoge upfront investering vereist om op te lossen.
    \item Asset Management lijkt nog niet volledig optimaal te worden ingezet aan de hand van de templates die grotendeels hetzelfde zijn. Hierdoor is er een grote kans dat de inventory plugin voor Ansible op korte termijn moet worden aangepast om eventuele herstructureringen in Asset Management te reflecteren.
\end{enumerate}