Кращі практики проектування архітектури підприємства на основі блокчейна

У цій статті наведено вказівки щодо того, як створити архітектуру підприємства, в цьому випадку, що стосується блокчейн та інших технологій.

Архітектура підприємства - це структура або модель, яка описує структуру та функції підприємства. Це допомагає нам аналізувати, проектувати, планувати, впроваджувати та підтримувати архітектурні компоненти. Ми визначаємо логічну архітектуру, а не фізичну архітектуру. Тобто архітектура описує те, що роблять компоненти, а не те, як вони реалізовані на практиці.

Архітектура може включати різні типи компонентів, такі як бізнес-процеси, організаційні підрозділи, люди, пристрої, системи та ІТ-інфраструктура. Зазвичай вони зосереджуються на системах та підтримуючої інфраструктурі, відображених на тлі, що показує бізнес-одиниці або логічні шари.

Як приклад, нижче наведена архітектура корпоративного фонду OEL. Фонд OEL - це неприбуткова організація, що забезпечує управління та ресурси для розвитку екосистеми "Блокчейн" логістики "Відкрите підприємство". В архітектурі показані компоненти, що використовуються для доставки логістичних продуктів та послуг учасникам екосистеми або за їх допомогою.

Як ми можемо розробити архітектуру підприємства, яка включає технологію blockchain?

Принципової різниці в розробці будь-якої архітектури немає - блокчейн - це ще один технічний компонент. Однак є деякі аспекти технології blockchain, такі як смарт-контракти, які повинні з'являтися в архітектурі як компоненти.

Отже, як ми можемо взагалі розробляти архітектуру підприємства?

Немає «правильних» чи «неправильних» відповідей, хоча деякі підходи корисніші за інші. Пам'ятайте, що архітектура підприємства - це також жива істота, яка з часом змінюватиметься та розвиватиметься.

Є кілька загальних рекомендацій, які корисні в архітектурному дизайні:

1. Нехай це буде просто

2. Зверніться до галузевих прикладів та найкращої практики

3. Розуміти відповідні розробки галузі

4. Визначте межу архітектури

5. Визначте принцип (и) організації, який потрібно використовувати

6. Населяйте архітектуру відповідними компонентами

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

8. Перегляньте та встановіть базову архітектуру

Не ускладнювати

Взагалі, якщо щось не просто, це зазвичай тому, що складність відображає один або кілька факторів, таких як: неповний аналіз та проектування, робота з занадто низьким рівнем деталізації або намагання включити занадто багато речей у модель.

Намагання повністю використовувати комплексний архітектурний стандарт, такий як Open Group Architecture Framework (TOGAF), також може бути недоцільним, окрім як для дуже великих організацій.

Архітектура підприємства може бути спроектована з використанням різного ступеня складності. Деякі архітектури підприємств дуже складні і важкі для розуміння навіть людьми, які повинні ними користуватися. Краще зберігати архітектуру максимально просто, не втрачаючи ключової інформації. Це допомагає людям зрозуміти та використовувати архітектуру та її компоненти.

Структурна схема є хорошою основою для простої архітектури. Це дозволяє нам бачити основні компоненти та їх широке відношення один до одного, не докладно описуючи їх функції чи зв’язки.

Зверніться до галузевих прикладів та найкращої практики

Існує безліч прикладів архітектур, що відрізняються складністю, різними підходами та принципами організації та великою кількістю різних типів компонентів.

Часто не існує стандартної структури архітектури або моделі, яка може бути використана в якості посилання. За відсутності цього, ми повинні шукати приклади архітектури від провідних учасників галузі або від науковців. Це може показати нам, як інші підходили до аналізу та дизайну архітектури та можуть слугувати основою для нашої власної архітектури.

Іноді легко знайти дуже різні підходи, що може заплутати.

Один корисний прийом - пошук зображень за допомогою відповідних ключових слів і відчуття того, які моделі візуально вам подобаються. Перегляньте їх на високому рівні, не втрачаючи деталей. Виберіть чотири-п’ять із них, які здаються вам особливо актуальними для подальшого огляду та довідок.

Подивіться, що у них спільного та які відмінності існують. Що входить в архітектуру, а що ні? Спробуйте подумати про принципи організації, які використовуються при їх побудові. Які компоненти перераховані? Не хвилюйтесь, якщо ви не повністю їх розумієте або якщо вони містять елементи, які здаються вам неважливими. Пам'ятайте, що немає "правильної" чи "неправильної" відповіді.

Для архітектури корпорації OEL Foundation ми використовували моделі архітектури Ethereum, Ontology, CSCC / IBM, Tibco та вибраних учасників галузі в якості посилань.

Розуміти відповідні розробки галузі

Ми в будь-який час працюємо в контексті галузі та набору технологій, які постійно змінюються. Це може зробити підходи, які використовувались порівняно недавно, здаються неактуальними та застарілими.

Ми повинні спробувати зрозуміти сучасний стан цього контексту, а також спробувати заглянути вперед і визначити можливі майбутні зміни в галузі, економіці та технологіях. Це зробити дуже важко. Найкращий підхід - спробувати визначити широкі події, які будуть актуальними.

Щодо архітектури, що базується на блокчейні, ми тут більше невдалі, ніж зазвичай, враховуючи відносну незрілість технології та швидкі темпи змін.

Для архітектури корпорації OEL Foundation ми виділили чотири категорії розвитку на ринку та технології, які ми вважаємо особливо актуальними для екосистеми Фонду OEL:

1. Моделі цифрового бізнесу

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

3. Зближення технологій blockchain та обміну повідомленнями

4. Зростаюче використання та важливість хмарних сервісів, таких як Програмне забезпечення як послуга (SaaS), Платформа як послуга (PaaS) та Інфраструктура як послуга (IaaS).

Визначте межу архітектури

Як і будь-яка система, нам потрібно визначити межу системи для нашої архітектури, розділивши те, що знаходиться всередині системи, а що поза системою.

Іноді межа не намальована в потрібному місці. Ми можемо побачити безліч зовнішніх дійових осіб та сторонніх компонентів (які не використовуються для прямої реалізації архітектури) в архітектурі. Це не допомагає нам визначити основні внутрішні компоненти, які будуть використовуватися для архітектури.

Якщо корисно подивитися на відношення архітектури до її оточення, це слід зробити за допомогою графічного результату, такого як контекстна діаграма. Це на більш високому рівні абстракції, ніж сама архітектура.

Для архітектури корпорації OEL Foundation ми використовуємо сторонні технології та стандарти в архітектурі, а також підключаємося до зовнішніх сторін та систем, використовуючи компоненти архітектури, такі як API, проміжне програмне забезпечення для обміну повідомленнями та компоненти міжмережевої інтеграції. Ми можемо вважати, що всі ці речі знаходяться в межах архітектури.

Учасники екосистеми, зовнішні системи чи пристрої або засоби, що використовуються для їх інтеграції з архітектурою, знаходяться поза межами архітектури.

Визначте принцип організації, який слід використовувати

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

Тут ми можемо скористатись декількома підходами, включаючи один або декілька з наступного:

1. Потік бізнес-процесів

2. Структура внутрішньої організації підприємства (із зовнішніми зв’язками або без них)

3. Стандартна модель відліку

Ми можемо спробувати використовувати потік бізнес-процесів для організації компонентів, таких як перехід від постачальника до замовника. Потім компоненти архітектури організовуються по потоку, що мається на увазі, між цими сторонами.

Часто архітектура відображає внутрішню організаційну структуру, яка складається з організаційних функцій (або організаційних підрозділів), таких як маркетинг, продажі, операції, фінанси тощо. Це може або не може включати зв'язки із зовнішніми системами чи сторонами.

Для архітектури корпорації OEL Foundation ми використовуємо варіацію моделі взаємозв'язку ISO Open Systems (модель OSI) як організаційного принципу. Модель OSI - це концептуальна модель, яка описує функції зв'язку телекомунікаційної або обчислювальної системи.

Модель OSI використовує сім шарів, але ряд архітектур на основі блокчейна використовують тришарову модель. Вони іноді називаються різними назвами, але зазвичай містять рівень платформи (або програми), рівень протоколу та мережевий рівень. Термін "протокол" сам по собі може бути заплутаним, неоднозначним та відкритим для тлумачення. Можливо, буде корисно погодитись, що означають такі терміни, що допомагає визначити компоненти, релевантні в цьому контексті.

Наповніть архітектуру відповідними компонентами

Коли у нас є загальна структура архітектури, ми можемо вирішити, які компоненти архітектури повинні містити, і призначити їх відповідної частини архітектури.

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

Це дуже галузь і навіть організація, тому важко дати загальну пораду.

Однак слід застосувати два загальних принципи:

1. Компоненти в цілому повинні бути на одному рівні дозволу

2. Обмежте кількість компонентів

Ми не хочемо, щоб компоненти значно відрізнялися від інших за розміром. Це часто видно, коли компонент називається чимось на зразок "ядро", що означає, що він може бути на більш високому рівні роздільної здатності, ніж інші компоненти, і, можливо, його потрібно буде розкласти на логічні частини.

Корисно використовувати велике правило про кількість компонентів, що з’являються в архітектурі. Для великої, складної багатонаціональної організації це може бути складним, оскільки може бути залучено сотні окремих заявок. Вони, однак, все ще можуть бути логічно згруповані в категорії додатків. Поширений підхід - використовувати сім плюс-мінус два компоненти на один шар і не мати більше двадцяти компонентів у всій архітектурі.

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

Нарешті, ви можете переглянути архітектуру щодо еталонних моделей, які ви визначили спочатку, використовуючи їх для перехресної перевірки вашої архітектури на повноту та послідовність.

Перегляньте кожну з еталонних моделей відповідно до вашої архітектури та перевірте, чи є компоненти еталонної моделі у вас. Якщо їх немає, запитайте, чому так і чи потрібно їх включити. Якщо у вашій архітектурі є додаткові компоненти, запитайте, чи потрібні вони, і спробуйте зрозуміти, чому вони відсутні в еталонній моделі. Вони можуть не відповідати контексту цієї моделі.

Це хороша перевірка обґрунтованості того, що ваша архітектура має певне співвідношення з іншими моделями, які, як ви бачите, використовуються на практиці.

Перегляньте та задумайте архітектуру

На даний момент у вас є діюча модель вашої архітектури. Тепер ви можете розповсюдити його на огляд колегам та іншим зацікавленим сторонам та спробувати використовувати його на практиці. Ви, ймовірно, виявите, що потрібні деякі зміни, що нормально. Не бійтеся переміщати компоненти навколо, якщо ви думаєте, що вони не в потрібному місці, або видаляти або вставляти нові компоненти.

Не забувайте, що архітектура підприємства - це жива істота, яка з часом змінюватиметься, відображаючи зміни потреб організації або зовнішні зміни в галузі чи технології.

Модель архітектури підприємства тепер може бути покладена під контроль версій та відповідальність за її поточне обслуговування, покладене на відповідну функцію чи партію. У великій організації це може бути формальна архітектурна функція або окремий архітектор. У менших організаціях цю функцію можуть взяти на себе один або кілька осіб, які зазвичай є бізнес-аналітиками або дизайнерами систем.

Ми сподіваємось, що ця стаття буде корисною для того, щоб дати вам деякі вказівки щодо підходу до аналізу та дизайнерських робіт для вашої власної архітектури підприємства та бажаємо вам успіху в цьому.

Марк Нельсон - очолюваний організацією Фонду OEL. Якщо ви хочете дізнатися більше про фонд OEL, перейдіть за посиланням https://oel.foundation або зв’яжіться з автором безпосередньо за адресою mark.nelson@oel.foundation

Ви також можете приєднатися до Фонду на Telegram.