Solution architect rolu: tələblərdən işləyən həllə qədər

Problem: forması olmayan sorğu

Biznes bölməsi deyir: "İstəyirik ki, müştərilər çatdırılmalarını tətbiqimizdə izləsin." Səthdə bu, bir funksiyadır. Altında isə açıq suallar var. İzləmə datası haradan gəlir və kimə məxsusdur? Nə qədər təzə olmalıdır? Kuryer sistemi işləməyəndə nə baş verir? Mövcud müqavilələrə, təhlükəsizlik qaydalarına və ya büdcəyə təsir edirmi? Müxtəlif developerlər fərqli cavablar verəcək, fərqli şeylər quracaq və fikir ayrılıqlarını gec kəşf edəcək.

Solution architect biznes ehtiyacını delivery komandasının qura, idarə edə və inkişaf etdirə biləcəyi bütöv texniki həllə çevirməyə cavabdehdir. Əhatə bir həll və ya bir neçə əlaqəli həlldir, bütün təşkilat deyil; o geniş baxış enterprise architecture-ə aiddir. Rol biznes tərəfləri, mühəndislik komandaları və əməliyyat arasında dayanır və əsas məhsulu diaqramlar yox, insanların başa düşdüyü sağlam qərarlardır.

Tələblərdən həllə

İşləyən axın altı addımdan ibarətdir. O iterativdir; sonrakı addımlar çox vaxt sizi geri qaytarır.

1. Məqsədi anlayın. Dəyişikliyin niyə lazım olduğunu və uğurun necə tanınacağını soruşun. Elan olunmuş həll ("API qurun") çox vaxt əsl ehtiyacı gizlədir.
2. Tələbləri və keyfiyyət atributlarını toplayın. Funksional tələblər həllin nə etdiyini deyir. Keyfiyyət atributları (qeyri-funksional tələblər də adlanır) nə dərəcədə yaxşı etdiyini deyir: əlçatanlıq, gecikmə, təhlükəsizlik, məxfilik, miqyaslanma, saxlanıla bilmə, xərc, audit. Arxitekturanı funksiyalardan çox onlar müəyyən edir.
3. Məhdudiyyətləri müəyyənləşdirin. Mövcud sistemlər, məcburi texnologiyalar, qanunlar, komanda bacarıqları, büdcə və müddətlər. Məhdudiyyətlər girişdir, mübahisə ilə aradan qaldırılacaq maneə deyil.
4. Variantlar yaradın. Ən azı iki inandırıcı yanaşma təsvir edin, ucuz variantı və "heç nə etməmək" bazasını da daxil edin.
5. Güzəştləri təhlil edin və seçin. Variantları ən vacib keyfiyyət atributları üzrə müqayisə edin.
6. Sənədləşdirin və çatdırın. Dizaynı başqaları həyata keçirə və ona etiraz edə bilsin deyə qeyd edin.

Keyfiyyət atributları praktikada

"Sistem sürətli və təhlükəsiz olmalıdır" yoxlanıla bilən deyil. Hər atributu mənbə, stimul və ölçülə bilən cavabı olan ssenariyə çevirin; rəqəmləri biznesdən və ya razılaşdırılmış fərziyyələrdən götürün:

Attribute:   Availability
Scenario:    A courier-system outage occurs during business hours.
Expectation: Customers still see the last known status with a
             "last updated" time; no error page.
Measure:     Tracking page loads successfully while the upstream
             is down (verified by a fault-injection test).

Belə ssenari komandaya nəyi quracağını (statusun lokal surəti, köhnəlmiş data göstəricisi) və necə test edəcəyini deyir.

Variantlar və güzəştlər

Çatdırılma izləmə sorğusu üçün qısa müqayisə belə görünə bilər:

Hamıya uyğun tək düzgün cavab nadirdir. Arxitekt seçimi hansı atributların həll etdiyini deyir. Təzəlik ən vacibdirsə və kuryer webhook təklif edirsə, üçüncü variant qalib gəlir; kuryer yalnız rate limit-li API verirsə, ikinci variant realist yoldur. Nəticəni ADR-də, rədd olunan variantları və yenidən baxma şərtlərini də daxil edərək qeyd edin.

Həllin sənədləşdirilməsi

Yaxşı həll sənədi qısa, qatlı və oxucuya yönəlmiş olur:

• Context və məqsədlər: biznes sponsorunun oxuya biləcəyi bir səhifə.
• Arxitektura görünüşləri: C4 context və container diaqramı və kritik axınlar üçün sequence diaqramı.
• Data: əsas entity-lər, sahiblik və saxlama müddəti.
• İnterfeyslər: API müqavilələri və event sxemləri, ideal halda maşın tərəfindən oxuna bilən spesifikasiya kimi.
• Keyfiyyət atributu ssenariləri və onların necə ödəndiyi.
• Risklər, fərziyyələr və açıq suallar, hər birinin sahibi ilə.
• Qərarlar: ADR-lərə keçidlər.

Heç kimin oxumadığı uzun sənədlərdən qaçının. Onları repository-də və ya sahibi və review vərdişi olan ortaq məkanda saxlayın.

Delivery komandaları ilə iş

Dizaynı təhvil verib yoxa çıxan solution architect sürüşən dizaynlar yaradır. Sağlam vərdişlər:

• komandanın da dizaynı formalaşdırması üçün refinement və dizayn sessiyalarına erkən qoşulmaq
• suallar üçün əlçatan olmaq, riskli Pull Request və dizaynları review etmək, amma code review-u üzərinə götürməmək
• öhdəlik götürməzdən əvvəl ən riskli fərziyyəni yoxlamaq üçün kiçik prototip və ya spike yazmaq
• komandaların sərhəd daxilində yerli qərar verə bilməsi üçün sərhədlər razılaşdırmaq; bax microservices boundaries
• yük testləri, təhlükəsizlik review-ları və əməliyyat rəyi ilə qurulmuş həllin keyfiyyət atributlarını hələ də ödədiyini yoxlamaq
• qeyri-müəyyənlik barədə dürüst qalmaq; "bunu ilk spike-da öyrənəcəyik" legitim plandır

Kommunikasiya işin yarısıdır. Eyni dizaynı müxtəlif dərinlikdə izah edin: sponsora nəticələr və risklər, developerə interfeyslər və məhdudiyyətlər, əməliyyat mühəndisinə nasazlıq davranışı və monitorinq lazımdır.

Tez-tez edilən səhvlər

1. Əvvəlcə texnologiyanı seçmək. Dəbdə olan alətlər tələb deyil.
2. Fil dişi qüllədən dizayn. Komandanın qura bilmədiyi və ya inanmadığı dizayn yaşamaz.
3. Keyfiyyət atributlarını production insidenti göstərənə qədər nəzərə almamaq.
4. Həddindən artıq və ya çox az sənədləşdirmə. İkisi də dizaynı yararsız edir.
5. Variantın olmaması. Tək variant analizdən əvvəl verilmiş qərardır.
6. Əməliyyat və xərci unutmaq. Həlli illərlə kimsə işlətməli və ödəməlidir.
7. Dizaynı son hesab etmək. Fərziyyələr pozulanda ona yenidən baxın.

Rolun özünün güzəştləri

Arxitektlər dərinlik və genişlik arasında tarazlıq saxlayır. Etibarı qorumaq üçün koda kifayət qədər yaxın qalmaq, uyğunluğu qorumaq üçün tərəflərə kifayət qədər vaxt ayırmaq daimi gərginlikdir. Həddindən artıq nəzarət komandaları yavaşladır; çox az nəzarət uyğunsuz həllər yaradır. Bir çox təşkilat çərçivələrə (prinsiplər, bir neçə standart) və onların daxilində komanda muxtariyyətinə üstünlük verir.

Yoxlama siyahısı

• Məqsəd və uğur meyarları yazılıb
• Keyfiyyət atributları ssenari kimi ifadə olunub
• Məhdudiyyətlər və fərziyyələr sahibləri ilə sadalanıb
• Ən azı iki variant müqayisə edilib
• Qərar nəticələri ilə qeyd edilib
• Müxtəlif auditoriyalar üçün görünüşlər
• Risklər və açıq suallar izlənir
• Dizayn qurulmuş nəticə ilə yoxlanılıb

Növbəti addım

Gündəlik işlədilən notasiya və qeydləri C4 modeli bələdçisində və ADR yazmaq məqaləsində öyrənin, əhatəni enterprise architecture ilə müqayisə edin və ya Solution Architect roadmap-ını izləyin.