Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ІСТ в упр орг-12k.doc
Скачиваний:
34
Добавлен:
27.11.2018
Размер:
4.09 Mб
Скачать

2.9. Інтеграція інформаційних систем підприємства

Взаємозв'язок інформаційних підсистем підприємства. Яким чином зв'язані інформаційні системи усередині підприємства? Звичайний шлях для української компанії середніх розмірів - починати впровадження інформаційних технологій з автоматизації роботи бухгалтерії, відділу кадрів і документообігу. Дані цих систем найбільш формалізовані, процеси легко автоматизуються. Широко поширені пакети "1C: Бухгалтерія", "Бос: Кадровик", "LanDocs", "LanStaff", "Salary" та інші дозволяють нарощувати себе будь-якими додатками і, таким чином, інтегрувати їх в загальну інформаційну систему підприємства. Рис. 2.25 показує яким чином модулі інформаційної системи компанії пов'язані один з одним. Модуль TPS обслуговує основні виробничі і допоміжні процеси, і звичайно це головне джерело для інших інформаційних модулів. ESS - головний одержувач даних і внутрішніх систем із зовнішнього середовища.

 

Рис. 2.25. Взаємодія модулів ІС

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

Зв'язки між DSS і сукупністю TPS, KWS, MIS навмисно показані невизначеними. Іноді DSS тісно пов'язана з іншими підсистемами. Але це тільки в тому випадку, якщо підприємство відрізняється високим ступенем автоматизації всіх процесів. Звичайно підсистема DSS ізольована від основних виробничих інформаційних систем і використовує їх дані і інформаційні потоки для роботи своїх аналітичних систем.

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

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

В даний час при формуванні інформаційної інфраструктури підприємства, при проектуванні і реалізації КІС все частіше застосовується сервіс-орієнтована архітектура (Service-Oriented Architecture - SOA). Це така архітектура ІС, в якій система будується з набору гетерогенних слабо зв’язаних компонентів (сервісів). SOA розуміється як парадигма організації і використання розподіленої безлічі функцій, які можуть контролюватися різними власниками. Базовими поняттями в такій архітектурі є "інформаційна послуга" і "композитний додаток".

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

Сервіс звичайно характеризується наступними властивостями:

можливість багатократного застосування;

послуга може бути визначена одним або декількома технологічно незалежними інтерфейсами;

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

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

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

створити систему корпоративних композитних додатків, заснованих на системі корпоративних Web-сервісів;

організувати інтеграцію додатків, процесів бізнесу, з автоматизацією процесів бізнесу, включаючи Human Workflow;

використовувати різні транспортні протоколи і стандарти форматування повідомлень, засобу забезпечення безпеки, надійної і своєчасної доставки повідомлень;

істотно підвищити швидкість розробки прикладних додатків і понизити витрати на ці цілі.

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

Обов'язковою умовою побудови і впровадження архітектури системи на основі SOA є використання єдиної інфраструктури опису сервісів (репозиторія сервісів), дозволених протоколів доступу і обміну повідомленнями, форматів повідомлень.

Згадана інфраструктура утворює так звану інтеграційну шину (ІШ) (Enterprise Service Bus - ESB), що є одним з центральних компонентів системи (рис. 2.26). Вона встановлює єдині правила публікації сервісів, управління і інформаційної взаємодії між додатками різних систем, що входять до складу інтегрованої системи. Це спрощує управління додатками і їх підтримку, а також знижує ризик фрагментації додатків і процесів.

 

 

Рис. 2.26. Структура побудови ESB і компоненти концепції SOA

 

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

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

За даними Gartner Group ("Predicts 2007: SOA Advances", 17 листопада 2006 року): "До 2008 року SOA стане пануючою архітектурою побудови ІТ-систем, що приведе до закінчення 40-річної ери панування архітектури монолітних додатків".

Зміна і вдосконалення процесів бізнесу в компаніях займає роки. За даними Gartner Group, 80% ІТ-бюджету - це витрати на супровід систем, з них 35% - витрати на інтеграцію додатків, 60% вартості впровадження корпоративної ІС складають витрати на інтеграцію, 50% ІТ-бюджету витрачено на забезпечення інтерфейсів систем. Використання SOA-архітектури дозволяє ефективно організувати оперативну адаптацію ІТ-систем під вимоги бізнесу, що дає стратегічну перевагу компанії, що полягає в:

підвищенні швидкості адаптації бізнесу до швидко змінних вимог ринку (Agility);

розширенні взаємодії гетерогенних корпоративних інформаційних систем при збереженні зроблених в них інвестицій;

скороченні витрат на ІТ-системи на основі повторного використання їх функціональних компонентів;

підвищенні продуктивності праці клієнтів, партнерів і співробітників (на основі архітектури Web 2.0).

З погляду бізнесу SOA можна представити як набір гнучких служб і процесів, які бізнес пропонує своїм замовникам, партнерам або усередині своєї власної організації. У даному контексті ці ж служби можна по-різному комбінувати і оснащувати, підтримуючи зміни або розвиток вимог бізнесу і моделей з часом.

Основні бізнес-цілі впровадження SOA-рішень полягають в ліквідації:

фрагментованості і дублювання даних;

дублювання реалізацій функцій бізнесу, процедур, процесів;

негнучкої архітектури.

Становлення і розвиток SOA відбувалося на базі практичних вимог бізнесу, що полягали перш за все в розумній економії програмних і технологічних засобів і витрат на реалізацію і супровід інформаційної інфраструктури:

забезпечувати спадкоємність інвестицій в IT, збереженні існуючих інформаційних систем і їх сумісному ефективному використанні для підвищення ROI від IT-вкладень;

забезпечувати реалізацію різних типів інтеграції:

призначена для користувача інтеграція (User Integration) - забезпечення взаємодії інформаційної системи з конкретним персоніфікованим користувачем;

інтеграція додатків (Application Connectivity) - забезпечення взаємодії додатків;

інтеграція процесів (Process Integration) - інтеграція процесів відповідно до бізнес-логіки діяльності підприємства;

інформаційна інтеграція (Information Integration) - інтеграція з метою забезпечення доступності інформації і даних;

інтеграція нових додатків (Build to Integrate) - інтеграція нових додатків і сервісів в існуючі інформаційні системи.

забезпечувати поетапність впровадження знов створених і міграції існуючих інформаційних систем;

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

дозволяти реалізацію різних моделей побудови інформаційних систем, особливо, таких як портальні рішення, grid-системи і on-demand-системи.

Сьогоднішній рівень розвитку SOA дозволяє стверджувати, що всі вказані вимоги в тій чи іншій мірі виконуються.

Зростання ринку продуктів для SOA-рішень - 100% в рік. У 2007 році SOA буде використана як основа створення 50% нових додатків, критичних для бізнесу і процесів бізнесу; до 2010 року цей показник виросте до 80%. Більше 80% додатків, введених в промислове використання в 2006 році, будуть частково або повністю перепроектовані до 2010 року, щоб бути використаними в побудові композитних додатків в SOA- архітектурі.

До 2010 року більше 80% всіх програмних інфраструктурних продуктів включатимуть корпоративну шину сервісів або вимагати її використання. Серед виконавчих директорів компаній 54% вважають, що в період до 2010 року в числі головних стратегічних переваг компаній нові моделі ведення бізнесу мають більше значення, ніж випуск нових продуктів і послуг. За даними Forrester ("The State of SOA in Financial Services", січень 2006), "Переважна більшість фінансових компаній використовуватимуть SOA до кінця 2008 р. Загалом, 50% європейських фінансових компаній або вже використовують SOA або знаходяться на останній стадії його впровадження".