Architekturansätze

Die Architektur eines Systems kann auf vielfältige Weise gestaltet werden und unterschiedliche Ansätze und Methoden umfassen, erfolgreiche moderne ArcGIS-Architekturen haben jedoch einige wichtige Prinzipien gemein. Dieser Abschnitt des Well-Architected Framework enthält mehrere Themen zur traditionellen Architektur, in denen es um die Trennung von Software und Hardware, Überlegungen zur Cloud oder Integrationsstrategien geht. Die Vielfalt der zusätzlichen Themen verdeutlicht jedoch, wie sich die Rolle eines Business- oder Systemarchitekten verändert hat. Auch die Ergebnisse der Architekturaktivitäten haben sich in Erwartung neuer Kenntnisse, Themen und Überlegungen geändert. Diese Empfehlungen zielen darauf, die Strategien auf eine stabile Grundlage zu stellen und nicht, eine Reihe von spezifischen Schritten und Ergebnissen bereitzustellen.

Zunächst einmal ist es wichtig, einen Business-First-Ansatz zu verfolgen. Was heißt das in der Praxis? Im Grunde bedeutet es, dass die Architektur in erster Linie so konzipiert sein sollte, dass bestimmte Workflows, geschäftliche Funktionen oder Ergebnisse, die die Organisation anvisiert, auch unterstützt werden. Anstatt sich auf einzelne Bereiche wie Performance, Verfügbarkeit, Bereitstellungstechnologie oder Produkterweiterungen zu konzentrieren, sollten diese Entscheidungen alle im Hinblick darauf getroffen werden, welche geschäftlichen Anforderungen die Funktion erfüllen soll. Dieser bedarfsorientierte Ansatz führt zu Systemen, die zuerst die primären Funktionen unterstützen und dann effektiv wachsen, um die Wirkung und Akzeptanz in der gesamten Organisation zu erhöhen.

Zweitens ist es wichtig, eine Architekturentwicklungsmethode (Architecture Development Methodology, ADM) zu verfolgen. Es gibt viele verschiedene ADMs und nicht eine einzelne optimale Option, aber wo immer möglich, sollten Sie für Architekturprojekte die in ihrer Organisation normalerweise verwendeten Methoden übernehmen.Mit Ansätzen, die sich an der Architektur anderer Systeme orientieren, können die Systemanforderungen einfacher kommuniziert, andere Architekturrichtlinien integriert und schließlich die Zustimmung oder Unterstützung anderer Teile der Organisation gewonnen werden. Dies gilt auch für die Einbeziehung von IT- und Business-Architekten aus anderen Teilen der Organisation, wo immer dies möglich ist.

Drittens gilt: Konzentrieren Sie sich auf ein flexibles Design und versteifen Sie sich nicht auf eine perfekte Hardware-Größe oder physische Definition. Während die Investitionsausgaben für Hardware-Anschaffungen viele Jahre lang die Projektkosten in die Höhe getrieben haben (und dies in einigen Organisationen auch weiterhin tun), hat der allgemeine Zugang zu Virtualisierung und Cloud Computing die Bedeutung genau festgelegter Hardware-Zusagen während der Architekturphase verringert. Das Ändern der Rechenleistung, des Arbeitsspeichers oder des Speichers eines Systems ist heute in der Regel einfacher und deutlich günstiger als in traditionelleren Architekturen. Dies deutet darauf hin, dass flexible, allgemein definierte Hardwareprofile für die meisten Architekturen ausreichen. Viele Organisationen legen nach wie vor Wert auf eine genaue Empfehlung für die anfängliche Dimensionierung eines Systems. Diese Systeme oder Anwendungen sind weiterhin für die laufenden Kosten solcher Systeme verantwortlich. Zusammenfassend lässt sich sagen, dass eine wichtige Aufgabe von Architekten darin besteht, eine vernünftige erste Schätzung gegen die potenziellen Änderungen, die durch eine zunehmende Nutzung, neue Funktionen oder neue Benutzer-Communitys entstehen, abzuwägen.

Neue Anforderungsbereiche tragen dazu bei, dass ein strukturierter Architekturansatz immer wichtiger wird, etwa in den Bereichen Sicherheit, Unternehmensintegrationen, Datenhoheit oder bei anderen Themen, die in herkömmlichen Umgebungen möglicherweise nicht so sehr im Vordergrund standen. Diese Anforderungen können sich auf das Lösungsdesign, die Hardwareauswahl und die allgemeine Managementphilosophie eines Projekts oder Systems auswirken und sind ebenso wichtig für die funktionalen oder performancebasierten Anforderungen, die normalerweise die Architekturauswahl bestimmen würden.

Beachten Sie bei der Architektur von ArcGIS-Systemen zusätzlich folgende Best Practices:

• Seien Sie flexibel: Stellen Sie sich auf wechselnde Dynamiken, Änderungen der Anforderungen während und nach der Entwurfsphase und Richtungsänderungen bei der IT-Strategie Ihrer Organisation ein.
• Seien Sie reaktionsfähig: Überprüfen Sie regelmäßig die Erfolge (und Herausforderungen) einer Architektur mit den Projektbeteiligten und schlagen Sie Änderungen vor, die ihre Anforderungen berücksichtigen, sowohl im Hinblick auf neue und verbesserte Funktionen als auch im Hinblick auf Änderungen an unerwünschten Funktionen.
• Seien Sie zielbewusst: Wenn Änderungen erforderlich sind, machen Sie sich die Wirkung, den Zeitplan und die Auswirkungen auf die Benutzer klar. Eine sorgfältige Koordination der Architekturänderungen reduziert unklare Situationen, erhöht das Vertrauen der Benutzer in das System und verbessert die Chance auf erfolgreiche Ergebnisse.

Der Architekturprozess

Beim Entwerfen von Systemen mit ArcGIS unternehmen viele Organisationen ähnliche Schritte in einem strukturierten Prozess, der in der Regel von der verwendeten Architekturentwicklungsmethode (ADM) abhängt. Als zusätzlichen Kontext finden Sie hier Beispiele zu Architekturphasen mit einigen spezifischen Details zu ArcGIS.

1. Erarbeitung des Frameworks und der Grundlagen: In dieser Phase ist es wichtig, ein ADM zu identifizieren und die wichtigsten Architekturprinzipien festzulegen, die den Entwurf leiten, z. B. die Fokussierung auf Service Level Agreements (SLA), die Erwartung flexibler oder Wasserfall-Projektansätze usw.
2. Definition einer Architekturvision: Hierbei werden Schlüsselthemen identifiziert, an denen sich die Architekturentwicklung orientiert, z. B. eine organisatorische Cloud-First-Initiative, die Umstellung auf einen anderen Datenbankanbieter oder auf ein anderes Betriebssystem oder der Wunsch, neue Funktionen schnell in das resultierende System zu implementieren. Diese Vision bildet die anfängliche Grundlage für Entscheidungen und Empfehlungen, die im späteren Verlauf des Prozesses getroffen werden.
3. In der Phase der Unternehmensarchitektur liegt der Fokus auf dem “Unternehmen” – ein subjektiver Begriff, der sich im Allgemeinen auf die täglichen Betriebsabläufe sowie die daran beteiligten Mitarbeiter einer Organisation bezieht, unabhängig davon, ob es sich um eine öffentliche oder private Einrichtung handelt. Diese Phase konzentriert sich auf vorhandene und gewünschte Workflows und Funktionen: Welche ArcGIS-basierten Komponenten tragen zur Erledigung der Aufgaben bei? Diese Phase umfasst auch nichtfunktionale Anforderungen, die für das Unternehmen wichtig sind, z. B. Benutzerfreundlichkeit, Sicherheit oder Performance. Die Trennung der funktionalen Anforderungen der Unternehmensarchitektur (die gewünschten Workflows und Funktionen) von den nichtfunktionalen Anforderungen und der Lösungsarchitektur (die logische Lösung oder Software und die Lösungskomponenten) ist enorm wichtig, wenn es darum geht, Lücken und potenzielle Bereiche, in denen diese Anforderungen miteinander in Konflikt geraten können, zu identifizieren.
4. Sobald diese Workflows definiert sind, geht es in der Phase der Daten- und Informationssystemarchitektur um die Strukturen, die den Workflows zugrunde liegen: die Anwendungsschnittstellen (z. B. Mobil-, Web- oder Desktop-Apps) sowie die Datenstrukturen (Schema, Datenmodell, Speicher), mit denen die Persistenz von Geschäftsdaten unterstützt werden. In dieser Phase können spezifische Empfehlungen zu den zu verwendenden Apps, Clientfunktionen oder Speichermustern erstellt werden.
5. Da es viele Möglichkeiten gibt, ArcGIS bereitzustellen, konzentriert sich die Phase der Technologiearchitektur auf die Entscheidungen und Unterscheidungen, die zu einer tatsächlichen Softwarespezifikation oder -anschaffung führen. In dieser Phase können Entscheidungen zur Rolle von ArcGIS Online und ArcGIS Enterprise getroffen oder ein spezifischer Datenbankanbieter, Cloud-Provider oder das Betriebssystem zum Hosten der Software ausgewählt werden.
6. Sobald das Zielbild klarer ist, kann eine Organisation mit der Planung der Bereitstellung, Möglichkeiten und Lösungen beginnen und sich dabei auf die Schritte und Änderungen konzentrieren, die nötig sind, um das neue System den Benutzern zur Verfügung zu stellen. Dies kann erhebliche organisatorische Änderungen, Anschaffungen oder Aufstockungen bei den Unterstützungsmöglichkeiten des technischen Personals oder der Bewertung von Technologie umfassen, auf deren Grundlage Entscheidungen getroffen werden können.
7. Wenn ein vorhandenes System bereits für einige Geschäftsprozesse eingesetzt wird, was tasächlich häufig der Fall ist, hilft die Migrationsplanung dabei, sicherzustellen, dass Benutzer schnell und effizient auf die neue Architektur umsteigen können. Dies kann eine personal- und prozessorientierte Change-Management-Planung umfassen, erstreckt sich jedoch auch auf die Planung der Technologie, damit Integrationen, Workflows und sogar öffentlich zugängliche Inhalte reibungslos umgestellt werden und auf die neue Architektur zugreifen und mit ihr interagieren können.
8. Nach Abschluss dieser Planung werden häufig weitere Überlegungen zur Governance diskutiert. Diese können beeinflussen, wie das neue System verwendet wird, wie Änderungen an Daten oder Anwendungen überprüft und kontrolliert werden und wie der Prozess der Überprüfung, Überarbeitung und Implementierung fortgesetzt wird, damit die Architektur weiterhin relevant bleibt, an neue Anforderungen angepasst werden kann und auf die Erwartungen der Benutzer reagiert.

Mit einer Struktur und einem gut geplanten Architekturprozess können sowohl große als auch kleine Systeme sorgfältig entworfen, effektiv implementiert und effizient über viele Jahre hinweg verwaltet werden, auch wenn sich die Benutzer und Zielgruppen ändern.