Архітектура та ІТ

Американський архітектор Френк Гері говорив, що

У моди є позитивні і негативні сторони. У моді на ІТ-архітектури добре те, що всмак погравши поняттям архітектури, ІТ-спільнота і «зацікавлені особи» виробили більш-менш подібний погляд. А погано те, що з модою до цікавої ідеї прилипає безліч «черепашок», що спотворюють її сенс. Обліплена ними ідея стрімко опускається на дно суспільної затребуваності, де і покоїться, поки ту чи іншу течію знов не підніме її на поверхню. При цьому - на жаль! - якість затонулої ідеї не має значення. Ажіотажна мода «на архітектуру» може привести до того, що необхідний для ІТ підхід ухнет на пару років в темряву псевдонаукових статей. Вже зараз при оповіданні про архітектуру часто доводиться ловити «скляні» погляди слухачів, в яких читається «а навіщо мені це треба?». Але архітектура як універсальна повноцінна модель підприємства необхідна для сучасних ІТ.

Про яку архітектурі йдеться? Множиться кількість визначень архітектури підприємства (Enterprise Architecture), але всі вони зводяться приблизно до наступного:

• архітектура описує компоненти системи і їх взаємозв'язку;
• архітектура включає в себе принципи розвитку, вдосконалення і підтримки.

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

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

Як описати архітектуру - повну модель системи? Для опису нерухомого та неживого предмета досить трьох проекцій. При описі будівлі використовують окремі архітектурні проекції і розрізи, плани поверхів, зображення фасадів і панорамні види. Описуючи ІТ (або їх окремий компонент - програмну систему, базу даних і т.п.) тільки в якомусь одному ракурсі, ми будуємо відповідну проекцію. Можна розробити проекції на основі точок зору, властивих різним групам співробітників всередині компанії і її партнерам. Це власник компанії, керівники підрозділів, співробітники та ІТ-фахівці, користувачі і адміністратори програмних систем, проектувальники баз даних і їх адміністратори, співробітники відділу закупівель, клієнти і т.п. Таких проекцій може бути дуже багато. Навіть якщо ми шляхом довгих зусиль опишемо їх, то отримаємо абсолютно не потрібну модель, сприйняти яку нормальна людина не зможе. Що ж робити?

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

Будемо називати проекцією відображення погляду на систему з деякою точки зору, а повної проекцією - вичерпний опис певного погляду на систему. Опис архітектури є сукупністю окремих проекцій, яка утворює архітектурну модель, з тим або іншим ступенем повноти описує систему. Будь-яку систему можна повністю описати за допомогою якогось кінцевого числа повних проекцій. Сукупність проекцій, повністю і вичерпно описують систему, назвемо повної архітектурної моделлю ( «повністю» в даному випадку означає, що будь-яку іншу проекцію вдасться побудувати на основі даної архітектурної моделі). Архітектурна (в широкому сенсі слова) наука пропонує нам повну модель Захмана (див., Наприклад, О. Полукеев, Д. Коваль, «Моделювання бізнесу і архітектура інформаційної системи» // СУБД, 1995, № 4). Відомі архітектурні моделі (строго кажучи, нотації опису архітектурних моделей) легко укладаються в цю модель. У світлі введених нами визначень рядки і стовпці моделі Захмана є проекціями: рядки - з точки зору груп зацікавлених осіб, стовпці - з точки зору областей розгляду (що, хто, як, коли, де і навіщо).

Зупинимося на повноті моделі Захмана. Якщо з рядками (із зацікавленими особами) все більш-менш зрозуміло і повнота залежить від грамотного виділення таких груп, то за допомогою стовпців справа дещо складніша. Чи завжди досить цих питань? Наприклад, з розгляду випав важливе питання «скільки коштує?». Крім того, модель Захмана передбачає статику, і без «пожвавлення» її додаткової проекцією, що характеризує динаміку, просто не обійтися. А оскільки предмети, що рухаються з постійною швидкістю, досить рідкісні, то треба знати ще й прискорення. Або, як варіант, застосувати до руху моделі Захмана її ж парадигму 5W + 1H: що рухається (тут підійде статична модель), хто рухає предмет, як він рухається (по якій траєкторії), коли відбувається рух, яка його мета і де воно відбувається .

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

Ризикнемо запропонувати варіант заповнення елементів таблиці Захмана ( табл. 1 ). Рядки в цій таблиці відрізняються від класичної інтерпретації моделі і додані два стовпці.

Таблиця 1.

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

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

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

Обговоримо іншу позицію: будь-який об'єкт може розвиватися стихійно або планомірно. Стихійне розвиток дозволяє підлаштовуватися під зміни навколишнього світу, але загрожує авралами і помилками. Планомірний розвиток, на жаль, часто відривається від реальності і при зайвому упертості (або ажіотажі, захопленості, прямолінійності, вузьколобості) загрожує привести до плачевного результату. Як завжди, істина знаходиться посередині, а сформулювати її можна так: необхідно планомірний розвиток, що дозволяє гнучко реагувати на зміни навколишнього оточення. Однак стихійне розвиток ІТ зовсім не заперечує важливості архітектурного підходу - як раз навпаки. Хоча б тому, що при певній складності ІТ ви просто не зможете визначити, як реагувати на зміни.

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

Таблиця 2.

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

Потім йде активно розвивається шар, який представляє собою матеріал побудови функціонального програмного забезпечення (СУБД, сервери додатків, технологічні програми). Наступний шар - структура і формати даних. За ним слідують шар додатків і, нарешті, шар сервісів, що надаються користувачам.

Тепер застосуємо всі ці проекції до кожного шару моделі Захмана ( таблиця 3 ). Виходить, що в моделі «листкового пирога» технологічної проекції зміст елементів таблиці більш одноманітно.

Таблиця 3.

Функціональна проекція охоплює бізнес-процеси ІТ. Вона виросла з шпальти «Як» моделі Захмана при описі ІТ-архітектури. «Листковий пиріг» тут менш звичний, але ми спробуємо також застосувати до нього модель Захмана ( таблиця 4 ). У сукупності технологічна і функціональна проекції мають властивість повноти опису ІТ.

Таблиця 4.

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

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

ITIL і COBIT пропонують перевірені часом архітектурні моделі, які також можна використовувати для опису архітектури компанії. До речі, багато елементів їхньої архітектури, такі як Business Continuity, SLA, Help Desk, були задіяні в наведених таблицях. Наприклад, ITIL можна представити у вигляді ієрархії наступних шарів: бізнес-перспектива, надання сервісів, їх підтримка, управління додатками, управління інфраструктурою. А COBIT являє собою поєднання елементів планування та організації, комплектації і впровадження, функціонування та обслуговування, моніторингу та контролю.

А тепер ще кілька зауважень, навіяних класичною архітектурою.

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

Зручність. Андреа Палладіо, архітектор і теоретик архітектури, писав: «Зручним буде називатися той будинок, який відповідає положенню свого мешканця і окремі частини якого знаходяться відповідно один з одним і з цілим». Чи часто ми замислюємося про зручність, коли говоримо про ІТ? В результаті замість хмарочоса нерідко отримують хатинку, правда, в хатинці іноді буде затишніше, ніж в хмарочосі. Тому архітектура ІТ залежить не тільки від вимог бізнесу, але і від конкретних користувачів і їх уявлень про зручність.

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

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

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

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

Марина Аншина ( [email protected] ) - директор департаменту програмного забезпечення компанії ISG (Москва).