Power BI Governance & Administration – Naming Conventions

Governance en Administation, cool, da’s echt een spannend en populair onderwerp! Nee? Nou, eigenlijk zou het dat wel moeten zijn! Vaak zien we dat ‘techniek en functionaliteit’ de boventoon voert in discussies met klanten en gebruikers. Om een BI platform toekomst bestendig op te leveren zijn een goede Governance en Administration echter een absolute vereiste. Zonder aandacht voor deze onderwerpen is je datavoorziening geen lang leven beschoren. Als onderdeel van de Powerdobs Best Practices ga ik in dit blog dieper in op Naming Conventions, en laten we beginnen met de vraag:

Wat zijn Naming Conventions?

“Naming Conventions zijn algemene regels die worden toegepast bij het maken van tekstscripts voor softwareprogrammering.“

Dat is de definitie van Techopedia, die vooral van toepassing is op (traditionele) softwareprogrammering. Dit geldt nog steeds voor gebruik tijdens het programmeren van bijvoorbeeld SQL, M of DAX.
Het kan elke overeengekomen syntax zijn, zoals een van de volgende:

• • DitIsPascalCase
  • ditIsCamelCase
  • dit-is-kebab-case
  • dit_is_snake_case

Maar ik denk dat het tegenwoordig veel breder is dan alleen de Naming Conventions voor programmeren te gebruiken. In de context van Power BI kun je Naming Conventions gebruiken in (letterlijk) alle dingen die een naam nodig hebben, zoals gateways, workspaces, apps, etc.

Waarom

Dus waarom zou je ergens een Naming Convention voor willen opzetten?

“Ze hebben veel verschillende doelen, zoals het toevoegen van duidelijkheid en uniformiteit [aan scripts], leesbaarheid voor applicaties van derden en functionaliteit in bepaalde talen en applicaties.”

Dat geldt nog steeds vooral voor programmeren. Ik zou zeggen dat het in de context van Power BI ook makkelijker is om dingen te vinden in je Power BI-ecosysteem. Niet alleen voor Power BI/IT Admins, maar ook voor rapportbouwers en eindgebruikers.

Hoe

En hoe zetten we een Naming Convention op? Ik zou zeggen “it depends”. ? Kijk bijvoorbeeld naar de eindeloze discussie over spaties of tabs.

Ik denk dat het er niet om gaat hoe je het implementeert, maar het feit dat je erover nadenkt, het implementeert en afdwingt en/of corrigeert. Het is beter om echt na te denken en het eens te worden over een bepaalde conventie dan om niets te doen.

Waar

En waar gebruiken we Naming Conventions? Omdat ze in traditionele programmeertalen zijn begonnen, is (zijn) de logische plaats(en) om te beginnen M en DAX. Ik denk dat de onderstaande 2 het meest bekend zijn voor DAX:

• • Schrijf altijd een kolom in het formaat TabelNaam[Kolom Naam]
  • Schrijf een measure altijd in het formaat [Measure Naam]

M en DAX

Er zijn al aardig wat goede bronnen beschikbaar die over M en DAX praten:

• • Power BI Antipatterns #13: Naming conventions in DAX door Daniil Maslyuk
  • Power BI Datasets: types and Naming Conventions door Sam McKay
  • Naming Tables, Columns And Measures In Power BI door Chris Webb, over het gebruik van voor mensen leesbare namen, correcte business terminologie en consistent zijn.
  • Power BI Best Practices door Matt Allington, waar hij in de eerste alinea spreekt over naamgevingsconventies
  • Naming temporary columns in DAX door SQLBI.com
  • Naming variables in DAX door Marco Russo

Power BI artifacts

Maar naast het gebruik van Naming Conventions in programmeertalen, zijn ook goede plaatsen om ze te (beginnen) te gebruiken:

• Gateways
  • Gatewaycluster/installaties zelf
  • Maar ook de gegevensbronnen in de gateway
    • Ik voeg graag het type gateway (Bestand/SQL/…), locatie/server/database en de gebruikersnaam toe, want dat is nog steeds niet zichtbaar in het nieuwe Power Platform Admin Center… Je kunt hier op het idee stemmen View Username Of A Gateway In Data Source Settings 🙂
• Workspaces
  • Marc Lelijveld heeft in deze blog post al een uitgebreid overzicht gegeven van de inrichting van de workspace en de naamgevingsconventies.
  • De naam van een workspace kan 256 tekens lang zijn, maar alleen omdat het kan, wil nog niet zeggen dat je het moet doen, toch?!
  • Ik vind de Implementation Planning docs ook erg nuttig, vooral de don’ts in de naam van een workspace:
    • Het woord workspace
    • De woorden Power BI
    • De naam van de organisatie, tenzij Business-2-Business wordt gebruikt
• Apps
  • Deze hoeven niet altijd dezelfde naam te hebben als de workspace, aangezien de app meestal is wat alle eindgebruikers zien en de toegang tot de workspacebeperkt is tot een subset van mensen.
    • Melissa Coates legt geweldig uit waarom je een Power BI-app moet gebruiken
• Datasets
  • Bekijk de blog van Marc waar hij uitlegt hoe je je Power BI-dataflows georganiseerd en geoptimaliseerd houdt
• AAD-groepen (gebruikt voor Power BI)
  • Als de groepen in een workspace worden gebruikt, probeer dan de naam/naamgevingsconventie van de workspace zelf op te nemen en voeg misschien de groep(en) van gebruikers toe, zoals [workspacenaam]-admins/members/viewers
• Premium capaciteiten
  • Als je er maar 1 hebt, is het misschien minder logisch, maar als je meerdere capaciteiten hebt, is het voor mij logisch om het type capaciteit in de naam op te nemen. Dus ofwel P1/2 of het aantal v-Cores dat aan die instantie is toegewezen
• Identiteits- en toegangsbeheer
  • Dit is misschien een beetje off-topic voor de meeste Power BI-gebruikers, maar als Power BI-beheerders nauw samenwerken met het IT/IAM-team/systeem en gebruikers toegang moeten krijgen tot workspaces/apps via IAM, waarbij de naamgeving tussen Power BI wordt gesynchroniseerd, kunnen naming conventions bij AAD(-groups) en IAM-verzoeken een goede zaak zijn

Afsluiting

Er zijn veel plaatsen genoemd waar naming conventions nuttig kunnen zijn. Ze worden gebruikt omdat ze consistentie bevorderen en voor meer leesbaarheid en duidelijkheid kunnen zorgen. Heb jij ergens naming conventions geïmplementeerd? Hoe gebruik jij ze? Of waarom niet? Laat het me weten!

Ben je naast naming conventions geïnteresseerd in meer ervaring en ideeën over Power BI, kijk dan ook naar een eerdere post over Governance en Administration en natuurlijk ook naar de Powerdobs Best Practices.