Класифікація проектів міграції

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

СУБД. Початок таким проектам поклав перехід з настільних і офісних систем на базі колись популярних dbase, Clipper, Foxpro і Paradox на промислові сервери баз даних. Сьогодні у зв’язку з різниними обставинами — не завжди через технічні проблеми — усе частіше здійснюється перехід з одного популярного сервера баз даних на іншій. Крім того, уже зустрічаються проекти переходу на іншу СУБД, що припускають організацію підтримки більш ніж однієї платформи.

Апаратні платформи. Програмні рішення не поспівають за прогресом апаратних платформ, темпи якого диктує Закон Мура.

(З позицій математики «закон Мура» представляється простим виразом:

N0 — кількість транзисторів на кристалі у деякому році (умовно вважаємо його нульовим),

N(y) — кільуість транзисторів на кристалі після y років,

yy — термін (в роках і долях року), за який кількість транзисторів зростає вдвічі.

Під N можно розуміти і інші параметри, наприклад, кількість комірок ячеек пам'яті у пристроях пам'яті, частоту роботи мікропроцесорів і мікросхем тощо. Визначенням N0 і початкового значення y можно переміщувати точку відліку початку дії «закона Мура» і оцінити його приємлевість для різних інтервалів часу.

Виходячи з формули і прийнявши: N0 = (8-10)*10³ (що існувало напередодні оголошення "Закону"), yy =1 (початкове формулювання "подвоюється кожен рік"), отримаємо, наприклад, на 2016 рік N(y) буде більш ніж 10¹⁹ транзисторів на чип.

З одного погляду на функцію ясно, что при великих "y" функція прямує до нескінченності, що є абсурдом для практичної мікроелектроніки.)

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

Програмні платформи. Типовий приклад — масова міграція з MS-DOS на Windows і з Novell Netware на Windows NT, або безліч проектів, пов'язаних з міграцією розв'язків на Java, J2EE і EJB. Сьогодні на корпоративному ринку росте попит на .Net, але найчастіше здійснюється перехід на наступну версію тієї ж операційної системи. Більш серйозні зміни потрібні при міграції на якісно іншу версію платформи (наприклад, при переході від COM+ к .Net). У таких випадках виробник базового програмного забезпечення звичайно надає засоби взаємодії й забезпечення сумісності старих і нових компонентів, які дозволяють поступово переходити на нову інфраструктуру.

Незважаючи на тенденцію до розподілених і багатоланкових архітектур, численні відмінності в реалізації розв'язків обумовлюють слабку сумісність і переносність розробок. Перехід з одного сервера додатків на іншій, якщо навіть обоє підтримують той самий стандарт ( приміром, J2EE і EJB), пов'язаний із численними змінами у відповідності зі специфікою платформи й реалізацією стандарту. Невеликою, але прикрою проблемою може стати те, що один сервер додатків чутливий до регістрів при передачі параметрів, а інший — ні. Інший приклад: як кожний Web-сервер інтерпретує запис localhost. А, наприклад, відмінності в обробці кэша об'єктів можуть серйозно вплинути на продуктивність перенесених на нову платформу компонентів Javabeans. І тільки організація в таких проектах повномасштабного тестування забезпечує працездатність системи.

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

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

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

Багатоланцюжкові архітектури. Початок таким проектам поклав перехід з «настільних» програм на рішення « клієнт-сервер» з виділенням рівня сервера бази даних. Потім почалися проекти створення трьохланцюжкової архітектури, у яких логіку додатка перенесли на рівень сервера додатків. З поширенням Web-технологій додалися рівні сервера й порталу, плюс до цього — «ланцюжки» забезпечення безпечного доступу. І останнє віяння — шарок «обгортки» Web-служб.

Засоби розробки. Інструментарій розроблювачів нерідко визначає коло їх можливостей по забезпеченню підтримки різних платформ. Усе ще актуальний перехід з компіляторів для MS-DOS на сучасні середовища розробки. У свій час багато програмістів зробили цей крок, вибравши інструментарій швидкої розробки на зразок Progress, Gupta або Powerbuilder. І якщо Oracle може собі дозволити розбудовувати Oracle Developer, пропонуючи спеціальний пакет міграції на Java, а Microsoft досить планомірно переходить із Visual Foxpro на Visual Basic і, далі, на Visual Studio.Net, то іншим постачальникам сутужніше знаходити засоби для міграції. Прихильники ж Delphi залишилися особняком. Перехід на новий інструментарій вимагає фази адаптації до нового середовища розробки і її нюансам.

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