Файл: Ответы на экзамен АП.docx

Очевидным логическим шагом для эффективного описания существующих в организации процессов и планируемых изменений явилось, по мнению авторов, введение понятия архитектуры предприятия (Enterprise Architecture), которая объединяет корпоративную ИТ-архитектуру масштаба предприятия c бизнес-архитектурой и позволяет обеспечить достижение стратегических целей предприятия. В реальности это две стороны одной медали, которые связаны неразрывно. По сути дела, это должна быть одна архитектура предприятия, показывающая, как связаны друг с другом все элементы ведения бизнеса, что включает также все элементы, связанные с информационными технологиями. Заметим, что в данном контексте мы не различаем деятельность коммерческих и государственных организаций. Действительно, для описания деятельности и функций государственных организаций за рубежом очень часто используется термин "бизнес государственных организаций", что пока не принято в условиях российской действительности.

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

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

9. Контекст Архитектуры предприятия.

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

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

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

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

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

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

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

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

10.Интегрированная концепция архитектуры предприятия

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

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

11.Уровни абстракции (перспективы) в описании архитектуры предприятия

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

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

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

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

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