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

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

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

Примеры технического долга в BI:

  • В BI проекте существует хранилище данных, но фактически оно является копией рабочей базы данных. В результате, теряются преимущества хранилища, такие как скорость обновления данных, также возможны потери или повреждения данных.
  • При загрузке и модификации данных (ETL) не происходит проверка/исправление повреждённых данных. Ошибки переносятся в приложение.
  • Неоптимальные названия полей и переменных затрудняют редактирование и использование приложения в будущем.
  • Изначально неправильно выбранная модель/структура данных приложения ведёт к проблемам при эксплуатации и модификации приложения.
  • Менеджер BI под давлением берет на себя обязательство завершить проект к определённой дате, которая в большей степени определяется ожиданиями заинтересованных сторон, чем ресурсами команды или оценками (если таковые имеются). И либо этого не происходит, либо проект получается низкого качества.
  • Каждый проект BI — это свой собственный остров пользовательских требований и подходов. Не существует централизованной стратегии BI. Например, из-за отсутствия унификации приходится тратить больше времени на изменение разных приложений.
  • Не определены конкретные роли людей, работающих над проектом, и методы их взаимодействия (коммуникации).
  • Администраторы своевременно не обновляют версии программного обеспечения BI, в результате чего могут возникнуть ошибки, либо могут воспроизвестись какие-то ошибки, которые уже были исправлены вендором.

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

Можно рассмотреть несколько полезных вопросов:

  1. Насколько легко можно в полной мере протестировать совершенно новый алгоритм для расчета показателей?
  2. Как точно можно измерить влияние нового изменения в системе?
  3. Как быстро можно ввести в курс дела новых членов команды?

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