ВИ може да создаде нацрт на архитектура за неколку минути. Тоа е корисно, но токму тука многу продуктни тимови прават скапа грешка: мешаат уверлив дијаграм со трајна одлука.

Дизајн генериран од ВИ може да именува услуги, да предложи редици, да ги опише табелите во базата на податоци и да скицира патеки за распоредување. Може да ја забрза фазата на празен лист. Она што не може да го преземе е трајната вредност на производот: расудувањето за тоа што мора да остане вистинито додека се менуваат клиентите, пазарите, тимовите и технологијата.

Таа одговорност им припаѓа на луѓето што го градат производот. За технички лидер, вистинската можност не е да ги отфрли нацртите за архитектура од ВИ или слепо да ги прифати. Таа е да ги претвори во дисциплинирана почетна точка за подобри одлуки.

Архитектурата е продуктна одлука пред да биде техничка

Тимовите често ја оценуваат архитектурата со технички јазик: латентност, достапност, скалирање, усогласеност со рамката и оперативен трошок. Тоа е важно. Но архитектурата што трае почнува со продуктни прашања.

Кој проблем на клиентот го решаваме? Кои работни текови се доволно централни за да ги заштитиме? На кои информации мора да им се верува? Каде бизнисот ќе треба брзо да се приспособува? Кои неуспеси би предизвикале вистинска штета, а со кои може да се постапи подоцна?

Нацрт од ВИ обично нема суштински одговор на овие прашања, освен ако не му го дадете контекстот. Дури и тогаш, неговиот одговор е предлог, а не одговорност. Не може да седне со клиент по нарушен работен тек, да објасни одложено лансирање на продажбата или да одлучи дали кратенка компромитира ветување што го дал вашиот производ.

Таа разлика го менува начинот на користење на излезот. Третирајте го нацртот како збир хипотези. Секоја кутија, граница и зависност треба да го заслужи своето место со поддржување на продуктен исход.

Почнете со вредноста што мора да трае

Секој успешен производ развива јадро што треба да остане сигурно дури и додека неговите функции се развиваат. За производ за закажување, тоа може да бидат доверливи резервации и достапност. За платформа за трговија, тоа може да бидат точно ценообразување и состојба на нарачките. За алатка за соработка, тоа може да бидат јасни дозволи и доверлив заеднички контекст.

Тоа не се само функции. Тоа се ветувања. Архитектурата треба да го олесни зачувувањето на тие ветувања.

Корисна вежба е да запишете три категории пред да прегледате каков било дизајн:

• Трајни продуктни ветувања: исходите на кои корисниците мора да можат да се потпрат.
• Веројатни области на промена: правила, интеграции, канали, планови и експерименти што може брзо да се развиваат.
• Критични граници на неуспех: дејства што не смеат да бидат дуплирани, изгубени, изложени или тивко оштетени.

Ова создава практична призма за предлог генериран од ВИ. Ако нацртот ја распрснува состојбата на нарачките низ неколку услуги, прашајте како ќе се одржува конзистентноста. Ако воведува нов слој за интеграција, прашајте дали тој слој ја изолира надворешната промена или само додава уште едно место каде што неуспесите можат да се скријат. Ако препорачува генеричка поделба на микросервиси, прашајте дали независното распоредување навистина му е потребно на производот.

Целта не е архитектонска чистота. Таа е да се зачуваат нештата што создаваат доверба кај клиентите, додека промената останува прифатлива.

Испитувајте го нацртот, не му се восхитувајте

Излезите од ВИ често се самоуверени и добро структурирани. Таа презентација може да прикрие претпоставки што недостигаат. Сениорскиот преглед треба да ги направи тие претпоставки видливи.

Прашајте за неповолниот пат

Повеќето нацрти за дизајн го објаснуваат успешното барање: корисникот испраќа податоци, услуга ги обработува и се враќа одговор. Продукциските системи се дефинирани исто толку и од она што се случува кога зависностите откажуваат.

Разгледајте тек на наплата што запишува нарачка и испраќа барање за плаќање. Што се случува ако плаќањето успее, но одговорот се изгуби? Што се случува ако повторниот обид го испрати истото барање двапати? Што се случува ако ажурирањето на залихите е привремено недостапно? Дизајн што не може да го објасни своето однесување при повторни обиди не е подготвен само затоа што неговиот нормален тек изгледа чисто.

Корисните прашања за преглед вклучуваат:

• Кои операции мора да бидат идемпотентни?
• Каде се дефинирани временските ограничувања, повторните обиди и обработката на неуспешни пораки?
• Како операторите ќе откријат делумен неуспех?
• Кои податоци може да бидат евентуално конзистентни, а кои не?
• Какво е однесувањето кон клиентот кога зависноста е недостапна?

Прашајте кој ја поседува секоја граница

Техничките граници треба да ја одразуваат одговорноста, како и имплементацијата. Услуга без јасен тим, без оперативен сопственик и без причина да се менува независно обично е покана за забуна.

Ова е особено важно за оддалечените тимови. Дистрибуираната работа ја засилува нејасната одговорност бидејќи контекстот што недостига не се надоместува преку разговори во ходник. Јасните интерфејси, документираните одлуки, корисното следење и експлицитен сопственик за клучните работни текови го намалуваат трошокот за координација.

Одговорноста не значи дека едно лице мора да ја одобри секоја промена. Таа значи дека тимот може да одговори кој го одржува договорот, кој реагира на инцидент и кој одлучува кога спротивставените барања бараат компромис.

Изберете ја наједноставната архитектура што ја штити иднината

ВИ често предлага богат збир од познати компоненти бидејќи има видено многу такви обрасци. Тоа не значи дека на вашиот производ му се потребни сега.

Модуларна апликација со добро дизајнирана база на податоци може да биде посилна основа од предвремен збир дистрибуирани услуги. Полесно е да се разбере, тестира, распореди и поддржува. Важното прашање е дали нејзините внатрешни граници се доволно јасни за некоја компонента подоцна да може да се извлече кога постојат докази што го оправдуваат тоа.

На пример, нов производ може да ги задржи сметките, наплатата и логиката на работниот тек во една апликација што се распоредува, додека нивните домени ги разделува во кодот и пристапот до податоци. Ако наплатата подоцна развие различни потреби за усогласеност, однесување при скалирање или ритам на изданија, тимот има суштинска причина повторно да ја разгледа границата. Дотогаш, оперативната едноставност е продуктна предност.

Ова не е аргумент против системи управувани од настани, разложување на услуги или специјализирана инфраструктура. Тоа е аргумент сложеноста да се заслужи. Секој нов подвижен дел треба да решава проблем што е присутен, важен и разбран.

Претворете ја ВИ во партнер за преглед

Највредната употреба на ВИ често е итеративна, наместо авторитативна. Дајте ѝ ги вашите ограничувања, а потоа искористете ја за да откриете опции што можете да ги оцените.

Побарајте од неа да идентификува претпоставки, да спореди алтернативи, да наброи начини на неуспех или да оспори предложена граница. Побарајте план за миграција од денешниот систем, наместо идеализиран дијаграм за нов систем од нула. Прашајте каква набљудливост би била потребна за управување со дизајнот. Потоа проверете го секое важно тврдење во однос на вашата реална платформа, база на код, добавувачи и способности на тимот.

Силен технички лидер исто така ја запишува произлезената одлука со јасен јазик: контекстот, разгледаните опции, направениот избор, прифатените последици и сигналите што би поттикнале повторно разгледување. Ова е особено вредно кога соиграчите работат низ временски зони. Краток запис за одлуката спречува архитектурата да стане усна традиција.

Вашата трајна предност е расудувањето

Алатките ќе продолжат да го забрзуваат изготвувањето на нацрти. Тоа е добра вест за луѓето што сакаат да трошат помалку време на генерирање шаблонски код и повеќе време на разбирање на работата што е важна.

Трајната вредност на продуктен тим не е способноста да произведе импресивен дијаграм на архитектура. Таа е способноста да донесува одговорни избори во услови на неизвесност: да ја заштити довербата на клиентите, да ја поедностави испораката, да учи од реалната употреба и да ги ревидира одлуките кога се менуваат доказите.

Нека ВИ ви помогне да почнете. Но задржете ја одговорноста за прашањата, компромисите и ветувањата што ги дава вашиот производ. Тука архитектурата престанува да биде нацрт и станува трајна предност.