Архитектура предприятия в контексте бизнес-реинжиниринга

Сегодня все больше руководителей и аналитиков начинают испытывать потребность в комплексном описании и планировании развития своей организации. Это им нужно как минимум для того, чтобы знать, что’ их организация представляет собой в реальности, поддерживать рациональный порядок ее устройства, а затем — приступить к ее планомерному развитию или трансформации с учетом всех важных обстоятельств. Таким целям служит «Архитектура предприятия» (АП, Enterprise Architecture) — важнейшая комплексная дисциплина нового времени. В мире наблюдается настоящий бум работ в этой области, в штатных расписаниях позиция «Enterprise Architect» заняла устойчивое положение, ведущие университеты разработали углубленные курсы и выпускают квалифицированных специалистов данного профиля.

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

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

Часть 1. Развитие АП от основ до рубежа XXI века

Истоки

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

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

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

Три актуальных определения

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

1. Предприятие. Международные стандарты определяют предприятие как некое образование, состоящее из одной или нескольких организаций либо их частей, разделяющих общую миссию и цели по предоставлению некоторого выхода, например услуги или продукта. (Дано на основе стандартов ISO 15704:2000, ISO/IEC 15288:2002, PMBOK Guide и ряда других.) Заметим, что специальных требований к миссии, целям и формам деятельности предприятия не предъявляется. Из этого вытекают важные вещи (и стандарты их подчеркивают):

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

2. Система. Даже прямо говоря именно об архитектуре предприятия, стандарты рассматривают предприятие как систему и определяют АП как архитектуру системы. Основой является закрепленное в современных стандартах и по системной инженерии, и по АП широкое понимание системы, создаваемой человеком. Так, в ISO/IEC 15288:2002 система — это «совокупность взаимодействующих элементов, упорядоченная для достижения одной или нескольких поставленных целей». Определение распространяется на самые разные по характеру и масштабу системы — от локального устройства (например, мобильного телефона) до целой отрасли (включая ее работников). Другие стандарты дополнительно указывают, что в составе систем рассматриваются машины, люди, программное обеспечение. Для наших целей важно, что понятие «система» охватывает и предприятия.

3. Архитектура. Определение АП как архитектуры системы возьмем из глоссария ФОСТАС (версия 2-08). Оно составлено путём рационального объединения формулировок из наиболее актуальных стандартов в области архитектуры предприятий, системной и программной инженерии. В зависимости от контекста архитектура системы — это:

1) многоаспектное описание или план задуманной или развиваемой системы на уровне ее компонентов, детализированное в достаточной мере для руководства ее воплощением, а также принципы и руководящие материалы, определяющие руководство конструированием и развитием системы во времени;

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

Стимулы оформления АП

Причины введения в оборот современных толкований предприятия и его архитектуры лежат в тех изменениях в жизни предприятий, которые начали происходить ещё в 70-х и 80-х годах. Среди главных изменений — начало перехода от рынка продавца к рынку потребителя, TQM (Total Quality Management) и конкуренция японских компаний как в мире, так и на внутреннем рынке США. Это побудило Эдвардса Деминга преобразовать методы повышения качества в подход CPI (Continuous Process Improvement), который проник в практику предприятий США. В единый комплекс были сведены цели и задачи бизнеса в конкурентной среде, особая ценность и роль людей, свойства используемых машин и технологий, аналитический подход к поиску причин имеющих место потерь и способов повышения конкурентоспособности, к опоре на измеримые показатели деятельности. Такое целостное представление было зафиксировано в четырнадцати принципах Деминга, которые в явном виде задавали как философию управления и культуру работников предприятия, так и постоянные изменения его процессов, в первую очередь за счет совершенствования базовых технологий и процессов.

В остро конкурентной среде организация бизнес-деятельности оформилась в виде комплексной дисциплины маркетингового управления предприятием (в первую очередь marketing management Ф. Котлера и М. Портера). Учитывалась необходимость преобразования всех компонентов предприятия (оргструктур, ценностных установок отдельных работников, базовых технологий и т. д.), учета всех различий территорий (рынков), на которых оно планирует работать, — от ценовых до культурных. Параллельно с этим процессный подход к совершенствованию предприятия стал выделяться в более явной форме и в конце 80-х годов вместе с идеями CPI проник в стандарты CMM (Capability Maturity Model).

Заметим, что в 80-х годах много говорилось о явно недостаточной отдаче, получаемой бизнесом от ИТ. Поэтому возросла значимость методов согласования ИТ-систем с реальными потребностями бизнеса — то, что и сегодня часто выделяется в отдельное направление «business & IT alignment». Так, в IBM длительное время развивалась методика BSP (Business Systems Planning), направленная на то, чтобы архитектура ИС выводилась из потребностей бизнеса и их приоритетов. Существовали и другие работы в этой области, но именно ведущие специалисты IBM по планированию архитектуры ИС дали определяющий толчок развитию АП как дисциплины.

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

Первый виток АП

В этой ситуации в 1987 году появились первая, а в 1992‑м — вторая (в соавторстве с Дж. Сова) [1] статья Джона Захмана, в которой был предложен вариант обобщенной схемы или структуры (framework, или «фреймвок») для описания и анализа архитектуры: формально (по названию) еще архитектуры ИС, но по содержанию — уже предприятия. Схема Захмана давно стала стандартом де-факто и приобрела у нас популярность, однако разработанные для нее правила менее известны. Для сохранения логики изложения нужно напомнить ее основные свойства. Схема получила форму матрицы 6×6, в которой каждая ячейка задает свой тип описания (модели) свойств предприятия. Вся совокупность ячеек разделена на шесть столбцов матрицы — шесть аспектов деятельности предприятия:

• «ЧТО делается», или объекты/данные;
• «КАК делается», или функции/процессы;
• «ГДЕ делается», — размещение или инфраструктура;
• «КТО делает» — люди, оргединицы;
• «КОГДА делается» — графики событий и работ;
• «ЗАЧЕМ делается» — стимулы, мотивы и стратегии деятельности.

Эти аспекты предлагается описывать в шести разных, но связанных представлениях, сгруппированных в строки матрицы. Для строк-представлений Захман применил аналогии с классическим архитектурным делом и строительством. Верхняя строка матрицы фиксировала представление «планировщика застройки», который рассматривает не одно здание, а все его окружение и то, как в это окружение вписывается здание. Вторая строчка фиксировала представление «владельца дома», третья — представление дизайнера, четвертая — того, кто будет руководить собственно строительными работами, пятая — взгляд тех, кто будет выполнять отдельные работы, а шестая относилась к эксплуатации дома. Посредством этой аналогии для АП задавались представления предприятия с позиций бизнеса, аналитиков-проектировщиков ИС, а также их разработчиков. (Более подробные и полные описания см. на www.zifa.com.)

Изначально матрица Захмана и описание ее применения были предназначены для совершенствования методики IBM BSP, однако вскоре стало ясно, что ее предназначение гораздо шире. В 1992 году Захман писал о своём удивлении по поводу того, как быстро его подход стал стандартом де-факто. Сегодня можно уверенно сказать, что это объясняется потребностями в комплексном рассмотрении предприятия и его ИТ, о которых говорилось выше, а также простотой представления матрицы (особенно в варианте 1987 года). По-настоящему удачной оказалась форма этой обобщенной схемы, воспринимаемая как своего рода таблица Менделеева для АП. Весьма ценной на мой взгляд явилась и аналогия с классическим архитектурным и строительным делом. Наконец, матрица Захмана много давала не только для соотнесения бизнеса и ИТ, но и для согласования работ в команде проектировщиков ИС. Надо сказать, что в работе 1992 года были заявлены и другие редко упоминаемые, но концептуально важные идеи, в частности:

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

Однако эти концептуально мощные идеи в статье 1992 года были изложены лаконично и не составили методологию работы с АП.

Ещё одним явлением, определившим судьбу АП, стала книга Стивена Спивака из IBM [2], в которой было предложено детальное описание процесса «Планирование архитектуры предприятия» или EAP (Enterprise Architecture Planning), методика его практического исполнения, а также осуществлён переход от названия «архитектура ИС» к понятию АП (после чего и Захман стал применять именно это название).

Спивак в явной форме основывался на упрощенной матрице Захмана 1987 года (в ней было всего три первых столбца) и писал, что суть процесса EAP состоит в определении верхних строк этой матрицы (однако включал в них концепцию технических средств). Главное, что он соединил совокупность частичных описаний-архитектур, задаваемых ячейками и столбцами матрицы Захмана, с методикой планирования и выполнения процесса их формирования (см. рис. 1). Таким образом, дисциплина АП кроме структурно-описательной части приобрела свою вторую половину — методологию анализа и формирования комплексной структуры предприятия. Произошло окончательное закрепление названия АРХИТЕКТУРА ПРЕДПРИЯТИЯ, были сформулированы главные цели и принципы устройства архитектуры, заложены основы для применения архитектурного подхода к разным объектам, а не только к планированию ИС.

Однако и framework Захмана, и EAP Спивака обладали заметными недостатками. Например, в одной вертикальной оси матрицы Захмана оказались слиты по сути разные измерения, в которых формируются архитектуры и архитектурные продукты. С одной стороны, разные строки отражают разные представления предприятия, объективно сосуществующие в один и тот же момент времени. С другой стороны, порядок расположения строк-представлений (сверху вниз) оказался связанным с порядком выполнения работ в жизненном цикле (ЖЦ) проектирования ИС или предприятия, то есть с осью и ходом проектного времени. Это и сейчас нередко приводит к путанице в проектах, опирающихся на матрицу Захмана. Надо отметить, что в [1] указано на работу с матрицами «как есть» и «как должно быть», но описанного выше недоразумения это не снимает.

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

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

Привязка EAP к стабильности бизнес-модели, а также к подходу, «управляемому данными» (что было характерно для IBM), во многом, хотя и не всегда, ограничивает применение EAP в сегодняшних условиях. Все же работы Захмана и Спивака стали применяться на практике и реализовали первый виток развития АП.

Подход Захмана вполне помогает решать сформулированные им задачи, в частности:

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

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

Изменения бизнес-среды и возможностей ИТ

В 80-х и начале 90-х годов среда и способы существования предприятий продолжали меняться. Изменения часто ассоциируются с реинжинирингом бизнес-процессов (BPR), описанным М. Хаммером и Дж. Чампи в 1993 году [3]. Главные стимулы — глобализация, рост ценовой конкуренции, сокращение длительности ЖЦ товаров. Стало общепризнанным, что стабильная бизнес-среда перестала существовать.

Вместе с тем ситуация в целом в огромной степени «разогревалась» Интернетом и другими ИТ-инновациями — от мобильных компьютеров до RFID. Творческое (по Хаммеру) применение ИТ привело к тому, что они стали играть роль своего рода волшебника, который давал возможность резко упрощать процессы и процедуры, сокращать время рассмотрения документов и обращений, дистанционно принимать и реализовывать решения, повышать интеллектуальную во­оруженность работников всех уровней.

Перед нами не стоит задача описывать BPR — напомним лишь, что выведенный на первый план процессный подход использовался не только для ломки административных барьеров, но и для соединения подразделений нескольких предприятий-партнеров по сути в одно синхронно работающее предприятие, а также для формирования виртуальных предприятий и групп, активизации аутсорсинга. Радикальность проводимых под маркой BPR преобразований часто сводилась не столько к упрощению бизнес-процессов, сколько к увеличению нагрузки на сотрудников, к массовым сокращениям персонала, что подвергалось серьезной критике. В результате появились более мягкие и гибкие подходы: BPI, BPT и т. п., например как сочетание BPR с идеями CPI. Для них характерна более плавная скорость изменений предприятия и менее грубое давление на людей. Но во всех вариантах оставалось неизменным одно: комплексный подход к предприятию для трансформации всех его компонентов в новое состояние.

Требования трансформации стали задавать постоянный процесс изменения предприятия, который воплощался не только процедурами BPR / BPT, но и несколькими другими методами, получившими одно и то же название — «управление изменениями» (Change management). Позднее в стандарте ISO 14258:1998 «Concepts and rules for enterprise models» было закреплено: «Предприятие динамично и подвержено постоянным изменениям из-за таких факторов, как изменение рыночных условий, технологий и знаний».

Планирование архитектур трансформирующихся предприятий

Все это привело к созданию «фреймвоков» АП, позволявших в более определенном виде отражать изменение архитектуры во времени. С 1994 года ассоциация CIMOSA активно работала над открытой архитектурой систем для автоматизированного управления производством. Разработанная обобщенная схема «Open System Architecture for CIM» получила такое же название — CIMOSA. Эта схема и совокупность связанных с ней концепций в 1997 — 1999 годах были использованы рабочей группой IFIP-IFAC и с учетом вклада еще нескольких коллективов и авторов легли в основу «Обобщенной референсной архитектуры и методологии предприятия» GERAM (Generalised Enterprise Reference Architecture and Methodology) [4]. Этап закончился включением GERAM (рис. 3) в качестве приложения в действующий базовый стандарт по дисциплине АП — ISO 15704:2000 «Requirements for enterprise-reference architectures and methodologies».

В CIMOSA-GERAM появилась специальная ось для фаз формирования и реализации АП. CIMOSA концентрировалась на трех фазах последовательного выведения моделей друг из друга, GERAM — на фазах, имеющих традиционное представление в стандартах проектирования «обычных» локальных систем — от «идентификации» (замысла) до «эксплуатации» и «удаления». Схема GERAM предусматривала:

• четыре группы аспектов архитектуры предприятия, названных представлениями (Views) — типы моделей («функ­ции», «данные», «ресурсы», «организация», что у’же, чем шесть аспектов Захмана), назначения (может быть ассоциировано со столбцом «ЗАЧЕМ» Захмана), реализации и «физические представления» (аппаратура, ПО) и возможность определять дополнительные аспекты;
• описание всех аспектов или какой-то их части на каждой из семи или восьми фаз формирования архитектуры и функ­ционирования предприятия;
• конкретизацию модели архитектуры на трех уровнях — обобщенном, уровне частичных моделей (они же повторно используемые референсные, reference) и конкретных моделей (у Захмана непосредственно в матрице таких уровней нет, но, с учетом использованиия «рекурсивной логики», число таких уровней у него не ограничивалось).

Особенность GERAM состоит в том, что ось фаз развития архитектуры в принципе может отражать ход времени и не связана жестко с представлениями разных участников процесса, а также в том, что в явной форме введено понятие референсной архитектуры и модели. (Заметим, что принятый в последнее время перевод reference model как «эталонная модель» придает этому понятию на русском языке избыточную обязательность, которая не подразумевалась ни в GERAM, ни в соответствующих стандартах.) Для представления развивающейся АП минусы этой схемы таковы:

• ось фаз формирования архитектуры традиционна для проектного цикла локальных систем, но, потенциально допуская итерации реинжиниринга предприятия, она недостаточно явно соответствует спиральной форме истории жизни предприятия в реальном времени его развития;
• структура схемы и ее описание, похоже, оказались слишком сложными, формальными и жесткими для восприятия практиками, в результате чего GERAM, оставаясь частью стандарта ISO 15704:2000, в широкой практике не получила заметного распространения.

Тем не менее GERAM содержит множество полезных методических элементов и до сих пор учитывается в новых стандартах (например, ISO 19439:2006 «Enterprise integration — Framework for enterprise modelling»).

3D-предприятие

Необходимость развития плоской схемы Захмана чувствовалась не только идейно, но и на практике. Дело в том, что для предприятий характерен не конечный ЖЦ локальных систем, а так называемая «история жизни», для представления которой лучше подходит форма спирали. Каждый виток спирали — законченная трансформация, которая может по-разному разделяться на фазы (например, на четыре фазы цикла Шьюарта — Деминга, на три фазы CIMOSA или семь фаз GERAM), но тут же перетекает в следующий виток. Причем для трансформации АП на текущем витке важны представления о вероятном ходе развития предприятия и его систем на следующем витке, а также прогноз дальнейших изменений. Кроме того, спираль эта не единственная, параллельно может выполняться несколько разных трансформаций, относительно самостоятельных по датам старта и завершения. Наконец, на практике проекты, предусмотренные стратегическим планом развития, и тактические действия, вызванные необходимостью срочных изменений, то есть трансформации разного масштаба, идут непрерывно и параллельно.

Было понятно, что целесообразно ввести полнокровную ось времени непрерывного развития архитектуры предприятия, которую можно градуировать для отметок самых разных по принадлежности и длительности отрезков времени. Вместе с тем в качестве других базовых осей было желательно оставить простую для восприятия и уже получившую широкое распространение матрицу Захмана. Это привело к тому, что в 1996 — 1997 годах автором данной статьи были предложены основные идеи, а в 2000-м опубликована в более полном изложении известная в русскоязычном Интернете обобщенная схема «3D-предприятие» (рис. 4) [5].

Главная идея состояла в том, что надо учитывать несколько будущих состояний предприятия и непрерывность временно’й оси, на которой располагаются и отдельные проекты, и целые программы развития. За счет этого схема 3D-предприятия лучше соответствует реальным «историям жизни» предприятий, имеющим спиральную или «мультиспиральную» форму. Были также предложены рекомендации по использованию двух верхних ячеек столбца «ЗАЧЕМ» матрицы Захмана для определения стимулов и целей трансформации, а также облегченные начальные шаги организации архитектурного процесса на предприятиях.

Тогда же было указано, что схема АП может иметь больше трёх измерений, и был приведен пример конкретного предприятия, для которого 3D-модель была расширена дополнительными измерениями. Тем самым были продемонстрированы возможность и вариант перехода от 3D-схемы к «nD-схеме», которая может понадобиться архитектору, планирующему сложную архитектуру.

О содержательных методиках трансформации архитектуры

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

Часто приходится говорить, что в деле формирования архитектуры таких однозначных методик быть не может, что архитектору надо самому формировать проектные решения, действуя на основе обобщенных и частичных (референсных) моделей. Это и так, и не так. Конечно, архитектору не стоит рассчитывать на то, что он целиком «срисует» у кого-то готовую архитектуру. Но все же типовые элементы и удачные примеры иметь полезно. К тому же известны методики с очень большой детальностью проработки референсных моделей и инструкций по проектированию АП, например TAFIM и DoDAF от Минобороны США. Мы не описываем эти и подобные методики ввиду ограниченности или непригодности их непосредственного применения в наших условиях, но стоит отметить, что и их рекомендации не решают всё за архитектора.

Таким образом, важны и степень проработанности, и число альтернативных вариантов, предусмотренных референсными моделями и типовыми заготовками, и методики, учитывающие конкретные цели и условия применения. Но еще важнее способность архитектора не только использовать методики, но и учитывать особенности предприятия и его ситуации и формировать на этой основе нужную АП. При этом для каждого представления АП положение с методиками своё. Так, в области бизнес-моделей методики BPR и BPT вполне могут применяться в качестве ядра методологии трансформации АП: само существо преобразования бизнес-процессов при любом из таких подходов требует учитывать все части и элементы предприятия, затрагиваемые преобразованиями, по сути — всю его архитектуру. Поэтому BPR, BPT и их варианты (как и упоминавшаяся методика CPI), осмысленные по правилам АП и дополненные методиками трансформации других компонентов, которые затрагиваются трансформацией процессов, становятся содержательными методиками трансформации АП. На этом пути появляются новые стили, например формирование сервисно-ориентированного предприятия.

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

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

Управление изменениями применяется также в ITSM (IT Service Management) и в управлении проектами. И то и другое в соответствии с масштабом применения может служить частью целостной содержательной методики трансформации предприятия и его архитектуры. Сюда стоит добавить также методики управления инвестициями — для выбора одного варианта развития конкретной архитектуры из нескольких — и методики управления программами и проектами, хотя бы для планирования структуры и последовательности работ по переводу архитектуры из текущего состояния в следующее (так называемые переходные планы АП). Таким образом, обобщенные схемы и методологии АП в сочетании со всем богатством известных под другими названиями методик тех или иных преобразований становятся полнокровными содержательными методиками трансформации предприятия и его архитектуры. Здесь важно сделать одно замечание. Ситуация с множеством методик реинжиниринга или трансформации бизнес-процессов показывает: единственной методики трансформации архитектуры быть не может. Их как минимум столько, сколько типов ситуаций, с которыми сталкиваются предприятия, и типов выхода из этих ситуаций. А выбирать нужную должен архитектор предприятия вместе с директором по развитию, а то и с генеральным директором. Более того, не может быть и единственной обобщенной схемы АП. Известно, что во всех крупных программах формирования АП каждое предприятие строило схему формирования своей архитектуры по-своему — конечно, адаптируя известный framework (чаще всего матрицу Захмана) к своим особенностям.

Промежуточный итог развития АП

К концу прошлого века дисциплина АП достигла известной зрелости. Возникли развитые, иногда даже чрезмерно формализованные и строгие обобщенные схемы. Накопилась практика реальных трансформаций — пусть под названием проектов реинжиниринга бизнес-процессов. Вместе с тем архитектурный подход в его целостном профессиональном виде и к концу 90-х еще не получил широкого развития, причем даже в США, где создавались и обкатывались основные методологии в этой области. Многие причины такого положения отмечаются в России в данное время, поэтому важно учитывать, как в 1999 году оценивал эти причины Дж. Захман и какими он видел перспективы. В статье «Enterprise Architecture: Looking Back and Looking Ahead» он так объяснял, почему АП еще не стала жизненно важной для предприятий.

1. Следование дисциплине АП противоречит культуре, в первую очередь культуре программирования и запуска ИС как таковой, которая гласит: «Главное — написать код и запустить программы». Несмотря на множество слов о «согласовании с бизнесом», стандартизации, управлении изменениями, ресурсах и инвестировании, практически ничего такого не делается. Он отмечал также, что рынок к «приобретению» архитектуры пока не готов: «Мы еще не знаем, как это измерить, поэтому людям непонятно, почему за это надо платить» (от себя добавлю, что платить надо регулярно, так как архитектура меняется).

2. Предприятия еще не ассоциируют АП с жизненно важными для себя вещами, особенно в связи с привычкой делать деньги так, «как это было естественным в индустриальном, а не в информационном веке». Конечно, ситуация изменилась, продукты и услуги унифицируются, глобализация требует других правил игры. Более того, «системы» уже не просто поддерживают предприятия, они работают как их части, и само предприятие является соединением систем, однако многие еще не поняли, что проектирование систем — это и есть проектирование предприятия.

3. Еще одна причина состоит в том, что мы не знаем, как делать АП. За границами данных и процессов (столбец «ЧТО» и ячейки второй, третьей и четвёртой строк столб­ца «КАК») мы мало что знаем. Например, мы мало знаем про то, как описывать и проектировать столбец «ГДЕ». Еще меньше мы знаем, как проектировать бо’льшую часть ячеек для остальных столбцов матрицы, и, что еще хуже, не имеем в этих областях существенной практики. И наша ментальность все еще толкает нас (что связано с культурными факторами) к такому образу действий: «Ты начинай писать программный код, а я пойду выяснять, что обо всем этом думает пользователь на самом деле!.. А про АП забудь!!»

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

Вот как писал об этом Захман. Не правда ли, то же самое мы наблюдаем и в нашей нынешней практике?!

Однако после таких оценок Захман тут же дал оптимистичный прогноз развития и практического распространения дисциплины АП. Основанием для такого прогноза было предвидение того, как каждая из названных им четырех причин поменяет направление своего вектора на противоположное. И этот прогноз самым замечательным образом оправдался уже в 2003—2005 годах — сначала в США, а затем и во многих других странах.

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

Литература

1. Sowa J. F., Zachman J. A. Extending and Formalizing the Framework for Information System Architecture // IBM Systems Journal. 1992. V. 31. № 3.
2. Spewak S. H., Steven C. Hill. Enterprise Architecture Planning: Developing a Blueprint for Data, Application and Technology. NY: John Wiley & Sons Inc, 1992.
3. Hammer M., Champy J. Reengineering the Corporation: A Manifesto for Business Revolution. Harper-Collins Publishers, Inc., 1993.
4. GERAM: Generalised Enterprise Reference Architecture and Methodology: Version 1.6.3 (March 1999). — www.cit.gu.edu.au/~bernus/taskforce/geram/versions/geram1-6-3.
5. Зиндер Е. З. «3D-предприятие» — модель трансформирующейся системы // Директор ИС. 2000. № 4 (более полное изложение статьи см. на www.sept2000.ru и www.citforum.ru/seminars/cbd2000/cbd_day2_01.shtml).