10 апреля 2025
383
В основе любой информационной системы — сложная структура. Спроектировать ее не легче, чем построить дом. Какие ошибки можно допустить при планировании ИТ-архитектуры, и в чем их основные причины? К чему они могут привести в долгосрочной перспективе и как этого избежать? Рассказывает Михаил Рощин, заместитель директора отделения управления проектами и архитектуры IBS.
Цена ошибки в ИТ-архитектуре
Раньше, когда информационные системы были небольшими, роль архитектора воспринималась формально. Все понимали, что этот специалист нужен, но зачастую обходились без него. На вопрос почему система нелогично устроена нередко отвечают: «Так исторически сложилось», «Решали оперативные задачи».
Сейчас внедрение большой системы в крупной компании — это длительный, сложный и дорогостоящий процесс. Цена недоработок/ошибок на этапе проектирования высока: исправление просчетов в будущем может потребовать значительных временных и финансовых затрат.
Архитектурные ошибки могут привести и к прямым убыткам для бизнеса, если ключевые процессы вдруг перестанут работать как нужно. Поэтому основная задача архитектора — спроектировать устойчивую стабильную систему с учетом возможностей дальнейшего развития.
Основные ошибки при проектировании
Перечислю наиболее часто встречающиеся ошибки, которых можно было не допустить на этапе проектирования.
Отсутствие масштабируемости
Часто системы проектируются под текущие задачи бизнеса с небольшим запасом на линейный рост. Но в реальности все сложнее: бизнес может расти нелинейно, а объемы данных увеличиваются экспоненциально. Компании сливаются, поглощаются, переживают резкие скачки развития — эти процессы создают непредсказуемые нагрузки на информационные системы. Так что архитектура должна предусматривать возможность масштабирования без серьезных потерь в производительности.
Есть проверенные решения для подобных задач: микросервисная архитектура, горизонтальное масштабирование, а также облачные технологии, хотя они подходят не всем. Несмотря на это, многие компании все еще сталкиваются с проблемами при масштабировании. Например, в хранилищах данных часто используются горизонтально масштабируемые базы, когда по мере роста информации добавляются дополнительные кластеры. Однако забывают учитывать, что важна не только функция хранения, но и обработки, мониторинга, доступности данных, чтобы избежать проблем с производительностью в узких местах.
Избыточная связанность компонентов
Современные ИТ-системы состоят из множества элементов, и задача архитектора — правильно выбрать и совместить их, чтобы из набора отдельных частей получилась цельная, но гибкая структура
Одна из распространенных ошибок — слишком жесткая взаимосвязь компонентов. В таком монолите невозможно заменить отдельные элементы, подключить что-то новое или без значительных затрат изменить протокол взаимодействия.
Для решения этой проблемы применяется модульный подход. Можно декомпозировать систему на отдельные бизнес-сервисы, чтобы каждый из них был относительно независим. Такая слабо связанная архитектура облегчает поддержку и развитие системы.
Невыстроенная работа с данными
Часто в компании нет единой корпоративной модели данных: никто точно не знает, какие данные существуют, где они хранятся, как их контролировать и правильно использовать.
Раньше считалось, что эту проблему могут решить хранилища данных, и отчасти так и произошло. Но объемы информации продолжают стремительно расти, поэтому даже централизованные хранилища не устраняют всех сложностей.
Ключевой тренд последних нескольких лет — внедрение систем управления данными (Data Governance) и выделение работы с данными в отдельное направление внутри компании.
Зависимость от вендора
Еще одна важная проблема — вендорлок, т.е. зависимость от одного поставщика. Если вендор уходит с рынка или меняет условия, бизнес оказывается в сложной ситуации. Кроме того, осознавая свою незаменимость, поставщик может повышать цены на обслуживание, вводить обязательные обновления и диктовать какие-то другие условия.
Чтобы избежать этого, важно придерживаться мультивендорного подхода. Например, у IBS как ИТ-сервисной компании нет жестких обязательств работать только с определенными поставщиками. Поэтому мы проектируем архитектуру с учетом потребностей заказчиков, помогая им нивелировать в том числе и эту зависимость.
Приоритет технических возможностей перед потребностями пользователя
Зачастую системы проектируются, исходя из технических возможностей: если что-то можно реализовать определенным образом, значит, так и должно быть. Однако этот подход не всегда оправдан.
Любая ИТ-система прежде всего должна отвечать на реальные потребности пользователей, соответствовать функциональному запросу. Кроме того, она должна быть удобной и интуитивно понятной.
При проектировании важно сначала думать о конечных пользователях, а уже затем о технологиях. Создать систему, которая формально работает, но никому не нужна или неудобна, — плохая стратегия.
Недостаточное внимание к информационной безопасности
При проектировании архитектуры необходимо учитывать вопросы кибербезопасности — угрозы взлома, утечек информации и т.д. Количество таких инцидентов постоянно растет, увеличиваются и штрафы, связанные с подобными происшествиями.
Стоит отметить, что на российском рынке, особенно среди крупного бизнеса, мало кто использует облачные решения. Это вполне логично с точки зрения информационной безопасности. Хотя облака могут быть экономически выгоднее, риски утечек и взломов делают их менее предпочтительными. Здесь нужно многое учесть.
Почему ошибки по-прежнему встречаются?
Крупные компании давно осознали важность архитектуры при создании корпоративных систем. Они обсуждают новые подходы, создают архитектурные комитеты. Число ошибок снижается, но полностью избежать их пока не удается. Почему? Единого ответа на этот вопрос, как и "волшебной таблетки", к сожалению нет. Но можно выделить наиболее распространненые ситуации.
Например, в большой организации может быть слишком много архитекторов, в результате согласование вопросов затягивается, а процессы — пробуксовывают.
Противоположная крайность — когда архитектор в компании один, а его ресурсов не хватает на все задачи. В итоге архитектура разрастается хаотично, ее целостность никто не контролирует.
Третья ситуация связана с эффектом «замыливания»: ежедневно работая с системой, сложно объективно оценить ее состояние. Кажется, что все работает, а если есть какие-то проблемы, то они некритичны. Поэтому независимый внешний аудит бывает полезен, даже если в самой компании есть сильные специалисты. Взгляд со стороны помогает выявить потенциальные риски и избежать ошибок, которые могут дорого обойтись в будущем.
Автор: Михаил Рощин
Оригинал статьи размещен на ibs.ru