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

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

Для достижения этих целей архитекторы данных определяют и поддерживают специфика ции, которые:

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

предоставляют стандартный бизнес-словарь для данных и компонентов;

обеспечивают согласованность архитектуры данных с корпоративной стратегией и бизнесархитектурой;

отражают стратегические требования к данным;

очерчивают высокоуровневые интегрированные проектные решения, призванные обеспе чить выполнение этих требований;

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

Практика разработки архитектуры данных в целом включает:

использование артефактов архитектуры данных (основных рабочих описаний — master blueprints) для определения требований к данным, проведения интеграции данных, контроля информационных активов и согласования инвестиций в данные с бизнес-стратегией;

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

использование архитектуры данных для определения и закрепления семантики организации с помощью создания общего бизнес-словаря.

1.3 Основные понятия и концепции

1.3.1 Предметные области архитектуры предприятия

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

114	Г Л А В А 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

Таблица 6. Архитектурные домены

				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

			Домен					Бизнес-архитектура	Архитектура данных	Архитектура приложений	Технологическая архитектура
								предприятия	предприятия	предприятия	предприятия
								Выявление путей	Описание того, как	Описание структуры	Описание технологической
			Назначение
								создания предприятием	данные должны быть	и функциональности	инфраструктуры,
								ценности для	организованы и как	используемых	необходимой для обеспечения
								потребителей и других	должно осуществляться	предприятием	функционирования систем
								заинтересованных лиц	управление данными	приложений	и предоставления с их
											помощью ценности
								Бизнес-модели,	Модели данных,	Информационные	Технические платформы,
	Элементы
								процессы, возможности,	определения данных,	системы,	сети, средства обеспечения
								сервисы, события,	спецификации	поддерживающие бизнес;	безопасности и интеграции
								стратегии, словарь	отображения данных	пакеты прикладного ПО;	данных
									(data mapping), потоки	базы данных
									данных, интерфейсы
									прикладного
									программирования
									(application
									programming interface,
									API), для работы
									со структурированными
									данными
								Устанавливает	Обеспечивает	Обеспечивает обработку	Предоставление ресурсов
		Зависимости
								требования для других	управление данными,	данных в соответствии	для размещения решений,
								доменов	создаваемыми	с бизнес-требованиями	определенных архитектурой
									и требуемыми согласно		приложений
									бизнес-архитектуре
								Бизнес-архитекторы	Архитекторы данных	Архитекторы приложений	Архитекторы инфраструктуры
			Роли
								и аналитики,	и специалисты
								распорядители бизнес-	по разработке моделей
								данных	данных, распорядители
									данных

1.3.2 Архитектурные рамочные структуры

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

Компьютерное сообщество при Институте инженеров по электротехнике и электронике (IEEE Computer Society), разрабатывающее и сопровождающее уже упомянутый стандарт архитектуры ISO/IEC/IEEE 42010:2011, ведет детальную таблицу сравнения применяющихся архитектурных

Архитектура данных

115

				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

рамочных структур1. Наиболее распространенные структуры и методики включают архитектуру данных в качестве одного из архитектурных доменов.

1.3.2.1 МОДЕЛЬ ЗАХМАНА

Самая известная рамочная структура архитектуры предприятия, «модель Захмана», была разра ботана Джоном Захманом2 в 1980-х годах (см. рис. 22). С тех пор она продолжала развиваться. Захман обратил внимание на тот факт, что к построению (созданию) зданий, самолетов, пред приятий, цепочек создания стоимости, проектов или систем имеют отношение различные груп пы людей, у каждой из которых есть собственная точка зрения (перспектива) на архитектуру соз даваемого объекта. Эту концепцию он применил к требованиям для различных типов и уровней архитектуры предприятия.

Модель Захмана представляет собой онтологию — матрицу 6×6, охватывающую полный на бор моделей, требуемых для описания предприятия, и связей между ними. Архитектурная рамоч ная структура Захмана не описывает, как именно создавать входящие в нее модели. Она просто показывает, что эти модели должны быть созданы.

Что

Как

Где

Кто

Когда

Зачем

	Руководство			Идентификация	Идентификация	Идентификация	Идентификация	Идентификация	Идентификация		Бизнес-
				объектов	процессов	местоположений	обязанностей	сроков	мотивов		контекст
	Бизнес-			Определение	Определение	Определение	Определение	Определение	Определение		Бизнес-
	менеджмент			объектов	процессов	местоположений	обязанностей	сроков	мотивов		концепции
				Представление	Представление	Представление	Представление	Представление	Представление
	Архитекторы										Бизнес-логика
				объектов	процессов	местоположений	обязанностей	сроков	мотивов
				Спецификация	Спецификация	Спецификация	Спецификация	Спецификация	Спецификация		Физический
	Инженеры
				объектов	процессов	местоположений	обязанностей	сроков	мотивов		уровень
				Конфигурация	Конфигурация	Конфигурация	Конфигурация	Конфигурация	Конфигурация
											Сборка
	Технические
	специалисты			объектов	процессов	местоположений	обязанностей	сроков	мотивов
				Реализация	Реализация	Реализация	Реализация	Реализация	Реализация		Реализация
	Предприятие
				объектов	процессов	местоположений	обязанностей	сроков	мотивов

Наборы	Потоки	Расположение	Распределение	Временные	Мотивы
объектов	процессов		обязанностей	циклы

Рисунок 22. Упрощенное представление модели Захмана

Столбцы матрицы отражают обсуждаемые вопросы (что, как, где, кто, когда и зачем), а строки — преобразования в процессе материализации (выявление — identification, определение — definition,

1 http://www.iso-architecture.org/ieee-1471/afs/frameworks-table.html

2 Джон Захман (англ. John A. Zachman, р. 1934) — американский специалист по информационным технологиям для бизнеса, разработавший описываемую модель в рамках концепции планирования бизнес-систем IBM, одним из авторов которой является. — Примеч. пер.

116	Г Л А В А 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

представление — representation, спецификация — specification, конфигурация — configuration, реализация — instantiation). В ячейках на пересечении строк и столбцов отражены уникальные типы артефактов архитектуры данных.

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

Что (столбец объектов): сущности (объекты), используемые для построения архитектуры.

Как (столбец процессов): проводимые работы.

Где (столбец местоположений): местоположения бизнес-структур и технологических структур.

Кто (столбец обязанностей): роли и организационные системы.

Когда (столбец привязки по времени): сроки, интервалы, события, циклы, расписания.

Зачем (столбец мотивации): цели, стратегии и средства.

Процесс материализации состоит из шагов, необходимых для перевода абстрактной идеи в кон кретный образец (реализация). Эти шаги отражены в строках матрицы, обозначенных с помо щью названий соответствующих ролей: планировщик, владелец, проектировщик, разработчик, внедренец, пользователь. Каждой из перечисленных ролей соответствует отличная от других перспектива процесса в целом, а также собственный круг решаемых проблем. Эта специфика и показана в строках. Например, каждая перспектива выражает различное отношение к столбцу «Что» (предметы или данные).

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

Перспектива бизнес-менеджмента (бизнес-концепции). Уточнение бизнес-менеджерами (как владельцами) связей между бизнес-концепциями и отражение их в моделях определения.

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

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

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

Перспектива пользователя (реализация). Реальные функционирующие объекты, с которыми работают сотрудники (как пользователи). Эта перспектива моделей не предусматривает.

Архитектура данных

117

				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

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

1.3.3 Корпоративная архитектура данных

Архитектура данных предприятия (enterprise data architecture) или корпоративная архитекту ра данных1, определяет стандартные термины и проектные решения, применяемые в отношении важных для организации элементов. Проект корпоративной архитектуры данных включает опи сание бизнес-данных как таковых, а также описание порядка их сбора, хранения, интеграции, перемещения и распространения.

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

Корпоративная модель данных (Enterprise Data Model, EDM). EDM представляет собой целостную, не зависящую от технических средств реализации концептуальную или логиче скую модель данных, отражающую единый согласованный взгляд на данные в масштабах всей организации. Термин корпоративная модель данных обычно используется для обозначения высокоуровневой упрощенной модели данных, но уровень абстракции может быть различ ным в зависимости от целей ее представления. EDM включает данные о ключевых сущностях предприятия (на уровне бизнес-концепций — business concepts) и связях между ними, крити чески важные руководящие бизнес-правила и некоторые ключевые атрибуты. EDM заклады вает на будущее основу для всех проектов в области данных или связанных с данными. Моде ли данных уровня отдельных проектов должны создаваться на основе EDM. EDM подлежит обязательной проверке всеми заинтересованными сторонами для обеспечения согласован ного мнения о том, что в модели зафиксировано правильное представления об организации.

Описание потоков данных. Содержит требования и основное рабочее описание (master blueprint) организации хранения и обработки данных в целом по всем базам данных, приложе ниям, платформам и сетям. Потоки данных отражают их перемещение с целью использования

1 В данном издании применительно к терминам, начинающимся со слова «enterprise» в качестве определения (на пример, «enterprise architecture» или «enterprise data architecture»); это слово чаще всего переводится как «корпоративный» — «корпоративная архитектура», «корпоративная архитектура данных» и т. п. (широко распространенный вариант перевода в подобных случаях). Такой перевод облегчает восприятие текста в тех местах, где указанные термины применяются совместно с термином «organization» («организация»). — Примеч. науч. ред.

118	Г Л А В А 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

в бизнес-процессах, на отдельных рабочих местах, сотрудниками с определенными бизнесролями, а также отдельными техническими компонентами.

Эти два типа спецификаций должны быть между собой хорошо согласованы. Как уже отмеча лось, и модель, и потоки данных должны быть отражены в трех состояниях — текущем, целевом (архитектурная перспектива) и переходном (проектная перспектива).

1.3.3.1 КОРПОРАТИВНАЯ МОДЕЛЬ ДАННЫХ

В одних организациях EDM создается как самостоятельный артефакт; в других под ней подразу мевается совокупность моделей данных, отражающих различные перспективы с различными уровнями детализации, но в комплексе дающих полное и непротиворечивое представление об общепринятом в организации понимании описываемых сущностей, атрибутов и связей в мас штабах предприятия. EDM включает как универсальные для всего предприятия модели (концеп туальную и логическую модели корпоративного уровня), так и модели данных, используемые конкретными приложениями и/или проектами, а также определения, спецификации, отображе ния (mappings) данных и бизнес-правила.

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

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

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

Представления сущностей и связей по каждой предметной области.

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

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

Архитектура данных

119

				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

Корпоративная модель данных

Концептуальная

модель

Модель Модель Модель Модель предметной предметной предметной предметной области области области области

Логическая Логическая Логическая Логическая модель модель модель модель

LDM	LDM	LDM	LDM	LDM	LDM	LDM
PDM	PDM	PDM	PDM	PDM	PDM	PDM

Модели в рамках приложений или проектов

Рисунок 23. Корпоративная модель данных

Одна диаграмма: 1–20 важных предметных областей бизнеса со связями

Одна и более диаграмм на предметную область:

50 (и более) важных сущностей предметнойобласти со связями

Логические модели покаждойпредметной области: увеличение детализации за счет добавления атрибутов

и менее важных сущностей и связей

Границы модели: отдельная подобласть и одношаговые внешние связи

Границы модели: физические объекты подобласти и связи

Все уровни в совокупности составляют корпоративную модель данных. Структура связей позво ляет проследить сущность с верхнего уровня до нижнего и между моделями на одном уровне.

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

120	Г Л А В А 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

логической модели, концептуальной сущностью Product модели предметной области Product

и, наконец, с сущностью Product корпоративной концептуальной модели.

Горизонтальные связи. Сущности и связи могут появляться во многих моделях одного уров ня; сущности в логических моделях одной тематики могут быть связаны с сущностями другой тематики, помеченными или описанными как внешние по отношению к предметной области на графическом изображении модели. Сущность Product Part (Комплектующий элемент про дукта) может фигурировать как в моделях, описывающих предметную область Product, так и в моделях, относящихся к другим областям: например, Sales (Продажи), Inventory (Запасы), Marketing (Mаркетинг), — за счет включения ее в эти модели с помощью внешних ссылок.

Разработка EDM на всех уровнях ведется с использованием стандартных методов моделирования данных (см. главу 5).

На рисунке 24 представлен упрощенный пример диаграмм, описывающих три предметные области. Каждая диаграмма содержит концептуальную модель данных с набором сущностей. Связи могут пересекать границы между предметными областями; каждая сущность в корпора тивной модели данных должна принадлежать строго одной предметной области, но может быть связана с сущностями из любой другой предметной области.

Предметная область

Предметная область

Предметная область

«Проектирование продукта»

«Коммерческие

«Продажи»

предложения»

Группа

Платформа

Портфель

Заказ

предложений

продуктов

продукта

на поставку

рынку

Диапазон

Включен в

Использует

предложений

Товарная

Позиция

Принадлежит

Продукт

заказа на

позиция

поставку

Ведомость

Специфицирует

материалов

(BOM)

Ведомость материалов

товарного комплекта

(BOM)

Комплектующий

элемент

Конфигурация

Детализирует позиции

Структура заказа элемента

Рисунок 24.

Архитектура данных

121

				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

Таким образом, корпоративная концептуальная модель данных создается путем объединения моделей предметных областей. При этом EDM может выстраиваться как сверху вниз, так и снизу вверх. Первый подход подразумевает сначала определение предметных областей, а лишь затем заполнение их моделями. При втором подходе структура предметных областей определяется су ществующими моделями данных. На практике обычно рекомендуется использовать разумное со четание обоих подходов: сначала обобщаются в предметные области имеющиеся и используемые предприятием модели (подход «сверху вниз»), а последующее дополнение EDM новыми моделями производится посредством делегирования функции моделирования предметных областей проектным командам отдельных проектов (подход «снизу вверх»).

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

1.3.3.2 ОПИСАНИЕ ПОТОКОВ ДАННЫХ

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

Потоки данных отображают и документируют взаимосвязи между данными и:

приложениями, используемыми в рамках бизнес-процесса;

хранилищами или базами данных в среде функционирования;

сегментами сети (полезно для описания мер безопасности);

бизнес-ролями — показывая, какие роли отвечают за создание, чтение, обновление, удаление данных (CRUD1 — Create, Read, Update, Delete);

местами, в которых происходят изменения данных.

1 CRUD — часто используемый акроним, обозначающий четыре базовые операции, выполняемые при работе с данными: создание (create), чтение (read), обновление (update), удаление (delete). — Примеч. науч. ред.

122	Г Л А В А 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

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

Бизнес-процессы

Проектирование	Маркетинг	Подготовка	Управление	Производство	Логистика	Выставление
продукта	и продажи	производства	заказами			счетов

Основные сущности

Продукт

Комплектующий

элемент

Производственное

предприятие

Клиент

Товарная

позиция

Структура

сборки

Заказ на поставку

Заказ на производство

Индивидуальный

продукт

Поставка

Счет клиента

Создание

Чтение / Использование

Рисунок 25. Поток данных, представленный в виде матрицы

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

Архитектура данных

123

				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

отображать потоки данных в аналогичном формате, просто заменив «процессы» на «возможно сти» в столбцах матрицы и в названии оси. Построение таких матриц — давно сложившаяся прак тика моделирования работы предприятия. Разработаны они были еще IBM в рамках методологии планирования бизнес-систем (Business Systems Planning, BSP), а популяризованы в 1980 е годы Джеймсом Мартином1 в его методологии планирования информационных систем (Information Systems Planning, ISP).

Статистика сервисного обслуживания и ремонтов Возврат материалов

Система управления взаимоотношениями с клиентами (CRM)

			Данные		Статистика
			о клиенте		сервисного
			Клиентский		обслуживания
			договор		и ремонтов
Ведомость материалов (BOM)
продукта
Характеристики продукта
Система управления						Систе
данными об изделии						послепродажного
(PDM)						обслужива

BOM продукта

BOM

Характеристики продукта

товарного комплекта

Данные снабжения

Состав заказа

	Систем		Систем
	технологической
			планирования
	маршрутизации	Производственная		Серийные номера
			производства
		ведомость		BOM индивидуального
		материалов		продукта

Технологический маршрут Время выполнения

Рисунок 26. Пример диаграммы потоков данных

1 Джеймс Мартин (англ. James Martin, 1933–2013) — английский специалист по информационным и ком пьютерным системам, основоположник концепции автоматизации разработки программного обеспечения (CASE), автор более сотни книг, в 1959–1980 годах работавший в IBM. — Примеч. пер.

124	Г Л А В А 4