В первой части этой статьи (Intelligent Enterprise, № 4/2008, стр. 46 [1]; www.iemag.ru/articles/detail.php?ID=6612) показаны истоки комплексной дисциплины «архитектура предприятия» (АП), её проблемы и актуальные достижения, накопленные к концу прошлого века. Теперь представим то главное, что появилось в АП в новом столетии и определяет эту дисциплину сегодня.

Универсальная дисциплина

Прежде всего напомним, что АП не есть дисциплина, ориентированная именно на ИТ или даже на согласование бизнеса и ИТ. У предприятия, функционирующего в меняющейся среде, есть много и других компонентов помимо ИТ, требующих комплексного описания и проектирования. Однако не случайно, что первый виток АП сформировали специалисты из IBM, а требования к референсным архитектурам и методикам этой дисциплины разработал комитет ISO по автоматизации предприятий. Общая информация и автоматизация сквозных процессов — два важных рычага, служащих объединению разных частей предприятия, поэтому ИТ-специалистам неизбежно приходится заниматься такой интеграцией. Именно по этой причине использование АП — это естественный путь повышения роли ИТ-руководителей и специалистов в развитии предприятий. И аспекты информатизации в АП постоянно будут оставаться в поле нашего внимания.
Тем не менее надо помнить, что «инженерия предприятий» (Enterprise Engineering) и «системная инженерия» (System Engineering), или создание предприятия и создание «системы масштаба предприятия» — это пересекающиеся, но всё же разные вещи. Поэтому сегодня не только масштабы, но и сфера применения АП закономерно расширились за пределы формирования ИТ-архитектур (см. таблицу).
Исследование IFEAD (www.enterprise-architecture.info) также показало, что в 2005 году АП использовалась:
  • в организациях самого разного масштаба, на предприятиях всех отраслей и типов, включая частные компании и госорганы,
  • в том числе и как инструмент стратегического управления предприятием в целом,
  • не только ИТ-директором или CIO, но также советами директоров и высшим менеджментом, в том числе для планирования изменений в организации.
При этом ответственность высшего менеджмента за АП постоянно росла. Позднее эти тенденции были подтверждены и другими исследователями.

Новые реалии

В первой части статьи было сказано, что основные прин­ципы и методы АП, определенные в 90-х годах, остаются актуальными и сегодня, а их назначение, как и цели применения самой АП, не должны заслоняться новыми архитектурными стилями или инструментами моделирования. Но можно ли говорить, что на идейном уровне изложенного там достаточно? Конечно, нет. Архитектурные подходы (например, ту же схему Захмана) правильно применять в соответствии с современным пониманием того, чем является предприятие, и с теми наработками, которые созданы за последние годы.
Очевидно, что контекст, в котором функционируют предприятия, все эти годы менялся. Росла информационная мобильность бизнеса и потребителей, услуги начали предлагаться повсеместно. Вместе с тем повысилась требовательность к эффективности бизнеса и ИТ-систем, TCO и ROI стали одним из определяющих элементов в работе CIO. И это лишь некоторые из тех новых стимулов, которые не могли не повлиять на развитие АП и определили новый виток ее развития.
И уже в 2000 году наиболее фундаментальные положения современной АП оказались закреплены в стандарте ISO 15704 [2], на базе которого сейчас готовится национальный ГОСТ.

Главные положения ISO 15704

Основной текст стандарта весьма насыщен при малом объёме — всего восемь страниц плюс важное четырехстраничное введение. Еще 32 страницы составляет приложение с описанием схемы GERAM (см. о ней в первой части статьи), имеющее статус примера. Стандарт предназначен для определения требований к архитектурам и методологиям предприятия (enterprise-reference architectures and methodologies). С учетом его положений в 2006 году был выпущен стандарт ISO 19439 «Enterprise integration — Framework for enterprise modelling»; сам ISO 15704 в 2005 году получил «Дополнительные представления с точки зрения пользователя».
Стандарт ISO 15704 нацелен на решение задач трех типов: создание предприятия, его реструктуризация и инкрементальные изменения. Он ориентирован как на людей, так и на технологии (базовые и вспомогательные) и фиксирует необходимость комплексного подхода: «Было бы ошибкой ограничить обсуждение интеграции только вопросами информации и систем управления…» — и далее: «…полное решение должно включать информацию, культуру и миссию».
Заметим, что ISO 15704 создан комитетом не по ИТ как таковым, а по автоматизации предприятий (рабочей группой по архитектуре, связям на предприятии и его интеграции). Наверное, по этой причине в его основе лежит подход, отличающийся от «обычных» стандартов и методик ИТ-специалистов: в центре внимания постоянно находится именно предприятие как комплексный объект. Причем в это понятие включены и так называемые расширенные и виртуальные предприятия. Для ИТ-специалистов все это — «объект автоматизации».
Принципиально важным в стандарте ISO 15704 является определение архитектур двух типов. Цитируем: «Архитектура — это описание (модель) основной компоновки и взаимодействия частей системы (будь то физический либо абстрактный объект или сущность).
Примечание. Есть два и только два типа архитектур, относящихся к интеграции предприятий:
  • архитектуры систем (иногда называемые архитектурами типа 1), которые имеют дело с конструкцией некоторой системы, например, компьютерной системы управления как части всеобъемлющей системы интеграции предприятия;
  • архитектуры (планы/проекты) предприятия (иногда называемые архитектурами типа 2), которые имеют дело с таким проектом, как интеграция всего предприятия, или с иной программой его развития».
В стандарте рассматриваются требования в первую очередь к архитектурам типа 2, которым соответствуют «референсные архитектуры и методологии».
Из определения вытекают важные следствия для выстраивания связей между АП в целом и архитектурами отдельных систем предприятия. Проиллюстрируем это схемой (рис. 1), выполненной на основе [3]. В этой схеме архитектура типа 2 определяет общие принципы и правила, а также план интеграции предприятия, в том числе в виде адаптированных референсных и специфических моделей. С их использованием создаются конкретные представления и модели архитектур типа 1 для отдельных систем. Далее эти конкретные представления и модели используются в процессе реализации соответствующей отдельной системы. В АП и в архитектуре отдельной системы показанные связи охватывают три традиционных взгляда на предприятие: «бизнес-архитектуру», «системную (логическую) архитектуру» и «физическую архитектуру» (в том числе технологическую, но также организационную и др.).
Предложенные на рис. 1 связи позволяют:
  • сознательно формировать баланс децентрализации и централизации при планировании и выполнении проектов развития предприятия;
  • разграничить функции архитектора предприятия и его группы, с одной стороны, и архитекторов отдельных систем — с другой.
Отсюда следуют основные виды работ архитектора предприятия и его группы (перечень не исчерпывающий):
  • создание внутренних стандартов предприятия в области АП (в том числе обобщенные элементы АП, принципы и правила, адаптированные референсные модели);
  • создание общих планов и схем выполнения программ интеграции и развития предприятия;
  • архитектурный мониторинг и экспертизы конкретных проектов с точки зрения стандартов, планов и схем АП.
Хотя в определение архитектуры по ISO 15704 не включены принципы и правила архитектурной работы, однако стандарт фактически определяет требования к полной дисциплине АП как включающей две части — структурную и процедурную. В нем постоянно используются выражения типа: «Референсные методики и архитектуры».
Указано, что референсные методики и архитектуры могут базироваться или не базироваться на модельном подходе. Это означает, что АП в первую очередь основана на обобщенных элементах (глоссариях, метамоделях и др.), обеспечивающих целостность представлений предприятия, а также на общих принципах и процедурах. При этом для работы с одним архитектурным представлением на одном предприятии могут использоваться разные методики.
Еще одно важное положение ISO 15704: к языкам моделирования предъявляются требования не столько формализации моделей, сколько их адекватности и понятности для всех, кто с ними работает. По этой причине на предприятии могут применяться различные языки в соответствии с предпочтениями разных пользователей.
АП, основанные на моделях, согласно стандарту должны поддерживать идею «многократно применимых референсных моделей» (reusable reference models). Такие модели вводятся стандартом для того, чтобы за счет использования концепций, применимых на многих предприятиях, можно было повышать эффективность моделирования. При этом указывается, что референсные модели требуют адаптации к конкретному предприятию, то есть не рассматриваются как эталон для непосредственного применения. Предусматривается также возможность создания специфических/детальных (particular) моделей, которые описывают некоторую сущность конкретного предприятия или его части.
Может возникнуть вопрос: как подобную децентрали­зацию проектирования совместить с обычным желанием описать в АП сразу все реальные бизнес-процессы, базы данных и т. д.? Или с положениями того же стандарта о том, что инструментальные средства могут связывать модели и реальные бизнес-процессы, или что одним из результатов может быть модель «операционной системы предприятия» (enterprise-operational system), непосредственно решающей его задачи?
Чтобы разрешить это кажущееся противоречие, необходимо принять следующие положения:
  • степень децентрализации архитектурного управления и проектирования выбирается в каждом случае отдельно;
  • обобщенные принципы, метамодели и методики в любом случае составляют центральную часть АП и играют роль стандартов предприятия;
  • каждую референсную модель надо вводить с чисто прагматической целью повысить эффективность моделирования и проектирования, причем по мере создания и адаптации таких моделей;
  • границы между обобщенными элементами и референсными моделями АП размыты, одно может переходить в другое.
Наконец отметим, что показанное выше — лишь малая часть тех положений стандарта, которые еще значительное время будут определять основы формирования АП.

FEA: «Федеральная архитектура предприятия»

Мощный толчок развитию архитектур сверхкрупных распределенных человеко-машинных систем дали программы создания электронных правительств (ЭП). Концепции, методы и модели архитектур ЭП в них планомерно разрабатывались в течение многих лет — вплоть до обобщенных «архитектур правительства». В результате процесс заимствования идей на определённое время поменял направление: многие методы и модели архитектур, созданные для ЭП, стали заимствоваться коммерческими предприятиями. В разных странах сделаны свои важные разработки, но здесь мы покажем вклад в архитектурный подход только FEA — «Федеральной архитектуры предприятия» [4], развиваемой в США и, возможно, получившей наибольшую известность.
В FEA реализуются федеративные принципы АП — оригинальное сочетание общего централизованного руководства и децентрализованного планирования при реализации архитектур отдельных организаций (а тем более — отдель­ных ИС). Из методических особенностей FEA укажем на ее полноценный состав, на принцип сегментного подхода и на развитие не только обобщенной схемы, но и важных референсных моделей. Состав FEA предусматривал следующие категории компонентов:
  • стимулы (деловые и технические) и стратегическое направление развития архитектуры (включая его видение, цели и объекты);
  • принципы, другие руководящие материалы, стандарты и глоссарий, а также примеры (образцы, сравнительные измерения) передового опыта;
  • архитектурные референсные модели;
  • текущую и целевую архитектуры;
  • переходные процессы, включая планирование инвестиций, проектов перехода к целевой архитектуре, управление проектами и их контроль;
  • архитектурные сегменты для специфических областей деятельности;
  • репозиторий для централизованного накопления и распределенного использования архитектурных компонентов всех видов.
Одно из полезных положений FEA — принцип сегментного подхода — дает возможность ускорять практическое внедрение АП, особенно в больших многоотраслевых образованиях, позволяя относительно независимо работать в рамках одного сегмента, обеспечивая минимизацию затрат, поддержку общих ресурсов и стандартов взаимодействия систем разных сегментов.
Отметим, что принципы FEA определены как важнейшие руководящие правила, и поскольку АП не обязательно базируется на моделях, этим (и подобным) принципам нужно уделять большое внимание. FEA включает и другие ценные методические документы, например, по управлению инвестициями, по оценке зрелости архитектуры.
Достижением FEA считаются её референсные модели, которых на октябрь 2007 года насчитывалось пять: модель результативности (эффективности); функций и сервисов деятельности; прикладных ИТ-сервисов/компонентов общего назначения; базовых технических ИТ-сервисов и стандартов; информации и данных. По большей части они представляют собой каталоги «эталонных» архитектурных элементов, многие из которых не несут особой специфики ЭП и могут быть адаптированы к любым предприятиям. Например, модель прикладных ИТ-сервисов/компонентов общего назначения в адаптированном виде пригодна для планирования приобретений или разработок программных продуктов практически в любой компании.
Одна важная деталь: хотя все эти модели определены как референсные, в США от государственных агентств требуется строгая привязка к их элементам. В отличие от требований ISO 15704 каждая организация, запрашивая централизованные инвестиции, должна доказать, что строит свою АП через конкретизацию этих моделей. В таком смысле модели FEA могут быть названы эталонными. Вместе с тем FEA вполне можно признать и «архитектурой типа 2» по ISO 15704.
Методики и модели FEA, учитывающие накапливаемый практический опыт, развиваются уже восемь лет. В итоге FEA стала одним из важнейших примеров последовательного развития и применения федеративной организации АП.

Другие актуальные достижения АП

В статье 1999 года про барьеры и перспективы развития АП Джон Захман писал, что никакой жизни не хватит для того, чтобы прочесть все книги и просмотреть все инструменты, посвященные хотя бы только его собственной схеме архитектуры. Поэтому, говоря о других достижениях дисциплины АП, упомянем лишь некоторые моменты.
  1. Развитие работ по интеграции стратегий и архитектур предприятий.
  2. Методика TOGAF в версии «Enterprise».
  3. Развитие сервисно-ориентированных подходов к архитектуре предприятия.
  4. Развитие программных инструментов, ориентированных на представление АП.
1. Интеграция АП и стратегии развития предприятия (либо только его ИТ). В настоящее время этой теме посвящено много работ, причем соседствуют два направления: встраивание АП в стратегию и наоборот, встраивание документов стратегического планирования в АП. Стоит обратить внимание на работу [3], где показано, как органическое соединение этих форм планирования предприятия основано на столбце «ЗАЧЕМ» схемы Захмана, на моделях эффективности предприятия и его ИТ, а также на цикле ситуационного маркетингового управления предприятием.
Последнее особенно важно в условиях обостряющейся локальной и глобальной конкуренции. В частности, конкурентная ситуация может в еще большей степени, чем раньше, требовать, чтобы «завтрашняя» целевая ИТ-архитектура формировалась с учетом перспективной «послезавтрашней» бизнес-архитектуры. Соответствующие связи, основанные на концепции «3D-предприятия» (см. первую часть статьи) показаны на рис. 2. Если такие связи не учитывать, ИТ могут оказаться серьезным тормозом для своевременного реагирования на конкурентное давление внешней среды.
2. TOGAF (The Open Group Architecture Framework) версии 8.1.1. В настоящее время популярность методики TOGAF [5], получившей в этой редакции характеристику «Enterprise Edition», возросла, приблизившись к популярности схемы Захмана. На взгляд автора, это связано в первую очередь с развитием описания циклической организации работ по согласованию ИТ с потребностями бизнеса. На самом верхнем своем уровне TOGAF включает блоки, схожие с блоками метода EAP Спивака (см. первую часть статьи), однако применяемые в другом порядке. В отличие от EAP, ориентированного на данные, TOGAF имеет явную процессную ориентацию. TOGAF сконцентрирована на планировании именно ИТ-архитектуры, однако в ее следующих версиях больше внимания будет уделено бизнес-аспектам предприятия.
3. Влияние SOA и сервисного подхода в целом на развитие АП. Сервисный подход в рамках АП является одним из важных стилей формирования архитектуры предприятия. При этом неправильно связывать этот стиль с технологией именно веб-сервисов. Скорее надо учитывать обобщенную референсную модель и архитектуру SOA консорциума OASIS («OASIS Reference Model for Service Oriented Architecture, v.1, 2006»; во второй половине 2008 года ожидается также подготовка референсной архитектуры для SOA). Однако и эти стандарты SOA — только один из элементов, поскольку для формирования АП первым делом рекомендуется рассматривать SOE, Service Oriented Enterprise — сервисную ориентацию предприятия в целом (включая его поведение, культуру и людей).
Сейчас SOA представляет наибольший интерес для ИТ-специалистов (отчасти — уже и для аналитиков по управлению бизнес-процессами), хотя практика пока не позволяет без оговорок признавать пользу повсеместного применения этого подхода для ИТ. Все же сервисный подход в широком его смысле является мощным направлением развития компонентных методик формирования систем, усиливает внимание к типовым компонентам и повторному использованию ИТ-ресурсов, придает большую гибкость бизнес-процессам.
4. Развитие программных инструментов для поддержки работы с АП. За последние годы инструменты для работы с АП вышли на качественно новый уровень развития. При этом многие из них позволяют использовать организацию моделей, предусмотренную схемой Захмана. Однако по мнению автора они еще в недостаточной степени позволяют решать в совокупности три задачи:
  • вести репозиторий весьма разнородной архитектурной информации с использованием средств, ориентированных в том числе и на бизнес-пользователей, сочетая, например, общедоступные описания АП в виде традиционных документов и формализованные модели на стандартизированных языках моделирования;
  • управлять неразрывной связью между формализованными моделями и находящимися в эксплуатации реальными системами предприятия (то, о чем писал Захман в 1992 году и что нередко проходит под названием «динамичная архитектура» или рассматривается как часть процесса Enterprise Architecture Management);
  • управлять переходными процессами преобразования АП из текущего состояния в промежуточные и целевые с поддержанием всех необходимых сведений о связях этих состояний, определяемых в смысле схемы «3D-предприятие»; здесь до сих пор превалирует «ручной» режим.
Тем не менее уже есть инструменты, сделавшие реальным то, о чем писал Захман: «Инструменты никогда не заменят интеллектуальную работу с АП, но они помогают делать архитектурный процесс более продуктивным».

Направления эволюции АП

Джон Захман уже в 1999 году был уверен, что не существует теоретических или технических препятствий для формирования АП на предприятиях: «Нам осталось сделать всего одну вещь — реальную работу по формированию АП». Это совсем не значит, что у АП как практической дисциплины не осталось проблем. Их достаточно, и часть из них была названа в отчете IBM Research 2006 года:
  • явный разрыв между методиками и способностью специалистов индустрии воспринимать их, между «методистами» и менеджерами функционирующих предприятий;
  • слабое осознание разрыва между нарастанием темпа изменений и возможностями людей на предприятиях к синхронной адаптации (переобучению);
  • отсутствие упрощенного языка, обоюдно понятного жаргона, пользуясь которым представители бизнеса, методисты АП и ИТ-специалисты могли бы легко работать вместе.
Здесь ещё многое можно добавить о проблемах отечественной практики, однако пусть это будет темой отдельного разговора.
Кроме того, продолжается дальнейшее усложнение предприятий, вызванное изменениями среды. Вкратце, в «телеграфном стиле» перечислим некоторые из них:
  • обострение конкуренции, перегрев финансовых рынков и глобальный дефицит ряда стратегических продуктов, обостряющаяся неравномерность развития стран, рынков, предприятий;
  • рост вынужденных слияний и изменений деловых альянсов, требований к изменчивости в кооперации, изменения парадигмы ERP в рамках расширенного предприятия, повышение требований к интероперабельности бизнес-систем;
  • усложнение архитектуры изделий при постоянном сокращении их жизненного цикла;
  • повышение информационной перегрузки руководителей и сотрудников других категорий, необходимость принятия решений в условиях растущей неопределенности;
  • приход нового поколения, живущего в Web 2.0, расширение концепции «Предприятие 2.0», конвергенция кооперативной работы и общения, расширение техник прямого веб-маркетинга и управления связями с клиентами;
  • резкое возрастание уровня угроз для информационной безопасности.
В результате этих изменений в чем-то уже делаются, а в чем-то ожидаются следующие шаги развития АП как дисциплины.
1. Дальнейшее встраивание моделей стратегии в АП, а АП — в процесс и документы стратегического управления. Более глубокое и наглядное моделирование бизнес-стратегий. Включение в АП ситуационно изменяемых маркетинговых стратегий и планов. И в стратегии, и в АП включаются модели эффективности, но потребуется значительно большее развитие их метамоделей, чем у сегодняшних BSC, в том числе в области эффективности ИТ.
2. Архитектурная под­держка принятия решений в условиях неполно­ты информации (возможно, пу­тём использова­ния особенностей «Пред­­прия­тия 2.0»). Аналогичная поддержка при решении задач отображения одного архитектурного представления на другие.
3. Моделирование АП с переменными и неопределенными границами. Развитие функций постоянной оптимизации предприятия и связанных с этим требований к синхронному динамическому изменению АП и действующих систем предприятия. Учет ограничений на масштаб таких изменений из-за противоречий между необходимостью проводить их через единую систему моделей и свободой принятия решений «на местах». Отсюда — дальнейшее усиление роли сегментного подхода и федерализма в АП.
4. Гармонизация и интеграция международных стандартов для согласования архитектурных работ в сфере АП, с одной стороны, и в системной и программной инженерии — с другой. Большее проникновение сервисной ориентации в стандарты АП (возможно, в стиле стандартов системной инженерии).
5. Поддержка в АП общих «горизонтальных» сегментов с некоторым усилением ориентации на данные (возможно, в стиле [6]). Усиление роли референсных моделей и стандартов прикладной информации в АП. Рост практического значения глоссариев, тезаурусов и онтологий.
6. Возрастание роли и сложности архитектурных репозиториев и одновременно развитие облегченных подходов и инструментов для работы с АП, доступных более широкому кругу пользователей. Развитие общего и углубленного образования в сфере АП, обновление сводов знаний в этой области.
7. Возрастание важности архитектуры комплексной безопасности начиная с соответствующих аспектов бизнес-архитектуры АП.
Итак, архитектура предприятия — это дисциплина, которая продолжает бурно развиваться. Бессмысленно ждать, когда она сформируется окончательно: еще долго АП будет накапливать новые средства, откликаясь на происходящие изменения. Важнее, что сегодня АП достаточно созрела для разворачивания в пределах конкретной организации, причём необходимые действия могут быть подготовлены и выполнены в течение нескольких месяцев.
Есть оценки экономии, которые дает использование архитектуры предприятия, но для ИТ-руководителей и специалистов не менее важна и другая возможность: работая с комплексной АП на равных войти в процесс развития своего предприятия.

Литература

1. Зиндер Е. З. Архитектура предприятия в контексте бизнес-реинжиниринга. Часть 1 // Intelligent Enterprise, № 4/2008, с. 46.
2. ISO 15704:2000. Industrial automation systems — Requirements for enterprise-reference architectures and methodologies.
3. Зиндер Е. З. Архитектура предприятия на пространстве от политики и стратегии до тактики // Управленческий консультант. Киев: изд-во БУК, 2005. С. 44—71. (www.fostas.ru/events/showdesc.php?id=79)
4. FEA Consolidated Reference Model Document. Version 2.3. October 2007.
5. TOGAF — The Open Group Architecture Framework, Version 8.1.1 Enterprise Edition.
(www.opengroup.org/bookstore/catalog/i061.htm)
6. ISO 15926. Integration of life-cycle data for process plants including oil and gas production facilities.