Введение. 
Основные элементы и слои архитектуры предприятия. 
Разработка архитектуры магазина одежды "Terranova"

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

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

архитектура информационный слой.

Теоретические аспекты архитектуры предприятия

Ключевые элементы архитектуры предприятия

Управление архитектурой предприятия (Enterprise Architecture) создает основу для синхронизации объектов внутри предприятия и в то же время обеспечивает их непрерывное изменение для целей оптимизации бизнеса.

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

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

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

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

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

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

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

Для построения архитектуры данных необходимо выделить основные сущности и агрегировать на них все «кванты» информации, собранные из описания бизнес-процессов. Практика показывает, что для решения данной задачи следует использовать стандартную методологию описания данных — модель «сущность-связь» (Entity-Relationship Model — ERM), в рамках которой можно четко структурировать всю информацию. Следующий этап формализации ИТ-архитектуры — переход от архитектуры бизнес-процессов и архитектуры данных к созданию архитектуры приложений. На этом этапе важно определить классы информационных систем, необходимых для автоматизации, а также модули для каждой информационной системы. Основой для проектирования архитектуры приложений и ее синхронизации с бизнес-архитектурой является карта процессов (обобщенное представление всех бизнес-процессов предприятия). На модели архитектуры приложений располагаются основные типы информационных систем, которые далее детализируются на модели модулей информационных систем и далее до уровня отдельных экранных форм — транзакций.

Еще одним ключевым элементом архитектуры с точки зрения взаимосвязи бизнес-архитектуры и ИТ-архитектуры являются требования к информационной системе. Фактически модели требований — это целевой функционал ИТ-решения, который структурируется по бизнес-процессам или по подразделениям. На основании этих требований и существующих моделей бизнес-процессов, а также с учетом построенных моделей данных проектируется новая (целевая) архитектура приложений. При этом помимо методологий управления архитектурой предприятия для решения поставленных задач необходимо использовать и отраслевые стандарты. Например, в случае телекоммуникационных компаний в качестве основы можно использовать материалы методологии New Generation Operation System and Software (NGOSS), которая была создана в 2001 г. TeleManagement Forum и содержит следующие модели:

• 1. модель операций телекоммуникационной компании eTOM (Enhanced Telecom Operations Map — eTOM);
• 2. информационная модель телекоммуникационного предприятия (Enterprise-wide Information Framework Shared Information and Data Model — SID);
• 3. структура приложений телекоммуникационной компании (Applications Framework — Telecom Applications Map — TAM).