Category:ГОСТ ИТ БД Структура и процесс применения (Проект)

From Стандартопедия
Jump to navigation Jump to search

ГОСТ

Информационные технологии ЭТАЛОННАЯ АРХИТЕКТУРА БОЛЬШИХ ДАННЫХ Часть 1 Структура и процесс применения

3 Термины, определения и сокращения

Большие данные (big data) - Большие массивы данных, отличающиеся главным образом такими характеристиками, как объем, разнообразие, скорость обработки и/или вариативность, которые требуют использования технологии масштабирования для эффективного хранения, обработки, управления и анализа.

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


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


Структура (framework) - Определенный набор утверждений (концепций, понятий) или идей для описания сценария или решения задачи.


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


Конфиденциальность персональных данных (privacy) - Право отдельных лиц контролировать или влиять на то, какая информация, связанная с ними (персональные данные), подлежит сбору и хранению, а также кем эта информация может быть раскрыта.


Происхождение (provenance) - Сведения о месте и времени появления, извлечения или создания ресурса, записи, доказательства подлинности или принадлежности в прошлом.


Реляционная модель данных (relational model) - Модель данных, структура которой основана на совокупности отношений.


Жизненный цикл (lifecycle) - Развитие системы, продукта, услуги, проекта или другой создаваемой человеком сущности от замысла до списания.


4 Сокращения и обозначения

BDA – аудитор больших данных (Big Data Auditor);

BDAcP – сервис-провайдер доступа к большим данным (Big Data Access Provider);

BDAnP – сервис-провайдер аналитики больших данных (Big Data Analytics Provider);

BDAP – сервис-провайдер приложения больших данных (Big Data Application Provider);

BDCP – сервис-провайдер сбора коллекций больших данных (Big Data Collection Provider);

BDFP – сервис-провайдер среды обработки больших данных (Big Data Framework Provider);

BDIP – сервис-провайдер инфраструктуры больших данных (Big Data Infrastructure Provider);

BDPlaP – сервис-провайдер платформы больших данных (Big Data Platform Provider);

BDPreP – сервис-провайдер предобработки больших данных (Big Data Preparation Provider);

BDProP – сервис-провайдер обработки больших данных (Big Data Processing Provider);

BDSD – разработчик сервиса больших данных (Big Data Service Developer);

BDSO – оркестратор системы больших данных (Big Data System Orchestrator);

BDSP – партнер сервиса больших данных (Big Data Service Partner);

BDRA – эталонная архитектура больших данных (Big Data Reference Architecture);

BDVP – сервис-провайдер визуализации больших данных (Big Data Visualization Provider);

GDPR – общие правила защиты данных (General Data Protection Regulation);

JSON – обозначение объектов JavaScript (JavaScript Object Notation);

RDF – структура описания ресурсов (Resource Description Framework);

SQuaRE – требования к оценке качества аппаратного и программного обеспечения (Systems and software Quality Requirements and Evaluation);

XML – расширяемый язык разметки (Extensible Markup Language).

7 Концептуальные основы

7.1 Общие сведения

Документы серии ИСО/МЭК 20547 призваны обеспечить широкому кругу заинтересованных сторон основу для однозначного описания и эффективного обмена сведениями о характеристиках и атрибутах конкретной системы больших данных. В соответствии с терминами и определениями, представленными в стандарте ИСО/МЭК 20546, система больших данных позволяет:

– обрабатывать большие массивы данных, отличающиеся объемом, разнообразием, скоростью обработки и/или вариативностью, с помощью масштабируемой архитектуры для эффективного хранения, обработки, управления и анализа;

– применять передовые методики построения масштабируемых систем данных на основе независимых ресурсов в ситуациях, когда характеристики массивов данных требуют разработки новых архитектур для эффективного хранения, обработки, управления и анализа;

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

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


7.2 Эталонная архитектура. Основные понятия

Для понимания того, что включает эталонная архитектура, необходимо определить, что под ней подразумевается. Как указано в стандарте ГОСТ Р 57100-2016 (см. п. 3.2), эталонная архитектура неизбежно обладает всеми характеристиками архитектуры, представляющей основные понятия или свойства системы в окружающей среде, которые воплощены в ее элементах, отношениях и конкретных принципах разработки и развития. В данном случае эталонная архитектура больших данных должна быть достаточно общей, охватывать многообразие потенциальных архитектур систем больших данных.

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

Определение эталонной архитектуры в области архитектуры программного обеспечения или архитектуры предприятия, типовое решение для архитектуры в конкретной области применения, а также общий словарь, который позволяет выявлять общие черты и обсуждать варианты реализации, даются в стандарте ISO/ТR 14639-2:2014. С учетом сказанного эталонная архитектура представляет собой структуру архитектуры, как это описано в стандарте ГОСТ Р 57100-2016, включающую строение и взаимосвязь компонентов, правила и ограничения, общие для всех систем больших данных, а также ряд соглашений, принципов и практик для описания архитектур систем больших данных.

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

БД Эталонная Архитектура рис1.jpg


7.3 Структура эталонной архитектуры

На рисунке 2, в соответствии со стандартом ГОСТ Р 57100-2016, представлено объединение концепции и структуры эталонной архитектуры.

БД Эталонная Архитектура рис2.jpg

Эталонная архитектура определяется для конкретной области применения. Областью применения для рассматриваемой эталонной архитектуры являются большие данные.

Область применения, в свою очередь, определяет окружающую среду. В случае больших данных окружающая среда в первую очередь определяется основными характеристиками больших данных — объемом, скоростью обработки, разнообразием, вариативностью.

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

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

Эталонная архитектура описывается на основе ее структуры, которая представлена в стандарте ИСО/МЭК 20547-3 и рассматривается с двух точек зрения:

– пользовательское представление — роли и деятельность;

– функциональное представление — функциональные компоненты.

Каждая из этих точек зрения, в свою очередь, затрагивает один или несколько интересов.

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

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

Как в пользовательском, так и функциональном представлениях эталонной архитектуры больших данных существует сквозной аспект безопасности и конфиденциальности персональных данных. Этот сквозной аспект связан с видом деятельности «Проведение аудита» и функциональным компонентом «Структура аудита», которые позволяют разрешить проблему.


8 Основы эталонной архитектуры больших данных

8.1 Обзор

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

ИСО/МЭК 20547-1: «Структура и процесс применения» включает описание структуры эталонной архитектуры больших данных и процесса применения стандарта в конкретной предметной области.

ИСО/МЭК 20547-2: «Сценарии использования и порождаемые ими требования» включает примеры описания сценариев использования больших данных в соответствии с областями применения и вытекающими из них техническими аспектами.

ИСО/МЭК 20547-3: «Эталонная архитектура» содержит описание эталонной архитектуры больших данных (BDRA), включающей в себя понятия и архитектурные представления (пользовательское и функциональное).

ИСО/МЭК 20547-4: «Безопасность больших данных и конфиденциальность персональных данных» содержит описание аспектов безопасности и конфиденциальности применительно к эталонной архитектуре больших данных (BDRA), включая роли, действия, функциональные компоненты, а также руководство по обеспечению безопасности и конфиденциальности при операциях с большими данными.

ИСО/МЭК 20547-5: «Дорожная карта стандартов» включает описание стандартов (как существующих, так и разрабатываемых) в соответствии с анализом приоритетов разработки будущих стандартов, относящихся к большим данным.

На рисунке 3 показаны взаимосвязи между частями стандарта ИСО/МЭК 20547.

Взаимосвязи между частями стандарта ИСО МЭК 20547.png

В стандарте ИСО/МЭК 20547-2 представлены сценарии использования и технические аспекты на основе исследований научных сообществ, оценок экспертов и специалистов предприятий и организаций. В стандарте ИСО/МЭК 20547-3 представлена эталонная архитектура больших данных с соответствующими техническими аспектами. В стандарте ИСО/МЭК 20547-4 представлены аспекты обеспечения безопасности больших данных и конфиденциальности персональных данных. В стандарте ИСО/МЭК 20547-5 представлен список применяемых стандартов в рамках эталонной архитектуры больших данных.

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

8.2 Заинтересованная сторона

Заинтересованная сторона в стандарте ГОСТ Р 57100-2016 определяется как индивидуум, команда, организация или их группы, имеющие интерес к системе. В общем случае заинтересованные стороны включают в себя владельцев системы, клиентов, специалистов по внедрению и др. К заинтересованным сторонам также относятся лица и организации, которых интересуют данные, обрабатываемые системой. К ним относятся владельцы данных, которые могут поставлять их в систему, потребители, принимающие решения на основе данных, поступающих из этой системы, а также лица или организации, сведения о которых представлены в системе. Определение заинтересованных сторон и их интересов (проблем) является первым шагом в разработке архитектуры больших данных. В стандарте ИСО/МЭК 20547-3 под заинтересованными сторонами системы больших данных подразумеваются стороны в рамках представления пользователя.


8.3 Интерес (проблема)

Любой интерес, актуальный для одной или нескольких заинтересованных сторон, как это представлено в стандарте ГОСТ Р 57100-2016, является проблемой, которая связана с техническими, функциональными, эксплуатационными, юридическими и даже социальными воздействиями на систему больших данных в окружающей среде. Окружающая среда системы определяется и ограничивается заинтересованными сторонами и их интересами (проблемами и задачами), связанными с этой системой. Некоторые из них могут быть представлены в терминах других международных стандартов.

П р и м е ч а н и я

1 Например, прозрачность распределения, представленная в эталонной модели открытой распределенной обработки в соответствии со стандартом ГОСТ Р ИСО/МЭК 10746-1-2004, относится к одной из проблем, связанных с функционированием системы больших данных. Ключевыми аспектами таких систем являются горизонтальное масштабирование и распределенная обработка.

2 Свойства программного обеспечения, такие как эффективность, производительность, доверие, риски и их снижение, а также гибкость, представленные в п. 4.2 (требования к оценке качества аппаратного и программного обеспечения) стандарта ГОСТ Р ИСО/МЭК 25010-2015, обозначают проблемы, связанные с качеством программного обеспечения.

При работе с большими данными возникают дополнительные проблемы, связанные с такими характеристиками, как объем, скорость обработки и разнообразие больших данных.

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

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

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

8.4 Представления эталонной архитектуры больших данных

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

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

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

На рисунке 4 представлена схема взаимодействия заинтересованных сторон, а также интересы (проблемы), связанные с указанными представлениями.

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


8.4.1 Пользовательское представление

Связь пользовательского представления с экосистемой больших данных описывается с помощью следующих понятий:

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

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

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

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

П р и м е ч а н и я

1 Примером сквозных аспектов является безопасность больших данных.

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

8.4.2 Функциональное представление

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

Функциональное представление соответствует следующим концептам больших данных:

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

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

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

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

9 Процесс применения эталонной архитектуры больших данных

9.1 Общие положения

В данном разделе представлен пошаговый процесс применения эталонной архитектуры для разработки архитектуры конкретной системы больших данных. Эталонная архитектура больших данных является достаточно общей и предназначена для применения в широком диапазоне систем, однако из-за потенциального разнообразия систем больших данных и их компонентов процесс применения обеспечивает поддержку возможности расширения эталонной архитектуры с учетом конкретных требований. Основной особенностью этого расширения является идентификация дополнительных действий, связанных с ролями, и/или назначение действий различным ролям/подролям. На данном шаге рекомендуется использовать соответствующие стандарты ИСО, включающие ГОСТ Р 57193-2016 для разработки систем, ГОСТ Р ИСО/МЭК 12207-2010 для описания жизненного цикла разработки систем. Качество процессов оценивается с помощью семейства стандартов ИСО 9000 для подтверждения того, что разработанная архитектура действительно охватывает и учитывает весь спектр проблем.

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

9.2 Идентификация заинтересованных сторон и их интересов

Первым шагом в процессе применения эталонной архитектуры является идентификация заинтересованных сторон и их интересов, связанных с разработкой системы больших данных. Анализ требований заинтересованных сторон проводится в соответствии со стандартом ГОСТ Р 57193-2016. В результате первого шага должны быть:

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

б) определены ограничения на соответствующую систему;

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

г) определены базовые положения для формирования системных требований;

д) определены базовые положения для валидации системных услуг;

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

В соответствии со стандартом ГОСТ Р 57193-2016 интересы (требования) заинтересованных сторон выражаются в потребностях, желаниях, ожиданиях и предполагаемых ограничениях. Они представляются в виде вербальной или формальной модели, сфокусированной на цели и поведении системы, и описываются в контексте операционной среды и условий функционирования.

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

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

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

На данном шаге при определении заинтересованных сторон и их интересов могут применяться результаты анализа других сценариев использования больших данных и соответствующих требований стандарта ИСО/МЭК 20547-2.

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

9.3 Отображение в ролях и подролях заинтересованных сторон и их интересов

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

В стандарте ИСО/МЭК 20547-3 определены следующие роли и подроли:

а) провайдер приложения больших данных (BDAP):

  • 1) сервис-провайдер комплектования больших данных (BDCP);
  • 2) сервис-провайдер предобработки больших данных (BDPreP);
  • 3) сервис-провайдер аналитики больших данных (BDAnP);
  • 4) сервис-провайдер визуализации больших данных (BDVP);
  • 5) сервис-провайдер доступа к большим данным (BDAcP);

б) провайдер среды обработки больших данных (BDFP):

  • 1) сервис-провайдер инфраструктуры больших данных (BDIP);
  • 2) сервис-провайдер платформы больших данных (BDPlaP);
  • 3) сервис-провайдер обработки больших данных (BDProP);

в) партнер сервиса больших данных (BDSP):

  • 1) разработчик сервиса больших данных (BDSD);
  • 2) аудитор больших данных (BDA);
  • 3) оркестратор системы больших данных (BDSO);

г) потребитель больших данных;

д) сервис-провайдер больших данных.

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

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

На данном шаге определяется деятельность системы или архитектуры. На основе эталонной архитектуры больших данных, представленной в категориях ролей и подролей, создаются механизмы для сбора и организации результатов реализации процессов системной и программной инженерии. При выполнении этого шага группа разработчиков должна опираться на положения стандарта ИСО/МЭК 29148:2011 «Системная и программная инженерия. Процессы жизненного цикла. Разработка требований» . Этот стандарт поможет трансформировать описанные выше проблемы в конкретные и тестируемые требования.

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

<Роль или подроль> должна <глагол><объект>

Роль или подроль обозначают субъект, модальность и глагол — предикат, а также объект — предмет, над которым выполняется действие. В 3-й части ИСО/МЭК 20547-3 подробно описываются классы действий, которые должны выполняться системами.

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

Такие утверждения могут рассматриваться как бизнес-правила, реализуемые в системе, для которой разрабатывается архитектура. Ниже приведены примеры возможных бизнес-правил, создаваемых на данном шаге:

– сервис-провайдер сбора коллекций больших данных должен подтверждать соответствие данных XXX стандарту YYYY;

– сервис-провайдер визуализации больших данных должен представлять результаты в виде ориентированного графа;

– сервис-провайдер доступа к большим данным должен фиксировать доступ пользователя к системе.

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

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

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

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

9.5 Определение функциональных компонентов для реализации деятельности

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

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

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

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

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

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

9.6 Соответствие сквозных действий/функциональных компонентов интересам

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

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