Багато компаній вже усвідомили необхідність планування розвитку не тільки бізнесу, а й ресурсів, необхідних для його підтримки. Налагодження оптимального взаємозв'язку бізнесу та ІТ неможливо без планування ІТ-стратегії, узгодженої з завданнями та цілями організації. Один з інструментів забезпечення такої узгодженості - сервісна архітектура, що застосовується при проектуванні і реалізації програм. Однак успіх вопрлощенія цього підходу в корпоративних інформаційних системах залежить від планування і проектування архітектури додатків або, якщо піднятися на один щабель вище, від планування і проектування архітектури підприємства в цілому.
архітектура підприємства
Архітектура підприємства (Enterprise Architecture, EA) - це концепція, що описує поточний і цільове стан архітектури додатків, бізнес-процесів, ІТ-інфраструктури, узгоджених з бізнес-стратегією компанії. Вона також описує механізми організації, управління і ведення архітектури, плани по переходу до цільового стану. Архітектура підприємства є спробою побудувати систему управління підприємством «зверху вниз». Є безліч різних моделей, що дозволяють вибрати найбільш оптимальний варіант здійснення подібної трансформації, частина з них пропонує різноманітні версії структури архітектури підприємства (метамоделі), розкриті в моделях Захмана (Zachman Framework) або в моделі US Federal EA, інші описують підхід до побудови архітектури підприємства ( TOGAF). Компанія SAP розробила методологію ведення архітектури підприємства SAP EAF на базі TOGAF, яка орієнтована на інтерпретацію і підтримку реалізації цілей компанії за допомогою планування і ведення спеціалізованих описів і уявлень в наступних областях: бізнес-архітектура (в тому числі бізнес-процеси, організаційна структура); архітектура додатків; архітектура даних; технічна архітектура. Основне призначення SAP EAF - прискорення розробки архітектури підприємства і зниження її трудомісткості.
В рамках методології створюється ряд взаємозв'язаних діаграм, що описують поточний і цільове стан компанії, а також план проведення змін. SAP EAF передбачає також постановку процесу з безперервного управління архітектурою підприємства і повну реалізацію циклу управління архітектурою підприємства.
Можна виділити три рівні архітектури: архітектура підприємства, архітектура корпоративних (наскрізних) додатків і архітектура додатків ( Мал. 1 ).
Архітектура підприємства розглядає ландшафт підприємства в цілому, визначає структуру, контекст і стандарти організації, підтримує корпоративну стратегію, планує розвиток бізнес-процесів та ІТ-систем. Горизонт планування архітектури підприємства становить зазвичай три-п'ять років. В рамках архітектури підприємства розробляється бачення і визначаються можливості і «розриви» в ландшафті, а також розробляється план переходу і план міграції, що включає нові рішення і проекти.
Архітектура корпоративних додатків орієнтована на підтримку рішення одним із стратегічних завдань в перспективі до двох років, включає в себе відповідні проекти по реалізації ІТ-систем. Один з підходів, який можна використовувати для підтримки стратегічних перетворень, базується на ідеях сервісної архітектури (Service-Oriented Architecture, SOA), його успіх багато в чому залежить від того, наскільки точно архітектор розуміє зв'язок ІТ-ландшафту з бізнес-процесами і цілями впровадження окремих компонентів ландшафту. Інакше виникає ризик створення і впровадження ефективного механізму інтеграції додатків на базі сервісів без отримання будь-яких бізнес-вигод.
Планування архітектури додатку орієнтоване на перспективу до року і підтримує тактичні проекти. Архітектура програми описує рішення і реалізацію конкретної ІТ-системи, відображає виконання відповідного кроку плану трансформації і реалізацію одного з проектів.
Підхід з планування та проектування архітектури на базі методології SAP EAF підтримує розробку архітектури на кожному з перерахованих рівнів.
SOA
Якщо переходити до архітектури конкретних програм, то можна побачити різноманітність різних типів архітектур, що використовуються при побудові інформаційних систем. Серед них все більшої популярності набуває сервісна архітектура додатків. Концепція сервісної архітектури існує вже давно, але далеко не завжди її застосування веде до успіху - багато що залежить від обраного підходу до ведення та управління архітектурою підприємства в цілому.
Прикладна логіка реалізується в SOA-додатках так само, як і в звичайних, а для доступу до функцій додатків використовується спеціальна «обгортка» у вигляді Web-сервісу, що дозволяє викликати дану функціональність з інших додатків і підсистем. При цьому SOA розглядається не тільки як архітектура для розгортання і виконання розподілених прикладних рішень, але і як модель програмування, в якій архітектура додатка будується на основі сервісів, що надаються іншим додаткам в мережевому середовищі за допомогою опису і публікації відповідних інтерфейсів. Однак концепція SOA не дає точного опису, як саме повинні взаємодіяти сервіси, як домогтися того, щоб вони розуміли один одного і могли бути інтегровані.
Сервіси в SOA можуть являти собою прості або складні об'єкти, процеси взаємодії деякого безлічі об'єктів, процеси, що складаються в свою чергу з декількох процесів, або навіть якийсь комплекс додатків, які в сукупності призводять до отримання єдиного результату. Важливо, що з точки зору архітектури сервіс (незалежно від внутрішньої структури і мови реалізації) виглядає як єдине ціле.
До сервісів можна віднести елементи, які: є затребуваною функцією додатка або системи; є виконуваною функцією; задовольняють політиці і вимогам до якості сервісу - забезпечують масштабованість, надійність, дотримання угоди про рівень обслуговування.
Для того щоб почати перехід до сервісної архітектурі, необхідно визначити процеси та додатки, які найбільше підходять для використання даної концепції. Для цього в SAP рекомендують аналізувати архітектуру підприємства в цілому, причому від рівня деталізації опису бізнес-процесів, ІТ-систем і даних, які виконуються в рамках проведеного аналізу, залежить опрацювання потенційних сервісів, опис їх операцій і політик. Це дозволить коректно відобразити і реалізувати цільові бізнес-процеси і потреби користувачів в ІТ-системах.
При ідентифікації сервісів необхідно звертати увагу на такі риси бізнес-процесу, які допоможуть відрізнити сервіси від звичайних операцій процесу та визначити потенційних кандидатів на роль сервісів:
- можливість повторного використання функціональності;
- ступінь стандартизації прикладної функціональності;
- ступінь автоматизації операцій сервісу, в якому не повинно бути задач, які виконуються вручну;
- прийнятна вартість реалізації;
- можливість синхронного взаємодії додатків; для реалізації асинхронного взаємодії, як правило, використовується корпоративна сервісна шина (Enterprise Service Bus, ESB).
В рамках архітектури підприємства виділяють два підходи: бізнес-уявлення SOA і її технічне уявлення. Технічне уявлення - це SOA в класичному розумінні, а бізнес-уявлення введено в рамках концепцій SAP EAF і TOGAF, і направлено воно на те, щоб виявити нові можливості бізнесу, застосовуючи концепцію SOA, і використовувати їх для успішного розвитку підприємства, а також при реалізації нових продуктів і послуг. Бізнес-сервіс - це компонент, який:
- виконується вручну або є автоматизованим;
- виконується в рамках підприємства або переданий на аутсорсинг;
- доступний для співробітників підприємства, партнерів, клієнтів і постачальників;
- виконується в рамках відповідної організаційної одиниці або на рівні корпоративного центру компетенцій;
- має угоду про рівень обслуговування (Service Level Agreement, SLA).
Прикладами бізнес-сервісів можуть служити електронна пошта, call-центр, ІТ-підтримка в режимі онлайн, енергопостачання, централізовані закупівлі і ін. Виділення бізнес-сервісів дозволяє визначити бізнес-модель підприємства, яка накладає обмеження на сервісні операції, інтерфейси і визначає угоду про рівень обслуговування. Крім того, така формалізація бізнес-процесів істотно полегшує роботу розробника SOA-рішень.
ІТ-стратегія, архітектура підприємства і SOA
Зрілі компанії досить чітко описують поточний стан архітектури підприємства (тобто в класичному варіанті стан бізнес-архітектури, архітектури додатків, архітектури даних, технічної архітектури) і необхідні організаційні процедури і процеси управління. Однак концепція архітектури підприємства охоплює лише частину ІТ-стратегії ( Мал. 2 ), А SOA є однією з концепцій рівня архітектури корпоративних додатків і допомагає створювати корпоративні програми на основі принципів, закладених в архітектуру підприємства.
Архітектура підприємства покриває частину важливих для ІТ-стратегії компонентів, залишаючи за рамками елементи стандартних для ІТ-департаменту процедур планування, принципів і методів управління, організації діяльності та підтримки. З іншого боку, в сучасних організаціях, де немає чітко виділеного процесу ведення архітектури підприємства, відсутні архітектори (бізнес, технічні та корпоративні), - в кращому випадку функції технічних архітекторів розподілені між кількома фахівцями.
Характерною ілюстрацією відмінності проектів з побудови ІТ-стратегії та архітектури підприємства є те, наскільки велика увага приділяється опрацюванні принципів управління ІТ-ресурсами при формуванні ІТ-стратегії, в той час як при проектуванні архітектури підприємства ведеться розробка відповідних документів тільки для групи архітекторів. Таким чином, концепція архітектури підприємства орієнтована на підтримку організації в частині ефективного планування та управління ІТ-процесами. Ця концепція повинна допомогти в побудові ефективної системи управління підприємством і спростити завдання ІТ-директора з управління і розвитку інформаційних технологій в рамках компанії.
ІТ-стратегія є важливим компонентом управління, планування і розвитку інформаційних технологій в рамках підприємства. Для того щоб допомогти організаціям у веденні і управлінні ІТ, з'явилася концепція архітектури підприємства, яка включає в себе компоненти управління ІТ-ландшафтом, ІТ-інфраструктурою, процедури ведення і зміни архітектури підприємства, планування навичок ІТ-персоналу, моніторинг ефективності.
Всі перераховані компоненти розшифровують і розширюють поняття ІТ-стратегії і допомагають ІТ-директору правильно побудувати план розвитку і переходу до цільового ландшафту в залежності від поставлених бізнесом цілей. При цьому добре структуровані і детальні описи всіх доменів архітектури підприємства дозволяють побудувати і реалізувати програми, в найбільшою мірою відображають вимоги бізнесу, а також вибрати відповідну архітектуру корпоративних додатків або прийняти рішення про перехід на сервісну архітектуру. У цьому випадку результати проектування архітектури підприємства використовуються як вхідна інформація і обмеження для опису і виділення сервісів додатків. Причому важливо розуміти, що SOA використовується для розробки архітектури корпоративних додатків і залежить від стратегічного бачення архітектурних принципів і ІТ-цілей, прийнятих в рамках архітектури підприємства.
***
Поняття SOA і архітектура підприємства відносяться до різних рівнів архітектури: архітектура підприємства визначає цільову ІТ-архітектуру в рамках компанії, основні напрямки розвитку і план трансформації, в той час як SOA використовується при розробці і проектуванні корпоративних додатків. Успішність реалізації і результат розробки сервіс-орієнтованих додатків залежать від того, наскільки повно
і детально ведеться архітектура підприємства, розуміється вона бізнес-користувачами і відображає актуальні бізнес-цілі і потреби. n
Ірина Пирлін ( [email protected] ) - старший консультант департаменту управління корпоративною архітектурою і основними даними компанії «САП СНД», Сергій Пузини ( [email protected] ) - керівник департаменту управління корпоративною архітектурою і основними даними «САП СНД».
Мал. 1. рівні архітектури
Мал. 2. ІТ-стратегія, архітектура підприємства і SOA
SOA: підходи до реалізації. управління ІТ
Поява концепції SOA стало закономірним кроком на шляху пошуку рішення однієї з найбільш нагальних і складних проблем ІТ-індустрії - проблеми інтеграції додатків.
http://www.osp.ru/os/2004/06/184450
Методологія SAP EAF
Методологія складається з SAP EAF Architecture Process, SAP EAF MetaModel, керівництва, ресурсної бази та інструментів.
SAP EAF Architecture Process - модель, що описує процес розробки архітектури і пропонує розбити його на фази (див. Малюнок): бачення архітектури (А) - визначення меж проекту, розробка загального уявлення архітектури, узгодження плану робіт і підходу; бізнес-архітектура (B) - безліч бізнес- і технічних вимог, цілей і стратегічних напрямків розвитку, дані gap-аналізу, опис поточних і цільових бізнес-процесів, функцій, сервісів, план переходу на нову бізнес-архітектуру; архітектура інформаційної системи (С) - формалізований опис існуючої архітектури додатків і даних на основі розробленої бізнес-архітектури та проведеного gap-аналізу, документація по цільовій архітектурі і складові елементи архітектури додатків і архітектури даних. Далі в SAP EAF Architecture Process входить опис поточної і цільової технічної архітектури (D): системне програмне забезпечення, сервери, бази даних, апаратне забезпечення, мережа, а також високорівнева план переходу до цільової архітектурі (Е).
Планування міграції (F) передбачає розробку детального плану переходу до цільової архітектурі, що включає всі необхідні для цього зміни (організаційні, бізнес-процеси, ІТ-ландшафт). Основна мета управління реалізацією (G) складається в моніторингу процесів проектування, реалізації корпоративних інформаційних систем і своєчасному внесення змін в усі домени архітектури підприємства. Управління змінами архітектури (H) включає в себе весь комплекс заходів з управління змінами (розробка нової функціональності, зміни в бізнес-процесах, зміни принципів управління). Управління вимогами є ядром процесу створення архітектури підприємства на базі SAP EAF і передбачає постійний моніторинг, збір і формалізація потреб бізнесу.
SAP EAF MetaModel - модель, яка визначає угоди про проектування архітектури підприємства. На базі окремих каталогів в моделі описуються компоненти архітектури, взаємини між компонентами відображаються за допомогою спеціальних матриць. У фінальному графічному поданні описуються всі домени поточної і цільової архітектур.
Керівництва з побудови архітектури підприємства, шаблони і приклади. Ресурсна база - база архітектурних стандартів, які використовуються при проектуванні архітектури підприємства. Інструменти, що підтримують розробку та моделювання архітектури підприємства. Модель архітектури підприємства на базі SAP EAF може бути описана за допомогою цілого ряду інструментів, що існують сьогодні на ринку моделювання бізнес-процесів (наприклад, ARIS).
Таким чином, методологія SAP EAF визначає послідовність дій (SAP EAF Architecture Process) і набір підсумкових документів (матриці, уявлення - SAP EAF Metamodel), що розробляються на кожному кроці при проектуванні архітектури підприємства.