Поделиться
11 артефактов для описания архитектуры предприятия
Термин "архитектура предприятия" (Enterprise Architecture) все чаще обсуждается на уровне ИТ-директоров, и сейчас даже бизнес стал его использовать. Сегодня мы продолжим начатый ранее разговор на эту тему. При анализе существующих подходов и стандартов по описанию архитектуры предприятия (Enterprise Architecture) можно столкнуться с большим числом артефактов – предметных областей описания, – которые нужно создать в проекте. Российская практика показывает, что на первых шагах можно обойтись и небольшим числом артефактов.Среди ИТ-архитекторов наибольшим спросом пользуются архитектурный процесс и методика описания архитектуры предприятия, описанная в TOGAF (The Open Group Architecture Framework), который приобрел известность из-за своей открытости и полноты.
Однако TOGAF часто является избыточным для описания архитектуры предприятия в российских условиях, именно поэтому во многих компаниях на практике вырабатывается сокращенный перечень артефактов, которые и описываются на первых шагах архитектурного проекта. При этом данный перечень может быть расширен или сужен в зависимости от поставленных задач, но, так или иначе, нижеописанные предметные области встречаются на практике достаточно часто. Нельзя забывать, что отдельное описание той или иной предметной области без взаимосвязи с остальными не имеет смысла, поэтому важной частью предлагаемого подхода является построение взаимосвязей при описании архитектуры предприятия.
Области описания Enterprise Architecture
Увеличить
Источник: данные автора, 2012
Цели бизнеса – описываются обычно в виде иерархического дерева. На верхнем уровне располагается миссия компании, при дальнейшем описании производится детализация целей на 3-4 уровня, до момента, когда цели могут быть измерены показателями. Чаще всего в рамках описания цели связаны с показателями бизнеса, бизнес-процессами, системой проектов и организационной структурой. Также существует более сложное представление целей, чем иерархическое, это карта системы сбалансированных показателей (BSC), в ней цели показаны во взаимосвязи межу собой.
Показатели бизнеса – эта предметная область, которая описывает набор ключевых показателей результативности бизнеса. Если описывать показатели отдельной моделью, отражая взаимосвязи влияния между показателями, то получаются достаточно сложные сетевые диаграммы, анализ которых бывает затруднен. При этом показатели бизнеса могут быть связаны с целями, бизнес-процессами и источниками данных, а также информационными системами, которые являются источниками для их расчета.
Требования бизнеса к информационным системам. Модели требований, как правило, строятся в виде иерархии, детализирующей требования "сверху-вниз". При этом важно не только классифицировать требования, но и связать их между собой связями влияния, а также создать инструмент трассировки зависимостей и управления их статусами.
Система проектов, иерархическая модель, состоящая из набора инициатив по трансформации бизнеса и переходу от архитектуры "как есть" к архитектуре "как должно быть". При этом проекты могут быть связаны с требованиями бизнеса, которые будут "закрыты", информационными системами, введенными в эксплуатацию по завершении проектов, и элементами организационной структуры, отвечающими за тот или иной проект.
Бизнес-процессы в большинстве проектов по описанию архитектуры предприятия являются той картой, на которой отражается взаимосвязь различных предметных областей. Описание бизнес-процессов часто выглядит как иерархический набор моделей с минимальной логикой на верхнем уровне описания и максимальной детализацией на уровне рабочих мест. В качестве методологии описания бизнес-процессов может быть использована любая, главное, чтобы она позволяла связать процесс с объектами других предметных областей – организационной структурой, информационными системами, документами, данными и т.д.
При описании архитектуры предприятия одной из ключевых предметных областей является организационная структура, которая позволяет отразить полномочия и подчиненность в компании, а также указать ответственных по большинству остальных предметных областей. На практике встречаются сложные варианты описания организационной структуры, например, в случае матричных структур или даже многомерных, но так или иначе эта предметная область используется в подавляющем большинстве проектов.
Для отражения в модели предприятия существующей архитектуры приложений делается модель информационных систем. При этом информационные системы могут быть описаны, как в виде иерархического реестра, так и с указанием взаимосвязей между ними. Детализация при описании информационных систем может быть доведена до отдельных модулей и даже отдельных пользовательских форм – экранов, которые указываются в моделях бизнес-процессов.
Еще одна предметная область, которая требует описания – это возможности информационных систем, в ее рамках документируется функционал информационных систем, уже используемых в компании. Ведь очень часто существующие системы имеют неиспользуемый функционал или перекрывают функционал друг друга.
Важным элементом архитектуры предприятия, который часто требует повышенных ресурсов при описании, являются данные. На уровне бизнес-архитектуры это чаще всего классификаторы документов, которые на нижнем уровне описания содержат документы компании, встречающиеся на моделях бизнес-процессов. При этом для дальнейшей детализации документа можно описывать атрибуты документов, или прилагать пример формы в текстовом формате.
На уровне ИТ-архитектуры данные могут быть описаны в виде модели «сущность-связь» (entity-relationship model, ERM), с помощью которой рисуются концептуальные схемы предметной области. При этом в качестве окружения информационных сущностей могут быть использованы атрибуты объектов, которые в свою очередь связаны с атрибутами документов или полями экранной формы.
Еще одной предметной областью является описание ИТ-инфраструктуры, в рамках которой создается модель сетевых и серверных ресурсов, во взаимосвязи с информационными системами, которые на них расположены.
Такие ограничения перечня предметных областей описания позволяет минимизировать затраты на описание архитектуры предприятия, и главное на последующую актуализацию созданной модели. При этом результатами описания являются не столько модели, сколько отчеты, которые можно получить через анализ взаимосвязей вышеуказанных артефактов. Примерами могут являться различные виды анализа, построенные на основании таблицы. Например, какие бизнес-процессы пострадают в случае отказа того или иного элемента ИТ-инфраструктуры. Или требования бизнеса, которые не закрыты существующей системой проектов. Еще одним примером может являться отчет показывающий, в каких бизнес-процессах используется, та или иная информационная система.
Таким образом, созданное описание архитектуры предприятия позволяет получить согласованную модель, а также инструмент анализа полноты элементов существующей архитектуры.
Короткая ссылка
