Myśleć jak architekt
Dostępne także w 28 językach
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Moduł 1 z 7 w rozdziale Myśleć jak architekt danych, pierwszym rozdziale kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: przegląd rozdziału · Dalej: Model danych to szkielet
Pytanie, na które odpowiada ten moduł: czym różni się budowanie od projektowania architektury i co właściwie robi architekt?
Przez większość kariery byłem budowniczym.
Zaczynałem jako programista. Pracowałem w Javie i .NET, zanim przeszedłem do Salesforce, a potem przez lata projektowałem systemy, pisałem kod, integrowałem platformy, uczyłem architektów i recenzowałem architektury.
Jedna z najważniejszych lekcji, jakie wyniosłem po drodze, brzmi jednak tak: bycie świetnym budowniczym i bycie świetnym architektem to nie zawsze to samo.
Budowniczy pyta:
Jak to zbudować?
Architekt musi zadać zupełnie inne pytania:
Czy powinniśmy to budować?
Dlaczego budujemy to właśnie w ten sposób?
Jakie są alternatywy?
Co się stanie, gdy to urośnie?
Co się stanie, gdy to zawiedzie?
I jaką decyzję podejmujemy dziś, nad którą za trzy lata będziemy żałować, że nie pomyśleliśmy dłużej?
Pamiętam projekt dla firmy handlowej, która umawiała wizyty klientów. Zapytałem: ile wizyt dziennie przypada na jeden sklep? Potem: ile macie sklepów? I ile dni w tygodniu są otwarte? Szybko zrozumiałem, że już w pierwszym roku będziemy mieli miliony wizyt. Takie pytania architekt zadaje na początku projektu.
O tej zmianie sposobu myślenia naprawdę jest ten kurs.
Osoba, która trzyma plan
Dział zatytułowany „Osoba, która trzyma plan ”Używałem tej analogii wiele razy, ucząc architektów.
Wyobraź sobie plac budowy. Są tam ludzie, którzy wylewają beton, prowadzą instalację elektryczną, montują hydraulikę, stawiają ściany i wykonują dziesiątki innych specjalistycznych prac. Muszą być w tym bardzo dobrzy.
Ale ktoś musi też trzymać plan.
Ta osoba musi rozumieć, jak wszystkie te elementy do siebie pasują. Musi zauważyć, kiedy coś, co dzieje się w jednej części projektu, tworzy problem gdzie indziej.
To jest architektura.
W technologii czasem popełniamy błąd, myśląc, że architekt to po prostu osoba, która wie najwięcej. Nie o to chodzi. Znajomość platformy jest ważna. Potrzebujesz głębi technicznej. Ale architektura to nie teleturniej.
Zadaniem architekta jest podejmowanie dobrych decyzji, czasem przy niepełnych informacjach i sprzecznych wymaganiach, oraz rozumienie konsekwencji tych decyzji.
To zupełnie inna umiejętność.
Nie przyjmuj wymagania bez pytań
Dział zatytułowany „Nie przyjmuj wymagania bez pytań ”Jeden z pierwszych nawyków, które chcę zaszczepić architektom, jest prosty:
Pytaj „dlaczego”.
Ktoś ci mówi:
Potrzebujemy kolejnego obiektu.
Dlaczego?
Potrzebujemy, żeby to pole było kopiowane na konto.
Dlaczego?
Potrzebujemy wszystkich tych danych w Salesforce.
Dlaczego?
Nie chodzi o to, żeby być trudnym. Chodzi o zrozumienie rzeczywistego wymagania biznesowego, zamiast od razu wdrażać zaproponowane rozwiązanie.
Wymaganie często przychodzi w przebraniu projektu.
„Potrzebujemy nowego obiektu niestandardowego” to niekoniecznie wymaganie. Wymaganiem może być w rzeczywistości „musimy śledzić te informacje osobno”. To nie to samo.
Gdy zrozumiesz prawdziwe wymaganie, możesz zacząć szukać alternatyw. Może nowy obiekt to dokładnie właściwa odpowiedź. Może te informacje pasują do czegoś, co już istnieje. A może Salesforce w ogóle nie powinien być właścicielem tych danych.
Architekt musi oddzielić to, czego potrzebuje biznes, od jednego z proponowanych sposobów, jak to dostarczyć.
Pracowaliśmy nad aplikacją sprzedażową, a klient miał wiele zatwierdzeń, każde z osobą zatwierdzającą i datą. Pierwsza prośba brzmiała: dodajcie na szansie sprzedaży pola Zatwierdzający 2 i Zatwierdzający 3, każde z datą. Gdy zagłębiliśmy się w temat, okazało się, że zatwierdzeń może być więcej niż dwa czy trzy. Przenieśliśmy więc zatwierdzenia do obiektu podrzędnego. Prośba dotyczyła dodatkowych pól; wymaganiem było śledzenie każdego zatwierdzenia, ile by ich nie było.
Myśleć poza wymaganiem
Dział zatytułowany „Myśleć poza wymaganiem ”Z pytania „dlaczego” wynikają dwa nawyki i każdy z nich dostaje dalej w tym rozdziale własny moduł.
Zwykle jest więcej niż jedna odpowiedź. Salesforce daje nam wiele sposobów rozwiązania problemu, a niektóre z nich są złe niemal od razu. Wybór między tymi, które działają, to sztuka kompromisów (moduł 4).
A wymagania, które dostajesz, to nie wszystkie wymagania, jakie masz. Nikt nie mówi „upewnij się, że to działa, gdy nocny import uda się tylko w połowie”, ale to wciąż jest wymaganie. Na każdy projekt patrzę przez trzy soczewki: buduj na dziś, planuj na jutro, planuj na awarię (moduł 5).
Pomyśl o kimś, kto zatrudnia architekta do zaprojektowania budynku. Nie prosi o alarm przeciwpożarowy, instalację tryskaczową ani o to, żeby budynek przetrwał trzęsienie ziemi. Oczekuje tego w ramach zlecenia, bez proszenia. W naszym świecie jest tak samo. Nikt nie prosi o łagodną obsługę błędów, o logi ani o sposób przywrócenia działania, gdy coś zawiedzie. To architekt musi wiedzieć, które z tych systemów należą do projektu, i je w nim umieścić.
Pokaż swoje rozumowanie
Dział zatytułowany „Pokaż swoje rozumowanie ”Architekt nie powinien po prostu wejść do sali i ogłosić: „Robimy tak”.
Twoim zadaniem jest też wyjaśnić dlaczego. Chcę, żeby interesariusze rozumieli alternatywy, które rozważaliśmy, i kompromisy, które się z nimi wiążą. Nie znaczy to, że dajesz członkowi zarządu 40-stronicowy dokument projektowy. Znaczy to, że potrafisz wyjaśnić tę samą architekturę programiście, biznesowi i członkowi zarządu: różne rozmowy o tej samej decyzji.
Robi się to za pomocą jasnych planów i instrukcji, tak jak osoba, która trzyma plan na placu budowy. Dla architekta danych jednym z najważniejszych takich planów jest model danych.
Jeśli nikt nie rozumie, dlaczego podjęto decyzję, jest spora szansa, że ktoś ją w końcu cofnie. I może mieć ku temu całkiem rozsądne powody, bo nikt nigdy nie wyjaśnił pierwotnej decyzji.
Architekt nie musi budować wszystkiego
Dział zatytułowany „Architekt nie musi budować wszystkiego ”Jest jeszcze jedno przejście, które bywa trudne, zwłaszcza dla osób, które trafiają do architektury z programowania.
Nie musisz wszystkiego budować osobiście.
Nadal lubię rozumieć, jak rzeczy działają na bardzo technicznym poziomie, i ten fundament ma znaczenie. Ale jako architekt odpowiadasz za więcej niż za własną implementację. Nie musisz budować wszystkiego; musisz umieć dać ludziom, którzy budują, właściwy kierunek i właściwe parametry. To znaczy rozumieć wystarczająco dużo, żeby prowadzić ich pracę, rozpoznać, kiedy zaproponowana implementacja tworzy problem architektoniczny, i przechodzić między szczegółami a szerszym obrazem.
Czasem oznacza to głębokie zanurzenie w zapytanie, API albo model danych.
Czasem oznacza to cofnięcie się o krok i pytanie, czy w ogóle powinniśmy cokolwiek z tego robić.
A coraz częściej tym, kto buduje, nie są już tylko ludzie. Przy AI architekt może pracować bezpośrednio z narzędziem, które generuje obiekty, kod i ekrany. Wtedy kierunek, parametry i wytyczne trafiają do AI, a dobre ich przekazanie staje się coraz bardziej odpowiedzialnością architekta. Wrócimy do tego w module 7.
To część drogi od budowniczego do architekta.
Twoim zadaniem jest podejmowanie decyzji
Dział zatytułowany „Twoim zadaniem jest podejmowanie decyzji ”Ostatecznie architektura to decyzje.
Niektóre decyzje łatwo zmienić. Inne nie.
Układ strony można zmienić. Etykietę można przemianować.
Ale jeśli wybierzesz zły podstawowy model danych, opublikujesz identyfikatory, od których zaczną zależeć dziesiątki systemów, albo umieścisz główną kopię krytycznych danych w złym miejscu, zmiana zdania stanie się dużo droższa.
To są decyzje architektoniczne. I właśnie na takich decyzjach skupia się ten kurs.
Jako architekt danych będziesz decydować o tym, jak informacje są zbudowane, gdzie się znajdują, jak rosną, jak się przemieszczają, kto ma do nich dostęp i jak rozumie je reszta przedsiębiorstwa.
Technologia ma znaczenie.
Ale celem nie jest znajomość każdej funkcji Salesforce.
Celem jest wyrobienie sobie osądu, żeby wiedzieć, którego narzędzia użyć, kiedy go użyć, z czego rezygnujesz i co stanie się dalej.
Tak myśli architekt.
A teraz możemy zacząć myśleć jak architekt danych.
Co tu decyduje architekt
Dział zatytułowany „Co tu decyduje architekt ”- Czy prośba to prawdziwe wymaganie, czy jeden z proponowanych projektów, który ma je spełnić.
- Jakie pytania zadać, zanim cokolwiek powstanie: czy powinniśmy, dlaczego tak, co innego moglibyśmy zrobić, co się stanie, gdy to urośnie albo zawiedzie.
- Które decyzje należą do architekta, a które do osób, które budują; i jaki kierunek i jakie parametry dać budującym, ludziom albo AI.
- Jak wyjaśnić decyzję, żeby zrozumieli ją i programista, i biznes, i członek zarządu.