Доброго дня!
Пишу с целью получить знания более опытных коллег.
Сейчас находимся на этапе разработки хранилища данных. Проблема в том, что разработка начинается из-за неудачного опыта с так называемыми аутсорсерами, которые не смогли. Разработали полумодель данных, на которых уже ретивые аналитики настроили машинное обучение и некоторые витринки. Дальше было решено делать хранилище собственными силами. Разумом было поглощено много тем, из которых сделан вывод, что:
- стоит грузануть исходные данные в первый слой как есть;
- разработать корпоративную модель данных с историчностью;
- из КМД строить уже нужные витринки для различных подразделений, причем предусмотреть возможность drill-down(пока непонятно как)
- оставить возможность разработки метаданных, так как они нужны будут потом для того же самого drill-down;
- оставить возможность для late data arriving - пока не загружать факты до пришедших измерений, но потом можно будет генерить фиктивные ключи и записи для обеспечения доступа к данным;

Проблема в том, что бизнес хочет уже сейчас так, как было настроено там, ведь уже рабочие процессы есть. Собственно вопросы:
- как сопротивляться agile разработке, если нужен результат, и обеспечить дальнейшую гибкость системы?
- как обосновывать ресурсные затраты человекочасов и человеколюдей, если "там уже есть таблички ведь, давай грузанем также", если данные загружены сейчас как набор витрин, некоторые из которых вообще без историчности. Это при том, что я вижу голодные пасти совершенно других подразделений со своими запросами в другой плоскости.
Пока решил, что сбоку пристрою текущую модель, и параллельно попытаюсь сделать "правильно". Может у кого-то есть опыт в таком?
И может кто скажет общие выводы, а то с английским пытаюсь дружить, но недостаточно пока что. DAMA DMBOK - это что-то вроде списка наборов знаний по управлению данными? Что насчет TOGAF, MIKE2.0?

Дедушкасовсем не понятно чем вас не устаивает текущее решение.
Скорее всего изначально хранилка делалась для одной задачи, и даже для ее развития пришлось тянуть отдельно историчность нескольких параметров этих витринок. Если продолжать затягивать данные таким образом, сбоку, система превратится в фавелы.
Дедушка без элементарных знаний
Пожалуйста, дополните, если не сложно, минимальный список элементарных знаний, которые необходимо получить. Статей и книг очень много, тяжело выбрать, с чего начать. Сейчас изучены основные принципы, назначение и некоторые реализации по Кимбаллу, по Инмону, различие в их подходах, их мнение друг о друге. Также прочитаны статьи, где описывалось внедрение в разных организациях, и на какие проблемы натыкались в это время, какие решения использовались.
На тему общения с бизнесом ответы, кажется получил, спасибо

Спасибо всем, кто ответил.
Где-то подтвердил свои догадки, где-то посмотрел на другие точки зрения.
Смог найти, кажется, хороший компромисс, закинув те данные в "мусорную" схему, параллельно разрабатывая небольшими кусочками более масштабируемо новую схему и заменяя конечные витринки более качественными, историчными и достаточно полными данными(договорились, что будет уходить больше времени на задачи, но приемлемо для бизнеса).

P.S. Ivan Durak - премию точно нет, "рабочие" процессы работали только на машинное обучение, результатами которого бизнес не пользовался ввиду плохого качества входной инфы