- •Оглавление
- •Список иллюстраций
- •Список таблиц
- •Вступительное слово компании «Юнидата»
- •Вступительное слово компании BSSG
- •Предисловие
- •Глава 1. Управление данными
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Цели
- •2. ОСНОВНЫЕ ПОНЯТИЯ И КОНЦЕПЦИИ
- •2.1 Данные
- •2.2 Данные и информация
- •2.3 Данные как актив организации
- •2.4 Принципы управления данными
- •2.5 Проблемы управления данными
- •2.6 Стратегия управления данными
- •3. РАМОЧНЫЕ СТРУКТУРЫ УПРАВЛЕНИЯ ДАННЫМИ
- •3.1 Модель стратегического выравнивания
- •3.2 Амстердамская информационная модель
- •3.3 Рамочная структура DAMA-DMBOK
- •3.4 Пирамида DMBOK (Айкен)
- •3.5 Дальнейшая эволюция рамочной структуры управления данными DAMA
- •4. DAMA И DMBOK
- •5. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 2. Этика обращения с данными
- •1. ВВЕДЕНИЕ
- •2. БИЗНЕС-ДРАЙВЕРЫ
- •3. ОСНОВНЫЕ ПОНЯТИЯ И КОНЦЕПЦИИ
- •3.1 Этические принципы, связанные с данными
- •3.2 Основополагающие принципы законодательства о конфиденциальности данных
- •3.3 Этические аспекты работы с данными в режиме онлайн
- •3.4 Риски, обусловленные неэтичными практиками обращения с данными
- •3.5 Формирование культуры этичного обращения с данными
- •3.6 Этика обращения с данными и руководство данными
- •4. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 3. Руководство данными
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Цели и принципы
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 Определение задач и функций руководства данными в организации
- •2.2 Проведение оценки готовности
- •2.3 Выявление возможностей / угроз и согласование с бизнесом
- •2.4 Создание точек взаимодействия внутри организации
- •2.5 Разработка стратегии руководства данными
- •2.6 Определение операционной рамочной структуры руководства данными
- •2.7 Выработка целей, принципов и политик
- •2.8 Поддержка проектов в области управления данными
- •2.9 Внедрение практики управления организационными изменениями
- •2.10 Внедрение практики управления проблемными вопросами
- •2.11 Оценка требований по нормативно-правовому соответствию
- •2.12 Внедрение руководства данными
- •2.13 Поддержка стандартов и процедур
- •2.14 Разработка бизнес-глоссария
- •2.15 Координация взаимодействия с архитектурными группами
- •2.16 Оказание содействия в финансовой оценке данных
- •2.17 Встраивание руководства данными в процессы
- •3. ИНСТРУМЕНТЫ И МЕТОДЫ
- •3.1 Присутствие в Сети / Веб-сайты
- •3.2 Бизнес-глоссарий
- •3.3 Инструменты для управления потоками работ
- •3.4 Инструменты для управления документами
- •3.5 Оценочная ведомость руководства данными
- •4. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ
- •4.1 Организация и культура
- •4.2 Согласование действий и коммуникации
- •5. МЕТРИКИ
- •6. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 4. Архитектура данных
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Результаты и практики разработки архитектуры данных
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 Внедрение практики разработки и сопровождения архитектуры данных
- •2.2 Интеграция с корпоративной архитектурой
- •3. ИНСТРУМЕНТЫ
- •3.1 Инструменты моделирования данных
- •3.2 Программное обеспечение для управления ИТ-активами
- •3.3 Приложения для графического проектирования
- •4. МЕТОДЫ
- •4.1 Проекции на фазы жизненного цикла
- •4.2 Четкость и ясность графических представлений
- •5. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ
- •5.1 Оценка готовности / Оценка рисков
- •5.2 Организационные и культурные изменения
- •6. РУКОВОДСТВО АРХИТЕКТУРОЙ ДАННЫХ
- •6.1 Метрики
- •7. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 5. Моделирование и проектирование данных
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Цели и принципы
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 План проведения работ по моделированию данных
- •2.2 Построение модели данных
- •2.3 Проверка и оценка качества моделей данных
- •2.4 Сопровождение моделей данных
- •3. ИНСТРУМЕНТЫ
- •3.1 Инструменты моделирования данных
- •3.2 Инструменты для отслеживания происхождения данных
- •3.3 Инструменты профилирования данных
- •3.4 Репозитории метаданных
- •3.5 Шаблоны моделей данных
- •3.6 Отраслевые модели данных
- •4. ЛУЧШИЕ ПРАКТИКИ
- •4.1 Лучшие практики в области соглашений об именовании
- •4.2 Лучшие практики проектирования баз данных
- •5. РУКОВОДСТВО МОДЕЛИРОВАНИЕМ И ПРОЕКТИРОВАНИЕМ ДАННЫХ
- •5.1 Управление качеством моделей и проектных решений
- •5.2 Метрики моделирования данных
- •6. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 6. Хранение и операции с данными
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Цели и принципы
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 Управление технологиями баз данных
- •2.2 Управление базами данных
- •3. ИНСТРУМЕНТЫ
- •3.1 Инструменты моделирования данных
- •3.2 Инструменты мониторинга баз данных
- •3.3 Инструменты управления конфигурацией баз данных
- •3.4 Инструменты разработки приложений
- •4. МЕТОДЫ
- •4.1 Тестирование в средах более низкого уровня
- •4.2 Стандарты именования для физической модели данных
- •4.3 Использование сценариев для внесения любых изменений
- •5. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ
- •5.1 Оценка готовности / Оценка рисков
- •5.2 Организационные и культурные изменения
- •6. РУКОВОДСТВО ХРАНЕНИЕМ И ОПЕРАЦИЯМИ С ДАННЫМИ
- •6.1 Метрики
- •6.2 Отслеживание и учет информационных активов
- •6.3 Аудит и проверка корректности данных
- •7. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 7. Безопасность данных
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Цели и принципы
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 Выявление требований по безопасности данных
- •2.2 Определение политики безопасности данных
- •2.3 Определение стандартов в области безопасности данных
- •3. ИНСТРУМЕНТЫ
- •3.1 Антивирусное программное обеспечение
- •3.2 Протокол HTTPS
- •3.3 Технологии управления идентификацией
- •3.4 Системы обнаружения и предотвращения вторжений
- •3.5 Межсетевые экраны
- •3.6 Отслеживание метаданных
- •3.7 Маскировка / Шифрование данных
- •4. МЕТОДЫ
- •4.1 Использование CRUD-матриц
- •4.2 Немедленное развертывание обновлений безопасности
- •4.3 Атрибуты безопасности в метаданных
- •4.4 Метрики
- •4.5 Учет потребностей в безопасности данных в проектных требованиях
- •4.6 Эффективный поиск в массиве зашифрованных данных
- •4.7 Санитизация документов
- •5. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ
- •5.1 Оценка готовности / Оценка рисков
- •5.2 Организационные и культурные изменения
- •5.3 Доступность информации о наборах прав пользователей
- •5.4 Обеспечение безопасности данных в условиях аутсорсинга
- •5.5 Обеспечение безопасности данных в облачных средах
- •6. РУКОВОДСТВО БЕЗОПАСНОСТЬЮ ДАННЫХ
- •6.1 Безопасность данных и корпоративная архитектура
- •7. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 8. Интеграция и интероперабельность данных
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Цели и принципы
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 Планирование и анализ
- •2.2 Проектирование решений по интеграции данных
- •2.3 Разработка решений по интеграции данных
- •2.4 Внедрение и мониторинг
- •3. ИНСТРУМЕНТЫ
- •3.1 Программный комплекс для преобразования данных / ETL-инструмент
- •3.2 Сервер виртуализации данных
- •3.3 Корпоративная шина данных (ESB)
- •3.4 Программный комплекс для управления бизнес-правилами
- •3.5 Инструменты моделирования данных и процессов
- •3.6 Инструменты профилирования данных
- •3.7 Репозиторий метаданных
- •4. МЕТОДЫ
- •5. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ
- •5.1 Оценка готовности / Оценка рисков
- •5.2 Организационные и культурные изменения
- •6. РУКОВОДСТВО DII
- •6.1 Соглашения о совместном доступе к данным
- •6.2 DII и происхождение данных
- •6.3 Метрики для оценки эффективности интеграции данных
- •7. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 9. Управление документами и контентом
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Цели и принципы
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 Планирование управления жизненным циклом
- •2.2 Управление жизненным циклом документов и контента
- •2.3 Публикация и доставка контента
- •3. ИНСТРУМЕНТЫ
- •3.1 Системы управления корпоративным контентом
- •3.2 Инструменты поддержки совместной работы
- •3.3 Инструменты управления контролируемыми словарями и метаданными
- •3.4 Стандартные форматы разметки и обмена
- •3.5 Технологии e-discovery
- •4. МЕТОДЫ
- •4.1 Сценарий подготовки электронной доказательной базы
- •4.2 Карта данных, которые могут быть найдены и представлены
- •5. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ
- •5.1 Оценка готовности / Оценка рисков
- •5.2 Организационные и культурные изменения
- •6. РУКОВОДСТВО УПРАВЛЕНИЕМ ДОКУМЕНТАМИ И КОНТЕНТОМ
- •6.1 Рамочные структуры руководства информацией
- •6.2 Рост объемов информации
- •6.3 Управление качеством контента
- •6.4 Метрики
- •7. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 10. Справочные и основные данные
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Цели и принципы
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 Работы по управлению основными данными
- •2.2 Работы по управлению справочными данными
- •3. ИНСТРУМЕНТЫ И МЕТОДЫ
- •4. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ
- •4.1 Строгое следование архитектуре основных данных
- •4.2 Мониторинг движения данных
- •4.3 Управление изменениями справочных данных
- •4.4 Соглашения о совместном использовании данных
- •5. ОРГАНИЗАЦИОННЫЕ И КУЛЬТУРНЫЕ ИЗМЕНЕНИЯ
- •6. РУКОВОДСТВО СПРАВОЧНЫМИ И ОСНОВНЫМИ ДАННЫМИ
- •6.1 Метрики
- •7. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 11. Ведение хранилищ данных и бизнес-аналитика
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Цели и принципы
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 Выработка понимания требований к DW
- •2.2 Определение и сопровождение архитектуры DW/BI
- •2.3 Проектирование и разработка хранилища и витрин данных
- •2.4 Заполнение хранилища данных
- •2.5 Внедрение портфеля инструментов BI
- •2.6 Сопровождение информационных продуктов
- •3. ИНСТРУМЕНТЫ
- •3.1 Репозиторий метаданных
- •3.2 Средства интеграции данных
- •3.3 Типы инструментов BI
- •4. МЕТОДЫ
- •4.1 Прототипирование с целью уточнения требований
- •4.2 BI по принципу самообслуживания
- •4.3 Открытые для пользователей данные аудита
- •5. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ
- •5.1 Оценка готовности / Оценка рисков
- •5.2 Дорожная карта выпуска релизов
- •5.3 Управление конфигурациями
- •5.4 Организационные и культурные изменения
- •6. РУКОВОДСТВО DW/BI
- •6.1 Обеспечение одобрения со стороны бизнеса
- •6.2 Удовлетворенность клиентов/пользователей
- •6.3 Соглашения об уровне обслуживания
- •6.4 Стратегия в области отчетности
- •6.5 Метрики
- •7. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 12. Управление метаданными
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Цели и принципы
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 Определение стратегии работы с метаданными
- •2.2 Выработка понимания требований к метаданным
- •2.3 Определение архитектуры метаданных
- •2.4 Создание и ведение метаданных
- •2.5 Применение метаданных в аналитике и при формировании запросов и отчетов
- •3. ИНСТРУМЕНТЫ
- •3.1 Инструменты управления репозиторием метаданных
- •4. МЕТОДЫ
- •4.1 Отслеживание происхождения и анализ влияния
- •4.2 Метаданные для обработки больших данных
- •5. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ
- •5.1 Оценка готовности / Оценка рисков
- •5.2 Организационные и культурные изменения
- •6. РУКОВОДСТВО МЕТАДАННЫМИ
- •6.1 Механизмы контроля процессов
- •6.2 Документация, описывающая метаданные
- •6.3 Стандарты и руководства
- •6.4 Метрики
- •7. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 13. Качество данных
- •1. ВВЕДЕНИЕ
- •1.2 Цели и принципы
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 Определение данных высокого качества
- •2.2 Определение стратегии качества данных
- •2.3 Определение критически важных данных и бизнес-правил
- •2.4 Проведение первичной оценки качества данных
- •2.5 Выявление и приоритизация потенциальных улучшений
- •2.6 Определение целей повышения качества данных
- •2.7 Разработка и внедрение операционных процедур обеспечения качества данных
- •3. ИНСТРУМЕНТЫ
- •3.1 Инструменты профилирования данных
- •3.2 Инструменты формирования запросов к данным
- •3.3 Инструменты моделирования данных и средства ETL
- •3.4 Шаблоны правил качества данных
- •3.5 Репозитории метаданных
- •4. МЕТОДЫ
- •4.1 Превентивные меры
- •4.2 Корректирующие меры
- •4.3 Программные модули проверки и аудита качества
- •4.4 Эффективные метрики качества данных
- •4.5 Статистическое управление процессами
- •4.6 Выявление и анализ корневых причин
- •5. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ
- •5.1 Оценка готовности / Оценка рисков
- •5.2 Организационные и культурные изменения
- •6. РУКОВОДСТВО КАЧЕСТВОМ ДАННЫХ
- •6.1 Политика в области качества данных
- •6.2 Метрики
- •7. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 14. Большие данные и наука о данных
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Принципы
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 Стратегическое планирование потребностей бизнеса в больших данных
- •2.2 Выбор источников данных
- •2.3 Определение источников и загрузка данных
- •2.4 Выработка гипотез и выбор методов
- •2.5 Предварительная интеграция / Cогласование данных для анализа
- •2.6 Исследование данных с помощью моделей
- •2.7 Внедрение и мониторинг
- •3. ИНСТРУМЕНТЫ
- •3.1 Технологии и архитектуры MPP без разделения ресурсов
- •3.2 Базы данных на основе распределенных файловых систем
- •3.3 Алгоритмы «в базе данных»
- •3.4 Облачные хранилища больших данных
- •3.5 Языки статистических вычислений и графических представлений
- •3.6 Средства визуализации данных
- •4. МЕТОДЫ
- •4.1 Аналитическое моделирование
- •4.2 Моделирование больших данных
- •5. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ
- •5.1 Согласование со стратегией организации
- •5.2 Оценка готовности / Оценка рисков
- •5.3 Организационные и культурные изменения
- •6. РУКОВОДСТВО В ОБЛАСТИ БОЛЬШИХ ДАННЫХ И НАУКИ О ДАННЫХ
- •6.1 Управление каналами визуализации
- •6.2 Наука о данных и стандарты визуализации
- •6.3 Безопасность данных
- •6.4 Метаданные
- •6.5 Качество данных
- •6.6 Метрики
- •7. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 15. Оценка зрелости управления данными
- •1. ВВЕДЕНИЕ
- •1.1 Бизнес-драйверы
- •1.2 Цели и принципы
- •1.3 Основные понятия и концепции
- •2. ПРОВОДИМЫЕ РАБОТЫ
- •2.1 Планирование работ по оценке
- •2.2 Проведение оценки зрелости
- •2.3 Интерпретация результатов
- •2.4 Создание целевой программы совершенствования управления данными
- •2.5 Проведение повторных оценок зрелости
- •3. ИНСТРУМЕНТЫ
- •4. МЕТОДЫ
- •4.1 Выбор рамочной структуры DMM
- •4.2 Возможность использования рамочной структуры DAMA-DMBOK
- •5. РЕКОМЕНДАЦИИ ПО ВНЕДРЕНИЮ DMMA
- •5.1 Оценка готовности / Оценка рисков
- •5.2 Организационные и культурные изменения
- •6. РУКОВОДСТВО УПРАВЛЕНИЕМ ЗРЕЛОСТЬЮ
- •6.1 Надзор за процессом DMMA
- •6.2 Метрики
- •7. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 16. Организация управления данными и ролевые ожидания
- •1. ВВЕДЕНИЕ
- •2. ВЫРАБОТКА ПОНИМАНИЯ СУЩЕСТВУЮЩЕЙ ОРГАНИЗАЦИОННОЙ СИСТЕМЫ И КУЛЬТУРНЫХ НОРМ
- •3. СТРУКТУРЫ ОРГАНИЗАЦИОННЫХ СИСТЕМ УПРАВЛЕНИЯ ДАННЫМИ
- •3.1 Децентрализованная операционная модель
- •3.2 Сетевая операционная модель
- •3.3 Централизованная операционная модель
- •3.4 Гибридная операционная модель
- •3.5 Федеративная операционная модель
- •3.6 Выбор оптимальной для организации операционной модели
- •3.7 Альтернативные варианты организационной системы и соображения проектирования
- •4. КРИТИЧЕСКИЕ ФАКТОРЫ УСПЕХА
- •4.1 Куратор в высшем руководстве
- •4.3 Упреждающее планирование изменений
- •4.4 Согласование позиций руководства
- •4.5 Прямая и обратная связь
- •4.6 Обеспечение заинтересованности и участия
- •4.7 Ориентировка, инструктаж и подготовка
- •4.8 Мониторинг восприятия и освоения новых методов
- •4.9 Соблюдение руководящих принципов
- •4.10 Эволюции — да! Революции — нет!
- •5. ПОСТРОЕНИЕ ОРГАНИЗАЦИОННОЙ СИСТЕМЫ УПРАВЛЕНИЯ ДАННЫМИ
- •5.1 Выявление действующих участников управления данными
- •5.2 Определение состава участников Координационного комитета
- •5.3 Выявление и анализ заинтересованных сторон
- •5.4 Привлечение заинтересованных сторон
- •6. ВЗАИМОДЕЙСТВИЕ DMO С ДРУГИМИ ОРГАНАМИ УПРАВЛЕНИЯ
- •6.1 Директор по данным
- •6.2 Руководство данными
- •6.3 Управление качеством данных
- •6.4 Корпоративная архитектура
- •6.5 Особенности управления данными, присущие глобальным организациям
- •7. РОЛИ В ОБЛАСТИ УПРАВЛЕНИЯ ДАННЫМИ
- •7.1 Организационные роли
- •7.2 Индивидуальные роли
- •8. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Глава 17. Управление данными и управление организационными изменениями
- •1. ВВЕДЕНИЕ
- •2. ЭМПИРИЧЕСКИЕ ЗАКОНЫ ПРАКТИКИ ИЗМЕНЕНИЙ
- •3. УПРАВЛЯТЬ НЕ ИЗМЕНЕНИЯМИ, А ПРОЦЕССОМ ПЕРЕХОДА
- •4. ВОСЕМЬ ОШИБОК УПРАВЛЕНИЯ ИЗМЕНЕНИЯМИ ПО КОТТЕРУ
- •4.1 Ошибка № 1: самонадеянность
- •4.2 Ошибка № 2: неспособность создать достаточно мощную поддержку сверху
- •4.6 Ошибка № 6: пренебрежение созиданием краткосрочных побед
- •4.7 Ошибка № 7: преждевременное объявление о победе
- •4.8 Ошибка № 8: Пренебрежение закреплением перемен в корпоративной культуре
- •5. ВОСЕМЬ СТАДИЙ ПРОВЕДЕНИЯ КРУПНОЙ РЕФОРМЫ ПО КОТТЕРУ
- •5.1 Выработка всеобщего понимания ситуации и безотлагательности перемен
- •5.2 Руководящая коалиция
- •6. ФОРМУЛА ИЗМЕНЕНИЙ
- •7. ДИФФУЗИЯ ИННОВАЦИЙ И ПОДДЕРЖАНИЕ ИЗМЕНЕНИЙ
- •7.1 Главные трудности на пути распространения инноваций
- •7.2 Ключевые элементы диффузии инноваций
- •7.3 Пять стадий восприятия инновации
- •7.4 Субъективные причины неприятия или отторжения инноваций и изменений
- •8. ОБЕСПЕЧЕНИЕ ПОДДЕРЖКИ ИЗМЕНЕНИЙ
- •8.1 Острота чувства неотложности или неудовлетворенности
- •8.3 Состав руководящей коалиции
- •8.4 Объективность и осязаемость улучшений
- •9. ДОНЕСЕНИЕ ЦЕННОСТИ УПРАВЛЕНИЯ ДАННЫМИ ДО ВСЕОБЩЕГО ПОНИМАНИЯ
- •9.1 Базовые принципы коммуникаций
- •9.2 Оценка информированности и подготовка целевой аудитории
- •9.3 Задействование элементов неформального общения
- •9.4 План коммуникаций
- •9.5 Продолжение осуществления коммуникаций по завершении внедрения программы управления данными
- •10. ЦИТИРУЕМАЯ И РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА
- •Выражение признательности
- •Предметный указатель
- •Именной указатель
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
Рисунок 26 представляет пример традиционной высокоуровневой диаграммы потоков дан ных между системами с краткими описаниями видов перемещающихся данных. Подобные диа граммы могут быть построены в различных форматах и описывать движение данных на различ ных уровнях детализации.
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
2. ПРОВОДИМЫЕ РАБОТЫ
Создание архитектуры данных (и архитектуры предприятия) сопряжено с необходимостью учета сложного комплекса вопросов, обусловленных следующими двумя основными точками зрения на архитектурные решения.
Ориентированная на качество. Основное внимание направлено на совершенствование дея тельности в рамках бизнес-цикла и цикла разработки в области ИТ. Без должного управле ния архитектурой качество архитектурных решений ухудшается. Системы со временем будут чрезмерно усложняться и утрачивать гибкость, а это создает дополнительные риски для ор ганизации. Неконтролируемое распространение и копирование данных, запутанные взаимо связи делают организации менее эффективными и снижают доверие к данным.
Ориентированная на инновации. Основное внимание направлено на трансформацию биз неса и ИТ в свете новых ожиданий и перспектив. Продвигать инновации за счет внедрения прорывных технологий и методов использования данных — еще одна задача современного корпоративного архитектора.
К двум этим драйверам нужно подходить дифференцированно. Подход, ориентированный на ка чество, укладывается в традиционное представление о работе по проектированию архитектуры, предусматривающее ее поэтапное совершенствование. Архитектурные задачи распределяются по проектам, в которых принимают участие архитекторы (или соответствующая работа выполняется с помощью делегирования). В любом случае архитектор, как правило, не теряет из виду цельность архитектуры и руководствуется долгосрочными установками, связанными с руководством данны ми, стандартизацией и структурированной разработкой. При подходе же, ориентированном на ин новации, может рассматриваться краткосрочная перспектива, а также предполагается использова ние еще не апробированных схем ведения бизнеса и передовых технологий. Такая направленность часто требует, чтобы архитекторы вступали в контакт с теми людьми внутри организации, которые обычно не входят в круг общения профессионалов в сфере ИТ (например, с представителями под разделений, отвечающих за разработку новых продуктов или бизнес-моделей).
2.1 Внедрение практики разработки и сопровождения архитектуры данных
В идеале архитектура данных должна быть неотъемлемой частью архитектуры предприятия. Но если в организации не внедрена функция поддержки корпоративной архитектуры, она тем
Архитектура данных |
125 |
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
|
X |
|
|
|
|
|
|||
|
|
- |
|
|
|
|
|
d |
|
||
|
|
F |
|
|
|
|
|
|
t |
|
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
||
|
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
|
to |
|
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
||
|
|
w |
|
|
|
|
|
|
|
o |
|
|
|
|
|
|
|
|
|
|
|
||
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
|
-x cha |
|
|
|
|
не менее может создать команду по поддержке архитектуры данных. В таком случае она должна определить и принять концептуальную рамочную структуру, которая поможет четко сформу лировать цели и драйверы поддержки архитектуры данных. Эти драйверы в дальнейшем будут влиять на подход, содержание и приоритеты, отражаемые в дорожной карте.
Рамочную структуру следует выбирать согласно роду деятельности (то есть в госсекторе долж на использоваться модель, предназначенная для государственных организаций; в бизнесе — для коммерческих, и т. п.). Представления и таксономия, определяемые рамочной структурой, долж ны быть полезными и понятными с точки зрения различных заинтересованных сторон. В рамках инициатив по созданию архитектуры данных это вдвойне важно, поскольку именно на данном этапе определяется системная и бизнес-терминология. Архитектура данных находится в тесной и неразрывной связи с архитектурой бизнеса.
Практика разработки и сопровождения корпоративной архитектуры данных обычно включа ет проведение работ (последовательное или параллельное) по следующим направлениям.
Стратегия. Выбор рамочных моделей, формулировка подходов, разработка дорожных карт.
Признание и культура. Информирование и мотивирование к изменениям поведения.
Организация. Организация деятельности в области архитектуры данных посредством рас пределения обязанностей и внедрения механизма подотчетности.
Рабочие методы. Определение лучших практик и проведение работ в области архитектуры данных в рамках проектов организации, связанных с разработкой, c учетом координации с работами в области корпоративной архитектуры.
Результаты. Предоставление артефактов архитектуры данных в соответствии с дорожной картой.
Кроме того, корпоративная архитектура данных влияет на содержание и границы проектов, а также на разрабатываемые системы.
Определение проектных требований в области данных. Архитектура данных накладывает определенные требования в части корпоративных данных по каждому отдельному проекту.
Проверка проектных решений в области данных. Проведение анализа проектных решений позволяет убедиться в том, что концептуальные, логические и физические модели данных проекта согласуются с архитектурой и обеспечат поддержку долгосрочной стратегии разви тия организации.
Определение и учет факторов, оказывающих влияние на происхождение данных. Гарантирует, что бизнес-правила в приложениях, задействованных по всему потоку данных, являют ся согласующимися и прослеживаемыми.
Контроль репликации данных. Репликация является распространенным способом повы шения производительности приложения и облегчения доступа к данным, но может приве сти к их несогласованности. Руководство архитектурой данных дает уверенность в наличии
126 |
Г Л А В А 4 |
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
|
X |
|
|
|
|
|
|||
|
|
- |
|
|
|
|
|
d |
|
||
|
|
F |
|
|
|
|
|
|
t |
|
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
||
|
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
|
to |
|
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
||
|
|
w |
|
|
|
|
|
|
|
o |
|
|
|
|
|
|
|
|
|
|
|
||
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
|
-x cha |
|
|
|
|
достаточного контроля репликации (методов и механизмов), поддерживающего требуемый уровень согласованности. (При этом следует заметить, что согласованность данных требуется не для всех приложений.)
Обеспечение соблюдения стандартов архитектуры данных. Разработка и обеспечение со блюдения стандартов в отношении жизненного цикла архитектуры данных. Стандарты мо гут быть сформулированы в виде принципов, процедур и руководств, а также представлены в формате рабочих документов, описывающих ожидания по обеспечению соответствия.
Стимулирование использования новейших технологий работы с данными и решений по проведению обновлений. Архитектура данных совместно с архитектурой предприятия обес печивают предоставление возможностей по регулярному обновлению применяемых техноло гий работы с данными. Для этого предусматриваются механизмы управления версиями, паке тами обновлений и политиками, которые использует каждое приложение, а также дорожная карта внедрения новых технологий.
2.1.1 Оценка существующих спецификаций архитектуры данных
В любой организации имеется представленная в том или ином виде документация на существую щие системы. Необходимо идентифицировать эти документы и оценить их на предмет точности, полноты и уровня детализации, а при необходимости доработать и привести в соответствие с те кущим состоянием.
2.1.2 Разработка дорожной карты
Если бы организация создавалась с чистого листа (вне всякой привязки к существующим про цессам), оптимальная архитектура должна была бы основываться исключительно на данных, тре буемых для эффективной работы подразделений; приоритеты определялись бы исключительно бизнес-стратегией, а решения принимались без учета предыдущей деятельности. В реальных ор ганизациях подобные случаи практически не встречаются. Даже в идеальной ситуации всевоз можные зависимости от данных, которые нужно учитывать и контролировать, развиваются очень стремительно. Дорожная карта служит хорошим средством управления такими зависимостями и принятия решений, нацеленных на перспективу. Она помогает организации находить возмож ности для компромиссов и выстраивать прагматичный план, сбалансированно учитывающий потребности и возможности бизнеса, внешние требования и имеющиеся ресурсы.
Дорожная карта реализации корпоративной архитектуры данных разрабатывается на сред несрочную перспективу от трех до пяти лет. Вместе с бизнес-требованиями, результатами ана лиза фактических условий и техническими оценками дорожная карта описывает, каким образом целевая архитектура превратится в реальность. Дорожная карта развития корпоративной архи тектуры данных должна быть интегрирована с общей дорожной картой реализации корпоратив ной архитектуры, которая включает высокоуровневые вехи, потребности в ресурсах, финансо вые оценки, разбитые по направлениям развития бизнес-возможностей. Дорожная карта должна строиться с учетом оценки зрелости управления данными (см. главу 15.)
Архитектура данных |
127 |
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
|
X |
|
|
|
|
|
|||
|
|
- |
|
|
|
|
|
d |
|
||
|
|
F |
|
|
|
|
|
|
t |
|
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
||
|
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
|
to |
|
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
||
|
|
w |
|
|
|
|
|
|
|
o |
|
|
|
|
|
|
|
|
|
|
|
||
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
|
-x cha |
|
|
|
|
Большинство бизнес-возможностей требуют данных в качестве входных ресурсов; какие-то из них также производят данные, от которых зависят остальные бизнес-возможности. Корпо ративная архитектура и корпоративная архитектура данных могут быть взаимоувязаны путем преобразования этого потока в цепочку зависимостей между бизнес-возможностями.
Управляемая на основе бизнес-данных (business-data-driven) дорожная карта начинается с ме роприятий, относящихся к наиболее независимым бизнес-возможностям (не зависящим от резуль татов другой деятельности), и заканчивается самыми зависимыми направлениями работ. После довательность проработки бизнес-возможностей будет соответствовать общему порядку возник новения бизнес-данных. Рисунок 27 содержит пример такой цепочки зависимостей с наименьшей зависимостью в верхней части. Управление продуктом и Управление клиентами не требуют ка ких-либо данных и, таким образом, производят основные данные. Самые зависимые направления отражены в нижней части. Здесь Управление счетами клиентов зависит от Управления клиентами и Управления заказами на продажу, которое, в свою очередь, также зависит от двух направлений.
Данные Управление о продукте продуктом
Данные о продукте
Управление ко плектующими
элементами продукта
|
|
BOM |
|
|
|
|
|
|
|
Ведомость |
|
|
|
|
|
|
Управление |
|
|
|
|
Данные |
|
|
клиентами |
|
|||
материалов |
|
|
о товарных |
|
|
|
|
||
|
|
|
|
|
|
||||
|
(BOM) |
|
|
позициях |
|
|
|
|
|
|
Управле |
Данные |
|||||||
|
|
|
|
|
|||||
|
|
|
товарными |
|
|
||||
|
|
|
|
|
о клиенте |
||||
|
|
|
позициями |
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Управле |
|
|
|
|
|
Управление |
|
|
|
заказами |
|
|
|
|
|
структурой |
|
|
|
на поставку |
Данные |
|||
|
сборки |
|
|
Данные |
|
|
о клиенте |
||
|
|
|
|
|
|
|
|
||
Данные |
Данные |
о заказе |
|
|
|
|
|||
о заказе |
|
|
|
|
Управление |
|
|||
о структуре |
|
|
|
|
|
|
|
||
сборки |
|
|
|
|
|
|
продуктом |
|
|
|
|
|
|
|
|
|
|
|
|
равление производственными
заказами
Рисунок 27. Зависимости бизнес-возможностей в отношении данных
128 |
Г Л А В А 4 |
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
|
X |
|
|
|
|
|
|||
|
|
- |
|
|
|
|
|
d |
|
||
|
|
F |
|
|
|
|
|
|
t |
|
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
||
|
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
|
to |
|
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
||
|
|
w |
|
|
|
|
|
|
|
o |
|
|
|
|
|
|
|
|
|
|
|
||
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
|
-x cha |
|
|
|
|
Таким образом, в идеале следует начинать разработку дорожной карты с возможностей по Управлению продуктом и Управлению клиентами, а затем пошагово осуществлять разрешение каждой зависимости, спускаясь по цепочке сверху вниз.
2.1.3 Управление корпоративными требованиями в рамках проектов
Архитектура не должна замыкаться в границах, существовавших на момент ее разработки. Модели данных и другие спецификации, описывающие архитектуру данных, должны быть достаточно гибкими для того, чтобы адаптироваться к будущим требованиям. Модель данных уровня архи тектуры должна обеспечивать единое глобальное представление об организации вместе с ясны ми определениями, понятными всем сотрудникам.
Проекты разработки (связанные с разработкой и внедрением) реализуют решения по сбору, хранению и распространению данных, которые основаны на бизнес-требованиях и стандартах, установленных корпоративной архитектурой данных. Этот процесс по самой своей природе но сит пошаговый характер.
На уровне отдельного проекта процесс определения требований посредством моделирования данных начинается с анализа потребностей бизнеса. Часто эти потребности касаются исключи тельно специфических целей проекта и не имеют отношения к организации в целом. Процесс определения требований, кроме того, должен включать выработку определений терминов, а так же другие работы, поддерживающие использование данных.
Важно, чтобы архитекторы данных были способны воспринимать требования с учетом об щей архитектуры. По завершении работы над проектной спецификацией архитекторы данных должны определить:
соответствуют ли корпоративные сущности, указанные в спецификации, согласованным стандартам;
какие сущности из спецификации следует включить в общую корпоративную архитектуру данных;
нет ли необходимости обобщить или доработать представленные в спецификации сущности и определения (с прицелом на будущие потребности, исходя из наблюдаемых тенденций);
нет ли необходимости в новых архитектурных решениях по предоставлению данных, или раз работчиков следует нацелить на использование уже имеющихся схем.
Организации часто откладывают решение насущных вопросов, касающихся архитектуры дан ных, до момента, пока в проектах не возникает необходимость разработки хранилищ данных и их интеграции. Однако предпочтительнее всё же проводить рассмотрение таких вопросов, начиная уже с ранней стадии планирования и затем на протяжении всего цикла жизни проекта.
Работы в рамках проектов, затрагивающих корпоративную архитектуру данных, включают
следующее.
Архитектура данных |
129 |
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
|
X |
|
|
|
|
|
|||
|
|
- |
|
|
|
|
|
d |
|
||
|
|
F |
|
|
|
|
|
|
t |
|
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
|
r |
||
|
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
|
to |
|
|
|
|
|
|
|
w Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
|
|
||
|
|
w |
|
|
|
|
|
|
|
o |
|
|
|
|
|
|
|
|
|
|
|
||
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
|
-x cha |
|
|
|
|
Определение содержания и границ проекта. Необходимо убедиться, что содержание, грани цы и взаимосвязи соответствуют корпоративной модели данных. Кроме того, следует понять потенциальный вклад проекта в общую корпоративную архитектуру данных, в частности от ветив на вопросы, что именно будет смоделировано и спроектировано и какие из имеющихся компонентов должны (или могут) быть повторно использованы в проекте. В тех областях, которые предстоит разработать, проект должен предусматривать определение новых зависимостей от заинтересованных сторон, которые не вошли в его границы (например, зависимо стей в рамках нисходящих процессов). Информационные артефакты, которые в проекте бу дут определены как подлежащие совместному или повторному использованию, должны быть включены в корпоративную логическую модель данных и размещены в назначенных для них репозиториях.
Углубление понимания бизнес-требований. Cбор связанных с данными требований (напри мер, в отношении сущностей, источников, доступности, качества, уязвимых мест), а также оценка экономической целесообразности и реальной ценности выполнения этих требований для бизнеса. Также сюда относится оценка выгод для бизнеса от выполнения этих требований.
Проектирование. Составление детализированных целевых спецификаций, включая описа ние бизнес-правил, применяемых на протяжении жизненного цикла данных. Утверждение конечных результатов, а также, при необходимости, определение и передача в заинтересо ванные подразделения требований по дополнению и расширению имеющихся стандартизо ванных моделей. Корпоративная логическая модель данных и корпоративный архитектурный репозиторий — подходящие места для поиска архитекторами данных проекта пригодных к повторному использованию структурных компонентов, к которым можно обеспечить об щий доступ в масштабах организации. Кроме того, необходимо регулярно отслеживать и при менять на практике технические стандарты в области данных.
Реализация.
При покупке готовых коммерческих приложений (Сommercial Оff The Shelf, COTS) следу ет проводить их реверс-инжиниринг с целью сравнения с имеющейся структурой данных. Нужно выявлять и документировать пробелы (gaps) и расхождения в структурах, опреде лениях и правилах. В идеале поставщики должны предоставлять модели данных к прода ваемым продуктам; на практике многие этого не делают, поскольку рассматривают модели как свою собственность. Если это возможно, желательно купить такую модель с детальны ми определениями.
При повторном использовании данных необходимо сопоставить модели данных прило жения с общеприменимыми в организации структурами данных, а также существующими и вновь внедряемыми процессами, чтобы понять, каким образом должны быть реализова ны операции создания, чтения, обновления и удаления данных (CRUD). Следует добивать ся использования систем записи или других надежных источников данных. Также необхо димо выявлять и документировать пробелы и несоответствия.
130 |
Г Л А В А 4 |