Е. З. Зиндер, директор фирмы «Группа 24» gr24@sept.ru или ezinder@osp.ru
(Данный материал является более полным вариантом статьи автора в журнале-приложения к еженедельнику Computerworld Россия, № 4 за 2000 год.)
Все знают, что мир меняется быстрее, чем раньше, и что информационные системы должны успевать за этими изменениями. Но известно и другое. Внедренную и реально используемую систему трудно (долго, дорого, часто даже невозможно) изменять. В результате ИС может стать или становится тормозом развития предприятия. Причины могут быть разные, но истоки проблем — всегда в трансформации предприятия .
Ниже рассматривается схема и общие правила построения «3D-предприятия» — стратегической модели информационно-управляющей системы (ИУС), трансформирующейся «рука об руку» с предприятием, целям которого она служит. Формулируются требования к качеству составления такой модели, предлагаются возможная организация первых шагов по ее построению. Кроме того, показывается способ перехода к дальнейшему использованию модели в проектной практике предприятия, характеризуется совместимость модели с другими, более формальными или специфичными моделями.
Изменения и архитектура ИС
Есть несколько известных глобальных подходов, содержащих часть ответов на вопрос «Как быть?» в условиях трансформации.
Ответ распространенный и правильный одновременно: реализуйте компонентный подход. Принципы определения и реализации компонентов могут быть разными. Это могут быть библиотеки программных процедур и модулей с открытым описанием их интерфейсов и общей базы данных. Это могут быть отлаженные библиотеки бизнес-классов плюс стандартизация обменов между объектами. Такие решения дают возможность гораздо более гибкой переналадки и развития (расширения, изменения комплектации) систем.
Есть и известные ограничения. Например, нет действительно «стандартных» классов. Но не это самое неприятное. Когда такие классы появятся, их использование в задачах вашего предприятия неизбежно приведет к появлению нестандартных конкретизаций. Но дело даже не в этом. Ведь такие классы, процедуры и базы данных — это только часть разделов обеспечения и уровней представления ИС.
Например, еще есть ИТ-платформа (сервера различного назначения, ОС, СУБД, оборудование АРМов, а также сеть). Во многих своих частях она не может меняться с той же степенью «мелкой грануляции», что программные компоненты или базы данных. Понятно, что добавление каждой пары столбцов в таблицу БД или пары модулей выдачи отчетов не может выполняться с синхронным расширением дискового пространства или добавлением процессоров в сервер.
В связи с этим надо сказать о другом подходе: ориентации на стандарты открытых систем, позволяющие так строить техническую платформу, чтобы изменения техники или операционных систем по крайней мере не приводили к выкидыванию всех остальных ИТ-компонентов ИС (прикладных и общесистемных). Плановое применение этих стандартов — еще один правильный ответ на вопрос «как быть». К сожалению, идеал тут не достигнут, но — опять таки — дело даже не в этом.
Оба подхода важны и полезны, но оба решают только небольшую часть проблем, причем даже эту часть могут решать при условии, что развитие системы хорошо ПРОДУМАНО ЗАРАНЕЕ.
Обратим внимание на то, что изменения ИТ-платформы подчиняются требованиям другого масштаба и, часто, другой природы по сравнению с изменениями в прикладных программах. Поэтому вопросы планирования серверов или сетевой инфраструктуры, имеющей «резерв на будущее», гораздо более понятны менеджерам разных профилей. Легко согласиться с тем, что нужен резерв для поддержки новых двадцати рабочих мест, которые появятся в ближайшие полгода, легко понять, что совсем другой резерв нужен для развития ИС при подключении новых филиалов предприятия или при изменении политики физического размещения изделий на складах торгующих подразделений. Поскольку hardware — гораздо более «твердая» вещь, чем программы, связь технических ИТ-вопросов с вопросами стратегии предприятия является более очевидной. Но конечно же эти связи есть и у всех остальных компонентов системы.
О «плоских» схемах архитектуры
Отвлечемся на время от трансформаций предприятия. Ограничимся рассмотрением того, что ИУС — это не только программы, данные и коммуникации, но также и люди (заказчики, пользователи, аналитики, конструкторы и «реализаторы»), организационные структуры, планы-графики работы, а также цели и стимулы предприятия и отдельных людей. И все эти «вещи» должны быть понятным и непротиворечивым образом соединены в одну систему. Все возрастающая сложность и многоаспектность предприятия определяют растущую сложность согласования его частей и аспектов работы.
Главная идея такого согласования: его надо начинать с самых главных характеристик предприятия, рассматривая самые главные содержательные аспекты. И проводить его не «мысленно» и не «на словах», а на явно изложенных описаниях предприятия, позволяющих видеть все существенные взаимосвязи, а это значит — на его моделях. Предыдущие два утверждения, учитываемые одновременно, приводят к пониманию того, что привычные нотации формальных моделей (структурных, объектных) слишком рано ведут к более низкому уровню моделирования, чем необходимый в начале.
Здесь надо вспомнить Дж. Захмана (John A. Zachman), одного из лидеров интеграции бизнес- и ИТ-подходов. В 1987 году появилась статья [Zachman87], название которой можно перевести так: «Общая схема архитектуры информационных систем» . В ней была предложена простая, но концептуально мощная схема, показывающая различные уровни представления архитектуры ИС, различные виды ее «обеспечения», а также их основные взаимосвязи.
На рис. 1 показана таблица, аналогичная схеме Захмана 1987 года. Три ее (развернутых) столбца отражают три раздела обеспечения системы: информационное, функциональное и коммуникационное. Или:
ДАННЫЕ, ФУНКЦИИ и СЕТЬ.
Шесть строк таблицы отражают шесть уровней представления системы:
1. реальная бизнес-среда,
2. концептуальная модель,
3. логическая модель,
4. технологическая (физическая) модель,
5. детальная реализация (часто — поблочная и выполняемая субподрядчиком),
6. представление пользователя.
Схема [Zachman87] была признана очень полезным средством, вошла во многие монографии по стратегическому планированию и проектированию архитектуры ИС. И в нашей практике ее полезность была очевидной. Мне — а как я знаю, и многим другим проектировщикам — не раз приходилось слышать слова: «архитектура ИС — это выбор серверов, организация сети и подключения клиентских машин». Или: «это структура главного меню системы, привязка к нему прикладных модулей и привязка пользователей к меню и базе данных». Понятно, что первое утверждение принадлежало «главному инженеру проекта», а второе — «главному программисту». И совместное обсуждение схемы, подобной рис. 1, помогало рассматривать задачи проекта в полном контексте, упорядочивать структуру требований к системе, правильно определяя причинно-следственные связи.
Позднее появилось развитие этой «плоской» модели. В [Sowa,Zachman92] рассматривалась уже схема архитектуры предприятия . На рис. 2 показана таблица, аналогичная этой схеме и показывающая три новых столбца, в которых отражаются еще три раздела: побудительные причины действий системы, события и графики выполнения действий, а также «действующие лица» — люди и организационные структуры. Или:
МОТИВЫ, ВРЕМЯ (операционное) и ЛЮДИ.
В результате появилось шесть разделов, которые содержат «ответы на вопросы»: почему выполняются действия, когда выполняются и кто их выполняет, а также что делает система, как делает и где. При этом уровни представления, они же строки таблицы, остались те же.
Такое расширение позволило интегрировать потребности предприятия, способы его функционирования и ИТ-решения, соединять предметы и действия с человеческим фактором и операционной динамикой.
Описанные разделы и уровни по Захману являются классификацией сущностей предприятия и его ИС, о которой говорится как об основном инструментально-методическом средстве таблиц.
Схема архитектуры служила простым, но мощным инструментом по применению системного подхода для планирования работ по созданию и использованию ИУС и стыковки этих работ.
Захман писал, что схема архитектуры позволяет концентрироваться на отдельных аспектах системы и, в то же время, не терять ощущение общего контекста или «холистической» перспективы (то есть взгляда на предприятие как на целое). Он подчеркивал, что именно потеря такой перспективы, в частности, разработка систем субподрядчиками, находящимися «вне контекста», уже около пятидесяти лет составляет причину появления неинтегрируемых и не поддерживающих предприятие систем, которые к тому же весьма дорого заменять. (В то же время, плоская модель Захмана ясно показывает возможное место подобного «аутсорсинга», названного им детальной реализацией «вне контекста».)
Баланс между прагматикой реализации отдельных блоков и интегрированным взглядом на систему поддерживается схемой Захмана за счет того, что эта схема:
- § облегчает понимание и общение людей, имеющих разные роли в процессах создания, развития и использования системы,
- § ясно определяет фокус внимания на (относительно) независимых параметрах для целей анализа, но, в то же время,
- § обеспечивает поддержку контекстных взаимосвязей, важных для сохранения целостности системы.
ЗАМЕЧАНИЕ об отличиях наших плоских схем от схем Захмана.
Уже говорилось, что здесь был представлен аналог схемы Захмана для построения схемы «3D-предприятие», а не сама схема Захмана. Укажем несколько специально сделанных различий. Так, Захман связал с уровнями представления системы роли тех, кто «заказывает», проектирует и реализует систему, но из описываемого здесь развития схемы архитектуры эти роли исключены. Представляется, что их гораздо более продуктивно «добавлять» отдельно и позже, на этапе планирования проектной программы (см. об этом ниже).
Также надо заметить, что на рис. 1 нижний уровень отражает представление пользователя о практике использования системы, а не «функционирующую систему» по Захману. Это сделано для того, чтобы явно показать полезность отражения разных представлений работающей системы. Так, возможно и полезно специальное представление с точки зрения эксплуатации системы , и это представление сильно отличается от представления пользователя, причем два эти представления могут меняться во времени относительно самостоятельно. (Понятно, что подобное разделение неизбежно, ведь нижний уровень не является действующей системой, а лишь ее простым отображением, поэтому он всегда обязательно будет отображением, связанным с каким-то принципом упрощения. А это значит, что таких отображений может быть много.)
Из предыдущего понятно, что возможно увеличение числа уровней в схеме до семи. Но в практике применения возможно и уменьшение числа уровней, так как в некоторых случаях применения стандартов, готовых методик и интегрированных систем проектирования ИС возможно объединение второго и третьего уровней или третьего и четвертого. Хотя риски проекта при таком «ускоренном» проектировании возрастают, но в маленьких проектах такой подход по типу «fast track» может быть полезен.
От плоских схем к «3D-предприятию»
В 1996 году и позже Джон Захман писал, что одной из важнейших побудительных причин для использования новых подходов является изменчивость предприятия. Он говорил, что его плоские схемы моделей архитектуры — это также и средство для организации знаний предприятия , которые очень важны в условиях усложнения работы и приспособления к высокой степени изменчивости предприятия во времени. Тем не менее, его плоская схема в явном виде включает только раздел операционного времени предприятия, а этого совершенно недостаточно для целей управления проектами развития ИС и трансформации предприятия.
В цикле [Зиндер95,96а-б] автор писал об изменениях в принципах и приемах представления моделей предприятия. Введенные тогда трехслойная модель предприятия, принцип динамической адаптации жизненного цикла системы, другие принципы и приемы Н.С.П. (подхода «Новое Системное Проектирование») служили для учета высокой скорости изменений предприятия и ИС. Но требовались и более явные средства работы с меняющимися объектами. Эта необходимость побудила автора ввести трехмерную схему (см. рис. 3), образовав ее добавлением к плоским схемам оси стратегического времени . На этой оси располагаются интервалы осуществления различных проектов и стадий развития ИС и всего предприятия. Как элементы базовой классификации сущностей на этой оси рассматриваются:
1. стратегический анализ целей и потребностей, детальный анализ предприятия,
2. конструирование технических решений,
3. детальная реализация системы решений,
4. внедрение решений,
5. использование (эксплуатация) системы,
6. совершенствование системы.
Стратегический и детальный анализ могут рассматриваться и как разные стадии, что демонстрирует принцип адаптации схемы к жизненным циклам разных типов. Характер расположения архитектурных компонентов ИУС в этом третьем измерении отличается большим разнообразием, поскольку в реальной жизни многие процессы трансформации предприятия идут параллельно и итерационно. Более того, надо осознанно управлять параллельностью, совмещая и координируя проекты разных типов, например, проекты развития предприятия («развитие бизнеса») или проекты разных подсистем ИС.
Так появилась «объемная» схема архитектуры предприятия, его ИУС и ИС, или — схема «3D-предприятие» . Сначала схема использовалась как рабочее средство обдумывания, обсуждения и планирования ИС в развитии. Затем применение «3D-схемы» оказалось полезным расширить на разработку целевых проектных программ разных видов. На http://www.sept.ru/gr24/ приведена общая информация о схеме и моделях «3D-предприятие».
Модель «3D-предприятие» на основе соответствующей схемы
Если схема является общей структурой для разных предприятий, то описание архитектуры конкретного предприятия , которое строится по общей 3D-схеме, является уже моделью «3D-предприятия». Она строится для отражения взаимосвязей ключевых компонентов ИУС предприятия на выбранном историческом участке времени его развития в трех измерениях, предусмотренных 3D-схемой (также см. рис. 3):
1. ось уровня проектирования и использования ИУС; см. на рисунке шесть «горизонтальных» уровней: потребности и планы, бизнес-модель, логическая модель, техническая конструкция, детальная реализация, практика использования;
2. ось раздела обеспечения и аспекта работы ИУС; шесть «вертикальных» разделов, выделенных, но не поименованных на рисунке: почему(цели), кто («деятели» системы — люди и организационные единицы), что (информация), как (функции и процессы), когда (события и графики функционирования), где (размещение и коммуникации);
3. ось времени , в котором развивается предприятие и его ИУС, см. на рисунке шесть возможных (но не единственных) стадий на «верхней грани» модели, соответствующих (возможным) стадиям жизненного цикла системы: анализ (стратегический может отделяться от детального), проектирование (конструирование), реализация и ввод в действие (могут рассматриваться отдельно), использование в работе, совершенствование (на этой оси моделируются и другие аспекты развития ИУС).
Первые две оси совпадают с теми, что использованы на рис. 1 и 2 в моделях, аналогичных таблицам Захмана. Третья ось позволяет явно определять изменения, которые происходили и будут происходить с предприятием и проектами создания ИС в процессах их развития и трансформации.
Требования к «3D-модели»
Создаваемое в этих осях описание становится конкретной 3D-моделью после того, как в элементарных «кубиках» или ячейках модели появляются согласованные описания, то есть частные модели. К их построению предлагаются определенные требования, и главные из них таковы.
При построении 3D-модели не должны использоваться никакие формализованные нотации и узко-профессиональные жаргоны. Модель 3D-предприятия (в развитие положений Захмана) должна быть:
- § ПРОСТОЙ ДЛЯ ПОНИМАНИЯ, не технической, доступной всем (техническим и нетехническим) руководителям и специалистам,
- § ЗАКОНЧЕННОЙ в отношении предприятия так, что каждая проблема соотносится с предприятием в целом — и в данное время и в его будущем.
- § ОТКРЫТОЙ в отношении развития и трансформаций так, чтобы каждая проблема или проект свободно включались в контекст конкретных событий будущего, причем как в отношении будущего отдельных проектов, так и предприятия в целом.
- § СРЕДСТВОМ ОБЩЕНИЯ, инструментом поддержки обсуждений сложных вопросов с использованием относительно немногих и нетехнических слов.
- § ИНСТРУМЕНТОМ ПЛАНИРОВАНИЯ, позволяющим лучше принимать решения за счет того, что решение никогда не будет приниматься «в пустоте».
- § СРЕДСТВОМ РЕШЕНИЯ ЗАДАЧ, позволяющим работать с абстрактными сущностями выделяя и изолируя отдельные параметры системы без потери ощущения предприятия как развивающегося целого.
- § НЕЙТРАЛЬНОЙ, полностью независимой от каких либо инструментов, благодаря этому каждый инструмент и методология могут быть отображены на схему или модель 3D-предприятия для того, чтобы явно показать, что они делают и что не делают.
При этом важно, чтобы даже самое общее описание каждой частной модели содержало оценку состояния с точки зрения данной модели как компонента системы.
Создаваемые в ячейках частные модели должны быть согласованы в своих взаимосвязях. Особенностью 3D-предприятия является описание этих взаимосвязей не только для какого-то одного момента, но и на концах всех отрезков оси времени, которым приписаны начала и концы рассматриваемых проектов, стадий и работ.
Правилом описания взаимосвязей частных моделей является явное выделение и описание:
- § связей каждой модели-ячейки с ближайшими ячейками более высокого и более низкого уровней представления архитектуры предприятия и ИС,
- § связей каждой модели-ячейки с ближайшими ячейками, отражающими предшествующему и будущему состоянию компонента архитектуры,
- § связей каждой модели-ячейки с другими типами моделей данного уровня.
Содержанием описания взаимосвязейдолжны быть характеристики:
- § соответствия потребностям и более формальным требованиям к компоненту,
- § качества и готовности,
- § соответствия плановому графику работ и согласованности различных графиков,
- § достоверность и обоснованность графиков инвестиций и их окупаемости,
- § прогноз возможности изменений — самого близкого по времени изменения потребностей, требований и обеспеченности этих изменений ресурсами,
- § смысловая целостность модели одного уровня.
Так же, как и сущности на осях плоских схем, сущности на оси стратегического времени в конкретных 3D-моделях могут представлять не только развитие ИС, но и «развитие бизнеса» предприятия. А уже результатом выполнения такого развития или его стадий могут быть проекты создания новых (или развития имевшихся) компонентов ИС. Так проект развития ИС вычленяется и оформляется как подпроект проекта развития предприятия.
Организация применения схемы «3D-предприятие»
В качестве примера покажем начальные работы по описанию текущего состояния предприятия в целом и его ИУС, то есть разновидности модели «as is», учитывающей наличие планов предприятия. Это важное методическое положение, ведь модели «as is» в чистом виде не бывает. Предприятие находится в состоянии трансформации постоянно, даже если такая трансформация существует только в виде плана или промежуточных результатов работ по развитию.
Первым шагомявляется общее обсуждение 3D-схемы руководителями предприятия и его подразделений. Оно имеет своей целью достижение общего понимания всех типов сущностей этой схемы как компонентов и представлений системы в процессах их жизни — процессах создания и последующих трансформаций.
Вторым шагомявляется разделение работ по построению самой общей модели «3D-предприятия» между руководителями.
Координатором всех работ может быть заместитель генерального директора — директор по развитию. Он же может выполнять описание модели первого уровня — уровня целей и потребностей. Но в этих работах естественно участвовать и руководителям других специализаций: маркетинг, финансовое управление, сбыт и связь с потребителями, проектирование новых изделий или услуг, связь с поставщиками и снабжение, планирование производства и др., а также информационное обеспечение и ИТ В соответствии с реальной степенью интеграции системы управления и ИС оправдано привлечение директора информационной службы предприятия уже к работам первого уровня.
ЗАМЕЧАНИЕ об использовании терминов модельного подхода на практике.
Очень хорошо, если все указанные руководители принимают понятие «модель» и умеют им пользоваться. К сожалению на практике это бывает редко, поэтому чаще частные модели обсуждаемого уровня полезно называть так, как принято называть на предприятии документ, в котором отражается соответствующая модель: план развития, бизнес-план, бюджет, организационная структура, положения об отделениях и отделах, инструкции по выполнению конкретных работ и т.п. А также планы и описания идущих проектов развития предприятия, включая проекты создания новых товаров, проекты захвата новых сегментов рынка, проекты создания новых подсистем ИС.
Следующие шаги нумеруются условно, так как осуществляться могут в разной временной упорядоченности или частично параллельно.
Третьим шагомявляется привлечение специалистов и руководителей среднего звена с закреплением за ними конкретных «участков», то есть областей моделирования (в одну область может входить один элементарный кубик «3D-предприятия» или совокупность таких ячеек) на уровнях 3D-модели со второго и ниже.
Четвертым шагомявляется первоначальное и неформальное описание тех частных моделей, которые актуальны для погружения в общую модель «as is».
На оси стратегического времени директор по развитию может самостоятельно описывать модель только на уровне результатов самых первых шагов стадии стратегического анализа. Обычно он подключает к работе директора по маркетингу и финансового директора. Роль последнего важно отразить, так как многие сущности на оси стратегического времени являются по сути инвестиционными проектами .
Затем или параллельно с этим выполняются работы по общему описанию так называемых бизнес-моделей или концептуальных моделей ИСУ и предприятия. Работы по описанию моделей логического и технического уровней выполняются при наличии компьютерной информационной системы или идущего проекта ее создания. Но при описании «as is» на уровне 3D-модели это описание носит характер самой общей инвентаризации.
Пятым шагомявляется рассмотрение совокупности частных моделей с их взаимосвязями. Указывалось, что в 3D-предприятии эти взаимосвязи описываются не только «на сегодня», но и на концах отрезков оси времени, которым приписаны начала и концы работ и проектов. Для построения временного слоя «as is» это относится к существующим планам, работам, проектам и их выполняемым этапам. Описание взаимосвязей выполняется с учетом указанных ранее требований.
Построенная таким образом модель используется далее и как основа диагностического анализа и как средство дальнейшего планирования проектов.
Дальнейшее использование модели «3D-предприятие»
3D-предприятие приносит наибольшую пользу в случаях, когда описываются несколько слоев по оси времени, явно представляющих предприятие и его ИУС в развитии. Поэтому рассмотрим планирование не одного проекта, а проектной программы.
По разным причинам полезно разбивать «бесконечные» работы по созданию или развитию ИС на короткие проекты 6-9 месяцев длительности. Одна из причин — скорость изменений требований к ИС, из-за чего давно стала понятной необходимость изменения подходов к построению моделей предприятия в проектах ИС. Вспомним, что в [Зиндер96б] описан недостаток рассмотрения двух моделей — «as is» и «to be» — и рекомендовано перейти к рассмотрению серии моделей, которые строятся для разных моментов времени.
В конкретных ИС часто полезно рассматривать три очереди развития ИС:
- § «для сегодня» (идущие проекты, проекты, планируемые к запуску в ближайшие дни или недели и завершение которых планируется на ближайшие недели и месяцы),
- § «для завтра» (проекты, которые должны поддержать основные стратегические задачи и будут завершены примерно через год, редко — полтора),
- § «для послезавтра» (проекты, которые должны опираться на сегодняшние и завтрашние, которые уже сегодня должны определять требования к совместимости старых и новых подсистем и единиц ИУС и должны завершиться через полтора — два года, поддерживая перспективные стратегии развития предприятия).
Каждой очереди соответствует группа взаимосвязанных проектов, а каждому проекту соответствует своя группа работ, захватывающая свою область смежных во времени ячеек 3D-модели. Именно при построении модели проектной программы, развивающейся во времени, становится наиболее ясной польза построения и применения общей понятийной модели предприятия, которая может играть роль минимального средства интеграции систем (см. [Зиндер96в]) уже начиная с составления «3D-модели». Кроме того, именно при построении такой модели становится наиболее наглядной картина согласованности различных инвестиционных акций предприятия.
Схема «мультикуб» и ее применение
Модель «3D-предприятие» может служить базой для перехода к следующему, более конкретному уровню планирования при управлении проектной программой. Для этого рассматривается сочетание областей работ каждого проекта и нескольких дополнительных осей :
- § применяемые методы \ инструменты разработки ИС или управления,
- § специализации конкретных разработчиков ИС или управленцев,
- § уровень абстракции модельных компонентов и др.
На рис. 4 показан процесс соединения выделенной в архитектуре 3D-предприятия проектной программы с параметрами организации проектов из этой программы. Добавляемые параметры (участники проекта и инструменты проектирования) связываются с 3D-предприятием по такой характеристике, как уровень проектной задачи.
На http://www.tline.ru/present1/ представлена система организации курсов профессионального обучения «Training Line System», разработанная учебным центром «Training Line» и фирмой «Группа 24». На этом примере конкретного применения схемы 3D-предприятия можно видеть как модель-мультикуб используется при планировании одного из видов проектных программ — целевых программ обучения.
«3D-предприятие» и другие схемы, модели и задачи
В 3D-предприятии использован аналог схемы Захмана, а не ее копия, причем отличия были введены специально. Так, Захман связал с уровнями представления системы роли тех, кто «заказывает», проектирует и реализует систему, а из описываемого здесь развития схемы архитектуры эти роли исключены. Представляется, что их гораздо более продуктивно «добавлять» отдельно, на этапе перехода к модели-мультикубу для более конкретного планирования проектной программы. Есть и другие отличия (их характеристику, а также дополнительные подробности о применении 3D-схемы можно будет получить из полного текста статьи на сайтах www.sept.ru и www.tline.ru).
3D-предприятие естественно стыкуется с другими видами схем стратегического и архитектурного уровней. К таким схемам относятся, например, схемы циклов маркетингового стратегического управления, или такие схемы создания ИС и ИУС, как трехмерная архитектура CIMOSA, схемы бизнес- и информационной платформ и архитектур Дж. Хендерсона, схемы «здания ARIS» А. Шеера.
3D-предприятие работает в проектах самых разных видов, и практика показала целесообразность применения этого подхода еще до первых шагов планирования проектов. А благодаря концептуальной совместимости с другими схемами после описания целостной и динамичной 3D-архитектуры можно включать в работу более специфические или более технические инструменты и модели, например, Turbo-BPR, Process Charter, ARIS ToolSet, UML RRose или Oracle Designer.
Литература
[Zachman87]John A. Zachman. A Framework for Information System Architecture. IBM System Journal, vol. 26, no. 3, 1987.
[Sowa,Zachman92] J.F. Sowa, J.A. Zachman. Extending and Formalizing the Framework for Information System Architecture. IBM System Journal, vol. 31, no. 3, 1992.
[Зиндер95,96а-б] Е.З. Зиндер. Новое системное проектирование: информационные технологии и системное проектирование. //СУБД №4, 1995; №1,2, 1996.
[Зиндер96в] Е.З. Зиндер. Проектирование баз данных: новые требования, новые подходы. //СУБД №3, 1996.
Евгений Захарович Зиндер — директор аналитического и конструкторского бюро «Группа 24»,шеф-консультант «Директора информационной службы». Ему можно написать по адресу: ezinder@osp.ru или gr24@sept.ru
Источник: hr-portal.ru