Бизнес архитектура основные элементы модели и инструменты описания бизнес архитектуры

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

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

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

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

Миссия и видение.

Руководящие принципы.

Цели, задачи и стратегии.

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

Политики (правила).

ИТ-стандарты.

Процедуры. Процедуры – это инструкции, описывающие, как выполняются политики и стандарты. Процедуры устанавливают и описывают процессы, которые выполняются на регулярной основе.

Руководства или рекомендации (guidelines).

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

Декомпозиция бизнес-процессов

Анализ бизнес – событий

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

Модель местоположения

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

Модель интеграции

определяет связь бизнес-процессов и бизнес — событий.

Ниже приведены примеры общих принципов, связанных с архитектурой в целом:

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

Функциональное руководство и руководство в области ИТ должно основываться на общем видении.

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

Функциональные (бизнес-) требования должны формировать архитектуру.

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

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

Архитектура должна быть инструментом реализации изменений.

Архитектура должна уменьшать сложность интеграции и способствовать улучшению качества бизнес-процессов.

Тенденции рынка должны учитываться при проектировании технологической архитектуры.

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

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

Модели и инструменты описания бизнес-архитектуры

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

К сожалению, «одной и самой лучшей» модели для описания бизнес-архитектуры организации не существует. Вместо этого могут использоваться модели причинно-следственных связей, функциональные модели, временные диаграммы, потоковые модели и т.п. Как уже отмечалось, наиболее популярными в этом деле являются модели бизнес-процессов. Существует целый арсенал программных средств — ARIS, BPWin, ER Win Software Architect и др. — поддерживающих процессы моделирования деятельности организаций в нотации бизнес-процессов.

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

• • декомпозицию функций/процессов;
• • анализ бизнес-событий;
• • моделирование местоположений выполнения функций/процессов;
• • моделирование интеграции функций/процессов.

Декомпозиция функций/процессов состоит в идентификации подпроцессов, которые составляют основу выполнения бизнес-функций и определение вклада каждой функции в цепочку создания добавленной стоимости. В результате декомпозиции должны быть определены следующие компоненты:

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

Некоторые сведения о том, как идентифицировать эти и другие

моменты бизнес-архитектуры, содержит табл. 2.1.

Ключевые моменты декомпозиции функций/процессов

Основные задачи анализа

Результаты (артефакты) анализа

определить границы каждой бизнес-функции;

понять состав подпроцессов каждой бизнес-функции;

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

подпроцессы основных бизнес-функций;

идентификация излишних, малополезных и неэффективных функций/процессов;

идентификация структурных подразделений/долж- ностных позиций, ответственных за реализацию функций/процессов;

требования к информации и прикладным системам

каковы основные функции организации;

какие функции бесполезны;

какие функции не поддаются декомпозиции;

какие подразделения организации отвечают за реализацию функций/процессов

Анализ бизнес-событий призван найти ответы на следующие вопросы:

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

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

Ключевые моменты анализа бизнес-событий

Основные задачи анализа

Результаты (артефакты) анализа

составить перечень набора основных бизнес-событий и обеспечить их однозначное понимание;

проанализировать возможности оптимизации бизнес-процессов;

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

основные инициаторы и участники бизнес- событий;

партнеры из внешней среды;

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

инициализация инновационных разработок;

новые формы ведения бизнеса

кто является инициатором бизнес-события;

как обрабатывается каждое событие;

кто является основными участниками события;

возможны ли инновации на базе данного события и будут ли они востребованы бизнесом

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

Ключевые моменты модели местоположений выполнения функций/процессов

Основные задачи анализа

Результаты (артефакты) анализа

определить места выполнения функций/ процессов;

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

выработать требования технологической инфраструктуры к географии бизнес-функций и бизнес-процессов

распределение функций по местоположениям;

уточнение связей между бизнес-функциями;

идентификация требований к технологической инфраструктуре и архитектуре прикладных систем;

возможности организационных изменений

где выполняются основные функции;

какие функции и как связаны между собой;

существуют ли возможности консолидации и/или рационализации функций/ процессов организации

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

Ключевые моменты модели интеграции

Основные задачи анализа

Результаты (артефакты) анализа

определить и обеспечить понимание ключевых внутренних и внешних точек интеграции;

идентифицировать информационные потоки между участниками бизнес-событий;

определить и обеспечить понимание основных интерфейсов прикладных систем;

сформировать и обеспечить понимание интеграционных требований к технологической инфраструктуре организации

потоки информации, диктуемые принятыми шаблонами бизнес- процессов;

связи между функциями;

требования к архитектуре информации, архитектуре приложений и технологической инфраструктуре;

возможности для организационных изменений

какая информация является критической для новых шаблонов реализации бизнес- процессов;

какие потоки информации существуют между точками соединения моделей бизнес-событий;

каковы временные требования к осуществлению обменных операций

В заключение параграфа заметим, что в связи с развитием принципов сервис-ориентированной архитектуры и появлением технологически нейтрального, информационно независимого языка описания и выполнения бизнес-процессов (Business Process Execution Language — BPEL) появилась возможность не только моделировать бизнес-процессы, но и делать их целиком или частично доступными другим системам и организациям в виде сервисов. Это открывает возможность создавать модели бизнес-процессов и многократно использовать их в архитектурных построениях различных систем и приложений.

Источник: studref.com

Разработка бизнес-архитектуры

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

1. Подготовительный этап

Выбор референсной модели

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

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

Определение набора точек зрения

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

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

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

Выбор подходов и инструментов

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

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

Подготовка такого рода позволяет существенно упростить процесс создания бизнес-архитектуры.

Формирование подхода к моделированию

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

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

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

Подготовка перечня каталогов

Каталог – перечень и описание однотипных элементов бизнес-архитектуры. Например: каталог организационных единиц, каталог бизнес-процессов, каталог ИТ сервисов и т.д.

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

Каталоги имеют свою иерархию, то есть они содержат описание классов, подклассов и конкретных элементов. Например: каталог организационных единиц, каталог должностей, каталог ролей.

Каталоги являются исходным материалом для разработки моделей и матриц.

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

Выбор набора матриц

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

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

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

Определение необходимых диаграмм

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

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

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

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

Сбор бизнес-планов

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

Формирование сценариев бизнес-архитектуры

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

Подготовка базы знаний бизнес-архитектуры

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

На данном этапе необходимо подготовить базу знаний для дальнейшего наполнения.

Выявление требований

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

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

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

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

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

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

2. Описание текущей архитектуры

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

Помимо этого объем и степень детализации зависит еще от двух факторов:

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

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

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

Бизнес-архитектура

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

3. Разработка целевой архитектуры

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

Объем описания и степень детализации определяются на основании:

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

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

Вы всегда можете обратиться в нашу компанию по вопросам описания и разработки бизнес-архитектуры
Свяжитесь с нами

Свяжитесь с нами, чтобы получить дополнительную информацию

4. Верификация и анализ разрывов

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

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

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

5. Формирование дорожной карты перехода

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

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

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

6. Оценка воздействия бизнес-архитектуры

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

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

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

7. Проверка заинтересованными сторонами

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

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

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

Согласование должно быть закреплено в Положении о бизнес-архитектуре.

8. Наполнение репозитория и базы знаний

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

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

9. Сборка итогового документа

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

Также необходимо убедиться в том, что:

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

o Подробное описание бизнес-функций и процессов

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

o Описание потребности функций и бизнес-процессов в информации

o Стандарты, правила, руководства, которые описывают методы реализации функций и бизнес-процессов

o Должностные инструкции

o Описание механизмов контроля и отчетности

• Модели, графики и отчеты, демонстрирующие основные точки зрения на бизнес-архитектуру

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

На этом я завершаю обзор процесса разработки бизнес-архитектуры.

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

Источник: deep-vision.one