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

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

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

Базовые принципы платформы

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

1. Доступный стек технологий

Использование всего богатства open source позволяет создавать как backend, так и frontend приложения любой сложности, решающие любые задачи. Такой практика также гарантирует высокую доступность компетенций в сфере создания ИТ-продуктов и исключает проблему замкнутости на одном вендоре (vendor lock).

2. Микросервисный подход

Он обеспечивает уход от практики «всё-в-одном» и монолитных архитектур финального решения. Гранулирование бизнес-функциональности на отдельные компактные и слабо связанные между собой приложения имеет и «обратную сторону»: растут сроки тестирования, поскольку увеличивается количество потенциальных точек отказа. Проблема решается грамотным релиз-менеджментом и распределением нагрузки между продуктовыми командами.

3. Слоистая архитектура

Этот принцип предполагает группировку компонентов платформы по слоям, отвечающим за решение задач своего уровня — технических, интеграционных и проч. Например, бизнес-сервисы группируются по функциональной области (domain-driven design). Все компоненты платформы формируют внутреннюю экосистему — «супермаркет» или маркетплейс стандартных сервисов платформы.

4. Надежность и производительность

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

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

На что обратить внимание

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

1. Микросервисы ≠ автоматический успех проекта

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

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

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

Необходимые стандарты и ключевые компоненты микросервисной архитектуры в современном понимании выглядят так — см. рис. 1.

2. Digital Decoupling

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

3. Особая культура разработки

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

Построение цифровой платформы «в коде» невозможно без изменений в культуре разработки, взаимодействия с партнерами, внедрения инструментов и практик DevSecOps. При формировании команд необходимо перенести фокус с проекта на продукт.

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

Отдельное направление — выстраивание процесса работы Scrum-команд и введение новых инструментов контроля метрик, сбора статистики, подготовки отчетности для руководства и контроля выполнения планов.

4. Слой техно

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

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

Пример реализации см. на рис. 2.

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

То есть, чаще всего это будет даже не проект, а целая программа развития. Ею должна заниматься специальная рабочая группа, которую координирует product owner платформы.

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

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

Уровень вызова и перспективы ответа

Основная задача кастомной разработки сейчас — замещение софта, лицензии на который более недоступны в РФ, в сочетании с миграцией больших объемов данных. Соответственно, «кастомные» проекты ставят перед заказчиком и исполнителем вызовы уровня полноценной цифровой трансформации.

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

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

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

Этот тренд будет только нарастать — ограниченность кадровых ресурсов быстро преодолеть не получится.

Автор: Дмитрий Кузнецов, руководитель разработки информационных систем и приложений компании Axenix
Источник: IT Channel News