Евгений Зиндер
Опубликовано в журнале "Директор ИС" №04 за 2000

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

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

Изменения и архитектура ИС

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

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

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

О "плоских" схемах архитектуры

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

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

Здесь надо вспомнить Джона Захмана (John A. Zachman), одного из лидеров интеграции бизнес- и ИТ-подходов. В 1987 году появилась его статья [1], название которой можно перевести так: "Общая схема архитектуры информационных систем". В ней была предложена простая, но концептуально мощная схема, показывающая различные уровни представления архитектуры ИС, различные виды ее "обеспечения", а также их основные взаимосвязи.

На рис. 1 показана таблица, аналогичная схеме Захмана 1987 года. Три ее развернутых столбца отражают три раздела обеспечения системы: информационное, функциональное и коммуникационное. Или: данные, функции и сеть.

Рис. 1. Архитектура ИУС, информационно-управляющей системы предприятия: фрагмент, аналогичный модели Дж. Захмана 1987 года

Шесть строк таблицы отражают шесть уровней представления системы:

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

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

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

Рис. 2. Архитектура ИУС: фрагмент, аналогичный расширению модели Дж. Захмана 1992-1994 года

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

От плоских схем к "3D-предприятию"

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

Рис. 3. "3D-предприятие": предприятие, его ИУС и его информационная система во времени развития и трансформации

В цикле статей [3] автор писал об изменениях в принципах и приемах представления моделей предприятия. Введенные тогда трехслойная модель предприятия, принцип динамической адаптации жизненного цикла системы, другие принципы и приемы Н.С.П. (подхода "Новое Системное Проектирование") служили для учета высокой скорости изменений предприятия и ИС. Но требовались и более явные средства работы с меняющимися объектами. Эта необходимость побудила автора ввести трехмерную схему (см. рис. 3), образовав ее добавлением к плоским схемам оси стратегического времени. На этой оси располагаются интервалы осуществления различных проектов и стадий развития ИС и всего предприятия. Как элементы базовой классификации сущностей на этой оси рассматриваются:

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

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

Так появилась "объемная" схема архитектуры предприятия, его ИУС и ИС, или - схема "3D-предприятие". Сначала схема использовалась как рабочее средство для обдумывания, обсуждения и планирования ИС в развитии. Затем применение "3D-схемы" оказалось полезным расширить на разработку целевых проектных программ разных видов.

Модель "3D-предприятие" на основе соответствующей схемы

Если схема является общей структурой для разных предприятий, то описание архитектуры конкретного предприятия, которое строится по общей 3D-схеме, является уже моделью3D-предприятия. Она строится для отражения взаимосвязей ключевых компонентов ИУС предприятия на выбранном историческом участке времени его развития в трех измерениях, предусмотренных 3D-схемой (см. рис. 3):

1. ось уровня проектирования и использования ИУС;
2. ось раздела обеспечения и аспекта работы ИУС;
3. ось времени, в котором развивается предприятие и его ИУС.

Первые две оси совпадают с теми, что использованы на рис. 1 и 2 в моделях, аналогичных таблицам Захмана. Третья ось позволяет явно определять изменения, которые происходили и будут происходить с предприятием и проектами создания ИС в процессах их развития и трансформации.

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

При построении 3D-модели не должны использоваться никакие формализованные нотации и узкопрофессиональные жаргоны. Модель 3D-предприятия (в развитие положений Захмана) должна быть:

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

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

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

Правилом описания взаимосвязей частных моделей является явное выделение и описание:

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

Описания взаимосвязей должны содержать:

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

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

Организация применения схемы "3D-предприятие"

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

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

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

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

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

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

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

Затем или параллельно с этим выполняются работы по общему описанию так называемых бизнес-моделей или концептуальных моделей ИСУ и предприятия. Работы по описанию моделей логического и технического уровней выполняются при наличии компьютерной информационной системы или идущего проекта ее создания. Но при построении модели "как есть" на уровне 3D-модели это описание носит характер самой общей инвентаризации.

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

Построенная таким образом модель используется далее и как основа для диагностического анализа, и как средство для дальнейшего планирования проектов.

Дальнейшее использование модели "3D-предприятие"

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

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

В конкретных ИС часто полезно рассматривать три очереди развития ИС:

• "для сегодня" (идущие проекты; проекты, планируемые к запуску в ближайшие дни или недели; и проекты, завершение которых планируется на ближайшие недели и месяцы);
• "для завтра"(проекты, которые должны поддержать основные стратегические задачи и будут завершены примерно через год, редко - полтора);
• "для послезавтра" (проекты, которые должны опираться на сегодняшние и завтрашние, которые уже сегодня должны определять требования к совместимости старых и новых подсистем и единиц ИУС и должны завершиться через полтора-два года, поддерживая перспективные стратегии развития предприятия).

Каждой очереди соответствует группа взаимосвязанных проектов, а каждому проекту соответствует своя группа работ, захватывающая свою область смежных во времени ячеек 3D-модели. Именно при создании модели проектной программы, развивающейся во времени, становится наиболее ясной польза построения и применения общей понятийной модели предприятия, которая может играть роль минимального средства интеграции систем (см. [4]) уже начиная с составления 3D-модели. Кроме того, именно при построении такой модели становится наиболее наглядной картина согласованности различных инвестиционных акций предприятия.

Схема "мультикуб" и ее применение

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

• применяемые методы/инструменты разработки ИС или управления;
• специализации конкретных разработчиков ИС или управленцев;
• уровень абстракции модельных компонентов и др.

На рис. 4 показан процесс соединения выделенной в архитектуре 3D-предприятия проектной программы с параметрами организации проектов из этой программы. Добавляемые параметры (участники проекта и инструменты проектирования) связываются с 3D-предприятием по такой характеристике, как уровень проектной задачи.

Рис. 4. Модель-мультикуб для понимания и управления стратегиями развития ИУС на уровне проектной программы (аналогично для группы подпроектов)

"3D-предприятие" и другие схемы, модели и задачи

В 3D-предприятии использован аналог схемы Захмана, а не ее копия, причем отличия были введены специально. Так, Захман связал с уровнями представления системы роли тех, кто "заказывает", проектирует и реализует систему, а из описываемого здесь развития схемы архитектуры эти роли исключены. Представляется, что гораздо продуктивнее "добавлять" их отдельно, на этапе перехода к модели-мультикубу для более конкретного планирования проектной программы. Есть и другие отличия.

3D-предприятие естественно стыкуется с другими видами схем стратегического и архитектурного уровней. К таким схемам относятся, например, схемы циклов маркетингового стратегического управления, или такие схемы создания ИС и ИУС, как трехмерная архитектура CIMOSA, схемы бизнес- и информационной платформ и архитектур Дж. Хендерсона, схемы "здания ARIS" А. Шеера.

3D-предприятие работает в проектах самых разных видов, и практика показала целесообразность применения этого подхода еще до первых шагов планирования проектов. А благодаря концептуальной совместимости с другими схемами после описания целостной и динамичной 3D-архитектуры можно легко включать в работу более специфические или более технические инструменты и модели, например, Turbo-BPR, Process Charter, ARIS ToolSet, UML RRose или Oracle Designer.

Литература

1. Zachman J. A. A Framework for Information System Architecture. IBM System Journal, vol. 26, No. 3, 1987.
2. Sowa J. F., Zachman J. A. Extending and Formalizing the Framework for Information System Architecture. IBM System Journal, vol. 31, No. 3, 1992.
3. Зиндер Е. З. Новое системное проектирование: информационные технологии и системное проектирование // СУБД - 4, 1995; - 1, 2, 1996.
4. Зиндер Е. З. Проектирование баз данных: новые требования, новые подходы // СУБД - 3, 1996.