«Архітектура ІТ-підприємства»

ЛЕКЦІЯ 2
ІНТЕГРОВАНА КОНЦЕПЦІЯ
ТА РІВНІ АБСТРАКЦІЇ
АРХІТЕКТУРИ
ІТ-ПІДПРИЄМСТВ

Лектор: к.е.н., доцент кафедри комп’ютерної математики та інформаційної безпеки

Корзаченко О.В.
 План лекції

1. Інтегрована концепція архітектури підприємства

2. Рівні абстракції в описі архітектури підприємства
3. Домени архітектури підприємства
4. Моделі архітектури підприємства
5. Архітектура та управління ІТ-портфелем підприємства

2
1.ІНТЕГРОВАНА КОНЦЕПЦІЯ
АРХІТЕКТУРИ
ПІДПРИЄМСТВА

3
Архітектура підприємства

■ Архітектура підприємства є динамічним і потужним інструментом, який

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

4
Моделі архітектури
підприємства
■ Важливою сферою використання архітектурних моделей є систематизація процесу планування ІТ і
забезпечення кращих умов для процесу прийняття рішень.
■ Деякі моделі архітектури підприємства націлені на підвищення рівня деталізації інформації про
підприємство – його цілі і завдання, що реалізуються в корпоративних програмах і організаційній
структурі, системах і даних, технологіях.
5
Переваги побудови
ефективної
архітектури
підприємства
■ Допомагає провести збалансований аналіз інформації про підприємство.
■ Допомагає формулювати нові стратегії.
■ Задає напрям в процесі планування розвитку (це необхідно для того, щоб підприємства відповідали постійно
мінливим умовам господарювання).
■ Забезпечує швидкість реакції та гнучкість, що знаходить відображення у відповідних організаційних формах,
процесах, системах, інформації та портфелі прикладних систем.
6
 Користувачі архітектури
підприємства:
Фахівці в галузі
Системністворення
архітектори, які відповідають за створення архітектури окремих інформаційни
інформаційних систем, які залучені до відповідних
корпоративних проєктів створення важливих для підприємства додатків;

Керівники, які зацікавлені в систематичному, структурованому аналізі

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

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

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

Всесвітня Організація Корпоративної Архітектури

(GEAO, Global Enterprise Architecture Organization) – www.geao.org

8
Контекст та рівні абстракції
архітектури
■ Представлена на слайді 10 схема, запропонована GEAO, ілюструє різні рівні абстракції, пов'язані із описом підприємства.
■ В рамках підприємства є тільки одна архітектура, але при цьому на рівні окремих систем може існувати значна кількість різних
видів архітектури рівня рішень (Solution Architecture).
■ Архітектура підприємства регламентує як аспекти, пов'язані з бізнесом, так і аспекти, пов'язані з ІТ, а також процеси
розвитку, еволюції архітектури, структури управління та контролю за цими процесами (Governance), які забезпечують
перехід від поточного стану архітектури в майбутній бажаний стан.

9
Контекст та рівні абстракції
архітектури Контекст

Розвиток і
Бізнес ІТ
управління

Архітектура підприємства • Масштаб впровадження в цілому

• Високий рівень абстракції
• Soft Skills
Рівні абстракції

Архітектура окремих систем і • Технології підприємства в цілому

рішень • Планування систем
• Структура рішень
• Архітектура програмних систем
Дизайн рішень Розробка рішень
• Технології
• Дизайн програмних систем
• Архітектура окремих компонентів
• Детальний опис технологій
10
 Контекст та рівні абстракції
архітектури Контекст

Розвиток і
Бізнес ІТ
управління
Архітектура підприємстваБачення, Місія Ключові цінності ІТ-стратегія, Стратегія розвитку
ІТ-політика Тенденції Ініціативи
Цілі, Стратегія, Задачі
Високорівнева архітектура інформації, додатків та технологій
Принципи, Напрями
Принципи
Рівні абстракції

Архітектура окремих систем і рішень Плани і схеми розвитку

Аналіз процесів Архітектура інформації, додатків та технології
Функції Угода про рівень обслуговування (SLA)

Дизайн рішень Розробка рішеньСтруктура бізнесу Архітектура ІТ-систем План реалізації проєктів

Розвиток нових форм бізнесу

Розробка ІТ-систем Підтримка супроводу

11
 При описі архітектури
підприємства
надзвичайно
важливу роль мають такі два
поняття:
спектива (Perspective) або рівень
Поданняабстракції
(View) або предметна область, домен а
12
 Домени та рівні
абстракції опису
архітектури

Бі зн ес-ар
хі текту
ра

Архіте ктураі нформ

а ції
Подан
ня
(домени,
предметні
Концепту області)
альн архітекту
Фізи Логі Рі ри
ий
чн чн вень
ріве
ий ий конт
нь
рів рів екст
ен ен у

Архітект
у ра при
кл адних систем

Технол огічна архітек

ту ра

13
Домени архіте
Бізнес-архітектура –
трудові ресурси і процеси

Архітектура інформації –
дані, інформація і знання

Архітектура прикладних
систем

Технологічна архітектура

14
 Рівні абстракції або перспективи
в аналізі архітектурних областей (доменів)

Концептуальний рівень або «бачення загальних вимог» – орієнтований на власників бізн

Рівень контексту – орієнтований на бізнес- керівництво

Логічний рівень
Фізичний рівень
– орієнтований ната рівень реалізації
архітекторів і проектувальників
– орієнтований
систем на проектувальників і розробни

15
 Відповідає на питання: «Для чого необхідна така архітектура і в чому полягає
Контекст (Чому?) загальний контекст?»

Безпека
Керівні принципи
Інтегрована концепція

Бізнес- архітектура Архітектура Архітектура додатків

Техно- логічна архітектура
інформації

Відповідає на питання: «У чому полягають загальні вимоги та яке

Концептуаль
н ий рівень че
або Ба ння загальних вимог (Що?) бачення рішення?»

Відповідає на питання: «Як ці вимоги можуть бути реалізовані?»

Логічний
рів ень (Як?) Відповідає на питання: «За допомогою яких рішень та
ідприємства

стандартів можна побудувати це рішення?»

Відповідає на питання: «За допомогою яких технологій та
Фізичний
рів ень (Як?) програм можна побудувати це рішення?»
16

Рівень реал і зації (Як?)

17
2. РІВНІ АБСТРАКЦІЇ
В ОПИСІ
АРХІТЕКТУРИ
ПІДПРИЄМСТВА
18
1.Рівень контексту

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

19
Питання, на які повинен
давати відповідь рівень
контексту:
■ Яких цілей хоче домогтися підприємство?
■ Чому підприємство займається таким бізнесом: бачення, місія та цілі?
■ Які тенденції у галузі, в якій працює підприємство?
■ Як підприємство розташоване і де воно працює географічно?
■ Які фактори визначають досягнення високих результатів у бізнесі (Value
Drivers)?
■ Якою інформацією оперує підприємство?
■ Які функції бізнесу?
■ У яких областях зосереджена ключова компетенція підприємства?
20
Призначення рівня
контексту
■ Рівень контексту забезпечує основу для всього процесу проектування архітектури з точки зору основної
діяльності та бізнесу підприємства в цілому.

21
2. Концептуальний рівень

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

22
Ключові питання, які
розглядаються на
концептуальному рівні (1):

■ Які області бізнесу повинні бути підтримані інформаційними технологіями?

■ Яка загальна бізнес-архітектура (наприклад, «фронт-офіс», «мідл-офіс»,
«бек-офіс») буде використовуватися?
■ Як системи будуть співвідноситися з організаційними структурами і бізнес- архітектурою, наскільки інформаційні системи окремих департаментів
будуть консолідовані в єдиний набір ключових прикладних систем?
■ Як виглядають бізнес-процеси, які забезпечують виробництво товарів і надання послуг?
■ Яка інформація потрібна для кожного бізнес-процесу і як ця інформація
може повторно використовуватися?
23
Ключові питання, які
розглядаються на
концептуальному рівні (2):
■ Який рівень делегування повноважень повинні забезпечувати системи?
■ Які існують загальні принципи щодо використання технологій, характерні для галузі, в якій працює підприємство, і типи послуг, що надаються?
■ Які питання з нагляду та керівництва використання технологій повинні бути
розглянуті на даному етапі?

24
Приклад
концептуального рівня
■ Концептуальний рівень опису архітектури певної прикладної системи використовується для визначення бізнес-вимог і відображає погляд на
систему з точки зору бізнес-користувача, тобто реалізованих функцій.
■ Для цього створюється бізнес-модель додатку. Основне завдання на етапі концептуального проектування і створення бізнес-моделі
полягає в описі ключових бізнес-процесів і даних таким чином, щоб підкреслити цілі і вимоги з точки зору бізнесу в формі, вільній
від опису технологій, що застосовуються .
■ В якості методів, які використовуються для побудови бізнес-моделей на етапі концептуального проектування, можуть бути,
наприклад, такі інструменти мови UML, як Варіанти використання (Use Cases), Діаграми
діяльності та інші методи проектування процесів.

25
3. Логічний рівень

■ Логічний рівень архітектури показує основні функціональні компоненти і їх взаємозв'язок без технічних деталей того, як на практиці
реалізована функціональність цих компонент.
■ Логічний рівень є «останнім» рівнем, який ізолює вимоги бізнесу від виконання цих вимог технологіями. Він визначає класи
прикладних систем, технологій і даних, але не в термінах конкретних продуктів і технологічних рішень.
■ Логічні моделі відповідають на питання про те, як вимоги, що ідентифіковані в концептуальних моделях, будуть
реалізовані. На цьому рівні визначаються загальні принципи, які будуть накладати певні обмеження на рішення, що приймаються на
нижчих рівнях (наприклад, орієнтація на технології web-сервісів).

26
Ключові питання, які
розглядаються на логічному
рівні:
■ Які програми потрібні для підтримки бізнес-процесів?
■ Хто є основними користувачами і зацікавленими сторонами в реалізації
даних прикладних систем?
■ Як виглядають нормалізовані моделі даних для цих додатків?
■ Які прикладні системи потрібні для управління даними: створення, читання, внесення змін і видалення даних?
■ Які технології потрібні для реалізації цих прикладних систем?
■ Як буде виглядати розподілена архітектура прикладних систем?
■ Які стандарти повинні бути прийняті підприємством?
27
Призначення логічного рівня

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

28
Особливості логічного рівня

■ Він може змінюватися, щоб відображати ініційовані зміни

«зверху-вниз», включаючи нові фундаментальні бізнес-моделі (наприклад, переорієнтація на модель
обслуговування, засновану на потребах клієнта), а також відображати зміни, ініційовані в напрямку «знизу-
вгору», такі як можливості, що відкриваються у зв'язку з використанням нових технологій (наприклад,
застосування CRM-системи для управління відносинами з клієнтами).
■ Зміни можуть бути пов'язані з новими технологічними парадигмами і концепціями, такими, наприклад, як
сервіс- орієнтована архітектура або Grid-обчислення.
29
Ключовими питаннями, які
повинні бути вирішені на
цьому рівні, є такі:
■ Як повинні бути згруповані логічні компоненти (наприклад, чи повинен використовуватися єдиний каталог користувачів для забезпечення єдиного сервісу
реєстрації, незалежно від використовуваних каналів взаємодії)?
■ Як логічні компоненти будуть розподілені між різними системами (чи будуть ці компоненти реалізовані у вигляді web-сервісів)?
■ Як єдина шина інтеграції буде забезпечувати різні бізнес-системи, або як засобу забезпечення спільної роботи будуть використовуватися крім баз
даних і засобів інтеграції для того, щоб забезпечити роботу віртуальних груп співробітників?

30
Логічний рівень (приклад)

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

31
4. Фізичний рівень

■ Фізичний рівень описує принципи проектування, стандарти і правила, включаючи групування

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

32
Питання, на які відповідають на
фізичному рівні абстракції:
■ Які функціональні специфікації кожної прикладної системи?
■ Чи буде підприємство розробляти спеціалізовані додатки або купувати стандартні?
■ Які критерії вибору і як будуть оцінюватися різні ініціативи щодо реалізації систем?
■ Як дані будуть представлені на фізичному рівні?

33
5. Рівень реалізації

■ Рівень реалізації, найнижчий рівень або перспектива в описі архітектури системи, формується розробниками системи в
термінах використання тих чи інших продуктів певних постачальників.
■ Тобто модель реалізації включає конкретні моделі обладнання, топологію мережі, виробника і версію СУБД, засоби
розробки і, власне, готовий програмний код.
■ На рівнях фізичної архітектури і рівні реалізації для прискорення циклу розробки, підвищення якості розроблюваних систем (за рахунок
використання перевірених рішень) та сприяння зменшенню ризиків проекту можуть використовуватися такі концепції
і архітектурні моделі, як, наприклад, Microsoft Systems Architecture (MSA).
34
Приклад розгляду системи на
різних рівнях абстракції
Рівень абстракції Рівень деталізації
Контекст o Підприємство представляється у вигляді «чорної скриньки» і є
центральною «дійовою особою» (фактором).
o Бізнес моделюється з точки зору зовнішніх для бізнесу факторів.
o Моделюються тільки бізнес-взаємодії, засоби ігноруються.
Концептуальний o Моделюються потоки бізнес-процесів, ідентифікованих на концептуальному рівні.
o Система, яка реалізує процеси, є центральним актором у формі «чорної скриньки».
o Бізнес-процеси моделюються з точки зору зовнішніх для системи факторів. Розглядаються засоби комунікацій, що використовуються для
виконання
транзакцій.

Логічний o Моделюється внутрішня архітектура системи.

o Основні компоненти системи є основними факторами.
o Поведінка системи моделюється з точки зору внутрішніх для системи
«чорних скриньок».
Фізичний o Моделюється фізична структура реалізації системи. 35
3. ДОМЕНИ АРХІТЕКТУРИ
ПІДПРИЄМСТВА

36
Основні домени (предметні
області) архітектури (1)
1. Бізнес-архітектура (Business Architecture). Описує діяльність
підприємства з точки зору його основних
бізнес-процесів. Використання бізнес-архітектури надає спільний погляд на діяльність ІТ та бізнес-фахівцям, а
також керівництву. Крім того, моделі бізнес-архітектури допомагають у разі необхідних змін (реінжинірингу,
автоматизації чи інших модифікацій) певних бізнес-
процесів при одночасному переході існуючої архітектури підприємства на спільну.
Основні домени (предметні
області) архітектури (2)
2. Архітектура інформації (даних) (Information
Architecture). Визначає, які дані необхідні для
підтримки бізнес-процесів (наприклад, модель даних) під час обслуговування потреб обміну інформацією
користувачів, а також для забезпечення стабільності та можливості довготривалого використання цих даних в
прикладних системах. Архітектура даних (Data Architecture) - стосується
підходу до даних, великих даних, а також їх обсягу та швидкості.
Основні домени (предметні
області) архітектури (3)
3. Архітектура додатків (Application Architecture). Визначає
різні бізнес-програми та сервіси з точки зору моделей компонентів та фіксує рамки й архітектурні
шаблони, що використовуються при їх створенні.
Основні домени (предметні
області) архітектури (4)
4. Технологічна архітектура (інфраструктура або системна
архітектура). Визначає, які технології (апаратне та системне ПЗ, мережі та комунікації) необхідні для створення
середовища роботи додатків. Це середовище має забезпечувати роботу
прикладних систем на заданому рівні надання сервісів своїм користувачам. ЇЇ умовно можна розділити на:
■ архітектуру інфраструктури (Infrastructure Architecture), яка презентує фізичні
мережі зв'язку та пов'язані з ними елементів управління (концентратори, маршрутизатори та комутатори);

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

■ Архітектура інтеграції (Integration Architecture) визначає інфраструктуру,

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

■ Архітектура впровадження (Implementation Architecture) детально

описує реальну реалізацію бізнес -додатків з використанням технологій, прийнятих підприємством, як вони зазначені у
технічній архітектурі.
■ Архітектура науки (Science Architecture) займається наданням
вебпослуг, мікросервісів та послуг знань.
■ Архітектура безпеки.

42
 Інші домени архітектури (3)

■ Мережева архітектура визначає опис, правила, стандарти, які пов'язані з мережевими і

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

■ Як окрему область, дуже часто виділяють архітектуру процесів управління

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

а операцій (управління ІТ)

Бізнес-архітектура

Архітектура інформації (даних)

Архітектура додатків

Технологічна архітектура
(інфраструктура: апаратне і
програмне забезпечення, комунікації )
4. МОДЕЛІ АРХІТЕКТУРИ
ПІДПРИЄМСТВА

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

Концептуаль- Сценарії використання (use Семантичні моделі, моделі Деталізація моделей до Моделі бізнес- логістики, операційні
ний рівень case), моделі зв’язків сервісів вимоги, архітектура розміщення
(власник) бізнес-процесів елементів центру оброблення даних
Моделі опису архітектури
підприємства (2)
Бізнес- Архітектура Архітектура Технологічна
Домени
архітектура інформації додатків архітектура
Перспективи (рівні абстракції)

Логічний Моделі процесів (потоків Логічні моделі даних, схеми Визначення сервісів, Логічні типи серверів: БД, поштові,
(проектуваль- ник) робіт), моделі бізнес- даних, взаємозв'язки між сервісами, транзакційні.
подій, модель специфікації документів моделі класів Географічний розподіл серверів,
розміщення хостинг ПЗ
процесів,
визначення ролей

Фізичний Специфікації Фізичні моделі даних, схеми БД, Код програм, опис інтерфейсів Фізичні сервери, топологія фрагментів
(розробник) процесів, моделі інтеграції процесів, код доступу до даних, довідник мережі, мапування
опис ручних даних продуктів на сервіси
процедур, стандарти якості та додатки
Побудова архітектури
підприємства
■ Побудова архітектури підприємства полягає в
поступовому уточненні моделей, тобто в «заповнені» елементів цієї матриці, починаючи з лівої верхньої
області (в цій частині формуються і бізнес-вимоги), в напрямку правої нижньої області (в цій частині
описується код програм, які розміщуються на серверах центрів обробки даних).
Види моделей архітектури

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

■ Немає однієї універсальної технології створення моделей архітектури підприємства.

■ Є значна кількість методик і засобів моделювання, які можуть успішно застосовуватися для розробки
моделей різних доменів архітектури підприємства.
 5. АРХІТЕКТУРА ТА
УПРАВЛІННЯ ІТ-ПОРТФЕЛЕМ
ПІДПРИЄМСТВА

53
Управління портфелем ІТ

■ Під управлінням портфелем інформаційних технологій розуміється процес

відбору, управління та оцінки інвестицій, пов'язаний як з ІТ-активами, так і з портфелем ІТ-проєктів.
■ Управління портфелем ІТ-активів дозволяє підприємствам категоризувати, оцінювати, розставити пріоритети,
купувати і управляти ІТ-активами і проектами відповідно до поточних і майбутніх потреб бізнесу з урахуванням
прийнятного ступеня ризику.

54
Управління ІТ-портфелем має
на меті:
■ максимізацію цінності (вартості) портфеля,
■ синхронізацію портфеля ІТ з цілями бізнесу і
■ пошук оптимального балансу між ризиком і потенційною віддачою від портфеля ІТ.

55
Ефективне управління
портфелем ІТ
Ефективне управління портфелем інформаційних технологій на
рівні підприємства в цілому повинно забезпечуватися за рахунок спільного використання:
■ стратегії і планування на рівні підприємства,
■ архітектури підприємства,
■ управління ІТ-програмами і проєктами.

56
ІТ-програми та проекти

■ ІТ-програми та проєкти – це основний механізм реалізації архітектури в рамках обраної

стратегії.
■ Управління ІТ-програмами і проєктами пов'язане (1) з навичками управління портфелем
взаємопов'язаних програм і проєктів на корпоративному рівні; (2) з управлінням процесами,
фінансовими і людськими ресурсами, які потрібні для реалізації проєктів; (3) з управлінням графіками реалізації
проєктів тощо.

57
ІТ-програми та проєкти

■ Управління ІТ-програмами / проєктами і архітектура підприємства взаємно доповнюють один одного,

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

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

59
Інтеграція
ключових
процесів Стратегія і планування на рівні
управління ІТ підприємства

підприємства
Управління
портфелем
ІТ

Управління корпоративними
ІТ-програмами і проектами
Архітектура підприємства

60
Архітектура, ІТ-проєкти, ІТ-
активи Портфель наявних активів

Бізнес-
■ Співвідношення між поточним станом архітектура
Портфель ІТ-
проєктів
архітектури підприємства (As-Is, «як є»),
майбутнім бажаним станом архітектури (To- Архітектура
інформації
Be, «як має бути»), портфелем ІТ- активів і
портфелем ІТ-
Архітектура
проєктів додатків

Технологічна архітектура
(інфраструктура)

Архітектура «As-Is»
Архітектура «To-Be»

61
а ІТ- архітектури та ІТ-стратегії

62
ДЯКУЮ ЗА УВАГУ!

63