Архитектурный консалтинг: как создать квалифицированную основу цифровой трансформации

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

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

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

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

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

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

Михаил Краснов: Обычно мы используем международные стандарты описания архитектуры TOGAF и Open Agile Architecture от международного консорциума Open Group. Также наши специалисты ориентируются на свой опыт построения нагрузочных систем и лучшие практики в современном мире ИТ.

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

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

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