Най-добри практики при проектирането на корпоративна архитектура, базирана на blockchain

В тази статия са дадени насоки за това как да се проектира архитектурата на предприятието, в този случай включващ blockchain и други технологии.

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

Архитектурата може да включва различни видове компоненти, като бизнес процеси, организационни звена, хора, устройства, системи и ИТ инфраструктура. Обикновено те се фокусират върху системи и поддържаща инфраструктура, картографирани на фона на които показват бизнес единици или логически слоеве.

Като пример по-долу е архитектурата на OEL Foundation Enterprise. Фондация OEL е организация с нестопанска цел, осигуряваща управление и ресурси за развитието на блокчейн екосистемата Open Enterprise Logistics. Архитектурата показва компонентите, използвани при доставката на логистични продукти и услуги на или от участниците в екосистемата.

Как да проектираме корпоративна архитектура, която включва блокчейн технология?

Няма фундаментална разлика при проектирането на каквато и да е архитектура - blockchain е просто друг технически компонент. Съществуват обаче някои аспекти на блокчейн технологията, като например интелигентни договори, които трябва да се появят в архитектурата като компоненти.

И така, как да продължим да проектираме корпоративната архитектура като цяло?

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

Има няколко общи насоки, които са полезни в архитектурния дизайн:

1. Дръжте го просто

2. Обърнете се към примери за индустрията и най-добри практики

3. Разберете съответните развития в индустрията

4. Определете граница на архитектурата

5. Вземете решение относно организационния (ите) принцип (и), който да използвате

6. Населете архитектурата със съответните компоненти

7. Препратка към вашата крайна архитектура с примери за индустрията

8. Преглед и основна архитектура

Не го усложнявай

Като цяло, ако нещо не е просто, обикновено това е, защото сложността отразява един или повече фактори като: непълен анализ и дизайн, работа с твърде ниско ниво на детайлност или опит за включване на твърде много неща в модела.

Опитът да се използва пълноценно архитектурен стандарт като Open Group Architecture Framework (TOGAF) също може да е неподходящ, освен за много големи организации.

Корпоративната архитектура може да бъде проектирана, като се използва различна степен на сложност. Някои корпоративни архитектури са много сложни и трудни за разбиране, дори от хората, които трябва да ги използват. По-добре е да запазим архитектурата възможно най-проста, без да губим ключова информация. Това помага на хората да разберат и използват архитектурата и нейните компоненти.

Блок-схемата е добра основа за проста архитектура. Това ни позволява да видим основните компоненти и широката им връзка помежду си, без да описваме подробно тяхната функция или връзки.

Вижте индустриалните примери и най-добрите практики

Има много примери за архитектури с различна сложност, различни подходи и принципи на организация и с голям брой различни видове компоненти.

Често няма стандартна архитектурна рамка или модел, който да се използва като еталон. При липсата на това трябва да търсим примери за архитектура от водещи участници в индустрията или от преподаватели. Те могат да ни покажат как другите са подходили към архитектурния анализ и дизайн и могат да послужат като основа за нашата собствена архитектура.

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

Една полезна техника е да търсите изображения с помощта на подходящи ключови думи и да получите усещане за това кои модели ви харесват визуално. Прегледайте ги на високо ниво, без да се губите в детайлите. Изберете четири до пет от тях, които изглеждат особено подходящи за вас за допълнителен преглед и справка.

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

За OEL Foundation Enterprise Architecture използвахме архитектурни модели от Ethereum, Ontology, CSCC / IBM, Tibco и избрани участници в индустрията като референции.

Разберете съответните развития в индустрията

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

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

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

За корпоративната архитектура на OEL Foundation ние идентифицирахме четири категории развитие на пазара и технологиите, които смятаме за особено важни за екосистемата на фондация OEL:

1. Дигитални бизнес модели

2. Развитие на блокчейн технологиите (особено нововъзникващата поддръжка на екосистемата)

3. Конвергенцията на блокчейн и съобщения технологии

4. Нарастващото използване и значение на облачните базирани услуги, като Софтуер като услуга (SaaS), Платформа като услуга (PaaS) и Инфраструктура като услуга (IaaS).

Определете граница на архитектурата

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

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

Ако е полезно да се разгледа връзката на архитектурата с нейната среда, това трябва да стане с помощта на графичен изход, като например контекстна диаграма. Това е на по-високо ниво на абстракция от самата архитектура.

За OEL Foundation Enterprise Architecture използваме технология и стандарти на трети страни в архитектурата, а също така се свързваме с външни партии и системи, използвайки архитектурни компоненти като API, междинни програми за съобщения и компоненти за междуверижни интеграции. Можем да разглеждаме всички тези неща като вътре в границата на архитектурата.

Участниците в екосистемата, външните системи или устройства или средствата, използвани за интегрирането им с архитектурата, са извън границата на архитектурата.

Вземете решение относно принципите за организиране, които да използвате

Организационният (ите) принцип (и) ни помага да структурираме архитектурата и представлява основа за присвояване на архитектурни компоненти на различни части от архитектурата.

Има редица подходи, които можем да използваме тук, включително един или повече от следните:

1. Поток от край до край

2. Структура на вътрешната организация на предприятието (със или без външни отношения)

3. Стандартен референтен модел

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

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

За организацията OEL Foundation Enterprise Architecture използваме вариант на модела за взаимно свързване на ISO Open Systems (модел OSI) като организиращ принцип. Моделът OSI е концептуален модел, който описва комуникационните функции на телекомуникационна или изчислителна система.

Моделът OSI използва седем слоя, но редица архитектури, базирани на blockchain, използват трислоен модел. Те понякога са различни имена, но обикновено съдържат платформа (или приложение) слой, протоколен слой и мрежов слой. Самият термин „протокол“ може да бъде объркващ, двусмислен и отворен за тълкуване. Може да е полезно да се съгласите какво означават такива термини, което помага да се идентифицират компоненти, които са релевантни в този контекст.

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

Когато имаме цялостната структура на архитектурата, тогава можем да решим какви компоненти трябва да съдържа архитектурата и да ги присвоим на съответната част от архитектурата.

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

Това е много специфично за индустрията и дори за организацията, така че е трудно да се дадат общи съвети.

Въпреки това трябва да се прилагат два основни принципа:

1. Компонентите трябва като цяло да са на същото ниво на разделителна способност

2. Ограничете броя на компонентите

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

Полезно е да използвате правило за броя на компонентите, които се появяват в архитектурата. За голяма, сложна многонационална организация това потенциално може да бъде трудно, тъй като може да има стотици отделни приложения. Те все още могат да бъдат логически групирани в категории на приложения. Често срещан подход е да се използват седем плюс или минус два компонента на слой и да няма повече от двадесет компонента в цялата архитектура.

Препратка към вашата окончателна архитектура с примери за индустрията

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

Прегледайте всеки от референтните модели спрямо вашата архитектура и вижте дали компонентите на референтния модел присъстват във вашия собствен. Ако те не са, попитайте защо това е така и дали трябва да бъдат включени. Ако вашата архитектура има допълнителни компоненти, попитайте дали те са необходими и се опитайте да разберете защо те не присъстват в референтния модел. Те може да не са от значение за контекста на този модел.

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

Преглед и основна архитектура

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

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

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

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

Марк Нелсън е техническият директор на фондация OEL. Ако искате да научите повече за фондацията OEL, моля, отидете на https://oel.foundation или се свържете директно с автора на mark.nelson@oel.foundation

Можете също да се присъедините към фондацията по Telegram.