Настоящий CTO: думай как технический директор - Алан Уильямсон

• Различные типы хранилищ данных

• ПО с открытым исходным кодом и выбор подходящего языка/фреймворка

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

• Стек технологий таков, что его невозможно обновить постепенно и по частям, только заменить целиком.

• Техническое руководство годами не желает (или не умеет) прикасаться к священной корове.

• У руководства есть опыт работы только с этими технологиями.

• Система настолько важна, что ее замена или модернизация становится слишком рискованной или дорогостоящей.

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

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

Заметки с полей

Системы 40-летней давности

Я участвовал во многих проектах модернизации после приобретения, когда новые владельцы желали потратить деньги на приведение платформы к современному стеку. Устаревшие системы страдают от высоких эксплуатационных расходов, отсутствия безопасности и ограниченной масштабируемости. Самой старой системе из тех, что видел лично я, было 46 лет (она запускала RPG от IBM через терминалы с зеленым экраном), хотя чаще встречаются системы возрастом от 30 до 40 лет, работающие под управлением Cobol. Я также часто вижу 30-летние системы, созданные с использованием языков четвертого поколения с графическим интерфейсом, таких как Visual Basic, Gupta и Delphi. Все их объединяет одно: они – ключ к успеху компании. Если бы не они, бизнес не выжил бы.

При выборе технологии следует учитывать следующие факторы:

• Какие перспективы у нее в будущем?

• Что произойдет, если технология устареет или больше не будет поддерживаться?

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

• Будет ли в дальнейшем кто-то использовать эту технологию?

Например – старые приложения на Visual Basic, созданные в середине 1990-х годов с использованием сторонних библиотек, которые давно перестали поддерживаться и работают только на Windows 95/XP, и поэтому их нельзя портировать на современные версии Windows. «Майкрософт» отказалась от попыток обеспечить обратную совместимость и вместо этого предоставляет для Windows 10 полноценную виртуальную машину Windows XP, чтобы дать хоть какое-то будущее этим устаревшим приложениям.

Существуют примеры того, как устаревание технологий вынуждает компании предпринимать корректирующие действия. Когда-то в моде были плагины для веб-браузеров. Вы могли использовать Adobe/Macromedia Flash, Microsoft Silverlight или Java-апплеты Sun, чтобы добавить на веб-страницу богатый «десктопный» функционал. С появлением HTML 5 и значительным усовершенствованием встроенного JavaScript стало очевидно, что эти плагины устарели (и имеют проблемы с безопасностью), и в течение нескольких лет они полностью исчезли из новых версий браузеров.

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

8.1. Избегайте попасть в зависимость

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

Заметки с полей

Flash

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

Java – хороший пример базового языка, не ограничивающего ваш выбор. Этот язык был создан для работы на множестве процессоров, применяемых для создания встраиваемых систем. Использование абстрагированной виртуальной машины позволило разработчикам писать на едином стандартном языке, а JVM (виртуальная машина Java) стала связующим звеном между оборудованием / операционной системой и вашим кодом. Java предлагает ряд высокопроизводительных JVM (Oracle, IBM, OpenJDK, Amazon), которые можно использовать, не меняя ни единой строчки в коде на Java. Независимо от того, где вы запускаете Java-приложение – в Linux, Windows, Amazon, Google или Microsoft, – код остается тем же. Вы сохраняете контроль над своей операционной системой, виртуальной машиной и всем остальным, и можете заменить что угодно, не отвлекая команду разработчиков.

Если вы выбрали решение, которое требует расходов на лицензию, вам необходимо подготовиться к возможному увеличению ее стоимости – насколько сильно это повлияет на ваш бюджет? Организации часто жалеют, что купили лицензии Oracle / SQL Server только чтобы увидеть, что с годами цены растут при меньшей гибкости (например, невозможно переехать в облако), и в то же время понимая, что никаких уникальных функций этого продукта они не используют.

Не выбирайте платформы или ПО, для которых нет альтернативы. Иначе вы окажетесь во власти цен и набора функций конкретного поставщика; это касается в том числе бэк-офисных инструментов, таких как Office 365, Google Workspace и Salesforce. Однако в некоторых случаях это может быть приемлемым компромиссом, особенно при использовании крупных поставщиков, которые обычно не меняют цены резко.

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

8.2. Разрабатывать или покупать

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

Программное обеспечение для бизнеса – это не Microsoft Word. Никакое готовое ПО не сможет стать основой для вашей компании. Если бы могло – бизнесу не нужен был бы технический директор. Обычному ресторану не нужно специальное ПО – он может использовать онлайн-сервисы, разработанные для управления современными ресторанами, включая автоматическую интеграцию с такими сервисами, как DoorDash и Uber Eats. Однако, если вы McDonald's и управляете франшизами по всему миру, вам потребуется индивидуальное решение (и технический директор для его запуска).

И наоборот, нет смысла изобретать велосипед. Для создания действительно