Veröffentlicht von Wir benutzen häufig Abkürzungen und oft hilft das unseren Gesprächspartner bei Architekturthemen nicht weiter.
Ich ergänze dieses Dokument und werde die vorherigen Wochen immer im Artikel lassen. So kann man diese auch schnell für eine Textsuche nutzen.
Fork – https://de.wikipedia.org/wiki/Abspaltung_(Softwareentwicklung) – Eine Abspaltung von einem Projekt und die Quelltexte oder Teile davon werden hierbei unabhängig vom ursprünglichen Projekt weiterentwickelt.
Canary Deployment – Eine neue Version wird z.B. in einer Server Farm parallel zur bestehenden Umgebung installiert, so dass ein Teil der User die neue Version bekommt. Beim Canary Deployment liegt der Fokus auf dem Deployment an bestimmte Usergruppen (Test-User oder die Abteilung IT)
Blue – Green – Deployment – Bei dieser Option für Rollouts werden Produktive Umgebung und die Staging / Test / Dev / QS Umgebung getauscht.
Rolling Deployment – Sehr ähnlich dem Canary Deployment, aber hier wird Stück für Stück die Lösung aktualisiert und damit greifen die Anwender zeitversetzt auf die neue Lösung zu.
SLA – Service Level Agreement – https://de.wikipedia.org/wiki/Service-Level-Agreement. Der SLA beschreibt die zugesicherten Leistungseigenschaften, also z.B. Verfügbarkeit, Antwortzeiten, Reaktionszeiten oder garantierte Bandbreite.
DTSTTCPW – Do the Simplest Thing That Could Possibly Work. Implementiere die einfachst mögliche Lösung, die funktioniert, da du sie nicht brauchen wirst. Siehe auch YAGNI.
IT – Abkürzungen im Architectural Elevator (vorherige Artikel)
SKU – Stock Keeping Unit – http://en.wikipedia.org/wiki/Stock-keeping_unit. Dies sind Artikelnummern und werden im Azure Umfeld häufig benutzt um Varianten / unterschiedliche Größen / unterschiedliche Performance von Produkten zu bezeichnen
BUFD – Big Up Front Design manchmal auch BDUF – Big Design UpFront. Beschreibt die klassiche IT Architektur in der man vor der Umsetzung eine große und sehr umfangreiche Architekturdokumentation erstellt.
YAGNI – https://de.wikipedia.org/wiki/YAGNI – You ain’t gonna need it. Dies bezeichnet ein Prinzip aus der Softwarearchitektur, das man Funktionalitäten erst implementiert, wenn man sie auch ganz sicher braucht. Auch wenn dieser Begriff aus der Softwarearchitektur kommt, so ist dies im Sinne von agilerer Architektur auch in anderen Architekturbereichen, wie Infrastruktur, ein sinnvoller Ansatz.
DRY – https://de.wikipedia.org/wiki/Don%E2%80%99t_repeat_yourself. Dieses Prinzip „Wiederhole dich nicht“ stammt auch aus der Softwarearchitektur und ist ein Prinzip, das besagt, Redundanz u vermeiden oder zumindest zu reduzieren.
KISS – Keep It Simple, Stupid – Halte es so einfach wie möglich. Dies stammt auch aus der Softwarearchitektur, aber gilt auch für alle anderen Bereichen und ist meinem Motto „Einfach ist immer besser!“, sehr verwandt.
Stakeholder – Interessensgruppen – Häufig verwendeter Begriff und kann jede Interessensgruppe oder Person mit Interesse beschreiben, die sich in dem Umfeld eures Projektes bewegt. Da wären z.B. die Anwender, der Entwickler, die Budgetverantwortlichen, der Datenschutzbeauftragte und jeder der eine Meinung zu eurem Projekt oder euerer Lösung haben könnte.
KPI – Key Performance Indicator – Definierte und messbare Werte an den die Performance von Gruppen, Systemen, Infrastuktur oder Personal gemessen wird.
Umgang mit Abkürzungen
Wenn ihr euch im Architectural Elevator bewegen wollt, dann gebt eurem „Stakeholder / Gesprächspartner“ die Chance die Begriff zu kennen. Eine Variante ist, dass man die Langform mehrmals benutzt und erst dann zur Abkürzung wechselt.
Wen das Thema Architecture Elevator interessiert und noch nicht sagt, der schaut am besten hier. Ich werde mich dem Thema in den nächsten Wochen auch hier im Blog widmen.