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