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

Завоевывая все большую популярность, agile-подход к построению хранилищ данных решает многие сложные проблемы, как правило связанные с разработкой хранилища данных: высокие затраты, низкая адаптивность для пользователей,  постоянно меняющиеся требования к бизнесу и невозможность быстро адаптироваться по мере изменения бизнес-условий. Гибкий подход может быть использован для разработки любой аналитической базы данных, поэтому давайте начнем с двух знакомых определений:

Хранилище данных - это просто база данных, которая содержит интегрированную и унифицированную информацию из одного или нескольких источников, собранных для поддержки анализа и отчетности. Эти источники могут быть вашими системами внутренней онлайн-транзакции (OLTP), такими как финансы, бухгалтерский учет, продажи, маркетинг, платежная ведомость, цепочка поставок и др. или внешние источники, такие как файлы поставщиков, приобретенные маркетинговые списки, Facebook, Twitter или данные переписи, и т.п.

В дополнение к хранилищу данных вы также можете использовать дополнительные типы баз данных для анализа и отчетности. Наиболее распространенными  являются витрины данных и операционные склады данных (ODS).

Business Intelligence (BI) включает в себя различные механизмы, используемые для работы с данными, хранящимися в базах данных. Приложения BI включают функции запроса, отчетности, анализа, статистики, включают прогнозные модели, информационные панели и ключевые показатели эффективности (KPI) и многое другое.

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

Зачем использовать agile-методологии?

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

Гибкие методологии предполагают подход, ориентированный на бизнес. Проще говоря, создание аналитических баз данных является процессом сложным, трудоемким и часто чрезмерно дорогостоящим, особенно когда используются традиционные, основанные на данных, методологии. Основополагающая истина BI и хранения данных заключается в том, что интеграция данных и гомогенизация составляют от 70% до 80% бюджета проекта, а риск достигает еще более высокого процента.

Давайте рассмотрим простой пример. Предположим, что ваша организация имеет четыре внутренних OLTP-системы и один внешний источник данных. В среднем каждая система имеет 30 таблиц базы данных, и каждая таблица содержит 30 столбцов. Это значит, что:

(4 OLTP-системы + 1 внешняя система)

x 30 таблиц x 30 столбцов

= 4500 элементов данных

При ориентированном на данные подходе нередко хочется интегрировать и гомогенизировать большинство (если не все) данные до того, как будет написан первый запрос или отчет. Это означает, что от 70 до 80% бюджета проекта будет расходовано еще до того,как стоимость бизнеса будет  реализована.  Точно так же интеграция тысяч полей может занять более 12 месяцев. Это означает, что ваша цель должна заключаться в минимизации усилий, связанных с интеграцией данных и гомогенизацией.

При гибкой разработке доступны только те данные, которые необходимы для ответа на конкретные бизнес-вопросы или для решения конкретных бизнес-задач. (Эти сообщения о необходимости фиксируются в серии ”истории бизнеса”.) Таким образом, вместо того, чтобы сначала пытаться объять необъятное, прикладывая огромные усилия по интеграции данных, специалисты-практики по agile-методам работают с бизнес-сообществом для определения сотен элементов данных, которые управляют производительностью. Это означает, что бизнес начнет получать прибыль гораздо быстрее - спустя недели или месяцы, а не сезон или годы.

Гибкие методологии снижают риски и вырабатывают системы с высокими уровнями усвоения. Организации, которые применяют традиционную каскадную модель к проектам BI к проектам BI или DW, рискуют получить систему, не удовлетворяющую потребности бизнеса. Каскадная модель предполагает, что вы получите или все, или ничего.  Другими словами, проектирование не может начаться пока не будут определены все требования, а кодирование не может начаться пока проектирование не будет завершено. Это означает, что риск проекта поэтапно возрастает, а стоимость бизнеса определяется в конце проекта.

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

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

Когда используются гибкие методологии, может отображаться текущее значение. Основные задачи проектирования базы данных - восстановление качества данных, интеграция данных и гомогенизация - разбиты на короткие, ограниченные по времени и объему циклы или «спринты», которые обычно занимают от двух до четырех недель каждый. Эти ориентированные на данные задачи сопряжены с прототипированием на уровне BI, что позволяет бизнесу многократно взаимодействовать с данными, обеспечивая действительно полезную информацию для аналитической базы данных

Использование спринтов поставки ведет к повышению стоимости бизнеса в начале проекта и снижает его риск до минимума. В конце каждого двух- четырехнедельного цикла спринтов команда доставки должна продемонстрировать свою работу, сделав ее более заметной для бизнеса и позволяя вносить коррективы в середине курса, потому что один из agile-принципов заключается в том, чтобы  немедленно прекратить работу (Fail Fast!) .

Быстрый расчет стоимости бизнеса

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

No Comments