Записки правдивого архітектора: просто про самому головному (Ч. 2)

Архітектура – це про майбутнє...
— саме на цій думці ми зупинилися в кінці 1й частини статті. Продовжуємо.

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

Завдання бувають різні. Стандартні і специфічні. Локальні і масштабні.
Але в будь-якому випадку, навряд чи хтось захоче дім «на один сезон» (хоча таке теж можливо, але це якраз із розряду «специфічного», і навряд чи для подібного будівництва будуть вдаватися до послуг архітектора) — так і сумнівно, щоб хтось хотів отримати в результаті систему без перспективи її розвитку в майбутньому.

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

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

Отже, до функціональних властивостей відносяться:
  • Надійність;
  • Продуктивність;
  • можливість модифікацій;
  • Масштабованість;
  • Здатність до інтеграції;
  • Безпека.
Крім того, добре продумана архітектура може дозволити організувати паралельне розвиток системи одночасно кількома виконавцями, т. к. межі відповідальності і точки інтеграції компонентів добре окреслені і зрозумілі.
І це позитивно позначається на термінах реалізації проекту.

Архітектура – це спосіб боротьби зі складністю
image
Не думаю, що хтось буде заперечувати факт: ІТ-системи – це, в цілому, складні системи. І вся практика створення ІТ-систем і комплексів йде під прапором боротьби зі складністю.

Дозволю собі згадати одну давню історію чудових студентських часів.
Коли настав час готувати дипломну роботу, я потрапила до дуже «правильному» вчитель, який в обов'язковому порядку вимагає від мене голову з розрахунком надійності мого «програмно-апаратного комплексу», як гордо іменувався моє невеликий додаток для персонального комп'ютера. Я спробувала обурюватися, потім засмутилася – мені здавалося, дуже безглуздо і марно витрачати дорогоцінний час на таке формальний питання… Але коли я прийшла в бібліотеку, я дізналася для себе багато цікавого. Зокрема, до рук мені потрапила чудова робота Р. Дж.Майерса «Надійність програмного забезпечення» («Software Reliability: Principles and Practices»).

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

На відміну від апаратних засобів, програмного забезпечення надто складно, щоб бути «абсолютно надійним». І один з постулатів теорії надійності ЗА говорить: «У будь-якій програмі є хоча б одна помилка».

Відповідно, в індустрії виробництва ЗА з'являється безліч практик, підходів, інструментів, які дозволяють знизити складність і керувати нею.
Зокрема, створення мов високого рівня, спеціалізованого (інфраструктурного) СУБД, сервери додатків і т. п. Все це спроби розбити складний процес реалізації на ієрархічні рівні, кожен з яких вирішує завдання свого рівня, а кожен наступний користується сервісом попереднього, «не замислюючись», як саме він це реалізує.

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

Крім поліпшення надійності, ми торкаємося тут ще одне важливе нефункціональне властивість системи – здатність до модифікації.
Уникаючи монолітних конструкцій, розділяючи систему на складові частини — модулі, які зрозумілим чином функціонують і взаємодіють, ми підвищуємо можливості вносити зміни в окремі компоненти, зводячи вплив на інші її частини до мінімуму. Простіше кажучи, в майбутньому в процесі розвитку системи це дозволить не опинитися в ситуації «тут торкнеш – там посиплеться».
Архітектура повинна підтримати майбутній процес управління змінами в системі, обмеживши вплив компонентів один на одного і передбачивши кошти виконання оцінки впливу майбутніх змін.

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

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

Навіщо потрібні архітектори? Яка їх роль? Що від них можна очікувати і чому?
Тепер від високого рівня «Enterprise» спустимося «на землю», тобто в проекти. І подивимося на світ очима архітектора учасників проектів з розробки пз.

Що це за таємничий людина — архітектор?
Код не пише (може і писати, але рідше і не зараз, коли ми за ним спостерігаємо). Сидить собі спершу в кутку – мислить, креслить, придумує… «Витає в хмарах» — думають розробники. «Ну-ну, подивимося» — думає начальник.

Так, код не пише. Часто пише на папері. Або на дошці. Один або з ким-то – малюють, малюють… Обговорюють. Знову малюють.
Потім у нього визріває… концепція (або бачення (vision) – в залежності від масштабу завдання).
У концепції реалізується основна ідея, яка прозвучала від «замовника архітектури» (див. 1ю частина статті).

Представлення концепції (бачення)
У підсумку, у архітектора з'являється набір картинок і коротка презентація, яка пояснює суть проблеми, поставлену задачу і підхід до її реалізації. Далі починається процес представлення архітектури зацікавленим сторонам і узгодження – як з боку бізнесу, так і з боку ІТ-фахівців, т. к. питання можуть бути у всіх різні. І вони повинні бути враховані. Завдання цього етапу – досягти рівного розуміння. Це не так просто, як здається. І це не завжди вдається… І… це нормально. Це частина професії.

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

Архітектор – це не скільки щасливий «кодер» і винахідливий «кулібін». Це людина, наділена відповідальністю за напрямок, за команду, за систему… Від його експертизи, вдумливості і вміння «заглядати у майбутнє» залежить успіх роботи багатьох людей.

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

Архітектору треба повірити у цю мету. Так як саме він відповідає за те, щоб «загін» по дорозі не злився в якомусь незрозумілому напрямку – наприклад, вирішив відправитися в лазню попаритися… або городи комусь копати… image
Коли цільове бачення вибрано, всім зрозуміло і співзвучно, то саме на його основі потім здійснює контроль правильності руху.
Належить шлях «1000 миль». Крок за кроком – перш ніж виникне щось працююче і відчутне. І завдання архітектора– «не дати згвинтити». Тому, крім технічного бекграунду і вміння мислити стратегічно, йому вкрай необхідні справжні лідерські якості і те, що зараз модно назвати soft skills — тобто здатність вести переговори, працювати з людьми, добре володіти собою і керувати ситуацією.
Рідко кому всі ці різноманітні якості даються від природи. Що нам дано, а що-то треба виховувати і вирощувати.

Хто ти – ідеальна специфікація?
Концепція або Vision — це лише перший крок.
Далі потрібно «заглибитися в деталі» — опрацювати окремі ключові моменти майбутньої системи і її компонентів.
І цей крок включає в себе опрацювання кілька моделей різного рівня і призначення, наприклад, моделі даних, взаємодії, бізнес-процесів, переходів станів і т. п.
Для цього використовуються спеціалізовані засоби, які призначені для того, чи іншого аспекту моделювання – так звані CASE-технології. Існують також опрацьовані стандарти в цій області – ER-моделі, UML-діаграми, нотації для опису бізнес-процесів (BPMN, EPC) і т. д.

Важливим моментом тут буде можливість підтримати безперервний процес розробки – з моделі повинна створюватися якась «робоча» частина системи – на основі моделі даних буде створена структура бази даних, на основі UML-діаграми класів – заготовки класів та інтерфейсів для майбутнього програмного коду. Також з боку CASE засоби важливо вміти підтримувати зворотний процес – від коду – до моделі.

І все-таки це ще не код. Це лише перші «мосточки» — каркас – від концепції до майбутнього продукту.

Графічна нотація і моделі – це добре. Але цього не достатньо. Повинно бути якесь опис – як з цим працювати. Так-так – без тексту – нікуди. Тут і з'являється такий артефакт як специфікація.

Хто пише специфікації?
Специфікації пишуть системні аналітики – в частині функціональних аспектів і системні архітектори – в частині системних (загальних, ключових) властивостей компонентів і їх взаємодії.
Специфікація – це, фактично, формалізовані вимоги – детальна постановка задачі для розробника.

Що важливо для специфікації?
Насамперед, дотримати баланс між:
  • точністю, зрозумілістю / і занадто високою детальністю;
  • універсальністю / і простотою;
  • повнотою охоплення / і реалістичністю ресурсів.
Важливий ще один момент.
Як не дивно, специфікація повинна не тільки обмежувати розробника, але і залишати йому деяку свободу — в області, де саме він приймає рішення і несе за нього відповідальність). Зрозуміло, він повинен про це знати.
Для чого це потрібно?
По-перше, важко передбачити і передбачити все заздалегідь. Розробка ПО – досить складна область, з нескінченною варіативністю можливих сценаріїв роботи.
По-друге, якщо цього не робити, то це буде позбавляти «систему» і колектив, який її розробляє, простору для саморозвитку.

Зайва «заорганизованность» позбавляє творчого початку. Людина починає відчувати себе «гвинтиком». А це страшно демотивує. На моїй пам'яті було кілька випадків, коли розробники втрачали інтерес і йшли саме з цієї причини. Як не дивно, при створенні архітектури системи, потрібно передбачати «острівці хаосу» – «острівці свободи» для творчості інших людей.

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

Що ж станеться, якщо не замислюватися про архітектуру підприємства?
Відповідь проста – небудь будуть упущені деякі можливості (втрачений прибуток), або трапляться якісь втрати (додаткові витрати).
Бо якщо ми не заглядаємо в «картину майбутнього», не намагаємося його побачити сьогодні – воно наздожене нас «раптово», але все одно наздожене. Що при цьому буде? Може бути, і нічого страшного не станеться. А може бути, компанія трохи втратить від своєї конкурентоспроможності, а може, трапиться щось більш серйозне, що поставить під удар її основний бізнес. Ми не знаємо цього заздалегідь.
Але надія і «рулетка» — вельми ненадійна стратегія розвитку – як бізнесу, так і ІТ, що забезпечує бізнес.
Елемент випадковості і хаосу, безумовно, буде присутній в будь-якому випадку. Ми не можемо передбачити все. Занадто багато зовнішніх факторів, що впливають на ситуацію.
Але питання – чи ми хочемо зробити його керованим? Чи ми хочемо розширити зону нашого впливу, або покластися на «авось»?

Якщо хочемо, то це вже наступний рівень зрілості – коли є усвідомлення необхідності побудови і управління архітектурою підприємства. У цьому випадку компанія «говорить» собі, що ми готові «подивитися в майбутнє» і сформувати якусь картину – на 1-3-5 років вперед. Зрозуміло, вона буде коригуватися «по ходу п'єси». Але ми повинні усвідомити, які напрямки для нас цінні, у що ми готові вкладатися і чому? Де ми готові ризикнути? Де може бути наше «вау»? Де нам потрібна, перш за все, стабільність, а в чому ми можемо бути трохи «божевільними»? У чому ми хочемо бути більш талановиті, ніж інші компанії, які наші реальні шанси? А де нам просто потрібні перевірені тиражовані рішення?

Одного усвідомлення мало. «Побачити» архітектуру, вибудувати архітектурні процеси (включаючи внесення змін і контролю) не так-то просто. Це не можна назвати «елементарним» (рутинним) дією. І не виключено, що при неправильних рішеннях і некоректних підходах ми можемо нанести швидше за шкоду, ніж користь — і компанія в гонитві за красивою, але не реалістичною картинкою може нести зайві витрати.
Тут в якійсь мірі на допомогу можуть прийти згадані раніше архітектурні фреймворки, які включають в себе як стандарти опису архітектур, так і методологію процесу її розвитку. Опора на них не виключає, але зменшує ризик невдачі в цій непростій справі.
Цінність застосування будь-якого стандарту, будь референсною практики полягає в умінні адаптувати. Будь-яка компанія унікальна. Не існує двох однакових банків, рітейл-компаній, заводів, міських адміністрацій і т. д. Скрізь є своя специфіка – географічна, людська, організаційна, технологічна і т. д. Тому, спроба «зняти кальку» з однієї організації і застосувати подібну практику до іншої, без будь-яких змін – швидше за все, ні до чого доброго не призведе. Можна перейняти певний досвід. Але і його треба адаптувати до своєї компанії.
Побудова корпоративної архітектури – процес творчий, унікальний – як унікальна кожна компанія і люди, які в ній працюють.
Крім того, на архітектурні процеси впливають особливості корпоративної культури компанії – особливо модель прийняття рішень, способи комунікації, інформаційна відкритість і т. д.

Архітектура – це про майбутнє, про людей, про сталий розвиток компанії.
Стало бути, якщо компанія бажає стійко розвиватися, то їй треба починати вкладатися в архітектуру і процеси управління її зміною.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.