Enterprise architecture: capability-lər, portfel və bürokratiyasız idarəetmə

Problem: bir-birinə uyğun gəlməyən çoxlu yaxşı həll

Təşkilat satın almalar və müstəqil komandalar hesabına böyüyüb. Dörd müştəri bazası, üç identity provayder, iki billing sistemi və heç kimin tam çəkə bilmədiyi bir neçə onlarla inteqrasiya işlədir. Hər layihə təkbaşına ağlabatan idi. Birlikdə isə hər dəyişikliyi yavaşladır: yeni məhsul beş yerdən data tələb edir, təhlükəsizlik düzəlişi yeddi yerdə tətbiq olunmalıdır və hansı sistemlərin təhlükəsiz söndürülə biləcəyini kimsə deyə bilmir. Bunu tək solution architect həll edə bilməz, çünki problem həllərin arasındadır.

Enterprise architecture (EA) bu "aralığı" idarə edən intizamdır: biznes capability-lərinin, tətbiqlərin, datanın və texnologiyanın strukturunu strategiya ilə uzlaşdırır ki, ayrı-ayrı layihələr bütöv bir mənzərə yaratsın. The Open Group-un TOGAF-ı bunun üçün məşhur çərçivələrdən biridir. Ideyalardan istifadə etmək üçün çərçivənin hamısını qəbul etmək lazım deyil.

EA və solution architecture

Onlar bir-birindən asılıdır. Enterprise arxitektlər istiqamət və çərçivə müəyyən edir; solution arxitektlər onları tətbiq edir və reallıq uyğun gəlmədikdə geri bildirir. Bax: solution architect rolu.

Əsas tikinti blokları

Biznes capability-ləri

Capability, biznesin nə edə bildiyidir, onun necə təşkil olunduğundan və hansı sistemin dəstəklədiyindən asılı olmayaraq: "müştəri identitetini idarə etmək", "məhsula qiymət qoymaq", "ödənişi hesablaşmaq". Capability xəritəsi onları iyerarxiya ilə sadalayır və illər boyu sabit qalır, təşkilat sxemləri və tətbiqlər isə dəyişir. Hər capability-ni strateji əhəmiyyəti və onu dəstəkləyən sistemlərin vəziyyəti ilə işarələyin. Capability-lər həm də servis sərhədləri üçün faydalı başlanğıc nöqtəsidir; bu, microservices boundaries məqaləsində işlənir.

Tətbiq portfeli

Az sayda və dürüst atributlarla tətbiqlərin inventarı: sahib, dəstəklədiyi capability-lər, həyat dövrü mərhələsi (planlı, aktiv, məhdudlaşdırılmış, söndürülən), texnologiya, kritiklik və məlum olduqda xərc. Onunla dublikatları (dörd müştəri bazası), boşluqları (capability üçün sistem yoxdur) və riskləri (dəstəklənməyən platformada kritik sistemlər) tapın. Saxlanılmayan portfel tez bir zamanda uydurmaya çevrilir, ona görə onu dəyişiklik idarəetməsi kimi mövcud proseslərə bağlayın.

Prinsiplər və standartlar

Prinsiplər əsaslandırma və nəticələri olan qısa bəyanatlardır, məsələn: "Qeyd sistemləri öz datasına sahibdir; digərləri API və ya event vasitəsilə oxuyur." Standartlar daha konkretdir: təsdiq olunmuş identity provayder, API üslubu, log formatı, dəstəklənən verilənlər bazaları. Standartları az saxlayın, niyə mövcud olduqlarını izah edin və istisna tələb etmək üçün aydın yol göstərin.

Hədəf və keçid arxitekturaları

Baseline hazırda harada olduğunuzdur, hədəf strategiyanın bir neçə ildən sonra sizi harada tələb etdiyi, keçid arxitekturaları isə yolda dəyər çatdıran ara addımlardır. Roadmap nəyin nə vaxt dəyişdiyini deyir. Yuxarıdakı identity problemi üçün nümunə ardıcıllıq:

Baseline:   3 identity providers, each app has own login
Transition: new apps must use provider A; legacy apps get
            an adapter (federation) in front
Target:     one identity provider for staff, one for customers;
            legacy providers retired

Keçidlər olmasa, hədəf arzudur; olduqda hər layihə öz kiçik töhfəsini bilir.

Bürokratiyasız idarəetmə

İdarəetmə qərarları ardıcıl və görünən etməkdir, qapıçılıq etmək deyil. Adətən işləyən təcrübələr:

• Qapılar yox, çərçivələr. Prinsipləri və hazır yolları dərc edin; onlara əməl edən komandalara təsdiq lazım deyil.
• Risk üzrə review. Yalnız domenləri keçən, yeni texnologiya sinfi gətirən, təhlükəsizliyə təsir edən və ya əhəmiyyətli xərci olan qərarlar arxitektura review-u tələb edir.
• Yüngül qeydlər. Uzun sənədlər yerinə ADR-lər və bir səhifəlik qısa təkliflər işlədin.
• Sürətli cavab. Həftələr çəkən review prosesi komandalara ondan qaçmağı öyrədir. Cavab müddətini razılaşdırın və ona əməl edin.
• Görünən qərarlar. Nəticələri dərc edin ki, digər komandalar öyrənsin.
• İstisnalar data kimi. İstisnaları izləyin; eyni standarta təkrar istisnalar həmin standartın yanlış olduğunu göstərir.
• Ortaq sahiblik. Standartları müəyyən edən forumlara delivery mühəndislərini də daxil edin.

Başlamaq üçün ən kiçik addım

EA-ya böyük proqramla başlamaq lazım deyil. Praktik ilk addım üç işdir: ən vacib otuz-qırx tətbiqin sahibi ilə inventarı çıxarmaq, biznes sahibləri ilə bir səhifəlik capability xəritəsini çəkmək və dörd-beş prinsipi komandalarla müzakirə edib yazmaq. Bundan sonra növbəti layihələr bu üç artefaktla yoxlanılır və boşluqlar real ehtiyacla doldurulur.

Müəssisə miqyasında diaqramlar

Bu səviyyədə C4 modelinin context görünüşü landşafta çevrilir: capability üzrə qruplaşdırılmış qutular kimi sistemlər və aralarındakı inteqrasiyalar. Hər interfeysi çəkməyin; vacib axınları və onların çoxunu daşıyan sistemləri göstərin.

Tez-tez edilən səhvlər

1. Fil dişi qüllə. Onlara əməl edəcək insanları cəlb etmədən yazılmış prinsiplər nəzərə alınmır.
2. Çərçivələr məqsəd kimi. Çərçivənin hər artefaktını tamamlamaq məqsəd deyil; məqsəd dəyişikliyin xərcini və riskini azaltmaqdır.
3. Köhnəlmiş inventarlar. Köhnəlmiş portfel heç olmamasından pisdir, çünki insanlar ona etibar edir.
4. Əsaslandırmasız standartlar. İzah oluna bilməyən qaydalar yan keçidləri çağırır.
5. Big-bang hədəf vəziyyət. Hər şeyin eyni anda dəyişməsini tələb edən planlar reallığa davam gətirmir.
6. Darboğaz kimi idarəetmə. Review ən yavaş addımdırsa, komandalar onu yan keçəcək.
7. İnsanları və maliyyələşməni görməmək. Büdcəsi və sahibi olmayan arxitektura slaydlarda qalır.

Güzəştlər

Standartlaşdırma xərc və riski azaldır, amma lokal optimallaşdırmanı məhdudlaşdırır; komandanın öz problemi üçün daha yaxşı aləti ola bilər. Mərkəzləşdirilmiş nəzarət sürət hesabına ardıcıllıq verir; federativ modellər dublikat hesabına sürət verir. Əksər təşkilat orta yol seçir: bir neçə kritik sahədə (təhlükəsizlik, identity, data sahibliyi) güclü prinsiplər, qalanında sərbəstlik. Kiçik şirkətlərə çox vaxt ayrıca EA funksiyası yox, bir səhifəlik prinsip siyahısı və tətbiq inventarı kifayət edir.

Yoxlama siyahısı

• Capability xəritəsi biznes sahibləri ilə razılaşdırılıb
• Sahibləri və həyat dövrü mərhələləri olan tətbiq portfeli
• Əsaslandırması olan qısa prinsip siyahısı
• İstisna prosesi olan bir neçə standart
• Əsas sahələr üçün baseline, keçid və hədəf təsvir olunub
• Cavab müddəti hədəfi olan, risk əsaslı review meyarları
• Qərarlar dərc olunur, istisnalar izlənir

Növbəti addım

Əhatələri solution architect rolu ilə müqayisə edin, yüngül qərar qeydlərini ADR yazmaq məqaləsində məşq edin və ya Enterprise Architect roadmap-ını izləyin.