Постдикция: если хранилища уходят в облако, у интегратора меняется вся экономика проекта

Это ещё одна постдикция. Предположим, что через три года облачные хранилища данных станут стандартным выбором для новых проектов - не экзотикой и не экспериментом, а первым вариантом, который рассматривают при старте. Что тогда меняется в том, как строятся ИТ-проекты и как компании их покупают? Экономический сдвиг, который делает этот сценарий правдоподобным - новое ценообразование и психология пилота, которую принёс Amazon Redshift.

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

Как меняется структура затрат

Когда хранилище облачное, первоначальная инсталляция перестаёт быть проектом. Это процедура. Несколько часов вместо нескольких месяцев.

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

У плохого проекта деньги просто исчезнут, потому что бюджет сформировался под старую модель, а пересматривать его никто не стал.

Итерации вместо долгого внедрения

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

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

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

Что меняется у интегратора

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

Зато появляется новое пространство: консультирование по модели данных, настройка пайплайнов, работа с качеством данных, помощь в интерпретации метрик. Это другая работа - менее монументальная, более непрерывная.

Интеграторы, которые вовремя перестроятся, превратятся из "тех, кто устанавливал сервер" в "тех, кто помогает думать о данных как об активе". Это более ценная позиция, если под неё есть реальная экспертиза.

Что это значит для заказчика

Если вы выбираете партнёра для проекта с данными в 2013 году, стоит смотреть не только на то, умеет ли интегратор ставить и настраивать ПО. Стоит спросить:

• умеет ли он итерировать, или он умеет только делать большие финальные релизы?
• как он работает, когда требования меняются в середине проекта?
• есть ли у него опыт работы с данными в бизнес-контексте, или только технический опыт с конкретными продуктами?
• как выглядит его модель сопровождения после запуска?

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

Простой проверочный вопрос

Когда вам предлагают проект "перейти на облачное хранилище данных", спросите: а что именно мы будем делать с данными после того, как хранилище запущено? Если внятного ответа нет - значит, вам продают инфраструктуру, а не решение. Инфраструктура без ответа на этот вопрос не создаёт ценности.