Всегда существует более одного способа описания архитектуры

Системная архитектура

Эта статья или раздел нуждается в переработке.

В стандарте ANSI/IEEE 1471-2000is дается следующее определение архитектуры: «фундаментальная организация системы, реализованная в ее компонентах, связях этих компонентов друг с другом и внешней средой и принципах, определяющих структуру и развитие системы».

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

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

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

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

Статический срез системной архитектуры на определённый момент времени включает:

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

Другими аспектами системной архитектуры являются:

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

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

Содержание

Архитектура приложений

Для каждой информационной системы, входящей в состав КИС, дает ответы на следующие вопросы:

• Какой продукт, услугу автоматизирует
• Какие функции выполняет
• Из каких компонент (подсистем) состоит
• С какими другими информационными системами КИС взаимодействует
• Какими сущностями (данными) оперирует информационная система
• Где размещена информационная система (на каком оборудовании)
• Кто владелец
• Кто отвечает
• Кто и как использует

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

Для каждой сущности, обрабатываемой/хранимой в КИС, дает ответы на следующие вопросы:

• Какие таблицы
• Какие информационные системы формируют, изменяют данные, используют данные
• Кто владелец
• Кто отвечает
• Кто и как использует
• Какие объёмы занимает и как быстро «прирастает»
• С какими другими данными связана сущность

Архитектура оборудования

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

• Какое оборудование используется
• За кем закреплено
• Кто отвечает
• Где расположено
• Из чего состоит
• Что расположено
• Темпы «прироста»

Ссылки

Wikimedia Foundation . 2010 .

Полезное

Смотреть что такое «Системная архитектура» в других словарях:

СИСТЕМНАЯ АРХИТЕКТУРА — Организация и структура основных элементов информационной системы, имеющая принципиальное значение для функционирования системы в целом Словарь бизнес терминов. Академик.ру. 2001 … Словарь бизнес-терминов

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

Архитектура (значения) — В Викисловаре есть статья «архитектура» Архитектура искусство проектировать и строить здания и другие сооружения (та … Википедия

системная сетевая архитектура — Разработанное компанией IBM общее описание структуры, форматов, протоколов, используемых для передачи информации между программами IBM и оборудованием. Системы передачи данных делятся на три дискретных уровня: уровень приложений (application… … Справочник технического переводчика

Архитектура IBM PC — Архитектура современного персонального компьютера это схема его чипсета, которую можно найти на сайтах производителей Intel и AMD.Чипсет это набор микросхем материнской платы для обеспечения работы процессора с памятью и внешними устройствами.… … Википедия

архитектура шины промышленного стандарта — шина ISA Системная 16 разрядная (8 МГц) шина компьютеров архитектуры IBM PC AT. Другое название AT bus. [http://www.morepc.ru/dict/] Тематики информационные технологии в целом EN Industry Standart ArchitectureISA … Справочник технического переводчика

Системная Глобальная Область — В СУБД, разработанных Oracle Corporation, Системной Глобальной Областью (от англ. System Global Area или сокр. SGA) называют часть оперативной памяти, разделяемой всеми процессами одного экземпляра базы Oracle. SGA содержит всю необходимую… … Википедия

Событийно-ориентированная архитектура — Архитектура, управляемая событиями (Event driven architecture EDA) является шаблоном архитектуры программного обеспечения, позволяющим создание, определение, потребление и реакцию на события. Событие можно определить как «существенное… … Википедия

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

Бэк-офис (Архитектура предприятия) — Бэк офис в бизнес архитектуре Совокупность бизнес процессов, процедур, нормативных документов (регламентов), справочников, печатных форм, организационно штатных подразделений, реализующих журнальный (регистровый) учет операций, совершенных… … Википедия

Источник

Архитектура предприятия: основные определения

Второй постулат заключается в том, что выделяются два понятия:

• собственно архитектура информационной системы – как объективная реальность, включающая существующие компоненты и их связи;
• описание архитектуры (architecture description) – отражение объективной или планируемой реальности в какой-либо документированной форме.

Взаимосвязь этих понятий иллюстрируется на рисунке 3.5.

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

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

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

Еще одно формальное определение приведено в стандарте IEEE 1471 Института инженеров-электриков и электронщиков, который предоставляет метамодель для определения архитектуры. Этот стандарт определяет такие абстрактные элементы архитектуры, как представления, системы, среды, обоснования, заинтересованные стороны и т.д. в соответствии со схемой, показанной на рис. 3.6.

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

Однако этот стандарт не определяет структуру собственно архитектуры предприятия. Например, говорится о том, что необходимо иметь различные представления архитектуры , но при этом не указывается, какие это должны быть представления. Подробную информацию об этом стандарте описания архитектуры можно получить по адресу http://www.enterprise-architecture.info/Images/Documents/IEEE%201471-2000.pdf.

Возвращаясь к предмету нашего обсуждения, можно рассмотреть различные аспекты понятия архитектуры ИТ. В частности, можно выделять такие подмножества, как системная архитектура ( архитектура систем – System Architecture ) и программная архитектура ( архитектура программного обеспечения – Software Architecture ). Вспомним, что мы уже отмечали неоднозначность трактовки терминов. На практике, в зависимости от контекста, термин «системная архитектура » может относиться либо к архитектуре ИТ-системы предприятия (в дополнение к бизнес-архитектуре) или даже в еще более узком смысле к технологической инфраструктуре информационной системы, либо – к архитектуре сложного продукта или семейства продуктов, выпускаемых предприятием.

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

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

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

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

Источник

Методики описания архитектур. Модели Захмана и Gartner, методики META Group и TOGAF

Контекст разработки архитектуры предприятия

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

Витрувий, архитектор времен Римской империи

Разработка архитектуры предприятия включает в себя компоненты, связанные с функциональной архитектурой (бизнесом), информационными технологиями и управлением архитектурным процессом. Приведенная ниже диаграмма отражает подход NASCIO (Национальной Ассоциации CIO США), которая наглядно отражает то, как различные компоненты взаимодействуют и влияют друг на друга.

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

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

• методики, опубликованные аналитическими компаниями, такими как Gartner, Giga Group, META Group и другими;
• модель Захмана;
• методика TOGAF;
• методика POSIX 1003.23, которая основывается на разработках компании Cap Gemini , переданных для публичного использования в 1996 году.

Для государственных организаций существуют специальные методики, такие как разрабатываемая при поддержке правительства США Федеральная Архитектура Госорганизаций (FEAF – Federal Enterprise Architecture Framework) или используемая в Министерстве Обороны США DoDAF ( Department of Defence Architecture Framework).

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

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

Если говорить формально, то существуют индустриальные стандарты на описание архитектуры предприятия, принятые такими организациями, как Институт инженеров электрики и электроники ( IEEE – Institute of Electrical and Electronics Engineers ), международная организация стандартизации ( ISO – International Organization for Standardization ), The Open Group и т.д. Но ни один из этих стандартов не занимает доминирующего положения . Более того, ни один из них, взятый в отдельности, не дает группам, ответственным за разработку архитектуры, всех инструментов, необходимых с методической точки зрения и с точки зрения шаблонов, используемых для описания архитектуры. Однако этот накопленный арсенал методик и стандартов предоставляет архитекторам широкие возможности выбора архитектурных моделей, примеров и опыта различных индустрий [5.2].

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

Важным для понимания методик являются используемые в них модели, различные представления (view) или домены архитектуры.

Описание ИТ-архитектуры служит детальным руководством, которое определяет основные, стандартные или типовые элементы ИТ-систем, их взаимосвязи, а также процессы управления информационными системами. Что хотелось бы получить от такого документа? Можно сформулировать следующие, частично противоречивые, требования :

• достаточно высокий уровень детализации для практического использования специалистами в области информационных технологий при разработке новых систем;
• простоту для понимания бизнес-аудиторией;
• динамику рассмотрения (т.е. «Архитектура как есть» – «Краткосрочные и среднесрочные задачи» – «Стратегические планы»);
• возможность адаптации по новым требованиям бизнеса и учет возможностей реализации незапланированных (ad-hoc) проектов.

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

В следующих разделах этой лекции мы рассмотрим наиболее распространенные методики описания архитектур. При этом мы не делаем принципиального различия между теми из них, которые ориентированы на описание архитектуры предприятия как целого, и теми, которые рассматривают более узкий контекст ИТ-архитектуры. Заметим, что достаточно важная и хорошо проработанная методика Федеральной архитектуры США FEAF, документы с описанием которой к тому же находятся в публичном доступе.

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

Таблица 8.1. Модель описания архитектуры

Содержание (предмет) Архитектуры предприятия		Определения архитектуры
		Описания систем		Руководства, Правила и Стандарты
		Как есть	Как должно быть
Бизнес-архитектура	Связи между бизнес-процессами	Принципы (система ценностей и постулатов)
	Бизнес-функции
	Подфункции
	Новые функции
Архитектура информации	Информация	Шаблоны, Правила (политики), Сервисы	Модели технологической архитектуры (список стандартных технологий и продуктов)
Архитектура приложений	Приложения
	Точки доступа
	Интеграция
Технологическая архитектура	Инфраструктура
	Платформы
	Системы хранения
	Сети
	Безопасность
	Системное управление
Описание текущей среды ИТ			Область управления и контроля архитектуры
Движущие силы с точки зрения бизнеса и стратегии

Первое определение говорит о том, что » архитектура – это описание некоторой сложной системы в определенный момент времени». Оно аналогично схемам описания и чертежам здания, города, сада или компьютерной сети. Этому определению архитектуры соответствует центральная секция таблицы . Данная часть таблицы описывает два представления архитектуры : существующее и будущее состояния. В лекциях 10-12, посвященных организации архитектурного процесса, мы отдельно обсудим, как должны, с точки зрения затрачиваемых усилий, соотноситься эти два представления архитектуры .

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

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

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

Источник