Dlaczego wdrożenie Salesforce pod wodzą architekta daje lepsze wyniki

Większość wdrożeń Salesforce nie wysypuje się na etapie budowy. Wysypuje się na decyzjach podjętych przed nią i w jej trakcie: na modelu danych, w którym nie zmieściły się dwa kolejne obiekty, na integracji połączonej na sztywno punkt-punkt, bo nikt nie pilnował wzorca, na automatyzacji dokładanej warstwa po warstwie, aż w końcu wybuchła na governor limits na produkcji. Każda z tych rzeczy to decyzja architektoniczna, która zapadła domyślnie — bo przy stole nie siedział nikt z autorytetem projektowym.

„Pod wodzą architekta — każde zlecenie” brzmi jak hasło z broszury. A jest konkretnym modelem pracy z konkretną tezą: osoba odpowiedzialna za strukturę Twojego orga bierze udział we wszystkim — od pierwszej rozmowy przez projekt, integracje i budowę aż po przekazanie. Nie wpada na jeden przegląd i nie znika. W tym tekście rozliczamy ten model z tego, co faktycznie daje — łącznie z sytuacją, w której go nie potrzebujesz.

Na czym w praktyce polega wdrożenie pod wodzą architekta

Architekt na projekcie to nie ktoś, kto podpisuje dokument i wychodzi. Chodzi o to, że autorytet projektowy jest ciągły. Ta sama osoba, która w pierwszym tygodniu broni modelu danych, w szóstym przegląda framework triggerów, a w dwunastym pisze dokumentację przekazania.

W praktyce ten autorytet obejmuje pięć decyzji, od których zależy wszystko, co dzieje się później: model danych i relacje między obiektami, model bezpieczeństwa i współdzielenia, wzorzec integracji, podział między konfiguracją a kodem oraz architekturę automatyzacji. Przegląd z przelotu dotyka ich raz. W modelu z architektem cały czas ma je jeden odpowiedzialny właściciel — bo wymagania się przesuwają. Zawsze się przesuwają.

Największą różnicę widać wtedy, gdy którąś decyzję trzeba zmienić. Nowe wymaganie integracyjne pojawia się w trakcie budowy i ktoś musi ocenić, czy wpisuje się w istniejący wzorzec, czy go wywraca. Gdy architekta nie ma na stałe, decyduje ten, kto akurat siedzi najbliżej klawiatury — i patrzy na ticket przed sobą, a nie na cały system.

Czy do projektu Salesforce potrzebujesz architekta?

Nie zawsze. Wdrożenie jednej chmury na standardowych obiektach, z niewielką konfiguracją i bez integracji zewnętrznych, spokojnie poprowadzi doświadczony konsultant na poziomie senior. Architekt staje się potrzebny dopiero wtedy, gdy złożoność przekracza pewien próg: kilka chmur, dedykowane modele danych, dwie lub więcej integracji, duże wolumeny rekordów albo wymogi regulacyjne.

Ten uczciwy próg ma znaczenie, bo pomyłka kosztuje w obie strony. Zatrudnij architekta klasy review board do dwutygodniowego porządkowania Sales Cloud, a zapłacisz za ubezpieczenie od ryzyk, których nie ma. Odpuść architekturę w programie z trzech chmur z integracją billingu, a za osiemnaście miesięcy kupisz sobie przebudowę. Sztuka polega na tym, żeby dobrze odczytać, jaki projekt naprawdę masz w rękach.

Mechanizm porażki, który ten model blokuje: decyzje podjęte domyślnie

Ten mechanizm działa po cichu. Nikt nie podejmuje decyzji „kupujemy dług techniczny”. On narasta sam — jeden rozsądny skrót naraz.

Developer potrzebuje pola na wartość z systemu zewnętrznego, więc dodaje je do niewłaściwego obiektu, bo tam akurat toczy się bieżące story. Ktoś inny pisze trigger, który powiela logikę już siedzącą we flow — bo tego flow nigdy nie widział. Trzeci wpisuje na sztywno ID typu rekordu, żeby zdążyć przed terminem. Każda z tych decyzji broni się sama w sobie. Razem tworzą org, którego żaden admin nie chce dotykać.

Autorytet projektowy temu zapobiega, bo architekt cały czas trzyma w głowie model całego systemu i dopasowuje do niego pojedyncze zadania. To on mówi „ta wartość należy do Accounta, nie do Kontaktu — i teraz wyjaśnię dlaczego”, zanim pole trafi do orga. A nie dopiero na post-mortem.

Co robi architekt Salesforce, a czego nie robi developer?

Developer buduje to, co przewiduje projekt. Za sam projekt odpowiada architekt: za model danych, wzorzec integracji, model bezpieczeństwa i kompromisy między konfiguracją a kodem. To on decyduje, co powstanie i dlaczego, wcześnie wyłapuje ryzyka związane z governor limits i skalą — i odpowiada za całość od pierwszej rozmowy po przekazanie.

To nie jest drabinka, na której architekt to po prostu developer z dłuższym stażem. Te dwie role myślą inaczej. Developer rozwiązuje zadanie, które ma przed sobą. Architekt myśli o wymaganiach, które jeszcze nie nadeszły: o drugiej integracji, o wolumenie rekordów w trzecim roku, o przejęciu, które podwoi liczbę użytkowników. Dobry developer pisze poprawny kod. Architekt pilnuje, żeby ten poprawny kod nadal pasował do orga w przyszłym kwartale.

Gdzie uciekają pieniądze w projektach bez odpowiedzialności za architekturę

Koszt braku autorytetu projektowego nie figuruje jako osobna pozycja w kosztorysie. Wychodzi w przeróbkach, w opóźnieniach i w nieudanej adopcji, której winę zrzuca się na co innego. Porównanie poniżej jest celowo jakościowe: skala zależy od zakresu, ale kierunek powtarza się we wszystkich ponad 50 wdrożeniach enterprise, które zrealizowaliśmy.

Wymiar	Bez autorytetu projektowego	Wdrożenie pod wodzą architekta
Decyzje strukturalne	Podejmuje je domyślnie ten, kto akurat siedzi najbliżej kodu	Podejmuje je świadomie jedna odpowiedzialna osoba, jeszcze przed budową
Przeróbki	Dużo: modele i integracje przebudowuje się, gdy uderzą w ścianę	Niewiele: błędy strukturalne wyłapuje się w projekcie, a nie na produkcji
Niespodzianki integracyjne	Częste: połączenia punkt-punkt wychodzą późno, brak wspólnego wzorca	Rzadkie: wzorzec integracji ustala się raz i egzekwuje
Dług techniczny	Przypadkowy i nieudokumentowany	Świadomy i odnotowany, z uzasadnieniem i planem spłaty
Governor limits i skala	Wybuchają na produkcji pod realnym obciążeniem	Modelowane i testowane, zanim ugryzą
Przekazanie	Wiedza plemienna w czyjejś głowie	Udokumentowane decyzje, które przejmie inny zespół

Najdroższa jest pozycja z przeróbkami. Cofnięcie decyzji strukturalnej na etapie projektu kosztuje jedną rozmowę. Ta sama zmiana na produkcji kosztuje migrację, cykl testów regresji i opóźnione go-live. O te pieniądze chroni odpowiedzialność za architekturę — dlatego przegląd orga przed projektem ratunkowym zwykle zwraca się sam. Nasza praktyka Salesforce Advisory and Architecture zaczyna dokładnie od tego: odczytujemy decyzje już wbudowane w org, zanim zaproponujemy kolejny ruch.

Co daje zatrudnienie architekta Salesforce?

Architekt ogranicza przeróbki, bo domyka decyzje strukturalne, zanim ruszy budowa. Efekt: mniej niespodzianek integracyjnych, model danych, który wytrzymuje wolumen, model bezpieczeństwa, który przechodzi przegląd, i dług techniczny, który pozostaje świadomy. Mierzalna korzyść to decyzje podjęte celowo, a nie domyślnie.

Warto tu doprecyzować jedną rzecz, bo klienci o nią pytają. Salesforce Certified Technical Architect to certyfikat, który zdobywa się przed review board — trzeba obronić własne decyzje architektoniczne pod ostrzałem pytań na żywo, a nie wyklikać test jednokrotnego wyboru. Na całym świecie ma go mniej niż 500 osób. Sam ten fakt nie jest jednak najważniejszy. Najważniejsze jest to, co review board faktycznie poświadcza: umiejętność podejmowania i obrony strukturalnych kompromisów pod presją. Dokładnie tę umiejętność, na której opiera się program, gdy wymagania zaczynają się ruszać.

Kiedy potrzebujesz architekta Salesforce?

Wtedy, gdy koszt błędnej decyzji strukturalnej przewyższa koszt architekta. Sygnały ostrzegawcze: zakres multi-cloud, dedykowane modele danych, dwie lub więcej integracji, duże wolumeny rekordów, praca etapami i wieloma zespołami oraz wymogi compliance — na przykład rezydencja danych wymagana przez RODO w przedsiębiorstwach z UE.

Poniżej tego progu bądź szczery — i ze sobą, i z partnerem. Jeśli firma mówi Ci, że proste wdrożenie Service Cloud dla jednego zespołu wymaga pełnego zaangażowania architektonicznego, to sprzedaje Ci godziny, a nie rozeznanie. Dobry partner powie Ci wprost, kiedy architekt to przesada. My mówimy — bo alternatywa to klient, który czuje, że sprzedano mu za dużo, i nigdy nie wraca z programem, który naprawdę tego wymaga.

Jak zmienia się praca zespołu

Zatrudnienie architekta to nie kwestia dodania jednej czapki w strukturze. Zmienia się sposób pracy całego zespołu. Gdy autorytet projektowy jest ciągły, developerzy szybciej się odblokowują, bo niejednoznaczne pytania strukturalne mają swojego właściciela. Mniej spraw ląduje na spotkaniach. Zespół buduje w oparciu o ustalony model, zamiast w kółko od nowa o niego walczyć.

Zmienia się też zespół po stronie klienta. Przy wdrożeniu pod wodzą architekta powstaje dziennik decyzji i model danych, które przejmują admini klienta. Wewnętrzny zespół sam prowadzi org po przekazaniu, zamiast trzymać dostawcę przy sobie na zawsze, bo tylko on rozumie system. To jest test anty-lock-in: czy inny zespół mógłby przejąć org w tydzień? Z udokumentowanym autorytetem projektowym — tak. Bez niego wiedza wychodzi z firmy razem z ostatnim kontraktorem.

Inaczej wygląda też ekonomia zespołu. Wyspecjalizowana firma prowadząca wdrożenia pod wodzą architekta stawia gęstość seniorów tam, gdzie to się liczy, i nie utrzymuje bencha juniorów, których trzeba za wszelką cenę obciążać godzinami. W skrócie: rygor dużego integratora bez jego narzutów. A w praktyce — osoba odpowiedzialna za Twoją architekturę to ta sama osoba, którą widzisz na rozmowie, wspierana przez seniorski zespół ze średnio ponad 15-letnim stażem zdobywanym w siedmiu branżach.

Kiedy nas nie potrzebujesz

Powiedzmy to wprost. Jeśli Twój projekt to zamknięta zmiana konfiguracji, budowa raportów, wdrożenie standardowej funkcjonalności dla jednego zespołu albo wzmocnienie zespołu pod konkretne zadanie — nie potrzebujesz wdrożenia pod wodzą architekta i nie powinieneś za nie płacić. Sprawny freelancer albo senior admin świetnie sobie z tym poradzi. Autorytet architektoniczny zarabia na siebie tam, gdzie decyzje strukturalne się kumulują, integracje mnożą, a org musi przetrwać własny sukces.

Jeśli tak wygląda Twój program, pierwszy krok to rozmowa z osobą, która realnie odpowiadałaby za projekt rozwiązania — nie z handlowcem. Porozmawiaj z architektem.

Najczęściej zadawane pytania

Czy architekt Salesforce to to samo co Certified Technical Architect?

Nie. „Architekt” to rola, a CTA to konkretny certyfikat, który zdobywa się, broniąc decyzji architektonicznych przed review board. Wielu świetnych architektów nie jest CTA, a sam tytuł nie jest nijak regulowany. Liczy się to, że ktoś realnie ogarnia modele danych, wzorce integracji i bezpieczeństwo — i odpowiada za nie przez całe wdrożenie.

Czy senior developer może pełnić rolę architekta?

Czasem, przy mniejszym zakresie. Ryzyko jest takie, że developer rozwiązuje zadanie, które ma przed sobą, a architektura dotyczy wymagań, które jeszcze nie nadeszły. Przy programach multi-cloud albo z dużą liczbą integracji lepiej rozdzielić te role, żeby ktoś patrzył na cały system, a nie tylko na bieżące story.

Ile kosztuje architekt Salesforce?

Każdą konkretną liczbę traktuj z nieufnością, bo wszystko zależy od zakresu. Właściwe porównanie to nie stawka dzienna, tylko całkowity koszt efektu: wyższa stawka, która uchroni Cię przed przebudową produkcji, wychodzi taniej niż niska, która dowozi dług. Stawkę oceniaj przez pryzmat przeróbek, których dzięki niej unikniesz.

Czym różni się architekt Salesforce od developera?

Developer buduje to, co przewiduje projekt. Architekt odpowiada za sam projekt i stojące za nim kompromisy: model danych, wzorzec integracji, model bezpieczeństwa i podział między konfiguracją a kodem. Developer pilnuje, żeby kod był poprawny. Architekt pilnuje, żeby poprawny kod nadal pasował do orga w przyszłym kwartale.

Czy małe orgi w ogóle potrzebują przeglądu architektury?

Na starcie rzadko, ale często przed większą zmianą. Org jednego zespołu, działający na standardowej funkcjonalności, nie potrzebuje architekta na stałe. Ale zanim dodasz drugą chmurę, pierwszą integrację albo migrację danych, warto krótko przejrzeć decyzje już wbudowane w org — żeby nie budować nowej funkcjonalności na chwiejnym fundamencie.