Bitta tizim yoki bir nechta ixtisoslashgan tizim: monolit va best-of-breed

Melvin Conway 1968-yilda bir kontrakt tashkilotini tasvirlagan: sakkiz kishi COBOL va ALGOL kompilyatorlarini yaratishi kerak edi. Dastlabki baholashdan keyin besh kishi COBOL ga, uch kishi ALGOL ga tayinlandi. Natijada COBOL kompilyatori besh bosqichda, ALGOL kompilyatori uch bosqichda ishlaydigan boʻldi. Dasturning tuzilishi jamoaning tuzilishini takrorladi.

Bu hodisa tizim tanlashga ham tegishli. Quyida “bitta yirik tizim” va “bir nechta ixtisoslashgan tizim” yoʻllarining dalillari manbalar boʻyicha keltiriladi. Hukm chiqarilmaydi: manbalarning oʻzi ham hukm chiqarmaydi.

Nima bilan nimani solishtiramiz

Birinchi atama — yagona tizim. Davenport korporativ axborot tizimlarini (enterprise systems) moliya, buxgalteriya, kadrlar, taʼminot va mijozlar maʼlumotini bir joyga yigʻishni vaʼda qiluvchi tijorat dasturiy paketlari deb tasvirlaydi. Dasturiy arxitektura tilida unga monolit tushunchasi yaqin: Lewis va Fowler monolitni “bitta mantiqiy bajariluvchi fayl” deb taʼriflaydi, uning har oʻzgarishi yangi versiyani qurish va joylashtirishni talab qiladi.

Ikkinchi atama — best-of-breed. Light va hamkasblari uni shunday taʼriflaydi: standart paketlar va/yoki maxsus yozilgan dasturlardan komponentlarni birlashtirib, tashkilot jarayonlariga koʻproq mos tizim yigʻish. Ikki tushuncha bir xil darajada emas: Fowler dasturiy arxitektura haqida yozadi, Davenport va Light — biznes dasturlari haqida. Ularni yonma-yon qoʻyish tahririyat analogiyasi, manbalarning oʻzida bunday taqqoslash yoʻq.

Manbalarning davri ham hisobga olinadi. Ular 1968-yildan 2015-yilgacha: eng yangisi Fowlerning 2015-yildagi yozuvi, Davenport va Light esa 1998 va 2001-yillarga tegishli. Bulutdagi tayyor xizmatlar (SaaS) davrida bu bahs qanday oʻzgargani bu yerda oʻrganilmagan. Matn mantiqiy asoslarni bayon qiladi, bugungi bozor tahlilini emas, va bu chegarani oʻquvchi bilishi kerak.

Yagona tizim foydasiga: axborot bir joyda

Davenport maqolasi “korporativ tizimlar orzu ushalgandek koʻrinadi” degan jumla bilan boshlanadi. Uning fikricha, bir-biriga mos kelmaydigan tizimlar va turlicha ish yuritishdan charchagan rahbar uchun tayyor integratsiya paketi jozibali. Light va hamkasblari ham ERP tashkilot boʻylab jarayonlarni qoʻllab-quvvatlash uchun keng ishlatilishini qayd etadi.

Soha tizimlarini ajratishning qiyinchiliklari dasturiy arxitektura adabiyotida yaxshi yoritilgan. Lewis va Fowler taqsimlangan tizimda masofaviy chaqiruv jarayon ichidagi chaqiruvdan qimmatligini, taqsimlangan tranzaksiyalarni amalga oshirish juda qiyinligini va izchillik ayrim hollarda faqat “oxir-oqibat” (eventual) boʻlishini yozadi. Agar ombor, savdo va moliya alohida tizimda boʻlsa, ular orasidagi har bogʻlanish shunga oʻxshash joy boʻladi: maʼlumot oʻzgarsa, boshqa tizim uni qachon va qanday oladi. Bu tahririyat analogiyasi, chunki Fowler dasturiy xizmatlar haqida yozgan.

Bogʻlanishlar soni tez oʻsadi. Ochiq hisob-kitob: agar besh tizim hammasi bir-biri bilan maʼlumot almashsa, 10 ta juft aloqa boʻladi; sakkizta tizimda 28 ta. Amalda hamma juft kerak boʻlmaydi, lekin mumkin boʻlgan marshrutlar soni tizimlar sonidan tezroq oʻsadi, va har biri alohida kuzatuv va tuzatishni talab qiladi.

Ish yuritish tomoni ham bor. Lewis va Fowler mikroxizmatlarda har xizmatning ish yuritish manzarasi oʻziga xos boʻlishi mumkinligini, koʻp xizmatni murakkab topologiyada joylashtirish bitta monolitni joylashtirishdan qiyinroq ekanini yozadi. Tizimlar toʻplamida yangilanish, zaxira nusxa va kirish huquqlari tartibi har tizimda alohida boʻladi: bu ham tahririyat analogiyasi, ammo mantiq bir xil.

Ixtisoslashgan tizimlar foydasiga: moslik

Light va hamkasblarining maqolasi ERP ni tanqid qilishdan boshlanadi: tanqidchilar uni moslashuvchan emas va muayyan tashkilot yoki tarmoq ehtiyojiga yaxshi mos kelmaydi deb hisoblaydi. Best-of-breed shu moslikni yaxshilashga urinadi. Mualliflar bitta best-of-breed loyihasini oʻrganib, uni yagona sotuvchi ERP si bilan toʻrt oʻq boʻyicha solishtirgan: amalga oshirish murakkabligi, funksionallik darajasi, biznes jarayonga moslashish imkoni va keyingi qoʻllab-quvvatlash. Bu bitta holat tahlili, shuning uchun umumiy qoida emas.

Davenport maqolasining annotatsiyasida ham xavf nomlangan: tayyor paket kompaniya strategiyasi, tashkiloti va madaniyatiga oʻz mantiqini yuklashi mumkin. Bu fikr maqolaning toʻliq matnidan emas, nashrdagi qisqa tavsifdan olingan.

Maʼlumot egaligi ham bahsga kiradi. Lewis va Fowler mikroxizmatlarda har xizmat odatda oʻz maʼlumotlar bazasini boshqarishini, turli xizmatlar uchun turli texnologiya tanlanishi mumkinligini yozadi. Biznes tizimlari uchun bu quyidagicha oʻqiladi: har soha oʻz yozuvlarini oʻzi saqlaydi, shuning uchun yagona mijoz yoki mahsulot katalogini kim yuritishi alohida kelishuv mavzusi.

Aloqa uslubi ham mazmunga taʼsir qiladi. Lewis va Fowler “aqlli nuqtalar, oddiy quvurlar” tamoyilini tavsiflaydi: biznes mantiq xizmatlarning oʻzida turadi, aloqa vositasi esa sodda qoladi, yaʼni yengil HTTP API yoki xabar almashish, markaziy korporativ shina emas. Tahririyat fikricha, bu tamoyil biznes tizimlari integratsiyasiga ham tegishli: bogʻlanish sodda boʻlsa, uni tushunish va kuzatish osonroq. API ning oʻzi qanday ishlashi alohida maqolada tushuntirilgan.

Conway qonuni: qaror tashkilotga qaytadi

Conway tezisi qisqa: tizim loyihalaydigan tashkilotlar oʻz aloqa tuzilmasining nusxasi boʻlgan loyihalarni yaratishga majbur. U buni ikki grafning oʻxshashligi bilan asoslaydi: guruhlar tizimning boʻlimlariga, muvofiqlashtiruvchilar interfeyslarga mos keladi. Lewis va Fowler bu fikrni mikroxizmatlar uchun qoʻllaydi: jamoalar texnologiya qatlami boʻyicha boʻlinsa, har oʻzgarish ular qoʻli yetadigan ilovaga tiqiladi; shuning uchun ular jamoalarni biznes imkoniyati boʻyicha tuzishni taklif qiladi.

Conway oʻzi ham xulosa chiqargan: loyihalash ishi aloqa ehtiyojlari asosida tashkil etilishi kerak, tashkilot esa moslashuvchan qolishi lozim. Yaʼni, tizim chegarasi tashkilot chegarasi bilan tasodifan emas, ongli ravishda mos kelishi kerak, degan fikr.

Tizim tanlash uchun natija: yagona tizim ham, tizimlar toʻplami ham tashkilotdagi suhbat chegaralarini yoʻq qilmaydi, ularni koʻrsatadi. Gipotetik misol: savdo va ombor bir-biri bilan kam gaplashadigan kompaniya bitta ERP olsa, ikkala boʻlim bitta tizimga kiradi, lekin hisobot va qoldiq haqidagi kelishmovchilik joyida qolishi mumkin. Va aksincha, ikki mustaqil tizim ikki mustaqil boʻlim tuzilmasiga mos tushishi mumkin. Bu mantiqiy taxmin, oʻlchangan natija emas.

Fowler: monolitdan boshlash va uning cheklovi

Fowler 2015-yilda “MonolithFirst” yozuvida yangi ilovani monolit sifatida boshlashni tavsiya qilgan. Uning kuzatuvi: muvaffaqiyatli mikroxizmat hikoyalarining deyarli hammasi monolitdan boshlangan, mikroxizmat sifatida noldan qurilgan tizimlarning deyarli hammasi jiddiy qiyinchilikka tushgan. Sabab ikkita. Yangi ilovaning foydasi oldindan nomaʼlum, va xizmatlar chegarasini boshida toʻgʻri chizish tajribali arxitektor uchun ham qiyin.

Chegara masalasi bu yerda asosiy. Fowlerning soʻzlari: funksiyani xizmatlar orasida koʻchirish monolit ichida koʻchirishdan ancha qiyin. Biznes tizimlarda ham shunga oʻxshash: ikki tizim orasidagi chegara noaniq tanlansa, uni keyin siljitish maʼlumot koʻchirish va integratsiyani qayta yozishni talab qiladi. Fowler tavsiyasini oʻzi taxminiy deb hisoblaydi: boshidan mikroxizmatlardan boshlash tarafdorlarining ham asosli dalili bor, tajriba maʼlumotlari esa hali kam.

Fowler yoʻllarni ham sanaydi: modulli monolit loyihalab keyin boʻlish, xizmatlarni chekkadan asta-sekin ajratib olish, monolitni bir martalik deb hisoblash yoki boshidan bir necha yirik xizmatdan boshlash. Shuningdek, har tizimni boʻlib boʻlmaydi: modullari bir-biriga qattiq bogʻlangan tizim boʻlinganda chalkash natijaga olib kelishi mumkin. Biznes tizimlarida bunga oʻxshash holat: boshida bitta tizimdan boshlab, keyin faqat aniq ajraladigan funksiyani (masalan, alohida jamoa yuritadigan modul) boshqa tizimga chiqarish.

Lewis va Fowler 2014-yilgi maqolada ham ehtiyotkor: mikroxizmatlar kelajak ekanini aniq deya olmasliklarini, arxitektura qarorlarining oqibati yillar oʻtib koʻrinishini yozadi.

Tanlov ikki qutbdan iborat emas. Fowler oʻrta yoʻllarni ham keltiradi: boshida bir necha yirik boʻlakdan boshlash. Light va hamkasblari best-of-breed ni ham tayyor paket, ham maxsus dastur aralashmasi deb taʼriflaydi. Yaʼni amaliy variantlar spektr shaklida: yagona tizim, uning chekkasida bir-ikki ixtisoslashgan tizim, yoki boshidan koʻp tizimli manzara.

Mezonlar boʻyicha yonma-yon

Bundan nima kelib chiqadi

Quyidagi toʻrt savol manbalardan chiqarilgan tahririyat xulosasi; ular tanlovning oʻrnini bosmaydi, lekin uni yengillashtiradi.

1. Qaysi yozuvlar albatta bitta boʻlishi kerak: mijoz, mahsulot, hisob-kitob? Bunday yozuv ikki tizimda yuritilsa, izchillik muammosi tugʻiladi va kimdir ularni qoʻlda solishtirishga majbur boʻladi.
2. Har sohaning egasi bormi? Egasi yoʻq sohaga alohida tizim olish chegarani aniqlamaydi, faqat uni tizimlar orasiga koʻchiradi.
3. Chegarani keyin siljitish mumkinmi va qancha turadi? Fowler fikricha, tizimlar orasida koʻchirish bitta tizim ichidagidan qiyinroq.
4. Paketning mantiqiga tashkilot moslashadimi yoki paket tashkilotga? Davenport annotatsiyasi shu savolga ishora qiladi: tayyor paket oʻz mantiqini yuklashi mumkin.

Amaliy tavsiya shundan iborat: tanlovdan oldin jadval tuzib, har sohani (savdo, ombor, moliya, kadrlar) bitta ustunda, uning egasi va ishlatadigan yozuvlarini ikkinchi ustunda yozib chiqish. Jadvalda bir yozuv bir necha sohaga tegsa, ular orasidagi chegara eng murakkab chegara boʻladi.

Light tadqiqoti bitta holat, Fowler tavsiyasi taxminiy, Conway esa 1968-yildagi kuzatuv. Oʻqilgan manbalarning birortasi “yagona tizim” yoki “tizimlar toʻplami” ning tez-tez yutib chiqishini oʻlchamagan. Shu sababli tanlovni mezonlar ustiga qurish mumkin, universal qoidaga tayanib boʻlmaydi.