что такое архитектура предприятия
Архитектура предприятия
Архитектура предприятия
Архитектура предприятия — это наиболее общее и всестороннее представление предприятия, как хозяйствующего субъекта, имеющего краткосрочные и долгосрочные цели ведения своей основной деятельности, определенные миссией на региональном и мировом рынке, и стратегией развития, внешние и внутренние ресурсы, необходимые для выполнения миссии и достижения поставленных целей, а также сложившиеся правила ведения основной деятельности (бизнеса).
Содержание
Элементы архитектуры предприятия
Для целей системного анализа архитектура предприятия может рассматриваться в двух аспектах:
Рассматриваемая в статике архитектура предприятия состоит из следующих элементов:
Рассматриваемая в динамике архитектура предприятия — это логически связанный цельный план действий и скоординированных проектов, необходимых для преобразования сложившейся архитектуры организации к состоянию, определенному как долгосрочная цель, базирующийся на текущих и планируемых бизнес-целях и бизнес-процессах организации.
Таким образом, архитектура предприятия в общем случае описывается следующими последовательно зависимыми разделами (см. рис. 1 и рис. 2):
На рис. 1 показано, что выполнение плана миграции не означает замораживания развития бизнес- и системной архитектуры. Таким образом, планируемая системная архитектура является архитектурой «to be» только на определенном витке развития предприятия. Одновременно возврат к стратегическому уровню миссии и стратегических целей и задач не означает необходимость пересмотра миссии и стратегии. Но в конце каждого цикла обязательно проводится анализ эффективности разработанных и осуществленных мероприятий, при необходимости при второй итерации корректируются бизнес-архитектура, системная архитектура, реализуются новые планы миграции. В каждый момент времени может быть несколько циклов, каждый такой цикл не обязательно затрагивает все предприятие в целом, цикл может затрагивать отдельные направления, отдельные вопросы бизнеса и может быть зафиксирован в виде отдельного проекта.
При поэтапном плане миграции для фиксации достигнутых результатов возможно построение промежуточных (миграционных) одной или нескольких архитектур.
Миссия, стратегия и бизнес-цели определяют направления развития банка и ставят долгосрочные цели и задачи.
Слои архитектуры предприятия
В архитектуре предприятия следует выделять следующие слои:
См. также
Ссылки
Фронт-офис (Архитектура предприятия) — Фронт офис в бизнес архитектуре Совокупность бизнес процессов, процедур, нормативных документов (регламентов), справочников, печатных форм, органанизационно штатных подразделений, обеспечивающих со стороны предприятия взаимодействие с клиентом (в … Википедия
Отчётность (архитектура предприятия) — Отчётность в системной архитектуре Совокупность информационных систем, включая базы данных и справочники, автоматизирующих построение отчётности на основе данных из информационного хранилища. Примеры систем отчётности: система управленческой… … Википедия
Учет (Архитектура предприятия) — Учёт в бизнес архитектуре Совокупность бизнес процессов, процедур, нормативных документов (регламентов), справочников, печатных форм, органанизационно штатных подразделений, бизнес процессы, реализующих ведение бухгалтерского учета и отчетности… … Википедия
Бэк-офис (Архитектура предприятия) — Бэк офис в бизнес архитектуре Совокупность бизнес процессов, процедур, нормативных документов (регламентов), справочников, печатных форм, организационно штатных подразделений, реализующих журнальный (регистровый) учет операций, совершенных… … Википедия
Мидл-офис (Архитектура предприятия) — Мидл офис в бизнес архитектуре Совокупность бизнес процессов, процедур, нормативных документов (регламентов), справочников, печатных форм, органанизационно штатных подразделений, обеспечивающих подготовку и принятие решений. Примеры подразделений … Википедия
Информационное хранилище (Архитектура предприятия) — Информационное хранилище в системной архитектуре Совокупность информационных систем, включая базы данных и справочники, реализующих функциональность по описанию метаданных, по сбору, очистке, обогащению, консолидации первичной информации из… … Википедия
Отчетность (Архитектура предприятия) — Отчётность в системной архитектуре Совокупность информационных систем, включая базы данных и справочники, автоматизирующих построение отчётности на основе данных из информационного хранилища. Примеры систем отчётности: система управленческой… … Википедия
Архитектура (значения) — В Викисловаре есть статья «архитектура» Архитектура искусство проектировать и строить здания и другие сооружения (та … Википедия
архитектура — (architecture): Набор элементов конструкции или описательных представлений, необходимый для такого описания объекта, чтобы он мог быть создан в соответствии с требованиями (с нужным качеством), а также обслуживаться в течение всего срока его… … Словарь-справочник терминов нормативно-технической документации
Архитектура предприятия: основные определения
Архитектура предприятия (Корпоративная архитектура)
Эволюция представлений об архитектуре предприятия
Для того чтобы разобраться, какой должна быть архитектура информационных систем предприятия, попробуем вначале определить самые общие рамки данного понятия. С одной стороны, она должна отражать специфику, связанную с информационными технологиями, с другой – отражать бизнес-аспекты деятельности Предприятия.
«Корпоративная Архитектура» или «ИТ-Архитектура» являются терминами, которые специалисты очень часто используют, но при этом редко бывает ясно, что имеется в виду на практике. В реальности профессионалы в области информационных технологий, как уже отмечалось, понимают под архитектурой ИТ достаточно большой спектр понятий – структурированное семейство технических руководств, включая концепции, принципы, правила, шаблоны и интерфейсы, а также взаимосвязи между ними, которые используются при создании новых информационных систем и развитии существующих систем. В отличие от них, профессионалы в области бизнеса не рассматривают этот вопрос как вопрос исключительно технологий. Наоборот, они разговаривают в терминах бизнес-моделей, бизнес-процессов и иногда – бизнес-архитектуры.
Рисунок 3.7 условно показывает эволюцию понятия «Архитектура предприятия». Каждый этап этой эволюции означал все более комплексный и всеобъемлющий подход к описанию и практике использования информационных технологий по обеспечению основной деятельности организации и, как результат, получение все более широкого спектра преимуществ.
В ранних работах ИТ-архитектура понималась в основном как Технологическая архитектура или архитектура, определяющая инфраструктуру информационной системы. Работы по описанию архитектуры были сосредоточены на формировании технологических стандартов и принципов, включая проведение инвентаризации различных технологий, используемых в организации. Такой подход позволяет добиться определенных частных выгод, связанных прежде всего с уменьшением стоимости закупок и эксплуатации информационных систем и уменьшением затрат на разработку приложений и обучение персонала. Однако он является заведомо ограниченным, так как не подразумевает ориентацию на решение бизнес-задач, таких как, например, формирование единых в масштабе компании данных по клиентам.
Следующей ступенью явилось понятие Корпоративной информационно-технологической архитектуры масштаба предприятия (EWITA – Enterprise-wide information technology architecture). Стало понятно, что усилия по описанию архитектуры предприятия должны включать в себя описание архитектуры информации и архитектуры прикладных систем, а не только технологический уровень. Основное направление работ при этом состоит в совместном использовании общих данных, исключении дублирования бизнес-функций, координации управления пользователями, ресурсами, информационной безопасностью за счет улучшений в управлении портфелем прикладных систем.
Корпоративная информационно-технологическая архитектура масштаба предприятия описывает то, как компоненты информационной системы связаны между собой; точно так же бизнес-архитектура описывает то, как элементы бизнеса связаны между собой.
Такой подход обеспечивает более эффективное взаимодействие различных структурных подразделений организации:
Получаемые преимущества носят, в основном, тактический характер.
Очевидным логическим шагом для эффективного описания существующих в организации процессов и планируемых изменений явилось, по мнению авторов [3.13], введение понятия архитектуры предприятия (Enterprise Architecture), которая объединяет корпоративную ИТ-архитектуру масштаба предприятия c бизнес-архитектурой и позволяет обеспечить достижение стратегических целей предприятия. В реальности это две стороны одной медали, которые связаны неразрывно. По сути дела, это должна быть одна архитектура предприятия, показывающая, как связаны друг с другом все элементы ведения бизнеса, что включает также все элементы, связанные с информационными технологиями. Заметим, что в данном контексте мы не различаем деятельность коммерческих и государственных организаций. Действительно, для описания деятельности и функций государственных организаций за рубежом очень часто используется термин «бизнес государственных организаций», что пока не принято в условиях российской действительности.
Преимуществами такого включения бизнес-архитектуры в контекст рассмотрения целостной архитектуры предприятия являются большая способность организации к изменениям или динамичность (agility) и синхронизация возможностей информационных технологий с бизнес-стратегией:
В графическом виде связь таких понятий, как бизнес-архитектура, корпоративная ИТ-архитектура и «архитектура предприятия», показана на рис. 3.8.
Что такое архитектура предприятия, и почему Захман ошибся?
Вторая статья про мифологическое сознание тоже будет короткой. Сегодня я расскажу, к каким проблемам приводит мифологическое сознание при моделировании архитектуры предприятия.
Известная модель Захмана пытается ответить на вопрос, что такое архитектура предприятия, и рассказывает о том, как она должна моделироваться. Основой этой модели являются вопросы, на которые предлагается ответить: кто, когда, где, почему и как совершает что-то над чем-то. Кажется, что это логичный фреймворк для описания архитектуры предприятия, и многие думают, что так оно и есть.
Однако, даже беглый взгляд на этот фреймворк оставляет чувство неудовлетворенности, потому что не понятно, как ответить на вопрос: кто и почему выточил деталь? Кто: Иван Иванович, или токарь, роль которого исполнял Иван Иванович? Почему: потому что токарь получил задание, или потому что Иван Иванович заключил контракт, в соответствии с которым он обязуется выполнять роль токаря в обмен на еду? Почему: потому что Иван Иванович хочет покушать, или затем, что деталь нужна в сборочном цехе?
Более глубокое изучение этого фреймворка заставляет задуматься над его применимостью к описанию технологических процессов. Например, пусть кукуруза растет в поле. Применяя модель Захмана, я должен ответить на вопросы. Кто? Кукуруза. Что делает? Растет. Почему? Потому что так устроен мир. Зачем? Да кто же его знает, зачем растет кукуруза?!
Читатель, натренированный в описании архитектур предприятий, быстро меня поправит. Он скажет, что я неправильно ставлю вопросы. Надо спрашивать: кто выращивает, почему он выращивает, что выращивает. Но тогда получается, что я могу описать деятельность субъекта, который выращивает кукурузу, но не могу описать сам рост. Смирившись с тем, что я не могу описать процесс роста, у меня все равно остаются неразрешенные вопросы: кто и почему выращивает кукурузу (см. выше)?
Получается, что, задавая вроде бы логичные вопросы, я в лучшем случае получаю несколько ответов, а в худшем, не получаю их вообще. Если взять предельный случай, когда у нас есть полностью роботизированное предприятие, на котором вообще нет людей, то ответом на вопрос «кто?» будет — «никто». В результате мы вообще ничего не можем сказать об этом предприятии! Правда, есть один выход из этой ситуации, немного лукавый, – надо лишь воспользоваться мифическим сознанием и одушевить роботов. Тогда, одушевив неодушевленное, мы сможем ответить на вопрос: кто? Робот. Почему? Потому что так устроен этот робот, или потому что программист его так запрограммировал. На второй вопрос мы снова получаем странные ответы. Почему же так получилось, и какие вопросы на самом деле стоит задавать? Я попытаюсь кратко изложить свое мнение на этот счет, рассказав о тех логических ошибках, которые я нашел в модели Захмана.
Если посмотреть на вопросы, которые задаются в модели Захмана, можно убедиться, что они в точности соответствуют теории деятельности. Деятельность – это психическая функция субъекта (группы субъектов). Поэтому, отвечая на вопросы Захмана, мы строим модель психической функции субъекта (субъектов). Наука, изучающая психические функции субъектов, называется психология. Получается, что Захман отвечает на вопросы, которыми задаются психологи: зачем субъект делает то или иное действие? Или как мотивировать субъекта на выполнение тех или иных действий? Эти вопросы, безусловно, интересные и важные, но являются ли ответы на них описанием архитектуры предприятия? Чтобы ответить на этот вопрос, надо понять, что же такое предприятие?
Как же на самом деле происходит проектирование предприятия и какие артефакты при этом возникают? Прежде чем проектировать предприятие, строится модель требований к нему. Модель требований формируется на основе требований, которые предъявлены к этому предприятию со стороны всех его участников, контрагентов и стейкхолдеров. Аналог в ИТ — требования к программному продукту. Далее на основе этих требований строится модель процессов предприятия с необходимой степенью детализации. Аналогом в ИТ будет перечень функций программного продукта. Далее строится модель функциональных объектов, или, говоря специализированным языком, технических мест, которые должны участвовать в перечисленных ранее процессах. Аналогом в ИТ будет описание процедур, и объяснение какие процедуры в каких функциях участвуют. Далее подбираются те единицы оборудования, которые могут выполнять роли перечисленных технических мест. Аналог в ИТ — это программный код.
Предприятие – это функциональный объект, который создан удовлетворяющим определенным требованиям. В этом смысле предприятие ничем не отличается от такого объекта, как часы, или производственная линия. Часто вместо термина функциональный объект можно услышать термин техническое место. Техническое место отличается от единицы оборудования тем, что единица оборудования выполняет роль технического места. Например, трансформатор выполняет роль преобразователя напряжения, при этом в разное время разные трансформаторы могут выполнять роль одного и того же преобразователя. Еще одним примером технического места является должность, отдел, подразделение, штат. Например, токарь участвует в функции изготовления деталей. Это — техническое место, роль которого в разное время могут выполнять разные единицы оборудования (физические лица). О сложностях моделирования технических мест и единиц оборудования я кратко написал в статье Моделирование активов предприятия: современные стандарты и практика.
При моделировании технических мест, мы описываем процессы и участников этих процессов. Замечу, что именно участников, а не исполнителей, — трансформатор не может преобразовывать напряжение, потому что он не является одушевленным существом. Об этом я писал в прошлой статье Моделирование активности и мифологическое сознание. Если все же сказать, что трансформатор «преобразует» напряжение, то это – метонимия, которая раскрывается так: трансформатор, исполняет роль преобразователя напряжения, который (преобразователь) участвует в процессе преобразования напряжения. О метонимии можно прочитать в книге «Метафоры, которыми мы живем», авторы: Джордж Лакофф, Марк Джонсон. Другой распространенной метонимией будет высказывание: «компьютер решает задачи». Те же, кто действительно считают, что трансформатор, или компьютер что-то делает на самом деле, одушевляют неодушевленное, пользуясь мифическим сознанием.
Заметим, что до сего момента мы ни слова не сказали о целях, об исполнителях и причинно-следственных связях. Мы лишь говорили о требованиях, о функциях и участниках этих функций – технических местах. Цели остались на этапе формирования требований к предприятию и далее они не пошли. Мы можем знать эти цели, а можем не знать, — для модели предприятия это не имеет никакого значения. Модель предприятия отвечает на вопрос: как мы удовлетворяем требования, а не то, откуда взялись эти требования. Исполнителей тоже нет, потому что нам не надо пользоваться теорией деятельности, чтобы описать участников активности. Мы не строим причинно-следственные связи. Если же надо построить модель причинно-следственных связей, то это еще одна дополнительная модель. Это знания, которыми пользуются технологи при проектировании предприятия, и я не видел, чтобы кто-то строил такие модели. Это — отраслевые знания, и учат им в институтах по много лет. Смоделировать, почему летит самолет – нереально трудно, и никто этого не делает. Просто моделируют полет самолета.
Итак, модель Захмана не включает в себя требования к предприятию, включает в себя модель процессов, но довольно специфическим способом — с указанием на исполнителей процесса, которых, как я уже сказал можно найти только в теории деятельности, и не разделяет модель технических мест и модель единиц оборудования.
Как я сказал ранее, модель Захмана скорее про деятельность. При этом было бы неплохо, если бы модель Захмана использовалась по назначению, — как способ описания деятельности. Это давало бы возможность анализировать мотивы и заинтересованность людей в их работе, но беда в том, что эта модель используется неверно. Например, на вопрос «почему токарь точит деталь?» можно получить ответ: «она нужна в сборочном цехе». Но необходимость ее в сборочном цехе не отвечает на вопрос, почему токарь точит деталь. Ответ был не на поставленный вопрос, а на какой-то другой. Например, для такого ответа правильным был бы вопрос: в каком процессе, или в какой операции должна участвовать выточенная деталь? Или на каком рабочем месте она нужна? Вы видите, что это совсем не вопрос «почему?». Кроме того, меня сильно смущает наделение Захманом компьютера или информационной системы способностью что-то делать. Скорее всего, он не одушевляет их, но использует метонимию в моделировании, что на мой взгляд, недопустимо.
Правильными вопросами будут: Какие существуют требования к предприятию? Какие процессы протекают на предприятии? Какие технические места в каких процессах участвуют? Какие единицы оборудования выполняют роли каких технических мест и когда?
Собственно, все. С наступающим, и до новых встреч!
Просто о сложном: как разработать архитектуру предприятия
Предпосылки трансформации
Для примера возьмем цифровую трансформацию производственной компании. Есть предприятие, которое выпускает продукцию. Эта продукция создается по определенной технологии в соответствии с производственными планами. Планы формируются на основе представлений менеджмента о запросах рынка. В один момент владельцы решают, что так дальше работать нельзя: спрос на продукцию низкий, а ее производство обходится дорого.
Перед предприятием встают два вызова: внешний (рыночный — низкий спрос на продукцию) и внутренний (неэффективная деятельность). Привлеченная консалтинговая компания рекомендует провести цифровую трансформацию: предприятие должно стать более гибким, а руководству следует принимать решения на основе фактических данных, а не частных мнений. Это задачи для архитектора предприятия.
Что делает архитектор
Архитектор предприятия выступает идеологом и руководителем программы трансформационных проектов. Чтобы понять, какие шаги предпринять, ему необходимо:
Текущее и целевое состояние предприятия (базовые элементы архитектуры) могут быть описаны в различных нотациях, терминах, схемах и таблицах.
Сначала архитектор описывает текущее состояние производства. После чего переходит к разработке целевого состояния производства. Этот процесс включает несколько этапов.
Разработка целевого состояния предприятия
Первый этап: постановка бизнес-задач
В нашем примере с производственной компанией бизнес-задач четыре:
Второй этап: проработка будущего ландшафта информационных систем
Разработав будущую бизнес-архитектуру предприятия, архитектор переходит к проработке будущего ландшафта необходимых информационных систем. Важно понимать, что архитектор предприятия — это и бизнесмен, и айтишник.
Третий этап: проектирование инфраструктуры
Разобравшись с данными и необходимыми прикладными средствами (ПО), архитектор проектирует для них инфраструктуру.
При проектировании инфраструктуры ему важно учесть три момента.
1. Обеспечить работоспособность систем при сбоях
Остановка некоторых процессов может привести к потере бизнесом крупных сумм, к штрафам или упущенной выгоде, поэтому ключевые информационные системы необходимо сделать отказоустойчивыми. Для этого надо зарезервировать критичные компоненты, а всю инфраструктуру разместить в дата-центре.
2. Предусмотреть новые роли в производстве
Кто-то должен развивать и эксплуатировать перспективные процессы, системы и инфраструктуру. Поэтому нельзя забывать про новые роли и новые подходы: управление сервисами, проектный менеджмент, архитектурный надзор и многое другое.
3. Обеспечить информационную безопасность
Важно не забыть про еще одну значимую задачу — обеспечение информационной безопасности. Необходимо решить, кто и каким образом будет обеспечивать защиту информации предприятия. Создать положения и регламенты, решить вопрос с обучением сотрудников и внедрением специализированных средств для целевого ландшафта.
Теперь можно говорить, что целевое состояние описано.
Разработка программы трансформационных проектов («дорожная карта»)
Сравнив «что есть» и «что должно быть», архитектор выявляет несоответствия — это называется gap-анализ. По его результатам формируются проекты. Проекты могут быть разные, к примеру:
После разработки программы проектов можно будет говорить, что архитектура предприятия создана.
Дальнейшие шаги
Разработка архитектуры — это лишь начало большого пути предприятия к тому, чтобы остаться конкурентоспособным в ближайшие несколько лет.
Один из идеологов цифровой трансформации, профессор Массачусетского технологического института Питер Вейлл, говорит, что основной мотивацией для трансформации являются возможные последствия, которые наступят, если от нее отказаться.
Архитектор будет сопровождать реализацию программы трансформации еще несколько лет после ее разработки. Будет много подрядчиков, много продуктов, будут конфликты и будут победы — все изменения архитектору предприятия необходимо будет пропускать через призму стоящих перед бизнесом вызовов и изучать на предмет непротиворечивости другим решениям. А это непростая задача.
Как найти архитектора
Перед владельцами бизнеса встает резонный вопрос: а где найти специалистов по архитектуре предприятия? Есть два пути.
Первый путь — растить из талантливых сотрудников с помощью учебных программ и курсов, выстроенных в логике стратегических планов компании. На обучение корпоративного архитектора потребуется не менее 400 тыс. руб., процесс займет около двух лет.
Второй путь — работать со специалистами из консалтинговых фирм. Это путь среднего и крупного бизнеса. В зависимости от задач и глубины проработки адресная стратегия развития архитектуры предприятия может стоить от нескольких миллионов до нескольких десятков миллионов рублей.
Напоследок рассмотрим, какие задачи архитектор может решить в ретейле и банковской сфере.
Архитектура предприятия: основные определения
Архитектура предприятия (Корпоративная архитектура)
Эволюция представлений об архитектуре предприятия
Для того чтобы разобраться, какой должна быть архитектура информационных систем предприятия, попробуем вначале определить самые общие рамки данного понятия. С одной стороны, она должна отражать специфику, связанную с информационными технологиями, с другой – отражать бизнес-аспекты деятельности Предприятия.
«Корпоративная Архитектура» или «ИТ-Архитектура» являются терминами, которые специалисты очень часто используют, но при этом редко бывает ясно, что имеется в виду на практике. В реальности профессионалы в области информационных технологий, как уже отмечалось, понимают под архитектурой ИТ достаточно большой спектр понятий – структурированное семейство технических руководств, включая концепции, принципы, правила, шаблоны и интерфейсы, а также взаимосвязи между ними, которые используются при создании новых информационных систем и развитии существующих систем. В отличие от них, профессионалы в области бизнеса не рассматривают этот вопрос как вопрос исключительно технологий. Наоборот, они разговаривают в терминах бизнес-моделей, бизнес-процессов и иногда – бизнес-архитектуры.
Рисунок 3.7 условно показывает эволюцию понятия «Архитектура предприятия». Каждый этап этой эволюции означал все более комплексный и всеобъемлющий подход к описанию и практике использования информационных технологий по обеспечению основной деятельности организации и, как результат, получение все более широкого спектра преимуществ.
В ранних работах ИТ-архитектура понималась в основном как Технологическая архитектура или архитектура, определяющая инфраструктуру информационной системы. Работы по описанию архитектуры были сосредоточены на формировании технологических стандартов и принципов, включая проведение инвентаризации различных технологий, используемых в организации. Такой подход позволяет добиться определенных частных выгод, связанных прежде всего с уменьшением стоимости закупок и эксплуатации информационных систем и уменьшением затрат на разработку приложений и обучение персонала. Однако он является заведомо ограниченным, так как не подразумевает ориентацию на решение бизнес-задач, таких как, например, формирование единых в масштабе компании данных по клиентам.
Следующей ступенью явилось понятие Корпоративной информационно-технологической архитектуры масштаба предприятия (EWITA – Enterprise-wide information technology architecture). Стало понятно, что усилия по описанию архитектуры предприятия должны включать в себя описание архитектуры информации и архитектуры прикладных систем, а не только технологический уровень. Основное направление работ при этом состоит в совместном использовании общих данных, исключении дублирования бизнес-функций, координации управления пользователями, ресурсами, информационной безопасностью за счет улучшений в управлении портфелем прикладных систем.
Корпоративная информационно-технологическая архитектура масштаба предприятия описывает то, как компоненты информационной системы связаны между собой; точно так же бизнес-архитектура описывает то, как элементы бизнеса связаны между собой.
Такой подход обеспечивает более эффективное взаимодействие различных структурных подразделений организации:
Получаемые преимущества носят, в основном, тактический характер.
Очевидным логическим шагом для эффективного описания существующих в организации процессов и планируемых изменений явилось, по мнению авторов [3.13], введение понятия архитектуры предприятия (Enterprise Architecture), которая объединяет корпоративную ИТ-архитектуру масштаба предприятия c бизнес-архитектурой и позволяет обеспечить достижение стратегических целей предприятия. В реальности это две стороны одной медали, которые связаны неразрывно. По сути дела, это должна быть одна архитектура предприятия, показывающая, как связаны друг с другом все элементы ведения бизнеса, что включает также все элементы, связанные с информационными технологиями. Заметим, что в данном контексте мы не различаем деятельность коммерческих и государственных организаций. Действительно, для описания деятельности и функций государственных организаций за рубежом очень часто используется термин «бизнес государственных организаций», что пока не принято в условиях российской действительности.
Преимуществами такого включения бизнес-архитектуры в контекст рассмотрения целостной архитектуры предприятия являются большая способность организации к изменениям или динамичность (agility) и синхронизация возможностей информационных технологий с бизнес-стратегией:
В графическом виде связь таких понятий, как бизнес-архитектура, корпоративная ИТ-архитектура и «архитектура предприятия», показана на рис. 3.8.