Архитектура предприятия: основные определения Лекция из курса «Архитектура предприятия»

Данилин Александр Валентинович, Слюсаренко Андрей Иванович
Интернет-Университет Информационных Технологий, INTUIT.ru

В самом общем виде, в соответствии с определениями Gartner , , архитектура – это:

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

Обратите внимание, что первое определение сфокусировано на описании существующих и будущих систем, второе – на процессе их построения.

Еще несколько определений:

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

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

Рассмотрим теперь более подробно, какие отдельные понятия в рамках представления об "архитектуре" существуют, и как они связаны между собой. Можно выделить, по крайней мере, 3 различных "измерения" в данном континууме определений:

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

Второй постулат заключается в том, что выделяются два понятия:

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

Взаимосвязь этих понятий иллюстрируется на .

Рис. 3.5. Описание архитектуры как проекции реальности

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

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

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

Рис. 3.9. Расширение представлений об "архитектуре предприятия" и дополнительные преимущества

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

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

Рис. 3.10. В поисках интегрированной концепции Архитектуры предприятия

Мы отмечали, что существуют различные определения того, что такое архитектура предприятия. Вот определение, данное The Open Group (): "архитектура предприятия – это способ понимания различных элементов, которые в совокупности составляют предприятие, и то, как эти элементы взаимосвязаны".

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

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

Одной из концепций, ключевой для понимания роли архитектуры предприятия, является концепция расширенной цепочки добавочной стоимости (value chain) ключевых бизнес-процессов . Идея "цепочки добавочной стоимости" привлекла к себе внимание в середине 1980-х годов, когда Майкл Портер (Michael E. Porter) из Гарвардской бизнес-школы опубликовал книгу "Конкурентное Преимущество" (Competitive Advantage, 1985). Большое количество специалистов в области корпоративной стратегии и управления активно используют на практике предложенные Портером модели, такие как "модель пяти факторов влияния", для анализа конкурентной среды и связанных с этим и возможностей угроз.

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

Рис. 3.13. Связь требований бизнеса и различных областей архитектуры ИТ

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

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

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

Архитектура уровня отдельных проектов определяет структуру и функции систем (бизнес и ИТ) на уровне проектов и программ (совокупностей проектов), но в контексте всей организации в целом, т.е. не в изолированном рассмотрении индивидуальных систем. Архитектура уровня отдельных проектов детализирует, соответствует и существует в рамках архитектуры предприятия.

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

Рис. 3.3. Уровни принятия архитектурных решений

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

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

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

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

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

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

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

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

Рис. 3.4. Архитектура как модель реальной информационной системы

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

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

Рис. 3.6. Рамочная модель разработки архитектуры по IEEE 1471

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

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

Возвращаясь к предмету нашего обсуждения, можно рассмотреть различные аспекты понятия архитектуры ИТ. В частности, можно выделять такие подмножества, как системная архитектура (архитектура систем – System Architecture) и программная архитектура (архитектура программного обеспечения – Software Architecture). Вспомним, что мы уже отмечали неоднозначность трактовки терминов. На практике, в зависимости от контекста, термин "системная архитектура" может относиться либо к архитектуре ИТ-системы предприятия (в дополнение к бизнес-архитектуре) или даже в еще более узком смысле к технологической инфраструктуре информационной системы, либо – к архитектуре сложного продукта или семейства продуктов, выпускаемых предприятием.

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

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

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

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

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

В соответствии с интерпретациями Финансово-контрольного управления США (GAO) "... архитектура предприятия является необходимым инструментальным средством для того, чтобы повысить результативность и эффективность существующих в организации бизнес-процессов, а также средством для разработки и реализации поддерживающих их технических систем. В наиболее простой интерпретации организация, учреждение, предприятие и т.д. представляют собой совокупность целенаправленных операционных действий, а архитектура предприятия дает структуру (или структурное описание) этого действия. Архитектура предприятия систематизирует и дает фиксированное описание в виде работоспособных моделей, диаграмм и функциональных описаний всех режимов деятельности данного объекта. Как отмечалось выше, в роли такого объекта может выступать либо отдельная автономная организация, либо функциональная или предметная область, которая охватывает несколько организационных границ (например, финансовое управление, управление сбором данных, управление материального обеспечения и т.п.)"

Формальное описание архитектуры предприятия впервые было сформулировано в стандарте ISO 15704 , который был предложен рабочей группой IFAC/IFIP (International Federation of Automatic Control / International Federation for Information Processing). Идея состояла в том, чтобы разработать максимально общую, так называемую эталонную (reference) модель архитектуры предприятия, которая охватывала бы дополнительно процесс развития предприятия во времени как проект, а также учитывала бы роль человеческого фактора. Архитектуры отдельных подсистем, в том числе ИТ-системы предприятия, могут быть тогда разработаны как специфические уточнения такой общей модели. Разработанная как приложение к данному стандарту, такая общая эталонная модель архитектуры получила название GERAM (Generalized Enterprise Reference Architecture and Methodology). Фактически GERAM представляет собой абстрактное описание архитектуры общего уровня, которая может быть использована для "привязки" и сравнения между собой различных практических моделей архитектур. В частности, в ее рамках определяются такие понятия, как "роль персонала в системе", "продукт", "жизненный цикл", "моделирование процессов" применительно к задачам описания функционирования предприятия.

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

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

Здесь уместна еще одна цитата из документов Финансово-контрольного управления США :

"Архитектура предприятия описывает деятельность предприятия с двух позиций:

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

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

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

Следует заметить, что эволюция понятия "архитектуры предприятия" связана с той эволюцией, которая происходила и происходит во взглядах на принципы организации деятельности предприятия как такового. Имеется в виду использование следующих организационных механизмов, которые условно показаны на :

функциональная специализация;
реинжиниринг бизнес-процессов;
корпоративная архитектура.

Рис. 3.11. Эволюция организационных принципов

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

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

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

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

Рис. 3.14. Бизнес-процессы и обеспечивающие информационные системы в рамках цепочек создания добавочной стоимости

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

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

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

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

Содержание раздела