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

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

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

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

Коротше кажучи, як менеджери, що не належать до ІТ, як нам найкраще керувати цим переходом?

Може здатися, що "повинна бути бізнес-модель для фірми з підтримки ІТ, яка зосереджується на таких застарілих платформах", але особисто я вважаю, що це просто бажання подумати з вашого боку, оскільки це "вирішить" проблеми, з якими ви стикаєтеся в одному махом.

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

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

Читайте "Як пережити наземне переписування, не втрачаючи розуму"

Не робіть помилку довгого міграційного проекту без реальних результатів протягом тривалого часу. Читайте "Як пережити наземне переписування, не втрачаючи розуму"

Я не можу наголосити на достатній мірі, як поради в цій статті допомогли мені вирішити / підійти до подібних проблем після того, як я спалюю себе на подібні проекти "старим" способом.

Налаштування автоматизованих тестів

Якщо ви його ще не встановили (чому ніколи?), Запропонуйте поточним програмістам створити автоматизований тестовий джгут для своїх додатків.

Автоматизований набір тестів повинен охоплювати всі функціональні області ваших програм. Він повинен / задокументував поточні робочі характеристики в правилах "when_X_then_Y" окремих тестів. Це допоможе як у збереженні змін у вашому поточному коді від порушення існуючої функціональності, так і підтримці будь-якої міграції до нового середовища.

Якщо ви маєте справу з COBOL та BASIC, набір тестів, мабуть, повинен знаходитись на рівні інтеграційних тестів: відпрацювання "фіксованого" набору вхідних файлів / баз даних та перевірка вихідних файлів / зміненого вмісту бази даних конкретних програм (COBOL) та / або додатки. Для частин програмного забезпечення BASIC це може означати додавання параметрів командного рядка, щоб змусити їх виконувати певні функції без втручання (G) інтерфейсу користувача або отримання автоматизованого інструменту тестування на основі (G) інтерфейсу користувача.

Виділіть обчислення та інші алгоритми

Навіть Cobol підтримує поняття про підпрограми, що дзвоняться з основної програми. Виділіть усі імпортні обчислення та інші алгоритми в окремих програмах чи модулях. Мета - створити бібліотеку програм / модулів / що завгодно, що роблять грубо працю, ізольовані від усього, що збирає вхід і створює вихід.

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

Запускайте новий набір програм у "поточному" середовищі

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

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

Це хороший спосіб зробити справи в будь-якому випадку, і у вашому випадку ви зможете мігрувати ці важливі частини на кожному конкретному випадку. Він також приховає тонкощі виклику основних та / або програм cobol від функцій виклику в новому середовищі.

Не продовжуйте налаштовувати програми та, можливо, налаштовувати найважливішу функцію введення / виводу, яка використовує обчислення з вашої COBOL / BASIC "бібліотеки".

Інтегруйте свою "бібліотеку" COBOL / BASIC

З’ясуйте, як назвати свою бібліотеку COBOL / BASIC у своєму новому середовищі. Це може включати налаштування файлів параметрів або таблиць баз даних, виконання програми COBOL / BASIC, яка обгортає бібліотеку COBOL / BASIC, яку ви створили раніше. Якщо вам пощастило, ваша версія BASIC може дозволити створення DLL-файлів, які можна викликати безпосередньо.

Реалізуйте клас у вашому новому середовищі, яке називатиме COBOL / BASIC "бібліотекою" та протестує його з допомогою тих самих тестів, що і у тестовій заправці старого середовища, але тепер у вигляді одиничних тестів у новому середовищі .

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

Але знову ж таки: не йдіть далі, ніж додавати одиничні тести для обчислення (ів), використовувані одним найважливішим з попереднього кроку.

Обновіть нові програми в ітераціях

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

Перемістіть основну бібліотеку в ітераціях

І нарешті перенесіть обчислення та алгоритми у свою "бібліотеку" COBOL / BASIC, повторно реалізуючи їх у вашому новому середовищі. Знову ж, зробіть це повторно, використовуючи (одиничні) тести, як спосіб зберегти здоровий стан.

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

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

Я б рекомендував один з двох маршрутів.

1. Співробітники ІТ-групи розробників / менеджерів проектів / QE / операцій та створюйте свою систему поступово, як зазначено у досить технічній відповіді вище. Однак це буде надзвичайно дорогим.
2. Замість того, щоб вийти з постачальника на полиці, шукайте кваліфікованого консультанта для розробників. Ця група буде обробляти всі ресурси для розробки вашої нової системи, тоді ви можете залучити її додому з невеликим персоналом, ніж варіант 1 для продовження. Цей варіант має різний набір ризиків, однак вибір хорошого постачальника може бути дуже складним для нетехнічного. Вони також можуть бути дуже високими ризиками із перевищенням витрат тощо. Щоб пом'якшити цей маршрут, використовуйте наявний персонал для складання дуже детального набору вимог (з точки зору користувача) для вашої ставки. Потім запитайте також про фіксовану ціну.

Удачі, вам належить подолати близько 20 років. Це буде не дешево, легко чи чисто.

Замість того, щоб шукати фірму, яка б підтримувала ваше застаріле програмне забезпечення, або фірма, яка переписала б ваше застаріле програмне забезпечення, шукайте фірму, щоб забезпечити постійну послугу системи адміністрування переваг. Аутсорсинг проблем вирішення питання про те, чи потрібно переписувати програмне забезпечення, який графік встановити, якою мовою чи мовами чи інструментами користуватися.

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