Was sind Namenskonventionen und wie sind sie in der IT Architektur von Nutzen?

Namenskonventionen im Kontext der Enterprise und Software Architektur sind Standards um verschiedene IT Assets wie Datenbanken, Services, Komponenten oder auch Umgebungen zu bezeichnen.

Was will man erreichen?

Mit der Vergabe einheitlicher Namen und Bezeichnungen können einige Vorteile erzielt werden:

  1. Konsistenz: Durch die Verwendung einheitlicher Namen und Bezeichnungen kann eine Konsistenz auf verschiedenen Ebenen erreicht werden.

  2. Zusammengehörigkeit: Es sollte klar ersichtlich sein welche Komponenten zusammengehören. So soll ersichtlich sein welche Datenbank zu welcher Anwendung gehört und welche URLs von welcher Komponente beantwortet werden. Auch die einheitliche Benennung von Laufzeitumgebungen (z.B. „INT“, „SYT“, „UAT“, „PROD“) bringt große Vorteile mit sich.

  3. Klarheit: Hält sich etwa ein Team nicht an die Vorgabe das die Umgebung für Akzeptanztest als UAT zu bezeichnen ist sondern benutzt das Kürzel STA, müssen auf einmal Verbindungen zwischen UAT und STA erstellt werden, was wiederum zu Verwirrung führen kann.

  4. Verhinderung von Namenskollisionen: Eine Standardisierung soll die mögliche Entstehung von zwei Ressourcen desselben Typs mit demselben Namen verhindern. Zwar ist es technisch möglich, dass zwei Datenbanken mit derselben Bezeichnung zu erstellen, dies würde aber immer wieder zu Verwirrung führen.

  5. Automatisierung: Die einheitliche Vergabe von Bezeichnungen erlaubt es einen höheren Grad der Automatisierung zu erreichen. So können verschiedene Programme und Skripte aus den Namen bestimmte Herleitungen treffen und ihre Aufgabe zuverlässig erledigen. Beispiele dafür sind eine automatische Kostenverrechnung von verbrauchten Ressourcen.

Wie geht das?

Im Enterprise Architecture Model (EAM) sollte für jede Anwendung eine eindeutige Bezeichnung inkl. Kürzel vergeben werden. Dabei ist es wichtig, dass das Kürzel selbst wiederum standardisiert ist, z.B. immer aus 3 alphanumerischen Zeichen besteht. Zusammen mit einer einheitlichen Benennung der verschiedenen Umgebungen kann ein hoher Grad an Standardisierung erreicht werden. So kann es ausreichen, in einer nächsten Umgebung nur die Bezeichnung der Umgebung zu ersetzen und ansonsten die Konfiguration konsistent zu halten (aus UAT wird PRD). Die Verwendung der Umgebung innerhalb einer Bezeichnung hat oft auch damit zu tun, wie der Scope der einzelnen Assets bereits eingeschränkt ist – so müssen zum Beispiel Domain Name im gesamten Unternehmen sicher eindeutig sein.

Tipps

Es gibt ein paar einfache Dinge welche sich in meinen Augen bewährt haben:

  • keine Leerzeichen in Bezeichnungen.
  • Sonderzeichen verhindern (möglichst alphanumerisch).
  • CamelCase für Namen.
  • Dreistelliges Kürzel verwenden; dieses kann, muss aber nicht eine Abkürzung sein.
  • Kürzel möglichst immer in Grossbuchstaben schreiben.
  • Teile der Bezeichnung klar vom Rest trennen (z.B. mit „_“ in ACM_1_AccountManager), dies erleichtert das extrahieren von Informationen aus der Bezeichnung und somit die Automatisierung.
  • Nur die Major Version in Bezeichnungen aufnehmen, da Minor und Patch Versionen rückwärtskompatibel sein sollten. Dies erlaubt es mehrere unterschiedliche Major Versionen parallel zu betreiben.
  • allfällige Limitierungen einzelner Plattformen beachten (z.B. dürfen Benutzernamen für MySQL maximal 32 und Datenbanknamen 62 Zeichen haben)

Beispiel

Definition

  • Anwendungsname: AccountManager
  • Kürzel: ACM
  • Version: 1
  • Umgebungen: INT (Integration-Test), SYT (System-Test), UAT (Useracceptance-Test), PRD (Production)

Anwendung

  • Artifakt <KÜRZEL>_<MAJOR_VERSION>_<FREE_TEXT> -> ACM_1_AccountManager
  • Datenbank ACM_ACCOUNTMANAGER
  • HTTP Resource /acm/accounts/627273
  • Kafka Topic ACM.accountsACM.accountvaluation
  • Domänen syt-acm.supercompany.comuat-acm.supercompany.com

Weiterführende Beispiele für Namenskonventionen zu physische Geräte wie Drucker oder Datenbanken.

Beitrag teilen

Dominik Bartholdi

Dominik Bartholdi ist ICT Architect bei Raiffeisen und bloggt aus dem Unterricht des CAS Digital Architect.

Alle Beiträge ansehen von Dominik Bartholdi →

Schreibe einen Kommentar