Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Захман жил, захман жив, захман будет жить -- версия 3.0 его подхода, организационная онтология (tm)

В сообществе организационных архитекторов (enterpise architecture) большое событие: пару недель назад вышла версия 3.0 Zachman Framework (http://www.zachman.com/). Рекомендую сразу вытащить большую .pdf картинку тут: http://www.ronross.info/blog/wp-content/uploads/2011/08/ZF3.03.zip3.zip (посмотрите при 400% увеличении, там даже красные квадратики первого ряда вполне читаемы, очень интересно!).

Если честно, то я давно сбросил со счетов работу Захмана -- мне было очевидно, что она имеет уже только историческое значение. С выходом версии 3.0 ситуация изменилась: в этой версии опять много современного -- и хотя она по основной своей сути остаётся важным музейным экспонатом (как пошутил один из комментаторов в LinkedIn -- что-то типа важной роли древнегреческой и римской архитектуры в современной архитектуре), нововведения хорошо отражают дух именно нынешнего времени. Вот только несколько из таких важных и неочевидных двадцать лет назад идей, мейнстримность которых Захман подтвердил своей новой версией:

1. Прямое указание на то, что "это метамодель, это онтология". Захман по факту синонимизирует эти слова. Более того, после упоминания того, что он презентует онтологию предприятия (enterprise), он скромно замечает, что она применима и ко всему остальному (забавно читать про buildings, aeroplans and other complex industrial products) -- http://www.zachman.com/about-the-zachman-framework. Рональд Росс отмечает, что Zachman considered changing the main title word “Framework” to “Ontology” but decided to stay with the former. А вот Яну Диетцу с его книжкой Enterprise Ontology может не понравиться TM нынешнего подзаголовка -- The Enterprise Ontology (TM). Вы теперь знаете, чья теперь официальная, зарегистрированная американским государством онтология предприятия.

2. Явный учет жизненного цикла инженерной системы "от задумки до реализации" -- по факту, вертикальное измерение таблицы повторяет идею 4-х аспектной (на самом деле -- многоаспектной) архитектуры ISO 15926 (связанные с жизненным циклом системы -- перехода от функции к конструкции, а затем к экземплярам -- уровни моделирования данных: типы, классы классов, классы, экземпляры), в свою очередь заимствованные из стандарта идентификации компонент инженерного проекта IEC-61346-4 (знаменитая диаграмма "жизненного цикла электромотора" -- последовательное появление функционального тэга, требований, техусловий, оборудования "в железе").

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


У Захмана это 6 уровней Reification Transformations. Фишка в том, что Захман связывает каждый из уровней этой реификации/воплощения/абстрации/представления системы с особой деятельностной/профессиональной позицией (напомню, что stakeholder -- заинтересованная сторона, определяется культурно-обусловленно, а не по экземпляру человеческой тушки). Вот эти связи, как их понимает Захман:
2.1. scope context (identifications) -- executive (business scope planners)
2.2. business concepts (definitions) -- business management (business concept owners)
2.3. system logic (representations) -- architect (business logic designers)
2.4. Technology physics (specifications) -- engineer (business logic builders)
2.5. Tool components (configurations) -- technician (business components implementers)
2.6. Operations instances (instantiations) -- users, The Enterprise (то есть уже индивид, а не класс). Фишка в том, что у Захмана это экземпляр классов, определенных только в ряде 2.2!

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

3. А вот, собственно, из чего состоит предприятие (те самые "что, как, где...") из прошлых версий -- и что должно быть реифицировано/воплощено в моделях и "железе и действиях" всех этих шести групп описаний из предыдущего пункта:
3.1. Активы (inventory sets) -- сущности и отношения.
3.2. Ход работ (process flows) -- трансформации, и что на входе/выходе этих трансформаций.
3.3. Распределительные сети (distribution networks), мне кажется это очень важным -- это ведь можно протрактовать и как прямой ход на потоковую factory physics. Хотя сам Захман, похоже, имеет ввиду главным образом пространственное размещение (location) и результирующих связях (connection) -- но слово "networks" указывает, что речь отнюдь не только о физическом пространстве.
3.4. Ответственность/полномочия (responsibility assignments) -- привет Яну Диетцу, он как раз сегодня в Нижнем Новгороде рассказывает, что это и есть "истинная организационная онтология, ибо кто кому чего имеет право поручить и определяет суть организации". Роли и рабочие продукты.
3.5. Временные циклы (Timing Cycles) -- и обратите внимание, что "жизненный цикл" потихоньку уступает место "временнЫм циклам" (в том числе из-за давления путаницы с case life cycle и project life cycle -- они-то уж точно не про "всю жизнь от замысла до смерти", речь не о жизни и смерти, а о кусочке времени в этой жизни). Вспомним, например, ISO 24744 -- Stage-WithDuration/*Kind is, in turn, specialized into TimeCycle/*Kind (having as objective the delivery of a final product or service), Phase/*Kind (having as objective the transition between cognitive frameworks) and Build/*Kind (having as major objective the delivery of an incremented version of an already existing set of work products). TimeCycle/*Kind also holds a whole/part relationship to Stage/*Kind, allowing for the recursive composition of time cycles and other stages. Да, timing cycles и у Захмана -- это интервалы и моменты.
3.6. Деятельностное намерение (Motivation Intentions) -- цели и средства.

Все это провязано друг с другом correspondence rules -- как и предполагается в ISO 42010 (и слово rules тут не случайно. См. постинг http://www.ronross.info/blog/2011/09/06/where-are-your-business-rules-%E2%80%A6-in-a-big-p-process-dead-zone/ с разъяснениями -- хотя я и понимаю, что business rules и correspondence rules далеко не одно и то же, но смысл использования каких-то логических пропозиций при обсуждении связи моделей из разных тематических групп описаний остаётся). И эта провязка делается в рамках одного уровня реификации, одной стадии жизненного цикла! Опять же, вспоминаем "стадию жизненного цикла" в ISO 24744 как "Phase/*Kind -- having as objective the transition between cognitive frameworks".

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

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

4. Слово "данные" у Захмана исчезло. Как по этому поводу замечает Захман, на это слово сразу прибегают айтишники, и убегают менеджеры. И разговор дальше идет не о предприятии, а о его IT-системах. Убрали слово "данные" -- и айтишников стало поменьше, менеджеров побольше. Захман хочет оставаться в содержательном "пользовательском" разговоре об информации, а не программистско-логическом разговоре о данных (см. http://ailev.livejournal.com/908102.html).

Конечно, в блогах идет много комментариев на предмет отсутствия в Захман-3 и данных, и правил. "Верблюда спросили: почему у тебя шея кривая? Верблюд очень удивился -- а что у меня прямое?!".

5. Итого: принять к сведению, и продолжать делать своё оргонтологическое дело. В принципе, у меня есть догадка по утилизации схемы Захмана образца 2011: если вы хотите быть модным и опираться на современные архитектурные подходы, но не хотите использовать ненужные вам монструозные подходы типа ARIS или TOGAF, то смело опирайтесь на схему Захмана -- она, вроде, что-то говорит, но не так много, и не так конкретно, чтобы вам помешать. И вы даже "современны" по состоянию на сентябрь 2011 года...
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 7 comments