Denken wie Architekt:innen
Auch in 28 Sprachen
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada)
Modul 1 von 7 im Kapitel Denken wie Datenarchitekt:innen, dem ersten Kapitel des Kurses Data Architect. Jedes Modul steht für sich. Zurück: die Kapitelübersicht · Weiter: Das Datenmodell ist das Skelett
Die Frage, die dieses Modul beantwortet: Was ist der Unterschied zwischen Bauen und Architektur, und was tun Architekt:innen eigentlich?
Den grössten Teil meiner Laufbahn war ich ein Bauender.
Angefangen habe ich in der Softwareentwicklung. Ich habe mit Java und .NET gearbeitet, bevor ich zu Salesforce kam, und ich habe Jahre damit verbracht, Systeme zu entwerfen, Code zu schreiben, Plattformen zu integrieren, Architekt:innen auszubilden und Architekturen zu prüfen.
Aber eine der wichtigsten Lektionen auf diesem Weg war: Grossartig in der Entwicklung und grossartig in der Architektur zu sein, ist nicht immer dasselbe.
Wer baut, fragt:
Wie baue ich das?
Architekt:innen müssen andere Fragen stellen:
Sollten wir das bauen?
Warum bauen wir es auf diese Weise?
Welche Alternativen gibt es?
Was passiert, wenn es grösser wird?
Was passiert, wenn es ausfällt?
Und welche Entscheidung treffen wir heute, bei der wir uns in drei Jahren wünschen werden, wir hätten gründlicher darüber nachgedacht?
Ich erinnere mich an ein Projekt für ein Handelsunternehmen mit Terminen. Ich fragte: Wie viele Termine pro Tag und Filiale? Dann: Wie viele Filialen haben Sie? Und an wie vielen Tagen pro Woche haben Sie geöffnet? Schnell wurde mir klar, dass wir allein im ersten Jahr Millionen von Terminen haben würden. Das sind die Fragen, die Architekt:innen zu Beginn eines Projekts stellen.
Um diesen Wandel im Denken geht es in diesem Kurs eigentlich.
Die Person, die den Bauplan hält
Abschnitt betitelt „Die Person, die den Bauplan hält “Diese Analogie habe ich beim Unterrichten von Architekt:innen schon oft verwendet.
Stellen Sie sich eine Baustelle vor. Da sind Leute, die Beton giessen, Elektrik verlegen, Leitungen installieren, Wände aufstellen und Dutzende anderer spezialisierter Arbeiten erledigen. Sie müssen in ihrem Fach sehr gut sein.
Aber jemand muss auch den Bauplan in der Hand halten.
Diese Person muss verstehen, wie all diese Teile zusammenpassen. Sie muss bemerken, wenn etwas in einem Teil des Projekts anderswo ein Problem verursacht.
Das ist Architektur.
In der Technologie machen wir manchmal den Fehler zu glauben, Architekt:innen seien einfach die Personen, die am meisten wissen. Das trifft es nicht wirklich. Die Plattform zu kennen ist wichtig. Sie brauchen technische Tiefe. Aber Architektur ist kein Quizwettbewerb.
Die Aufgabe von Architekt:innen ist es, gute Entscheidungen zu treffen, manchmal mit unvollständigen Informationen und konkurrierenden Anforderungen, und die Folgen dieser Entscheidungen zu verstehen.
Das ist eine ganz andere Fähigkeit.
Nehmen Sie die Anforderung nicht einfach hin
Abschnitt betitelt „Nehmen Sie die Anforderung nicht einfach hin “Eine der ersten Gewohnheiten, die Architekt:innen entwickeln sollen, ist einfach:
Fragen Sie nach dem Warum.
Jemand sagt Ihnen:
Wir brauchen noch ein Objekt.
Warum?
Wir brauchen dieses Feld auf den Account kopiert.
Warum?
Wir müssen all diese Daten in Salesforce speichern.
Warum?
Das heisst nicht, schwierig zu sein. Es heisst, die eigentliche fachliche Anforderung zu verstehen, statt sofort die vorgeschlagene Lösung umzusetzen.
Eine Anforderung kommt oft als Entwurf verkleidet daher.
«Wir brauchen ein neues benutzerdefiniertes Objekt» ist nicht unbedingt eine Anforderung. Die Anforderung könnte eigentlich lauten: «Wir müssen diese Information getrennt erfassen.» Das ist nicht dasselbe.
Sobald Sie die eigentliche Anforderung verstanden haben, können Sie Alternativen prüfen. Vielleicht ist ein neues Objekt genau die richtige Antwort. Vielleicht gehört die Information an eine Stelle, die es schon gibt. Vielleicht sollte Salesforce diese Daten überhaupt nicht besitzen.
Architekt:innen müssen das, was das Geschäft braucht, von einem vorgeschlagenen Weg, es zu liefern, trennen.
Wir arbeiteten an einer Vertriebsanwendung, und der Kunde hatte mehrere Genehmigungen, jede mit einer genehmigenden Person und einem Datum. Der erste Wunsch war, Genehmiger 2 und Genehmiger 3, jeweils mit Datum, als Felder auf der Opportunity anzulegen. Als wir tiefer gruben, stellten wir fest, dass es mehr als zwei oder drei sein konnten. Also verlegten wir die Genehmigungen in ein untergeordnetes Objekt. Der Wunsch war: mehr Felder. Die Anforderung war: jede Genehmigung erfassen, wie viele es auch werden.
Über die Anforderung hinausdenken
Abschnitt betitelt „Über die Anforderung hinausdenken “Aus der Frage nach dem Warum folgen zwei Gewohnheiten, und jede bekommt später in diesem Kapitel ihr eigenes Modul.
Es gibt meist mehr als eine Antwort. Salesforce bietet viele Wege, ein Problem zu lösen, und manche davon sind fast sofort falsch. Zwischen denen zu wählen, die funktionieren, ist die Kunst der Abwägung (Modul 4).
Und die Anforderungen, die man Ihnen nennt, sind nicht alle Anforderungen, die Sie haben. Niemand sagt: «Stellen Sie sicher, dass es funktioniert, wenn der nächtliche Ladelauf nur zur Hälfte gelingt», aber es ist trotzdem eine Anforderung. Ich betrachte jeden Entwurf durch drei Blickwinkel: für heute bauen, für morgen planen, für das Scheitern planen (Modul 5).
Wer ein Architekturbüro mit dem Entwurf eines Gebäudes beauftragt, verlangt keine Brandmeldeanlage, keine Sprinkleranlage und auch nicht, dass das Gebäude ein Erdbeben übersteht. Man erwartet das als Teil der Arbeit, ohne zu fragen. Unsere Welt funktioniert genauso. Niemand verlangt eine saubere Fehlerbehandlung, Protokolle oder einen Weg, sich nach einem Ausfall zu erholen. Es liegt an den Architekt:innen zu wissen, welche dieser Systeme in den Entwurf gehören, und sie einzuplanen.
Machen Sie Ihre Begründung sichtbar
Abschnitt betitelt „Machen Sie Ihre Begründung sichtbar “Architekt:innen sollten nicht einfach in einen Raum kommen und verkünden: «So machen wir das.»
Ihre Aufgabe ist es auch, das Warum zu erklären. Ich möchte, dass die Beteiligten die Alternativen verstehen, die wir erwogen haben, und die Abwägungen, um die es geht. Das heisst nicht, einer Führungskraft ein 40-seitiges Designdokument zu geben. Es heisst, dieselbe Architektur dem Entwicklungsteam, dem Fachbereich und einer Führungskraft erklären zu können: verschiedene Gespräche über dieselbe Entscheidung.
Und das gelingt mit klaren Bauplänen und Anweisungen, wie bei der Person, die auf der Baustelle den Bauplan hält. Für Datenarchitekt:innen ist einer der wichtigsten dieser Baupläne das Datenmodell.
Wenn niemand versteht, warum eine Entscheidung getroffen wurde, ist die Wahrscheinlichkeit gross, dass jemand sie irgendwann rückgängig macht. Und vielleicht hat diese Person dafür vollkommen vernünftige Gründe, weil niemand die ursprüngliche Entscheidung je erklärt hat.
Architekt:innen müssen nicht alles selbst bauen
Abschnitt betitelt „Architekt:innen müssen nicht alles selbst bauen “Es gibt noch einen Übergang, der schwierig sein kann, besonders für Menschen, die über die Entwicklung zur Architektur kommen.
Sie müssen nicht alles persönlich bauen.
Ich verstehe immer noch gern, wie Dinge auf sehr technischer Ebene funktionieren, und dieses Fundament ist wichtig. Aber in der Architekturrolle wird Ihre Verantwortung grösser als Ihre eigene Umsetzung. Sie müssen nicht alles selbst bauen; Sie müssen wissen, wie Sie den Menschen, die es bauen, die richtige Richtung und die richtigen Parameter geben. Das heisst, genug zu verstehen, um ihre Arbeit anzuleiten, um zu erkennen, wann eine vorgeschlagene Umsetzung ein Architekturproblem schafft, und um zwischen den Details und dem grossen Ganzen zu wechseln.
Manchmal heisst das, tief in eine Abfrage, eine API oder ein Datenmodell einzusteigen.
Manchmal heisst es, einen Schritt zurückzutreten und zu fragen, ob wir überhaupt irgendetwas davon tun sollten.
Und immer öfter sind es nicht nur Menschen, die bauen. Mit KI arbeiten Architekt:innen womöglich direkt mit dem Werkzeug, das die Objekte, den Code und die Oberflächen erzeugt. Dann gehen Richtung, Parameter und Leitlinien an die KI, und sie gut vorzugeben, wird immer mehr zur Verantwortung der Architektur. Darauf kommen wir in Modul 7 zurück.
Das gehört zum Weg vom Bauen zur Architektur.
Ihre Aufgabe ist es, Entscheidungen zu treffen
Abschnitt betitelt „Ihre Aufgabe ist es, Entscheidungen zu treffen “Letztlich geht es in der Architektur um Entscheidungen.
Manche Entscheidungen lassen sich leicht ändern. Andere nicht.
Ein Seitenlayout kann geändert werden. Eine Beschriftung kann umbenannt werden.
Aber wählen Sie das falsche grundlegende Datenmodell, veröffentlichen Sie Kennungen, von denen Dutzende Systeme abhängig werden, oder legen Sie die Masterkopie kritischer Daten an die falsche Stelle, dann wird es sehr viel teurer, die Meinung zu ändern.
Das sind Architekturentscheidungen. Und genau auf diese Art von Entscheidungen konzentriert sich dieser Kurs.
In der Datenarchitektur treffen Sie Entscheidungen darüber, wie Informationen strukturiert sind, wo sie liegen, wie sie wachsen, wie sie sich bewegen, wer darauf zugreifen kann und wie der Rest des Unternehmens sie versteht.
Die Technologie ist wichtig.
Aber jede Salesforce-Funktion zu kennen, ist nicht das Ziel.
Das Ziel ist, das Urteilsvermögen zu entwickeln, um zu wissen, welches Werkzeug Sie verwenden, wann Sie es verwenden, was Sie dafür aufgeben und was als Nächstes passiert.
Das heisst, wie Architekt:innen zu denken.
Und jetzt können wir anfangen, wie Datenarchitekt:innen zu denken.
Was Architekt:innen hier entscheiden
Abschnitt betitelt „Was Architekt:innen hier entscheiden “- Ob eine Anfrage eine echte Anforderung ist oder ein vorgeschlagener Entwurf dafür.
- Welche Fragen vor dem Bauen zu stellen sind: Sollten wir, warum auf diese Weise, was könnten wir sonst tun, was passiert, wenn es wächst oder ausfällt.
- Welche Entscheidungen Architekt:innen treffen und welche den Menschen gehören, die bauen; und welche Richtung und Parameter sie denen geben, die bauen, ob Menschen oder KI.
- Wie man eine Entscheidung so erklärt, dass das Entwicklungsteam, der Fachbereich und eine Führungskraft sie jeweils verstehen.