Определяет структуру и функции систем на уровне проектов и программ

Понятие «архитектура предприятия» впервые появилось в 1987 г. в статье Дж.А. Захмана «Структура архитектуры информационных систем», опубликованной в журнале IBM Systems Journal. В этой статье автор изложил свое видение архитектур предприятий и связанных с ними проблем, которое задало направление развития на последующие 20 лет. В качестве проблемы было обозначено управление сложностью распределенных систем. Захман говорит:

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

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

Лекция 3. Организационные структуры управления

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

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

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

Многие организации испытывают постоянные трудности и находятся в постоянном поиске синхронизации целей и задач бизнеса и процессов развития своих информационных систем. Существует как бы «облако неопределенности» между определением организацией и обеспечивающей ее ИТ-инфраструктурой своих целей и задач.

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

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

Прекрати писать код в ОДНОМ файле Python | ТОП 5 Ошибок и создание правильной архитектуры

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

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

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

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

В самом общем виде, в соответствии с определениями Gartner, архитектура – это:

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

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

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

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

Уровни принятия архитектурных решений

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

Источник: studfile.net

Определяет структуру и функции систем на уровне проектов и программ

В самом общем виде, в соответствии с определениями Gartner [3.6], [3.7], архитектура – это:

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

Обратите внимание, что первое определение сфокусировано на описании существующих и будущих систем, второе – на процессе их построения.

Еще несколько определений:

  • «Архитектура – это инвестиция в стандарты процессов, технологий и интерфейсов в целях улучшения возможностей организаций и уменьшения стоимости разработки и сопровождения информационных систем. Преимущества инвестиций в архитектуру распространяются на несколько проектов сразу, но не все эти проекты могут быть известны в момент разработки архитектуры»;
  • «Корпоративная архитектура ИТ – это видение, принципы и стандарты, которыми организации руководствуются при разработке и внедрении технологий» (Giga Group) [3.8];

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

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

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

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

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

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

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


Рис. 3.3. Уровни принятия архитектурных решений

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

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

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

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

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

Возникает вопрос: «Почему мы должны делать нечто, что соответствует широте охвата уровня предприятия в целом?» Ответ заключается в том, что это открывает новые возможности и позволяет решать проблемы так, как было бы невозможно на более «низком уровне», т.е. в более узких рамках. Например, это позволяет улучшить совместную работу так, что мы сможем уменьшить дублирование между бизнес-подразделениями, и это, в конечном итоге, приведет к созданию более эффективных систем и экономии затрат.

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

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

Читайте также:
Команда shell запускает программы

Источник: citforum.ru

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

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

· иерархия архитектур различных организационных систем;

· соотношения между объективной реальностью и субъективным восприятием;

· соотношения между общесистемной архитектурой и частными архитектурами.

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

Таким образом, мы можем говорить об

1. архитектуре предприятия в целом,

2. архитектуре уровня отдельных проектов или семейства продуктов,

3. архитектуре отдельной прикладной системы.

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

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

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

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

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

Рис. 3.3. Уровни принятия архитектурных решений

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

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

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

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

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

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

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

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

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

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

Возникает вопрос: «Почему мы должны делать нечто, что соответствует широте охвата уровня предприятия в целом?» Ответ заключается в том, что это открывает новые возможностии позволяет решать проблемы так, как было бы невозможно на более «низком уровне», т.е. в более узких рамках. Например, это позволяет улучшить совместную работу так, что мы сможем уменьшить дублирование между бизнес-подразделениями, и это, в конечном итоге, приведет к созданию более эффективных систем и экономии затрат. Теперь рассмотрим «другое измерение», отражающее гносеологический аспект проблемы. С нашей точки зрения, представляется полезным описать следующий «прагматический» подход к формулировке того, «что такое есть архитектура», который частично использует идеи из [3.11].

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

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

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

Читайте также:
Как удалить программу из администратора устройства

Рис. 3.4. Архитектура как модель реальной информационной системы

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

Рис. 3.5. Описание архитектуры как проекции реальности

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

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

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

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

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

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

Этот стандарт определяет такие абстрактные элементы архитектуры, как представления, системы, среды, обоснования, заинтересованные стороны и т.д. в соответствии со схемой, показанной на рис. 3.6.

Рис. 3.6. Рамочная модель разработки архитектуры по IEEE 1471

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

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

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

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

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

В частности, можно выделять такие подмножества, как системная архитектура (архитектура систем – System Architecture) и программная архитектура (архитектура программного обеспечения – Software Architecture).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник: megaobuchalka.ru

Рейтинг
( Пока оценок нет )
Загрузка ...
EFT-Soft.ru