Корпорация IT Systems, направление. Инвестировать в А или Б?

Question

Это более общий вопрос о том, какое направление будет лучшей инвестицией для компании.

Основное бизнес-приложение нашей компании написано на Visual FoxPro и ему более 9 лет. База данных насчитывает более 15 гигов, а основная логика сложна, и, что еще хуже, модель данных ужасна. Двум парням, которые построили его и поддерживали его все эти годы, по крайней мере, за пятьдесят, поэтому нет необходимости говорить, что выход на пенсию или смерть могут наступить в течение следующего десятилетия или около того.

Это приложение VFP управляет всеми нашими основными бизнес-функциями и требует терминальных услуг и Citrix для доступа к нему из внешнего мира. Наши веб-приложения должны взаимодействовать с ним через ODBC, и у нас всегда возникают проблемы с производительностью. Серверы, на которых работает эта система, также очень стары, такие как сервер Win 2000, и разваливаются.

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

Ценник будет в ценовом диапазоне от 55 до 65 тысяч долларов. Поэтому, как веб-разработчик, я считаю, что это огромная трата денег! Моим решением было бы вложить эти деньги в переписывание базовой системы для работы на веб-платформе .Net. Это исключило бы необходимость лицензирования Terminal Server и Citrix вместе с дорогостоящим управлением оборудованием и конфигурацией для его запуска. Я не вижу смысла вкладывать деньги такого рода в устаревшую систему, которая должна быть в любом случае.

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

Answer 1

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

Вы не можете выиграть в аргументе ROI. Если система не тривиальна и вы не гений, то переписать приложение, которое на самом деле делает что-то , всегда будет стоить 100 000 долларов или больше. Подумайте несколько человек лет.

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

Реальный вопрос - начать исправлять сейчас? или "ждать, пока оно не сломается, а потом страдать?" И это не имеет однозначного $ -значного ответа.

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

---

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

(Мне за 50, я не планирую умирать в ближайшее время. Этот аргумент не завоевывает сердца и умы. Если им не за 80, вы не можете использовать возраст, кроме как как способ получить ваш аргумент проигнорирован.)

Сосредоточьтесь на стоимости (и риске) внесения изменений.

Докажите, что у вас есть веб-решение, которое делает изменения менее дорогостоящими и менее рискованными.

Далее, покопайтесь в том, что там, и найдите детали, которые можно заменить веб-фреймворком. Код, который вы не пишете, дешевле поддерживать код, который вы пишете.

Answer 2

Каждый проект нуждается в анализе затрат и выгод. Если единовременное вложение в размере 60 000 долларов США решит все проблемы в течение следующих 10 лет, то это (вероятно) гораздо более экономично, чем наем команды разработчиков на один год для создания более новой и лучшей системы.

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

Или вы можете пойти по середине и начать оборачивать его чем-то непрозрачным, например, веб-службой, а затем постепенно заменять компоненты более качественными (более эффективными, более удобными в обслуживании и т. Д.) Внутренними компонентами. Многие компании идут по этому пути, потому что это откладывает первоначальные затраты на переписывание; при необходимости вы можете отложить ИТ-ресурсы в другом месте.

Хотя С.Лотт прав: вполне вероятно, что вы не сможете конкурировать в одиночку. Вы должны попытаться количественно оценить риски, связанные с этими древними системами - например, сколько будет стоить компании найти и обучить квалифицированных разработчиков FoxPro, если первоначальные программисты решат уйти (или, используя язык многих менеджеров, которых я встретил, "переехал на автобусе") ...

---

Просто чтобы добавить к этому дополнительную перспективу: до .NET (и в течение нескольких лет после) я проводил большинство своих проектов исключительно в Delphi. В то время это действительно был отличный выбор для развития предприятия. Я был на самом деле человеком, который не хотел «обновляться». Однако через некоторое время и мне, и моим руководителям стало очевидно, что это напугало людей за пределами компании.

Инвесторы, аудиторы, все остальные - им не нравилась идея, что наш основной ИТ-актив сделан на каком-то "неясном" языке. Конечно, Delphi не был / не очень неясен; здесь в SO есть тэг "delphi" со счетом 3340. Но давайте использовать SO в качестве нашего примера - вот текущие значения:

• c# - 57293
• .net - 30577
• asp.net - 26600
• java - 31023
• vb.net - 5996
• delphi - 3340
• foxpro - 69
• vfp - 27

Позвольте этим числам погрузиться на некоторое время. Delphi, мой инструмент выбора в то время, теперь имеет менее 10% представлений о C #, и это заставило нетехнических специалистов нервничать. Foxpro / VFP даже не на 1%. Я даже не помню, сколько раз мне приходилось отвечать на такие вопросы, как:

• Что произойдет, если ведущий разработчик (я) выйдет или столкнется с автобусом?
• Насколько сложно / дорого будет нанимать программистов в этой области?
• Что если продавец перестанет его поддерживать? (Это почти случилось)
• Что если мы хотим получить помощь извне? Консультанты? Аудит безопасности?
• Насколько легко будет заставить его работать с внешними продуктами?

Бла-бла-бла, беспокойство, беспокойство, беспокойство, это было то, что я чувствовал в то время, и это был продукт, который на самом деле не был таким неясным. В вашем случае мы говорим о FoxPro здесь. FoxPro стал почти как COBOL; Конечно, он все еще здесь, есть люди, которые знают это, но кто сегодня запускает новый проект в FoxPro? Это скучно, это прямо гетто . VB6 начинает становиться гетто, и VB / Access фактически заменил FoxPro много лет назад.

Я явно немного мелодраматичен, но на вашем месте я бы взял этот угол. Забудьте о краткосрочной экономике, забудьте о возрасте и сосредоточьтесь на незаметности продукта. Сколько подлинных, квалифицированных ответов, по их мнению, они получат, если разместят объявление о покупке для разработчика FoxPro? Какую плату они должны предложить за такую ​​должность? Каким будет товарооборот? Все это может показаться далеким, если эти два разработчика были там более 20 с лишним лет, но когда вы управляете многомиллионным бизнесом, вы должны знать, что никогда не стоит делать ставку на выживание или два сотрудника - нет, если вы можете помочь ему .

Answer 3

Как исторический разработчик VFP (более 20 лет с Foxpro / VFP и STILL заставляют людей просить меня написать / обновить их системы с помощью VFP по разным причинам), он все еще очень мощный. Однако, изучая и используя большую часть своего опыта в области ООП и разработки, а также работая с .Net, я нахожу некоторые вещи в .Net намного проще, особенно при сильном приведении типов. Однако выполнение базового отчета ТРЕБУЕТ все строгого приведения типов к таблицам / структурам / объектам базы данных, а во многих случаях до сих пор выполняет PITA.

Ценник на переписывание всегда имеет большое значение, но также и крах ЛЮБОЙ системы ... независимо от VFP, VB, Access или других. Я настоятельно рекомендую привлечь консалтинговую компанию для помощи в перемоделировании вашей системы и, возможно, выступить в качестве менеджера проекта / наставника для ваших штатных сотрудников программистов, которые могут предложить свои таланты, даже если это может потребовать некоторых обучение в новой среде разработки. Таким образом, вы можете получить хорошую основу для сильных языковых навыков, но при этом сократить расходы, используя свой собственный персонал по программированию, однако вам может потребоваться нанять дополнительный персонал по программированию. Кривая обучения от VFP до .Net есть, и все еще может быть головным убором.

Существует множество компаний, которые были специалистами VFP, которые впоследствии перенесли свои услуги в мир .Net и могут предложить идеальную пару для вашей организации, обладающей историческими знаниями и профессиональным опытом ОБОИХ миров. Я знаю, что они тоже могут выступать в качестве наставников для развития такой работы.

Answer 4

Два важных числа:

• Количество заданий "FoxPro", перечисленных в craigslist Сан-Франциско прямо сейчас: 2.
• Количество заданий ".NET", перечисленных в craigslist Сан-Франциско, сейчас: 252.

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

Звучит как хорошее время, чтобы начать говорить о миграции & sup1; к новым, лучше поддерживаемым технологиям. (И через 10 лет, когда .NET устарела, вы можете сделать это снова:)

^[1] И развивайте систему, не переписывайте ее. Я предполагаю, что ваша нынешняя система очень органично развивалась в зависимости от потребностей в то время. Невозможно полностью заменить все это (по крайней мере, без пары лет и нескольких миллионов долларов).

Answer 5

Чтобы выяснить, стоит ли это делать, вы должны рассчитать, помимо стоимости переписывания:

1. Документирование всего, что система в настоящее время делает, и обратное проектирование требований.

2. Написание модульных и интеграционных тестов для всего, что существует в настоящее время. Это, вероятно, еще не существует, но должно быть.

3. Стоимость обслуживания новой системы. Новая система не собирается устранять расходы на техническое обслуживание, а просто снижает ее. Сколько вы сэкономите?

4. Стоимость оборудования для новой системы. Новая система должна будет работать на чем-то.

5. Лицензионные расходы на любое программное обеспечение и т. Д. которые необходимы для новой системы. Все будет с открытым исходным кодом? Или вам понадобятся несколько тестовых выпусков Visual Studio для разработчиков и тестеров?

6. Стоимость найма нового персонала для разработки. В дополнение к прямым затратам на заработную плату, есть офисные расходы. Общая сумма может составить 300 000 долл. США, скажем, для 3 разработчиков, включая зарплату, офисные помещения, оборудование, лицензии, медицинские пособия.

7. Временной горизонт для экономии. Экономия не произойдет сразу. Это произойдет в будущем. В то же время, они все еще должны платить за лицензирование для текущей системы, потому что что-то должно делать работу, пока новая система не будет введена в действие.

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

9. Деловой риск. Может быть опасность, что перезапись может стоить дороже, работать хуже,

Answer 6

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

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

Answer 7

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

Answer 8

Может быть, лучше

1. Рассмотрите возможность переписывания частей системы для лучшей ремонтопригодности.

2. Оптимизация системы для повышения производительности.

3. Абстрагирование специфических частей Foxpro, чтобы их можно было легко преобразовать в другие технологии.

Такой поэтапный подход позволил бы снизить риск и обеспечить некоторые краткосрочные улучшения.

Answer 9

Классическая ошибка в JOS - «система беспорядок, давайте перепишем ее».

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

Внезапно здание обрушивается вокруг вашей головы:)

Answer 10

Вы можете только сказать, что это пустая трата денег после того, как вы проанализировали ROI - это будет сильно зависеть от того, сколько стоит перезапись системы.