Architektura to sztuka kompromisów

🌐 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)

Obraz wygenerowany przez AI

Przetłumaczone przez AI. Jeszcze niesprawdzone przez społeczność. Czytaj po angielsku

Moduł 4 z 7 w rozdziale Myśleć jak architekt danych, pierwszym rozdziale kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Test Odwracalności · Dalej: Buduj na dziś. Planuj na jutro. Planuj na awarię.

Pytanie, na które odpowiada ten moduł: kiedy kilka rozwiązań mogłoby zadziałać, jak architekt wybiera i jak wyjaśnia swój wybór?

Gdyby architektura polegała po prostu na znalezieniu poprawnej odpowiedzi, byłoby dużo łatwiej. Poznaj platformę, poznaj wzorce, poznaj limity, wybierz właściwy, gotowe.

Prawdziwa architektura tak nie działa. Trudne decyzje rzadko dotyczą wyboru między oczywiście dobrym a oczywiście złym rozwiązaniem. Dotyczą wyboru między kilkoma rozwiązaniami, które mogłyby zadziałać, każde z zaletami i wadami, każde prowadzące architekturę w nieco innym kierunku. Właśnie tu architekt zapracowuje na swoje miejsce przy stole.

Wiele sposobów na rozwiązanie problemu

Używałem wersji tego przykładu wiele razy, ucząc architektów.

W Salesforce problem często da się rozwiązać na wiele sposobów. Czasem podaję liczbę, powiedzmy dziesięć, ale to analogia, a nie wyliczenie. Wiele opcji ma problemy od samego początku: natrafiają na ograniczenie platformy, pomijają kluczowe wymaganie albo tworzą problem z bezpieczeństwem lub wydajnością, którego nie możemy zaakceptować. Te możemy szybko odłożyć. Niektóre inne działają dziś, ale będą miały problemy, gdy dane urosną. Technicznie działają, ale nie wytrzymają wzrostu, o którym już wiemy, że nadejdzie.

Zostaje niewielka liczba opcji, które udźwigną twoje potrzeby w przyszłości, i tu robi się ciekawie. Każda z nich może zadziałać, skalować się i spełnić wymagania. Która jest więc poprawna? Może wszystkie. Zadaniem architekta jest zrozumieć różnice.

Nawet coś tak prostego jak lista wyboru działa dziś, a może mieć problemy, gdy dane urosną. Lista wyboru jest łatwa dla użytkowników. Ale zapytaj, skąd biorą się wartości i ile może ich być. Listy wyboru najlepiej działają przy mniej więcej 20 wartościach. Czasem dochodzimy do 50, jak stany USA, a rzadko ponad 100, jak kraje, i wtedy robią się nieporęczne. Dla każdej listy wyboru znaj więc górną granicę. A zmiana wartości listy wyboru to zmiana metadanych, a nie danych.

Użyj zamiast tego relacji wyszukiwania (lookup), a interfejs użytkownika trochę się skomplikuje. Za to lista może rosnąć bez górnej granicy, a nowe wartości mogą przychodzić z integracji. To kompromis kosztem użyteczności. Na tym polega równowaga.

Click to enlarge

Optymalne nie znaczy idealne

Słowa optymalny używam ostrożnie. Optymalna architektura to nie taka, w której każda pojedyncza decyzja jest idealna; taka architektura raczej nie istnieje. To taka, w której całe rozwiązanie jest zrównoważone.

Załóżmy, że rozwiązanie A daje najlepszą wydajność, ale jest drogie i trudne w utrzymaniu. Rozwiązanie B kosztuje mniej i łatwiej je obsługiwać, ale traci trochę na wydajności. Rozwiązanie C jest bardziej elastyczne na przyszłość, ale dziś dodaje złożoności. Które jest optymalne? Na podstawie samych tych faktów nie potrafię odpowiedzieć. Muszę znać biznes, wymagania i priorytety oraz wiedzieć, które ograniczenia są prawdziwe, a które są tylko preferencjami. Architektura zależy od kontekstu. Dlatego wzorzec, który był właściwy dla jednego klienta, może być zupełnie zły dla następnego.

A twoim zadaniem jako architekta danych jest równoważyć te decyzje. Dziesiątki z nich podejmiesz samodzielnie albo z zespołem. Wiedz, które to są, i wiedz, kiedy decyzja ma większy wpływ, na koszty, czas albo funkcjonalność, i musi trafić do kluczowych decydentów.

Decyzja nieoptymalna może być częścią optymalnej architektury

To jedna z najważniejszych myśli w tym rozdziale. Czasem świadomie podejmuję nieoptymalną decyzję w jednej części architektury, bo dzięki temu całe rozwiązanie jest lepsze.

Może zduplikuję niewielką ilość danych, bo usunięcie duplikacji stworzyłoby niepotrzebną złożoność integracji. Może wybiorę prostszy model danych, bo teoretycznie czystszy bardzo utrudniłby raportowanie i codzienną pracę. Może zaakceptuję niewielki koszt wydajności, bo alternatywa dodaje infrastrukturę, której organizacja nie jest gotowa utrzymywać.

Spójrz na którąkolwiek z tych decyzji w oderwaniu, a powiesz, że nie jest optymalna. Słusznie. Ale architektura nie polega na optymalizowaniu każdego komponentu osobno; polega na optymalizowaniu systemu. Lokalnie nieoptymalna decyzja może być częścią globalnie optymalnej architektury, o ile rozumiemy kompromis, na który idziemy. Niebezpieczne jest zawieranie kompromisu bez świadomości, że się go zawiera.

Wiedz, z czego rezygnujesz

Kiedy ktoś mi mówi: „to najlepsze rozwiązanie”, moje następne pytanie brzmi: „najlepsze w czym?”. Najszybsze? Najtańsze? Najprostsze? Najbardziej skalowalne, najbezpieczniejsze, najbardziej elastyczne? Najłatwiejsze w utrzymaniu, najszybsze do dostarczenia, najmniej zależne od specjalistycznych umiejętności? Niemal zawsze jest jakiś inny wymiar, w którym odpowiedź nie brzmi „najlepsze”. To jest kompromis. Chcę wiedzieć, co zyskujemy, i chcę też wiedzieć, z czego rezygnujemy.

Weźmy dwie opcje dla dużego zbioru danych przedsiębiorstwa. Pierwsza kopiuje dane do Salesforce, co ułatwia korzystanie z natywnych możliwości Salesforce, ale wtedy to my odpowiadamy za ich przenoszenie, przechowywanie, synchronizację, zabezpieczenie kolejnej kopii i radzenie sobie z opóźnieniem. Druga zostawia dane tam, gdzie są, i sięga po nie w razie potrzeby. Usunęliśmy część duplikacji, ale teraz bardziej liczą się dostępność, wydajność zapytań, zależności sieciowe i możliwości zdalnego systemu. Żaden z tych opisów nie mówi nam, co wybrać. Mówi nam, jakie pytania zadać.

Wymagania nie są sobie równe

Kompromisy zmuszają nas też do zauważenia, że nie każde wymaganie waży tyle samo.

Ktoś mówi: „Dane muszą być dostępne natychmiast”. Dobrze, co znaczy natychmiast? Sekunda, dziesięć sekund, minuta? I dlaczego? Może chodzi o wykrywanie oszustw, gdzie liczą się sekundy. Może ktoś po prostu nie lubi czekać na nocny import. To bardzo różne wymagania, a architekt pyta dalej, dopóki nie wiemy, z którym mamy do czynienia.

Lubię wymagania, które przetrwają pytania: ile, jak wiele, jak szybko, jak często, dla kogo i co się stanie, jeśli tego nie zrobimy? „Szybko” to nie jest wymaganie architektoniczne. „95 procent aktualizacji danych klienta musi być dostępnych dla agenta serwisu w ciągu 30 sekund” jest już dużo bliżej. Teraz możemy oceniać kompromisy.

Ograniczenia zmieniają odpowiedź

Czasem architekturę ogranicza nie technologia, tylko pieniądze, ludzie, czas, licencje albo dojrzałość organizacji.

Architektura technicznie znakomita, ale wymagająca zespołu operacyjnego, którego firma nie ma, nie jest dobrą architekturą. Funkcja, która elegancko rozwiązuje problem, ale wymaga licencji, których klient nie kupi, też nie jest rozwiązaniem. A idealna trzyletnia transformacja nie pomoże firmie, która musi wystartować za osiem tygodni.

Nic z tego nie znaczy, że porzucamy dobrą architekturę z powodu terminu. Znaczy, że rozumiemy, na jaki kompromis idziemy, dlaczego i jakie konsekwencje akceptujemy, a najlepiej także, jak przejdziemy od dzisiejszego kompromisu do jutrzejszej architektury.

Architekt potrzebuje obrazu „optymalnego”

Jest tu ciekawe napięcie. Mówię ci, że często nie ma jednej idealnej odpowiedzi, a jednocześnie chcę, żeby w twojej głowie był obraz tego, jak wygląda optymalne rozwiązanie. To nie jest sprzeczność. Potrzebujesz punktu odniesienia.

Kiedy patrzę na model danych, chcę wiedzieć, co bym zbudował, gdybym mógł optymalizować pod wymagania bez zbędnych ograniczeń. Potem, gdy prawdziwe ograniczenia odpychają nas od tego projektu (spłaszczamy część modelu, duplikujemy trochę danych, odkładamy integrację, akceptujemy tymczasowy proces ręczny), nie zawieram przypadkowych kompromisów. Wiem, w którą stronę oddalam się od optimum i dlaczego. To jest sztuka architektury, a ten instynkt wymaga praktyki.

Narysuj to

Jednym z najlepszych sposobów, żeby zrozumieć kompromis, jest jego narysowanie. Diagramy architektury to nie ozdoby do prezentacji; to narzędzia myślenia. Jeśli wybieramy między dwoma podejściami, narysuj oba. Gdzie znajdują się dane i dokąd się przemieszczają? Kto jest ich właścicielem? Gdzie są granice i gdzie egzekwowane jest bezpieczeństwo? Co się dzieje, gdy coś zawiedzie, i co się zmienia, gdy rośnie wolumen?

Diagram wyciąga niejasności na światło dzienne i daje wszystkim ten sam obraz, na który można wskazać palcem.

Jak bardzo to ważne, przekonałem się przy projekcie dla firmy energetycznej. Przegląd za przeglądem znów tłumaczyłem te same pojęcia i sprowadzałem rozmowę z powrotem do pierwotnego projektu. Zmieniłem więc sposób prowadzenia tych spotkań: każdy przegląd zaczynał się od modelu danych na ekranie. Nie szczegółowego, z każdym polem. Modelu poglądowego: konto ma kontakty, ten rekord ma rekordy podrzędne, tu wisi praca. Na sali byli głównie członkowie zarządu, a zajmowało to kilka minut.

Ponieważ na każdym spotkaniu byli ci sami ludzie, diagram stał się naszym wspólnym językiem. Ludzie zaczęli używać jego nazw. Powtarzające się pytania zniknęły, a spotkania stały się dużo łatwiejsze. Nazywam to ugruntowaniem spotkania: prosty diagram, pokazywany za każdym razem, był wart dużo więcej, niż kosztowało jego przygotowanie.

Celem nie jest artystyczna doskonałość. Czasem to szczegółowy diagram dla inżynierów, czasem pięć prostokątów i sześć strzałek dla członka zarządu. Celem jest jasność.

Wyjaśnij kompromis

Dobry architekt przedstawia to po kolei: oto opcje, które rozważyliśmy, oto co każda nam daje, oto ile każda nas kosztuje, oto opcja, którą rekomenduję, i oto dlaczego.

Zwróć uwagę, że rekomendacja przychodzi po kompromisach. Nie chcę, żeby architektura sprowadzała się do „robiłem to już, zaufaj mi”. Doświadczenie ma ogromne znaczenie; pomaga szybciej rozpoznawać wzorce i wcześniej dostrzegać problemy. Ale twoje doświadczenie powinno ulepszać twoje rozumowanie, a nie je zastępować. Naszym zadaniem nie jest tylko rozumieć architekturę. Jest nim pomóc organizacji zrozumieć decyzję, zwłaszcza gdy osoby, które ostatecznie decydują, nie są architektami.

Think Correct. Think Fast.

Nie zawsze będziesz mieć trzy tygodnie na przeanalizowanie każdej opcji. Czasem będziesz mieć trzy minuty. Wymaganie zmienia się w trakcie spotkania, ktoś wspomina o ograniczeniu, o którym nie było wiadomo, albo członek zarządu pyta: „A co, jeśli w przyszłym roku będziemy tego potrzebować w Europie?”.

Używam hasła Think Correct. Think Fast. (Myśl poprawnie. Myśl szybko.) Szybkość nie bierze się z pomijania myślenia. Bierze się z tego, że przemyślało się dość dużo, zanim ten moment nadejdzie: znasz wzorce, znasz platformę, masz za sobą porażki, wiesz, jakie pytania zadać i które decyzje trudno odwrócić. Dlatego przez cały kurs przerabiamy scenariusze. Im więcej decyzji przeanalizujesz, tym szybciej rozpoznasz kształt następnej.

Miałem klienta, który potrzebował wypełniania formularzy. Ale formularzy było wiele, a pytania mogły się z czasem zmieniać. Szybko rozpoznałem potrzebę modelu danych ankiety, wzorca, do którego wrócimy później w kursie. Ponieważ rozpoznałem wzorzec i rozwiązanie, mogłem wnieść pełniejszy model danych, taki, który obsługiwał także wymagania, które dopiero miały nadejść, a nie tylko te, które mieliśmy przed sobą.

Architektura to równowaga

Gdy wejdziemy głębiej w architekturę danych, trafisz na wybory, przy których wzbraniam się przed podaniem prostej reguły. Normalizować czy spłaszczać? Kopiować dane czy je federować? Synchronicznie czy asynchronicznie? Obiekt standardowy czy niestandardowy? Archiwizować czy trzymać online?

Są zasady, wzorce i limity, a czasem wyraźnie złe odpowiedzi. Ale często zadaniem architekta jest znaleźć właściwą równowagę dla tego systemu, tego biznesu i tej chwili.

Wiedz, jak wygląda optimum. Zrozum ograniczenia. Wskaż opcje, które mają sens. Pokaż kompromisy. Potem podejmij decyzję.

To nie jest niezdecydowanie. To jest architektura.

Co tu decyduje architekt

• Które opcje mają sens, a które są złe już teraz albo zepsują się w ciągu roku.
• Co każda sensowna opcja daje, a z czego rezygnuje, mierzone wymaganiami, które przetrwają pytania.
• Które ograniczenia są prawdziwe, a które są tylko preferencjami.
• Którą opcję zarekomendować, po przedstawieniu kompromisów, i jak ją wyjaśnić.