Визначення меж архітектури і використовуваних методик
Наступний важливий елемент, з яким необхідно визначитися, - це кордону архітектури. Наприклад, якщо ви відповідаєте за розробку архітектури електронного уряду на регіональному, міському рівні, то, можливо, ви свідомо зосередите основні зусилля в розробці архітектури на питаннях, пов'язаних з міжвідомчим інформаційною взаємодією (як, наприклад, це зроблено в проекті e-GIF проекту електронного уряду Великобританії).
Якщо ви вирішили, що архітектура підприємства повинна зачіпати ваших партнерів і постачальників, то, отже, це потребуватиме певного участі їх представників у роботі. Або навпаки, ви свідомо виберете якусь частину підприємства, найбільш важливу в якомусь сенсі, і тільки частина бізнес-процесів організації.
Припустимо, що команда проекту розробки архітектури сформована і готова почати свою роботу. Як і для традиційних проектів, перш за все слід забезпечити формалізацію цього процесу шляхом складання і затвердження статуту проекту. Такий статут визначає завдання проекту, графік виконання, використовуваний підхід і процедури, а також фіксує той факт, що ця діяльність підтримана керівництвом організації. Відповідно, такий статут повинен буде періодично, зазвичай раз на рік, переглядатися і затверджуватися Керуючим комітетом організації. Більш детально питання управління розглядаються нижче в "Процес розробки архітектур: управління і контроль, Gap-аналіз, впровадження".
При переході до практичної реалізації очевидно, що для досягнення кінцевої мети необхідно попередньо визначити деяку узгоджену основу. В якості такої основи може виступити набір архітектурних моделей високого рівня [6.11]. В "Елементи Архітектури підприємства. Бізнес-архітектура та архітектура інформації" ми дали докладний опис того, як високорівневі моделі бізнес-процесів можуть використовуватися на початковому етапі робіт.
Ще раз варто підкреслити, що на даному етапі не слід заглиблюватися в зайву деталізацію. Навпаки, більш важливим є "розширення" області охоплення. При цьому тимчасові рамки етапу також повинні бути чітко визначені і обмежені - так, що навіть для великих компаній термін реалізації етапу з урахуванням обговорень і узгоджень не повинен перевищувати трьох місяців, а для дрібних і середніх - значно менше.
Іншим важливим завданням початкового етапу буде вибір і узгодження всередині команди найбільш придатною методики або моделі (framework) для детального опису архітектури. Раніше в "Методики опису архітектур. Моделі Захмана і Gartner, методики META Group і TOGAF". "NASCIO. Моделі" 4 + 1 "і SAM. Методики Microsoft та інші. Вибір" оптимальної "методики" ми вже розглянули декілька поширених методик і навіть вказали деякі порівняльні характеристики. Якоїсь однієї, обов'язковою до застосування методики не існує - кожна організація має право вибирати ту, яка найбільш для неї зручна. Найбільш доцільним буде вибір однієї з методик в якості основної з доповненням елементів інших методик. Необхідним кроком буде документування обраного рішення (або точніше, обраного підмножини) з тим, щоб це короткий, не більше ніж на 10 сторінок, опис могло бути використано командою проекту в якості методологічної основи.
Іншими важливими документами, які будуть використовуватися в якості основи, є:
- стратегія комунікації, тобто поширення інформації за проектом всередині організації з урахуванням потреб в інформації усіх зацікавлених учасників - тобто, з самого початку проекту необхідно передбачати кроки для забезпечення впровадження його результатів, як це описано нижче в "Процес розробки архітектур: управління і контроль, Gap-аналіз, впровадження ";
- процедури розгляду і розбору виняткових ситуацій і відхилень від стандартів архітектури.
- ретельне планування;
- адекватне фінансування і забезпечення ресурсами (учасники, час);
- мотивація і реалізація ( "батіг і пряник");
- талант і кваліфікація команди;
- бачення мети.
Реальний ефект досягається за рахунок синергетичного поєднання всіх цих елементів, так що відсутність або недостатність окремих частин може призводити до наступних варіантів невдач:
- недостатнє фінансування і брак ресурсів, як правило, призводить до того, що проект обмежується рішенням тактичних задач на рівні ІТ-служби, типу вибору версії того чи іншого продукту без урахування реальних бізнес-потреб. Майбутня архітектура буде нечітко визначена і не дозволить отримати реальну віддачу при практичній реалізації;
- недостатня мотивація персоналу команди може бути пов'язана з відчуттям "роботи на полицю" - якщо розроблені архітектурні рішення не будуть підтримані відповідними організаційними заходами і політикою реалізації на практиці;
- страх перед змінами - пропоновані рішення не повинні сприйматися як неможливі. Пропоновані зміни повинні бути підтримані відповідним розвитком кваліфікації;
- розпорошеність - зміни, як правило, є досить болючими і тому будуть об'єктивно затягуватися під різними приводами без прийняття відповідних заходів. Важливим є чітке фокусування на кінцевій, яка визначається баченням, цілі, - інакше багато реалізовані ініціативи можуть бути проведені даремно.
Орієнтовна структура опису ІТ-архітектури
Звичайно, важливо з самого початку визначити формат і структуру опису архітектури. Наведений нижче як приклад формат документа може бути найбільш корисним, перш за все, для малих і середніх компаній і відносно нескладних інформаційних систем.