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

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

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

Кажется, что для ИТ-службы поддержки должна существовать бизнес-модель, которая концентрируется на унаследованных платформах, подобных этой, и предоставляет талант программиста и разработчиков программного обеспечения для поддержки такой системы, как наша, устраняя из-за спины риски, связанные с поиском подходящего талантливого программиста и работа по убеждению молодых программистов в том, что у них может быть продуктивная и полезная карьера, частично на старом несексуальном языке, таком как BASIC.

Короче говоря, как не-ИТ-менеджеры, как мы можем лучше всего управлять этим переходом?

Может показаться, что «должна существовать бизнес-модель для фирмы поддержки ИТ, которая концентрируется на устаревших платформах, подобных этой», но лично я думаю, что это просто желаемое за действительное с вашей стороны, так как это «решит» проблемы, с которыми вы сталкиваетесь в одном махом.

Оставаться застрявшим в старых условиях - это не способ идти вперед. И я, например, не стал бы ставить жизнь любой компании на попытки застрять, найдя какую-то фирму, которая на данный момент готова делать то, что вы, очевидно, не можете.

Поэтому не ответ на вопрос, который вы задали, а искренний совет о том, как вы могли бы двигаться вперед, сохраняя при этом риски перехода к минимуму.

Читайте "Как выжить с нуля переписать без потери здравомыслия"

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

Я не могу не подчеркнуть, как советы, изложенные в этой статье, помогли мне решить / приблизиться к подобным проблемам после того, как я сжег себя, выполняя подобные проекты «старым» способом.

Настройка автоматических тестов

Если у вас его еще нет (почему вообще нет?), Попросите ваших нынешних программистов создать автоматизированный тестовый комплект для ваших приложений.

Набор автоматизированных тестов должен охватывать все функциональные области ваших приложений. Он будет документировать текущие рабочие спецификации в правилах «when_X_then_Y» отдельных тестовых случаев. Это поможет не только нарушить существующую функциональность изменений в вашем текущем коде, но и поддержит любую миграцию в новую среду.

Поскольку вы имеете дело с COBOL и BASIC, набор тестов, вероятно, должен находиться на уровне интеграционных тестов: отрабатывать «фиксированный» набор входных файлов / баз данных и проверять выходные файлы / измененное содержимое базы данных конкретных программ (COBOL) и / или приложения. Для ОСНОВНЫХ частей вашего программного обеспечения это может означать добавление параметров командной строки, чтобы они выполняли определенные функции без вмешательства (G) UI, или получение инструмента автоматического тестирования на основе (G) UI.

Изолировать расчеты и другие алгоритмы

Даже Cobol поддерживает понятие подпрограмм, вызываемых из основной программы. Изолируйте все расчеты импорта и другие алгоритмы в отдельных программах или модулях. Цель состоит в том, чтобы создать библиотеку программ / модулей / чего бы то ни было, выполняющих основную работу, изолированную от всего, что собирает входные данные и создает выходные данные.

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

Запустить новый набор приложений в «текущей» среде

Не конвертируйте свой текущий код. Преобразование одного языка в другой означает наложение ограничений старой среды на новую. Результат, если часто меньше, чем хотелось бы (читай: результат будет ужасным и боль в поддержании). Migrate. Потратьте время на настройку приложений в новой среде таким образом, который считается наилучшим для этой среды.

Привлеките новых программистов, хорошо разбирающихся в выбранной вами среде. Сделайте приоритетом с первого дня выделение всех важных вычислений и алгоритмов в отдельных классах и / или пакетах и ​​скрытие их за интерфейсами. Используйте внедрение зависимостей (самый дешевый вид самостоятельного внедрения зависимостей), чтобы сообщить вашему новому приложению, какие классы создавать / использовать для расчетов.

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

Не идите дальше, настраивая приложения и, возможно, устанавливая единственную наиболее важную функцию ввода / вывода, которая использует вычисления из вашей «библиотеки» COBOL / BASIC.

Интегрируйте свою «библиотеку» COBOL / BASIC

Выясните, как назвать вашу библиотеку COBOL / BASIC из новой среды. Это может включать настройку файлов параметров или таблиц базы данных, выполнение программы COBOL / BASIC, которая оборачивает библиотеку COBOL / BASIC, которую вы установили ранее. Если вам повезет, ваша версия BASIC может позволить создавать библиотеки DLL, которые можно вызывать напрямую.

Реализуйте класс в вашей новой среде, которая будет называть COBOL / BASIC «библиотекой», и проверяйте его, используя те же тесты, которые используются в тестах старой среды, но теперь в форме модульных тестов в новой среде. ,

Да, это означает «дублирование» тестов, но это система безопасности, без которой вы не хотите обойтись. Хотя бы потому, что эти модульные тесты позже будут служить тестами для проверки реализации ваших вычислений и алгоритмов, когда они будут перенесены в вашу новую среду.

Но опять же: не идите дальше, чем добавление модульных тестов для вычислений, используемых наиболее важными из предыдущего шага.

Уточнение новых приложений в итерациях

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

Миграция основной библиотеки в итерациях

И, наконец, перенесите вычисления и алгоритмы в свою «библиотеку» COBOL / BASIC, заново внедрив их в новую среду. Опять же, делайте это итеративно, используя (модульные) тесты как способ сохранить ваше здоровье.

Похоже, это приложение является «ядром» для вашего бизнеса. В тех случаях, когда система или процесс - это то, что является вашим бизнесом, необходимо иметь собственное решение.

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

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

1. Укомплектуйте ИТ-группу разработчиков / менеджеров проектов / QE / операций и постепенно наращивайте свою систему, как отмечено в довольно техническом ответе выше. Это, однако, будет исключительно дорого.
2. Вместо того, чтобы готовить поставщика, ищите квалифицированного консультанта по разработке. Эта группа будет обрабатывать все ресурсы для создания вашей новой системы, затем вы можете принести ее в дом с небольшим персоналом, чем вариант 1, чтобы продолжить. Этот вариант имеет другой набор рисков, однако, выбор хорошего поставщика может быть очень сложным для нетехнических. Они также могут быть очень рискованными из-за перерасхода средств и т. Д. Чтобы смягчить этот маршрут, используйте свой существующий персонал для составления очень подробного набора требований (с точки зрения пользователя) для вашей ставки. Тогда попросите также предложения с фиксированной ценой.

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

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

Да, очевидные затраты на этот подход могут превысить очевидные затраты на наем новых программистов, но, по вашему собственному признанию, вы не являетесь ИТ-менеджером, и легко предвидеть сценарии, в которых вы принимаете решения, которые в конечном итоге обходятся вашей компании дороже, чем очевидные затраты на аутсорсинг.