Что такое legacy: терминология — Что такое legacy code?

Legacy-код — это рак / Хабр

Все чаще и чаще я вижу, что люди уклоняются от новейших технологий, делая выбор в пользу обратной совместимости. «Мы не можем повышать минимальные требования к PHP до 5.5, потому что у нас 50% пользователей еще на 5.4» говорят они. «Нет никакого способа обновиться до Guzzle 4+, у нас бекенд на версии 3 и переделывать его слишком долго и дорого». И самый лучший аргумент от WordPress: «Мы не может придти к полному ООП, потому что большинство пользователей сидят на shared-хостингах с 5.1 или не знают про MVC».

Нонсенс.

Legacy-код – это большое НЕТ

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

Для уточнения: исправление ошибок предыдущих версий до тех пор, пока их контракт на долгосрочную поддержку не закончится, да. Добавление нового функционала, который можно выпустить в версии X, в версии X-1, только для того, чтобы не обижать пользователей X-1 — абсолютно и 100% нет. Аналогично, добавление X-1 кода в версию X только потому, что он может «пригодиться», должно быть признано недопустимым. Если вы по-прежнему берете с людей плату за X-1 и строите свои апгрейды поверх этого, то у вас очень плохой бизнес-план.

Хотя, кто я такой, чтобы нести подобную чушь? Я никогда не поддерживал большой проект с кучей заинтересованных сторон и саппортом, который развивается супермедленно и делает всех счастливыми. Насколько долго он делается и как работает не важно, ведь потенциально он может работать в 100 раз безопасней и в 1000 раз быстрее, верно? Не совсем. Моим самым большим ребенком был сайт крупного издателя со сложным бекендом на ZF1.

Если вы когда-нибудь делали проекты на ZF1, то знаете, этот фреймворк — вихрь из костылей и анти-паттернов. Когда приложение начало показывать признаки ухудшения из-за увеличения трафика, я перестроил фронтенд наиболее интенсивно используемой части приложения полностью на работу через ajax и вызовы API. Нагрузка резко упала и этим мы купили себе достаточно времени для переноса всех остальных частей приложения на Zend Framework 2. Тем, кто делал что-то подобное известно, что это все та же смесь из костылей и анти-паттернов, но чуть менее плотная.

Я пытаюсь сказать, что большие изменения и рефакторинг может произойти лишь в том случае, когда за ними стоят способные люди. Если все что вы делаете — это сплошные agile-митинги и мозговые штурмы, то никакое количество LTS контрактов не может помешать вам глупо выглядеть в течение пяти лет.

Даже если вы делаете бесплатную и/или open source работу, конечно же вы не должны ломать совместимость для X-1 пользователей. Делая им одолжение, развивая старые версии, при глобальном обновлении вы можете столкнуться с потенциальной потерей обратной совместимости. Просто усвойте одну вещь — они должны либо приспособиться, либо умереть.

Так все же почему мы должны изгнать legacy-код из современных систем?

Бесконечное LTS проклятие

Подписываясь под подходом «поддерживаем все так долго, как только можем», вы хоронитесь в бездонную яму, и, глядя на себя через несколько лет, когда вы окажитесь вынуждены поддерживать четыре различные версии вашего продукта, вы будете биться головой об стену из-за того, что не отказались от пользователей V1 и V2, если могли. В попытке сохранить аудиторию разработчики часто выходят за рамки своих возможностей и несправляются под гнетом тонн legacy-кода. По той же причине WordPress и оказался в своем нынешнем состоянии. Не позволяйте приковывать себя к старой версии.

Эти пользователи — мертвый груз, они должны быть уничтожены вне зависимости от того сколько денег они вам приносят. Дайте им возможность перехода и двигайтесь дальше, если они способны, то догонят вас. Если же нет, то они того не стоят.

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

Вы отчуждаетесь и негативно влияете на продвинутых пользователей

В последний раз я сталкивался с отчаянным legacy-кодом, когда устанавливал CMS, что оказалось очень трудным занятием в среде Vagrant — не только из-за проблем с symlink, которые сейчас широко известны всем (даже создателю Vagrant), но и с тем, что многие оставляют устаревшие версии CMS, т.к. часть модулей/плагинов еще не выпустили свои обновления. Раз нет обновлений модулей, то к чему обновлять ядро? Зачем торопить события, если ты к ним не готов?

Оставляя legacy-код в новой версии, вы в конечном итоге получаете монстра Франкенштейна, который вроде как по-прежнему работает, но плохо, и новый код, имеющий потенциал, не может его развить из-за беспорядка в унаследованной кодовой базе. Такой подход хоть и делает работу компаний-разработчиков, которые все еще застряли где-то в 90-х, проще, но в тоже время продвинутым пользователям становится сложнее работать с продуктом. Решениями, принятыми для толпы, которая уже давно и безнадежно отстала от технологий, вы отчуждаете и негативно влияете на продвинутых пользователей, способных принести гораздо большие деньги.

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

Неудачи иногда предвещают успех

Конечно, иногда это просто невозможно, и подобные исключения являются очень редким и ценным обучающим материалом. Один из любопытных случаев версионирования — 2й и 3й Python. Python — это удивительный язык, с ним вы можете сделать практически все что угодно. Но он не будет работать также как мог бы язык, построенный специально для вашей цели, это общий недостаток «мастер-на-все-руки» языков — они могут сделать что-то очень хорошо, но нет ни одного варианта сделать работу с помощью них безупречно. Когда пришел Python 3, в него были введены некоторые фичи, ломающие совместимость и пользователи 2й версии уже не могли так просто перейти на него.

Большинство отговорок вроде «пока еще не хватает Py3 пакетов» и «у нас слишком много кода в Py2, чтобы переписать все это» получают от меня ответы — «портируйте то, что вам нужно» и «Бедные программисты, их заставляют писать код», соответственно. Согласен, тут было несколько аргументов, но и те, как правило, берут в пример проекты, которые были изначально неправильно спроектированы, что и вылилось в их абсурдно большой размер.

На самом деле сейчас противостояние Py2 против Py3 уже превратилось в разлом, по обеим сторонам которого стоят программисты. Но многие не задумываются о том, что к тому времени как будет Python 4, люди, которые так яростно отказывались от перехода на версию 3+ будут по прежнему оставаться на Py2 и несовместимость станет еще больше. К тому моменту они могли бы уже освоить другой язык, а не противиться изменениям в текущем. С другой стороны, те, кто «отважился» переступить через разлом и переписал свой код на 3+ без долгих колебаний, получат все новейшие возможности будущих версий с нулевыми трудозатратами.

Слом обратной совместимости достаточно эффективно отсек ленивых и подготовил Python для нового поколения разработчиков. На мой взгляд, это огромный успех. Программирование, как и многие другие сферы жизни, все еще основано на выживании наиболее приспособленных — и если вы не можете использовать новые технологии адекватно — уйдите с дороги, не мешайте тем, кто может.

Приложения vs Библиотеки/Пакеты

Также есть вопросы по поводу противостояния приложений и библиотек. Другими словами, если правило «не устаревать» применимо для приложений, например при получении нового релиза фреймворка, то должно ли оно распространяться и на библиотеки?

Да.

Библиотеки, получившие бамп X+1, должны четко следовать пути к прогрессу — с момента, когда ваша версия библиотеки стала публично доступна, поддерживайте только багфиксы последней.

Приложения, которые используют такие библиотеки, находятся в более сложной ситуации из-за их зависимости от API, которые, возможно, могут измениться. Разумный подходом будет ждать отзывов из комьюнити о стабильности, прежде чем начать переход. В течении переходного периода, как старая, так и новая версии библиотеки/фреймворка могут оставаться в использовании, и после того, как все необходимые части будут модернизированы, старая версия должна быть удалена. Ведь это не займет много времени, правда?

Не бывает достаточно большого приложения

«Но Бруно, некоторые приложения огромны и их переписывание займет несколько месяцев», скажете вы. «Переход с ZF1 на ZF2 — это год работы!», на что я отвечаю: чушь. Нет достаточно большого веб-приложения, апгрейд которого займет подобные сроки. Я пойду еще дальше и скажу, что на самом деле нет веб-приложений достаточно больших, которые могли бы сравниться по размерам с Symfony или Zend.

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

Схема обновления

Как правильнее всего обновляться? Есть только один приемлимый вариант обновления программного обеспечения, которого должны придерживаться разработчики независимо от популярности их приложения/библиотеки:

1. Создайте новую ветку для новой версии
2. Пометьте старую версию/ветку как deprecated
3. Публично заявите, сколько вы еще будете поддерживать старую версию
4. Предупредите всех пользователей старой версии
5. Внедряйте новые функции ТОЛЬКО в новой ветке, в старой — багфиксы
6. Когда время жизни старой версии истечет, обрывайте все концы. Не исправляйте, не советуйте, вообще удалите упоминание о старой версии из документации. Убейте ее.

После прохождения данной процедуры вы никогда не получите в наследство неприятности.

Один из проектов, следущий этому пути — Guzzle. У него есть 3+ версия и 4+, для тех, кто хочет жить в ногу со временем и всегда быть на пике прогресса.

Вывод

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

А что думаете вы? Следует ли legacy-код хранить неограниченное время? Определенное число версий? Возможно не все? Как вы относитесь к legacy-коду в сторонних проектах? Должен ли разработчик волноваться о проблемах с legacy в библиотеках, которыми он пользуется? Ошибся ли я в этой статье? Данным постом я хотел начать дискуссию об этом — в конце концов, мои взгляды на проблемы и переживания — лишь моя точка зрения. Дайте знать в комментариях ниже.

Легаси код — зло вселенского масштаба

ГлавнаяУслуги

—

О насРаботыОтзывыБлог

Главная
Блог
Легаси код — зло вселенского масштаба

Обратно

Legacy code — устойчивое выражение, обозначающее старый код без каких-либо пояснений как в нём разобраться. Legacy (англ.) – наследство. Это может быть чужой код, старый код, свежий кривой или старый качественный. Главный признак — отсутствие возможности в нём разобраться.

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

Я в своей жизни ещё ни разу не встречал проекта, где бы всё было сделано по правилам проектирования архитектуры, с хорошей документацией и чётким пониманием того, куда движется проект. Как правило — это ужасный легаси код, отсутствие не только документации, а даже каких-либо комментариев в самом коде, полное отсутствие логики построения приложения и полное попустительство со стороны заказчика. Что же делать и как с этим жить?

Для начала нужно проанализировать ситуацию, почему так вообще происходит. Причин для этого много:

• нежелание заказчика контролировать команду разработчиков
• отсутствие на проекте архитектора и тимлида
• отсутствие код-ревью
• отсутствие в команде понимания, что такое командная работа
• банальная лень и непрофессионализм
• очень сжатые сроки для разработки

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

Это очень частые и роковые заблуждения. Для наглядности, можно сравнить команду разработчиков со строительной бригадой. Если в строительной бригаде не будет прораба, то все знают, к чему это приведет. И это не смотря на то, что все строители профессионалы своего дела. А все вместе, без четкой организации и контроля — это сборище выпивох и бракоделов.

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

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

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

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

И еще много похожих пунктов, которые не просто подкосят бизнес, а наверняка его убьют! Согласитесь, перспектива малоприятная. И если сегодня ещё всё хорошо, то завтра уже может быть всё плохо.

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

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

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

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

источник
источник иллюстрации Medium

5 способов мышления, ориентированного на наследие, определят ваше лидерство

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

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

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

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

Если бы вам нужно было оценить последние 10 лет вашей карьеры и ее различные этапы, что бы вы рассказали другим о своем наследии? Если бы эту историю рассказали другие, была бы верна та же самая история? Основываясь на повествовании, как будут выглядеть следующие 10 лет? Что бы вы изменили или сделали по-другому?

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

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

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

1.  Личность и ценности должны знать и быть чрезвычайно связанными с тем, кто вы и что вы представляете как личность и лидер. Какие ценности и убеждения влияют на то, как вы руководите, на ваше поведение и ваше отношение? Знают ли другие вас настоящую и то, что вы представляете как лидер для улучшения здоровья в целом?

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

2. Основополагающие принципы

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

Бывший генеральный директор General Electric Джек Уэлч был известен быстрым ростом в условиях медленно растущей экономики 1980-х годов за счет устранения предполагаемой неэффективности, сокращения запасов и ликвидации бюрократии. Руководящий основополагающий принцип Уэлча заключался в том, что компания должна быть либо № 1, либо № 2 в своей конкретной отрасли, либо они должны полностью покинуть ее. Этот подход и мышление позже были приняты другими руководителями корпоративной Америки.

3.  Смелость и умение идти на риск

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

Наследие Рональда Рейгана как никогда сильно, поскольку политические партии США ищут нарратив, на который обе стороны могут опереться, чтобы восстановить общественное доверие к правительству, и пример того, как должен руководить президент. Наследие Рейгана было основано на мужестве и своевременном риске. Сторонники указывают на более эффективную и процветающую экономику в 80-х годах в результате внешнеполитических триумфов Рейганомики, включая мирное окончание холодной войны. В результате своих смелых действий и харизматичной личности Эдвин Фельнер, президент фонда «Наследие», сказал, что Рейган «помог создать более безопасный и свободный мир» и что «он взял Америку, страдающую от «недуга»…, и сделал ее горожане снова верят в свою судьбу.

4.  Искренняя забота о других

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

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

5.  Ответственность и подотчетность

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

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

Мы постоянно видим примеры этого, из которых можем извлечь уроки. Тим Кук продолжает поддерживать и развивать наследие, которое Стив Джобс оставил в Apple. Как новый владелец The Washington Post Джефф Безос, основатель Amazon, не только продолжит ее наследие, но и планирует развивать его, стремясь вывести газету на современный уровень.

Лидеры, чувствующие, что их карьера застряла, больше заботятся о признании, чем об уважении. Ричард Брэнсон, основатель Virgin Group, был прав, когда сказал, каким он хочет видеть свое наследие: «Создать одну из самых уважаемых компаний в мире. Не обязательно самый большой». Только когда лидеры захотят быть значимыми, они откроют для себя истинное значение лидерства и построения наследия. Когда этот момент реализуется, линза, через которую вы смотрите, становится кристально чистой; вы начинаете понимать, что ответственность за продвижение и успех других в конечном счете определит вашу значимость как лидера.

• Пишите по электронной почте или подписывайтесь на меня в Twitter @GlennLlopis. Поставьте нам лайк на фейсбуке! Присоединяйтесь к нашей группе LinkedIn.

Что такое устаревшая система?

Статьи по теме

• Что такое MySQL? Все, что вам нужно знать
• Что такое промежуточное ПО? Технологический посредник
• Что такое Shadow IT? Определение, риски и примеры
• Что такое бессерверная архитектура?
• Что такое SAP?

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

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

Существуют разные причины, по которым компания продолжает использовать устаревшую систему.

• Инвестиции : Хотя поддержка устаревшей системы со временем обходится дорого, обновление до новой системы требует предварительных инвестиций, как в долларах, так и в рабочей силе.
• Страх: Меняться тяжело, и перевод целой компании или даже отдельного отдела на новую систему может вызвать внутреннее сопротивление.
• Сложность : Устаревшее программное обеспечение может быть создано с использованием устаревшего языка программирования, что затрудняет поиск персонала, обладающего навыками для выполнения миграции. Документации по системе может быть мало, а первоначальные разработчики покинули компанию. Иногда простое планирование переноса данных из устаревшей системы и определение объема требований для новой системы является непосильной задачей.

Проблемы, вызванные устаревшими системами

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

1. Обслуживание дорого (и бесполезно)

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

В какой-то момент прекратится поддержка устаревшей системы и обновлений. Если система дает сбой, деваться некуда.

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

2. Данные застряли в разрозненных хранилищах

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

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

3. Соответствие требованиям намного сложнее

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

Нормативно-правовые акты, такие как GDPR, например, требуют, чтобы компания знала (и подтверждала), какие данные о клиентах у них есть, где они находятся и кто имеет к ним доступ. Компании, располагающие данными о клиентах, должны вести хорошо управляемые записи, что намного сложнее (если вообще возможно) в устаревших, разрозненных системах.

4. Безопасность с каждым днем ​​становится все слабее

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

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

5. Новые системы не интегрируются

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

Разработка процессов, обеспечивающих совместную работу систем, обременительна и по-прежнему подвергает компанию рискам безопасности. Это вызывает неспособность к технологическому росту внутри компании.

Ключ к обновлению устаревших систем: успешный перенос данных

Самое главное при обновлении устаревшей системы — защитить уже существующие данные. Это можно сделать только путем успешной миграции данных.

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

Успешный перенос данных включает: 

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

Миграция устаревшей системы финансовой отрасли 

Money Super Market необходимо было обновить свою устаревшую ETL до современной, более конкурентоспособной системы. Было необходимо предложить своим клиентам более быстрое обслуживание, а их устаревшая система не могла этого сделать.

После простого перехода от устаревшей системы Money Super Market улучшила свои инструменты сравнения продуктов для клиентов, а также увеличила продажи.

Миграция устаревшей системы государственного сектора 

Региональный совет Лангедок-Руссильона занимается экономическим ростом в пяти регионах Франции. Его успех может затронуть до 2,5 миллионов человек и 127 000 компаний.

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

Начните миграцию устаревшей системы

Устаревшие системы часто встраиваются из-за удобства. Но правда в том, что это стоит времени и денег и обрекает компанию на провал.

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

Перспективные решения для интеграции данных, такие как Talend Data Fabric, упрощают, казалось бы, непосильную задачу переноса данных. Talend Data Fabric защищает компанию посредством:

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

Не позволяйте страху отказа от устаревшей системы поставить под угрозу вашу компанию.