3.3 Характеристика кіс
Найбільш значущими характеристиками КІС являються:
Архітектура інформаційної системи - склад елементів і їх взаємодія;
Мережеві технології, їх масштаби і топологія мережі;
Функціональна структура управління, реалізована в інформаційній системі (склад підсистем, комплексів завдань);
Організаційна форма зберігання інформації (централізована або розподілена база даних);
Пропускна спроможність системи - швидкість обробки транзакцій;
Об'єм інформаційного сховища даних;
Системи документів і документообіг;
Кількість користувачів КІС;
Призначений для користувача інтерфейс і його можливості;
Типові інформаційні технології процесів збору, передачі, обробки, зберігання, витягання, поширення інформації.
Забезпечення повного циклу управління в масштабах корпорації : нормування, планування, облік, аналіз, регулювання на основі зворотного зв'язку в умовах інформаційної і функціональної інтеграції;
Територіальна розподіленість і значні масштаби системи та об'єкту управління;
Неоднорідність складових технічного і програмного забезпечення структурних компонентів системи управління;
Єдиний інформаційний простір для вироблення управлінських рішень, об'єднуюче управління фінансами, персоналом, постачанням, збутом і процес управління виробництвом;
Функціонування в неоднорідному обчислювальному середовищі на різних обчислювальних платформах;
Реалізація управління в реальному масштабі часу;
Висока надійність, безпека, відкритість і масштабованість інформаційних компонентів.
4 Архітектура КІС
Досвід останніх років розробки ПО показує, що архітектура інформаційної системи повинна вибиратися з урахуванням потреб бізнесу, а не особистих пристрастей розробників. Далі розглядається існуюча клієнт-серверна архітектура побудови інформаційних систем.
Не секрет, що правильна і чітка організація інформаційних бізнес-рішень є чинником успіху будь-якої компанії, що складає. Особливо важливим цей чинник являється для підприємств середнього і малого бізнесу, яким потрібна система, яка здатна надати увесь об'єм бізнес-логіки для вирішення завдань компанії. В той же час, такі системи для компаній з середнім і малим масштабом мереж часто потрапляють під критерій "ціна - якість", тобто повинні мати максимальну продуктивність і надійність при доступній ціні.
Спочатку системи такого рівня базувалися на класичній дворівневій клієнт-серверній архітектурі(мал. 3.1).
Малюнок 3.1 - Дворівнева клієнт-серверна архітектура
Ця клієнт-серверна архітектура характеризується наявністю двох взаємодіючих самостійних модулів - автоматизованого робочого місця (Арма) і сервера бази даних, в якості якого може виступати Microsoft SQL Server, Oracle, Sybase і інші. Сервер БД відповідає за зберігання, управління і цілісність даних, а також забезпечує можливість одночасного доступу декількох користувачів. Клієнтська частина представлена так званим "товстим" клієнтом, тобто додатком (АРМ) на якому сконцентровані основні правила роботи системи і розташований призначений для користувача інтерфейс програми. При усій простоті побудови такої архітектури, вона володіє безліччю недоліків, найбільш суттєві з яких - це високі вимоги до мережевих ресурсів і пропускної спроможності мережі компанії, а також складність оновлення програмного забезпечення із-за бізнес-логіки, що "розмазала", між АРМом і сервером БД. Крім того, при великій кількості АРМов зростають вимоги до апаратного забезпечення сервера БД, а це, як відомо, найдорожчий вузол у будь-якій інформаційній системі.
Як бачимо, мінусів у такої архітектури досить, а рішення тривіальне - треба відокремити бізнес-логіку від клієнтської частини і СУБД, виділивши її в окремий шар. Так і поступили розробники і наступним кроком розвитку клієнт-серверної архітектури стало впровадження середнього рівня, що реалізовує завдання бізнес-логіки і управління механізмами доступу до БД (мал. 3.2).
Малюнок 3.2 - Трирівнева клієнт-серверна архітектура (Three - tier architecture)
Плюси цієї архітектури очевидні. Завдяки концентрації бізнес-логіки на сервері додатків, стало можливо підключати різні БД. Тепер, сервер бази даних звільнений від завдань розпаралелювання роботи між різними користувачами, що істотно знижує його апаратні вимоги. Також знизилися вимоги до клієнтських машин за рахунок виконання ресурсоємних операцій сервером додатків і вирішальних тепер тільки завдання візуалізації даних. Саме тому таку схему побудови інформаційних систем часто називають архітектурою "тонкого" клієнта.
Але, проте, вузьким місцем, як і в дворівневій клієнт-серверній архітектурі, залишаються підвищені вимоги до пропускної спроможності мережі, що у свою чергу накладає жорсткі обмеження на використання таких систем в мережах з нестійким зв'язком і малою пропускною спроможністю (Internet, GPRS, мобільний зв'язок).
Існує ще один важливий момент використання систем, побудованих на такій архітектурі. Самий верхній рівень (Армы), що в цілому має величезну обчислювальну потужність, насправді простоює, займаючись лише виведенням інформації на екран користувача. То чом би не використовувати цей потенціал в роботі усієї системи? Розглянемо наступну архітектуру(Мал. 3.3) яка дозволяє вирішити це завдання.
Малюнок 3.3 - Розподілена архітектура системи
Ще два-три роки тому реалізація такої архітектури системи для середнього і малого бізнесу була б не можлива через відсутність відповідних недорогих апаратних засобів. Сьогодні хороший ноутбук має потужність, яку кілька років тому мав сервер великої корпорації, і дозволяв розраховувати безліч важливих і доленосних звітів для усіх співробітників цієї корпорації.
Більше 95 % даних, використовуваних в управлінні підприємством, можуть бути розміщені на одному персональному комп'ютері, забезпечивши можливість його незалежної роботи. Потік виправлень і доповнень, що створюється на цьому комп'ютері, нікчемний в порівнянні з об'ємом даних, використовуваних при цьому. Тому якщо зберігати безперервно використовувані дані на самих комп'ютерах, і організувати обмін між ними виправленнями і доповненнями до даних, що зберігаються, то сумарний передаваний трафік різко знизитися. Це дозволяє знизити вимоги до каналів зв'язку між комп'ютерами і частіше використовувати асинхронний зв'язок, і завдяки цьому створювати надійно функціонуючі розподілені інформаційні системи, що використовують для зв'язку окремих елементів нестійкий зв'язок типу Інтернету, мобільний зв'язок, комерційні супутникові канали. А мінімізація трафіку між елементами зробить цілком доступною вартість експлуатації такого зв'язку. Звичайно, реалізація такої системи не елементарна, і вимагає рішення ряду проблем, одна з яких своєчасна синхронізація даних.
Кожен АРМ незалежний, містить тільки ту інформацію, з якою повинен працювати, а актуальність даних в усій системі забезпечується завдяки безперервному обміну сполученнями з іншими Армами. Обмін повідомленнями між Армами може бути реалізований різними способами, від відправки даних по електронній пошті до передачі даних по мережах.
Ще однією з переваг такої схеми експлуатації і архітектури системи, являється забезпечення можливості персональної відповідальності за збереження даних. Оскільки дані, доступні на конкретному робочому місці, знаходяться тільки на цьому комп'ютері, при використанні засобів шифрування і особистих апаратних ключів виключається доступ до даних сторонніх, у тому числі і IT адміністраторів.
Така архітектура системи також дозволяє організувати розподілені обчислення між клієнтськими машинами. Наприклад, розрахунок якого-небудь завдання, що вимагає великих обчислень, можна розподілити між сусідніми Армами завдяки тому, що вони, як правило, мають одну інформацію у своїх БД і, таким чином, добитися максимальної продуктивності системи.
Таким чином, запропонована модель побудови розподілених систем цілком здатна вирішити і реалізувати функції сучасного програмного забезпечення для підприємств середнього і малого бізнесу. Побудовані на основі цієї архітектури системи матимуть надійність, безпеку інформації і високу швидкість обчислень, що від них в першу чергу і вимагається.