Как да осигурите солидна архитектура в един гъвкав свят? Ето метод за създаване на архитектури, приспособени към постоянна промяна

Имало едно време, в началото на жизнения цикъл на проекта, архитектурата щеше да бъде „завършена“.

Това е важна стъпка, която изследва всички „способности“ (скалируемост, достъпност, видимост и т.н.).

И така, като се има предвид днешният забързан свят и клиентът може да не види осезаема полза от (скъпата) фаза на архитектура, как да направим „гъвкава архитектура“?

Архитектура в гъвкав свят

Има много написано за Agile Architecture, но не мисля, че все още сме там с приета практика за това.

Архитектурата, направена добре и направена старателно, е трудна. Ако не ми вярвате, препоръчвам „Основи на софтуерната архитектура“ и „Софтуерна архитектура: твърдите части“. Освен това има цялата специфична архитектура на облачната инфраструктура и DevOps архитектура.

Добрата архитектура трябва да отчита много различни гледни точки (както технически, така и човешки) и непрекъснато да обменя една срещу друга.

Аргументът за MVP

Има школа на мисълта, че няма нужда от архитектура и разработчиците могат да създадат минимален жизнеспособен продукт (MVP).

За ясни решения това може да бъде ценно упражнение. Ако се направи правилно, MVP може да предостави много уроци, за да помогне да се определи какво искат клиентите. В този смисъл това е форма на прототипиране.

Въпреки това, всеки растеж от MVP ще изисква някаква форма на архитектура.

Освен това:Ако имате клиент, който плаща за решение, и вие предлагате да доставите Минималния жизнеспособен продукт на клиент, това може да звучи като „Ние ще доставим всичко минимум за парите, които ни давате”. Ако обаче кажете, че първо ще изградите MVP, за да ускорите процеса на събиране на изискванията и след това да доставите стабилното решение, за което са платили, това е много различно предложение.

Като архитект на проект, доставящ MVP, вие трябва да помогнете за правилното му обхват. Уверете се, че MVP е за изхвърляне или по-типично, има ясна точка, когато MVP е отговорил на въпросите, и има структурирана еволюция в цялостен продукт.

Архитектурата все още трябва да се работи

Във всичко друго, но не и при бързо и разхлабено стартиране, архитектурата все пак ще трябва да се направи в даден момент.

Често отлагането за по-късно води до скъпо пътуване.

Предоставяне на архитектурното намерение

В днешния свят няма място за Big Up-Front Design (BUFD), което е хубаво нещо. BUFD потъна в разходи за милиони без ясна стойност и често дизайнът беше остарял, когато (или ако) беше завършен.

Решението за това е да се разработи Архитектурно намерение.

Архитектурното намерение е голямата картина.

Предвид нуждите на вашия проект, клиент, решение или предприятие, каква е най-добрата архитектура, която се справя с всички „задачи“? Кои възможни продукти могат да помогнат за постигане на целите?

На пръв поглед това може да звучи като BUFD, но това, което правите, е да изложите дългосрочната архитектурна визия. Все още не са уточнени всички подробности. Вашето конкретно решение ще зависи от идентифицирането на архитектурно значимите аспекти, които може да се нуждаят от повече конкретизиране.

Това е достатъчно голяма архитектура, за да зададе посоката.

Освен няколко (и вече редки) правителствени ИТ проекта, никой не може да си позволи да внедри пълната архитектура от самото начало.

Архитектурното намерение определя посоката за цялостната архитектура. Архитектурното намерение обаче може и ще се промени.

Както при всички гъвкави или постепенни доставки, изискванията ще се променят. Промените в изискванията могат да променят посоката, зададена от архитектурното намерение.

Освен това една програма за трансформация може да отнеме няколко години. Докато предоставите някои аспекти на Архитектурното намерение, може да са налични различни технологии от тези, когато сте започнали.

Но какво да кажем сега?

С Архитектурното намерение, определящо дългосрочната визия, изграждането към тази визия ще бъде постепенно.

Като се има предвид архитектурното намерение, кои аспекти са първите, за да осигурят непосредствените изисквания?

Освен това, предвид настоящите технически възможности на екипа за разработка, каква част от намерението трябва да бъде намалена, за да се избегне рискът от доставка?

Още веднъж, архитектурата е свързана с тези компромиси. И това са компромиси, идващи с търговски последици, а не нещо, което архитектът прави изолирано.

За разлика от Архитектурното намерение, Непосредствената архитектура е конкретна. Налице са точни спецификации или политики за това какво трябва да се случи.

Непосредствена архитектура към намерение за архитектура

Не е изненадващо, че стъпките от непосредствената архитектура до архитектурното намерение формират вашата пътна карта и дефинират стъпките на продукта или изданието.

В зависимост от това колко гъвкав е проектът, само следващите стъпки в пътната карта могат да бъдат добре дефинирани. Целта е да не правите твърде много BUFD; напразни усилия, когато изискванията се променят.

Това не оставя ли решение без съществена архитектура в началото?

Не. Като архитект все още трябва да се уверите, че всички необходими „илиности“ са в непосредствената архитектура. Възможно е обаче да има известни преговори с клиента за първоначалните увеличения.

Може също така да откриете, че обемите данни и броят на потребителите първоначално са ниски, което позволява поетапен подход за поддържане на мащабируемост и паралелност.

Какво мислиш?

Опитвали ли сте да доставите солидна архитектура в гъвкав свят?

Смятате ли, че концепциите за архитектурно намерение срещу непосредствена архитектура имат смисъл за вас?