Об Захмана

Очень трудно объяснять, почему что-то давно известное в курсе менеджмента или инженерии не преподаётся, почему выкинуто из курса. Например, почему раньше в курсе фреймворк архитектуры предприятия Захмана давался, а сейчас -- нет.

Действительно, лет десять-пятнадцать назад о Захмане и его идеях было много разговоров. Конечно, в первых версиях курса менеджмента я давал этот фреймворк Захмана, в разных его версиях. В том числе я рассказывал на курсах байку о том, как пил чай с Диецем в Нижнем Новгороде в 2011 — https://ailev.livejournal.com/952625.html (главная тема там была традиционная для Диеца: "в предприятии важны конструктивные части, а функциональные части путают", я же приводил альтернативное мнение). Я тогда рассказал Диецу, что Захман назвал свою третью версию фреймворка "Онтология предприятия" и поставил там знак трейдмарка, (tm). Диец там аж подпрыгивал, у него же книга ровно так называется, и он считал, что у него в этом приоритет! Правда, это оказалось неверной ставкой, уже в 2012 году нейронные сети выиграли ImageNet, и онтологии с их пика популярности в 2013 году как очевидного хода на "искусственный интеллект" где-то в 2015 году оказались на периферии, были всеобще забытыми -- и "онтология предприятия" оказалась так же забыта. Пришли другие способы описывать предприятия. Ещё буквально в это воскресенье на первой встрече текущего потока "Системного менеджмента и инженерии" я ссылался, что Захман специально убрал из последней версии фреймворка поминание "данных", чтобы директор предприятия не ставил заниматься архитектурой предприятия айтишников, ибо любое слово из айтишного лексикона приводит к тому, что вопросы архитектуры предприятия топ-менеджмент скидывает айтишникам, которые делают вместо описания предприятия описание корпоративного софта, который содержит описание предприятия (вот пост об этом, это 2011 год — https://ailev.livejournal.com/951732.html). Но даже и тут всё изменилось: где-то с 2017 года понятие "архитектуры" и в софте поменялось, и постепенно начало меняться везде -- включая архитектуру предприятия. Концепция использования и концепция системы как основные решения по поводу того, что и как делает система (в том числе в немного другой терминологии -- предприятие) вовне и внутри себя оказались именно про состыкованность всех видов системных описаний (конструкция, функционирование, компоновка/размещение, стоимость и даже кандидатами сейчас -- работы систем создания), а архитектура оказалась про особенности деления на модули и организацию межмодульного взаимодействия. Диец тем самым был в своём нюхе будущего прав (конструктивное в современной архитектуре превалирует), но будущее оказалось пришедшим по-другому, через архитектурные характеристики, технический/архитектурный долг и т.д.

Тем не менее, книжку Диеца в его втором издании мы в курсе системного менеджмента даём в числе важной литературы. А ссылок на Захмана (изобретателя термина "архитектура предприятия"!) не даём. Вся захмановщина сильно подустарела. Дела давно минувших дней, преданья старины глубокой.

Действуем по принципу бритвы Оккама: фреймворк Захмана порождает сущности без надобности, выдаёт "всеохватное описание". Он менее эффективен, чем имеющиеся сегодня практики описания предприятия. Задать вопросы "что где когда (а также зачем сколько почему и т.д.)" можно и без Захмана. То, что эти вопросы задаются на разных уровнях к разным объектам -- так системное описание с его обязательными моментами это вполне подразумевает. Первые архитектурные описания не специфицировали того, что обязательно надо описывать, они просто говорили, что должно быть много view (аспектных описаний), которые порождаются многими viewpoints (методами описаний), и было довольно много популярных списков таких возможных описаний. Классика инженерии с функциональным, конструктивным, пространственным, стоимостным появилась попозже. Захман же победил всех -- составил матрицу, позволяющую бесконечно долго и подробно описывать предприятие. Ну прямо как Старик Хоттабыч, который выдал футболистам не один мяч для игры на 22 человека команд, а 22 мяча -- чтобы каждого занять делом. Вот моё замечание по Захману из коммента ещё 2007 года к посту https://ailev.livejournal.com/515025.html: "нам Захман представляется чересчур навороченным для наших целей: он уже привел к появлению дюжины самых разных стандартов для описания всего этого хозяйства -- и вся эта "корпоративная архитектура" абсолютно неподъемна". Замечу, что TOGAF мы в курсе тоже не рекомендуем, по той же причине. Подход "чтобы ещё такого описать, чтобы вам не было скучно, и чтобы вы могли оправдать затрату денег ссылкой на наш важный стандарт" -- это анахронизм.

Эволюционно подход Захмана — просто вымер, не выдержал конкуренции с новыми подходами. Вот цитата из ещё одного моего поста 2007 года (16 лет назад!), https://ailev.livejournal.com/518240.html: "За последние несколько лет произошел четкий уход от примата Zachman Framework в организационном моделировании. "Организационная архитектура" (а как еще перевести, чтобы уйти от коммерческого оттенка "предприятия"?!) заговорила онтологическим языком. Ключевые слова теперь -- "онтология", "метамодель", "модель"". И дальше я там даю ссылки на подход BORO к описанию онтологии предприятия. Захман, конечно, это тоже почувствовал, его третья версия фреймворка, которая вышла в 2008 году включила вот это самое "enterprise ontology", https://en.wikipedia.org/wiki/Zachman_Framework -- но вся эта история к этому моменту шла почти тридцать лет!

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

Практики проектирования предприятия и архитектуры предприятия разделились в последнее время: первая про изобретение того, как функциональные объекты с их практиками разлеглись по конструкции/оргструктуре, а вторая -- про то, чтобы подразделения действовали оптимально автономно, избегали влияния закона Амдаля и учитывали закон Конвея. Ни материалы Захмана, ни материалы TOGAF (и многочисленных других "архитектурных фреймворков") этого уже не учитывают. И не учитывают, что архитектура должна описывать самое важное, а не описывать всё подряд, что представляется возможным описать. Секрет оказался в том, чтобы описывать поменьше, lean/элегантно, а не в подсказках о том, что вообще можно было бы описать. Не надо подсказывать "что где когда", это и так люди понимают. То, что у Захмана матрица, а не просто ответы на вопросы, дела не меняет. У нас же ещё обязательные аспекты системного описания есть, они точней работают, чем матрица Захмана. Потом ещё и архитектурные языки появились, которые не только говорят, какие у нас есть виды view, но и дают viewpoints (это важно: viewpoints чаще всего включает в себя язык, а описание view не говорит о языке. Скажем, "функциональность холодильника на кухне" может быть представлена текстом, учебным кинофильном, use case -- все эти Захмановские фреймворки и прочие TOGAF останавливаются на этом, и не говорят о собственно методе описания. А там будут свои проблемы. Скажем, в ArchiMate нет никаких слов из TOGAF, кроме поминания, что все view из помянутых в TOGAF вполне выразимы в ArchiMate с его расширениями в третьей версии. Но на практике выясняется: нужное для оргпроектирования ArchiMate показывает плохо, ибо ArhciMate не системный (https://ailev.livejournal.com/1454948.html), а ещё сами диаграммы представляют собой тарелки со спагетти, работать невозможно. Поэтому выкидываем и TOGAF, и ArchiMate из курса. Но учим организационному проектированию, организационному моделированию, организационной архитектуре! И нормально так работает, у всех выпускников, хотя и без блеска десятилетий активной пропаганды раскрученных трейдмарок, без сияния сотен и тысяч презентаций, которые сделали в этой предметной области за тридцать-сорок прошедших лет спецы по прошлым поколениям архитектуры предприятия.

Всё, поезд Захмана ушёл. Это же касается многочисленных других старинных подходов, крайне ранее популярных. В новых версиях курсов их нет! Всё, вымерли! Если кто-то где-то это практикует, в каких-то крупных старых организациях, просто по инерции, то необязательно перетаскивать эти практики в новые места, в новых местах, в новых организациях надо разворачивать новые практики, работать на фронтире!

Но как же быть с реально старыми книжками, которых не так много, но которые поминаются в моём курсе? Например, книжка Атула Гаванде про чеклисты (первая публикация -- декабрь 2009 года)? Мне единственное зачем нужна эта книжка — убедить, что чеклисты таки работают, их таки нужно делать. И что чеклисты могут существовать в очень разной форме. Это больше методический материал, чем методологический. Именно так и работает. Читают как художественную книжку, после чего больше про чеклисты вопросов не задаётся, размышлений особых нет — берут, и делают. А без книжки — думают, обсуждают, рассуждают, но до дела почему-то руки не доходят, не случается "внутреннего убеждения". Ещё можно привести из "старых книг" бестселлер Эрика Риса про "элегантный стартап" -- это классика, показывающая важность эволюции продукта, кручение трёх циклов. Там есть очень спорные идеи (типа обязательности "кратного роста"), и потихоньку появляются новые интересные объяснения/теории для того набора идей, который давался в этой книжке как абсолютно фронтирный. Сейчас это не фронтир и радикальная новация, а самый мейнстрим, вполне работающий. Возможно, в следующих поколениях курса эта книжка тоже перестанет цитироваться.

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


Справка "об об" -- https://ailev.livejournal.com/982750.html