Введение

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

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

На основании тройной стратегии, рекомендованной архитектуры, сформулированных принципов и лучших практик построения КХД предложен план управления проектом разработки программного обеспечения корпоративного хранилища данных. Компания IBM предлагает полный набор средств для интеграции данных, метаданных и нормативно-справочной информации (НСИ) на всех этапах жизненного цикла проекта создания КХД. Целью данной статьи является анализ упрощенного решения на основе программного обеспечения IBM Forms, IBM InfoSphere Warehouse и IBM Cognos BI. Решение должно быть масштабируемым и функционально расширяемым, легко интегрируемым в корпоративную ИТ инфраструктуру и способным стать основой для корпоративного хранилища данных.

В начало

Архитектура системы сбора и анализа первичных данных

В работах ^{1, 2} предложено типовое решение для системы сбора, хранения и анализа первичных данных ручного ввода. Напомним основные требования к системе:

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

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

На Рис. 1 представлена централизованная архитектура системы сбора, хранения и анализа данных, которая предполагает, что ввод данных может осуществляться удаленно, а все серверы сбора данных IBM Forms ³ , хранения данных InfoSphere Warehouse ⁴ и анализа и интерпретации данных Cognos ^5,6 установлены в едином центре обработки данных.

Посмотреть в увеличенном варианте.

Аналитики могут работать как локально, так и дистанционно, благодаря тому, что Cognos предоставляет Веб-интерфейс для подготовки и выполнения аналитических расчетов. Предложенная архитектура была основана на максимально простой конфигурации программного обеспечения для типовой задачи без учета специфических требований различных проектов. Несмотря на очевидные ограничения, предложенный подход может быть использован в качестве основы самых разных решений для различных отраслей и предприятий.

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

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

Как можно заметить, рассматриваемая архитектура системы сбора, хранения и анализа данных (Рис. 1) не содержит средств ведения метаданных или НСИ. На первый взгляд, это противоречит предложенной тройной стратегии создания хранилищ данных ⁷ , которая предполагает интеграцию данных, метаданных и НСИ. С другой стороны, не ясно, как решение соотносится с рекомендованной архитектурой хранилищ данных ⁸ , и чем отличается предложенный подход от многочисленных проектов, основная цель которых - демонстрация быстрого маленького успеха.

В начало

Место проектов ведения метаданных и НСИ

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

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

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

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

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

Централизованное ведение нормативно-справочной информации должно быть начато одновременно с ведением метаданных. Причина проста – НСИ и метаданные тесно связаны ⁷ , и ведение одного проекта без другого, как правило, не приводит к успеху.

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

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

В начало

Рекомендованная архитектура КХД

Рекомендованная архитектура корпоративного хранилища данных, предложенная в работе ⁸ построена в соответствии со следующими основными принципами.

• КХД является единым источником непротиворечивых данных и должно обеспечивать пользователей согласованными качественными данными из различных информационных систем.
• Данные должны быть доступны сотрудникам в объеме, необходимом и достаточном для выполнения своих функциональных обязанностей.
• Сотрудники должны иметь единое понимание данных, то есть, должно быть установлено единое смысловое пространство.
• Необходимо устранить конфликты в кодировках данных в системах - источниках.
• Аналитические вычисления должны быть отделены от оперативной обработки данных.
• Необходимо обеспечить и поддерживать многоуровневую организацию данных
• Необходимо следовать эволюционному подходу, позволяющему обеспечить непрерывность бизнеса и сохранить инвестиции в ИТ.
• Информационное наполнение будущего хранилища данных, этапность построения КХД и ввода функциональных моделей в эксплуатацию определяются, в первую очередь, требованиями бизнес - пользователей.
• Необходимо обеспечить защиту данных и их надежное хранение. Меры по защите информации должны быть адекватны ценности данных.

Архитектура, построенная в соответствии с этими принципами, следует принципам модульного конструирования «непотопляемых отсеков». Разделяя архитектуру на модули, мы одновременно концентрируем в них определенную функциональность (Рис. 2).

Средства очистки, преобразования и загрузки данных ETL (Extract, Trasform, Load) обеспечивают полный, надежный, точный сбор информации из источников данных благодаря сосредоточенной в ETL логике сбора, обработки и преобразования данных и взаимодействию с системами ведения метаданных и НСИ.

Средства очистки, преобразования и загрузки данных ETL (Extract, Trasform, Load) обеспечивают полный, надежный, точный сбор информации из источников данных благодаря сосредоточенной в ETL логике сбора, обработки и преобразования данных и взаимодействию с системами ведения метаданных и НСИ.

Система ведения метаданных является основным источником информации о данных в КХД. Система ведения метаданных поддерживает актуальность бизнес - метаданных, технических, операционных и проектных метаданных. Система ведения НСИ позволяет устранить конфликты в кодировках исходных данных в системах - источниках.

Центральное хранилище данных (ЦХД) несет только нагрузку по надежному защищенному хранению данных. Структура данных в ЦХД оптимизирована исключительно с целью обеспечения эффективного хранения данных. Средства выборки, реструктуризации и доставки данных (SRD) в такой архитектуре являются единственным пользователем ЦХД, беря на себя всю работу по заполнению витрин данных и снижая нагрузку на ЦХД по обслуживанию запросов пользователей.

Витрины данных содержат данные в структурах и форматах, оптимальных для решения задач пользователей данной витрины.

В начало

Связь архитектуры решения с рекомендованной архитектурой

Архитектура решения для системы сбора, хранения и анализа первичных данных на Рис. 3 переведена в термины рекомендованной архитектуры КХД и совмещена с ней.

Сбор данных осуществляется с помощью набора продуктов IBM Forms, который использует электронные формы для ручного ввода данных и позволяет передавать собранные данные в другие системы. Сервер приложений IBM Forms может быть в дальнейшем интегрирован с репозиториями структурированных и неструктурированных данных. Единственным источником данных в проекте являются формы, заполняемые по строгим правилам, поэтому на текущем этапе нет необходимости в средствах ETL выборки, преобразования и загрузки данных (например, DataStage). Однако, по мере развития проекта ожидается подключение других источников. Возможность использования средств ETL обеспечивает функциональную расширяемость системы без необходимости ее радикальной переработки.

Хранение данных реализовано с помощью IBM InfoSphere Warehouse. Анализ данных может быть выполнен средствами IBM InfoSphere Warehouse и IBM Cognos Business Intelligence (BI). IBM InfoSphere Warehouse предоставляет следующие инструменты анализа данных: реализация аналитической обработки OLAP на основе инструментов Cubing Services и Alphablox, интеллектуальный анализ данных с помощью программных средств Miningblox и Alphablox, интеллектуальный анализ данных с привлечением программного обеспечения Intelligent Miner.

Интегрированный программный комплекс для управления корпоративной эффективностью IBM Cognos 10 BI помогает аналитикам интерпретировать данные, возникающие в процессе деятельности компании. Используя IBM Cognos 10 BI, любой сотрудник организации может построить графики, сравнить план и факт, создать различные типы отчетов и встроить их в удобный портал; создать персонализированные панели управления (dashboard), выполнить анализ данных и провести мониторинг событий и метрик с целью выработки эффективных бизнес – решений.

Аналитический инструментарий может быть дополнен высокопроизводительным средством корпоративного планирования IBM Cognos TM1, которое предоставляет полную среду планирования для подготовки персонализированных бюджетов и прогнозов. Метаданные, полученные как побочный продукт согласования форм, и НСИ, как результат приведения данных к нормальной форме в реляционной базе данных КХД, являются прототипами будущих корпоративных систем управления метаданными и НСИ (Рис. 4).

Первые публикации о необходимости создания систем словарей-справочников появились в середине 80-х годов ⁹. В 1995г. была опубликована статья ¹⁰ , в которой было указано, что для успешной интеграции данных необходимо организовать и поддерживать поток метаданных. Современная практика показывает, что это требование нуждается в уточнении, так как метаданные порождаются на всех этапах создания и эксплуатации информационных систем. Связь между данными, НСИ и метаданными подробно рассмотрена в работе ⁸ , в которой было показано, что НСИ содержит бизнес - метаданные и технические метаданные.

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

В начало

Сравнение предлагаемого и существующих подходов

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

Разработка корпоративного хранилища данных в глазах проектной команды была равносильна «большому взрыву», создавшему Вселенную. Проектная команда, избегая решений уровня предприятия, внедрила системы ведения метаданными и НСИ для одной специфической области деятельности. Поэтому репозиторий финансовых данных является узкотематической витриной для финансовой отчетности (Рис. 5).

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

Как видим, основная цель этого проекта - демонстрация быстрого маленького успеха. Многие из нас были поставлены в такую же ситуацию, когда было необходимо срочно продемонстрировать пусть маленькую, но работающую систему. Опытный разработчик понимает, что ему придется последовать совету Брукса ¹³ и выбросить эту первую версию. Причина заключается в том, что цена переработки созданных приложений и их включения в корпоративную инфраструктуру будет чрезмерно высока из-за отсутствия согласованных метаданных и НСИ.

В начало

Итоговая архитектура реализации существующих подходов

Коротко суммируем итоги выполненного анализа.

1. Существующие подходы фактически внедряют разрозненные прикладные витрины данных. Данные в витринах могут иметь ценность внутри подразделений, но не для компании в целом, из-за невозможности их сведения вследствие разного смысла данных и их кодировки.
2. Распространено убеждение, что создание корпоративного хранилища данных подобно смертельному трюку с непредсказуемыми последствиями, поэтому зачастую выбирается создание локальных витрин без учета развития КХД в целом.
3. Требование мгновенных результатов вызывает стремление разработать и внедрить какое-нибудь ограниченное решение без связи с остальными задачами.

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

В результате пользователи независимых прикладных витрин говорят на разных языках бизнеса, и каждая витрина содержит собственные метаданные. Другая проблема заключается в различии нормативно-справочной информации, используемых в независимых витринах данных. Разница в кодировке данных, в используемых кодификаторах, справочниках, классификаторах, идентификаторах, нормативах и словарях делает невозможным объединение этих данных без серьезного анализа, проектирования и разработки средств ведения НСИ.

Так в компании создаются несколько хранилищ несогласованных данных, что в корне противоречит самой идее создания КХД как единого и единственного источника очищенных, согласованных и непротиворечивых исторических данных. Отсутствие корпоративного ведения метаданных и НСИ (затенены на Рис. 6) еще более затрудняют возможность согласовать данные между собой.

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

Таким образом, стремление к достижению сиюминутных результатов и к демонстрации быстрых успехов приводит к отказу от единого, сквозного управления метаданными и НСИ. Итогом такого подхода является наличие семантических островов, где сотрудники говорят на разных бизнес – языках. Полная переработка корпоративной архитектуры интеграции данных становится настоятельной необходимостью и приводит к повторному расходу средств и времени на создание полноценного КХД (Рис. 6).

В начало

Тройная стратегия и планирование создания КХД

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

Роль компаса, указывающего на глобальные цели, отводится скоординированной интеграции данных, метаданных и НСИ (Рис. 7):

1. интеграция НСИ, нацеленное на устранение избыточности и несовместимости данных;
2. интеграция метаданных, направленное на обеспечение единого понимания данных и метаданных;
3. интеграция данных, целью которой является предоставление конечным пользователям единой версии правды на основе согласованных метаданных и НСИ

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

Поэтому на первой фазе следует выбрать 2-3 пилотных проекта. Основными критериями выбора этих проектов являются поддержка руководства и готовность пользователей и экспертов участвовать в постановке задачи. Проекты должны обеспечить минимально приемлемую функциональность будущего КХД.

В качестве условного примера на Рис. 7 выбраны следующие пилотные проекты для реализации на первой фазе:

1. интеллектуальный анализ данных (data mining) на основе Intelligent Miner (IM);
2. многомерный анализ (OLAP) с помощью Cubing Services и Alphablox;
3. анализ неструктурированного текста с использованием программных инструментов Unstructured Text Analysis Tools (UTAT).

Все перечисленные инструменты, используемые на первой фазе пилотных проектов, входят в состав IBM InfoSphere Warehouse. Очень важно, чтобы в результате реализации этих коротких проектов пользователи ощутили реальные преимущества КХД. Совместно с пользователями необходимо выполнить анализ результатов внедрения проектов и определить, при необходимости, меры по изменению среды КХД и внести коррективы в мероприятия по интеграции данных, метаданных и НСИ.

Следующим шагом необходимо отобрать 3-4 новых проекта, которые бы продвинули компанию к созданию базовой функциональности перспективного КХД. Желательно, чтобы в отборе участвовали все заинтересованные стороны – руководство компании, пользователи, эксперты, проектная команда и специалисты по эксплуатации и поддержки КХД. Централизованная среда управления данными, метаданными и НСИ должна быть достаточна развита, чтобы соответствовать требованиям базовой функциональности КХД.

Допустим, что на второй фазе выбраны для реализации следующие проекты и инструменты:

1. построение отчетов и исследование данных с помощью Cognos Business Insight Advanced и Report Studio;
2. создание сложных интерактивных панелей управления (dashboard) на основе Cognos Business Insight;
3. Сценарный анализ с использованием Cognos TM1;
4. Корпоративное планирование с помощью Cognos TM1.

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

Итак, примерный план по созданию КХД может выглядеть следующим образом:

• Стратегические задачи:
  • Скоординированная интеграция данных, метаданных и НСИ
• Тактические задачи:
  • Выбор 2-3 проектов для демонстрации преимуществ КХД
  • Создание централизованной среды управления данными, метаданными и НСИ
  • Анализ результатов и изменение среды КХД при необходимости
  • Внедрение 3-4 проектов с учетом полученного опыта
  • В случае успеха – развитие КХД в масштабах компании
  • Промышленная эксплуатация КХД и создание новых задач, постановка и решение которых стало возможным благодаря накопленному опыту эксплуатации КХД

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

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

В начало

Заключение

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

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

В начало

Литература.

¹ Асадуллаев C. “Система сбора и анализа первичных данных – I. Постановка задачи, сбор и хранение данных ”, 2011

² Асадуллаев C. “Система сбора и анализа первичных данных – II. Анализ первичных данных”, 2011,

³ IBM, “IBM Forms documentation”, 2010

⁴ IBM, “InfoSphere Warehouse overview 9.7”, 2010

⁵ IBM, “Cognos Business Intelligence”, 2010

⁶ IBM, “Cognos TM1”, 2010

⁷ Асадуллаев С. “Данные, метаданные и НСИ: тройная стратегия создания хранилищ данных”.

⁸ Асадуллаев С. “Архитектуры хранилищ данных – III”, 2009

⁹ Leong-Hong B.W., Plagman B.K. “Data Dictionary / Directory Systems”. John Wiley & Sons. 1982. (Леонг-Хонг Б., Плагман Б. “Системы словарей-справочников данных”, М.: Финансы и статистика, 1986)

¹⁰ Hackathorn R. “Data Warehousing Energizes Your Enterprise”, Datamation, Feb.1, 1995, p. 39.

¹¹ Асадуллаев С. “Управление качеством данных с помощью IBM Information Server”, 2010

¹² Financial Service Technology. «Mastering financial systems success», 2009, http://www.usfst.com/article/Issue-2/Business-Process/Mastering-financial-systems-success/

¹³ Brooks F. P. “The Mythical Man-Month: Essays on Software Engineering”, Addison-Wesley Professional; Anniversary edition, 1995. (Брукс Ф., «Мифический человеко-месяц или Как создаются программные системы», Символ-Плюс, 2010).

Об авторе

Сабир Асадуллаев более 25 лет работает в информационных технологиях. Является специалистом в области проектирования хранилищ данных и ведения корпоративных метаданных. Руководил ИТ проектами в нефтегазовой отрасли, в банковской сфере, на транспорте, в науке и других областях в Европе и в Северной Америке. Обладает опытом организации коллективной разработки программного обеспечения и создания офиса управления проектами (PMO). Работая в IBM c 2006г, подготовил ряд ключевых архитектурных решений для крупнейших клиентов IBM. Окончил физический факультет МГУ (1979), кандидат физ-мат. наук (1986), сертифицированный руководитель проектов (2001), лучший архитектор CEMAAS IBM (2006), сертифицированный архитектор корпоративных решений IBM (2008), исполнительный архитектор (2010). Автор более 30 публикаций в ИТ, астрономии и биологии.

Оценить эту статью

Комментарии

В начало

Содержание

• Введение
• Архитектура системы сбора и анализа первичных данных
• Место проектов ведения метаданных и НСИ
• Рекомендованная архитектура КХД
• Связь архитектуры решения с рекомендованной архитектурой
• Сравнение предлагаемого и существующих подходов
• Итоговая архитектура реализации существующих подходов
• Тройная стратегия и планирование создания КХД
• Заключение
• Литература.
• Об авторе
• Комментарии