Когда мы пытаемся создать более-менее формальную систему описаний различных организаций, то мы должны сначала выбирать из этих подходов тот стиль/вид языков программирования/моделирования/онтологического описания мира, который будет удобен для того или иного потребного администраторам программирования/моделирования/онтологического описания мира -- и прежде всего создания organizational knowledge domain specific language = метамодели = нашего целевого языка описания организации. Назовем этот язык-метамодель-оргонтологию Орглан (слово пока никем не занятое). Конечно, нужно сразу постулировать возможность трансляции/перевода формальной записи на Орглане из одной языковой семьи в другую, если потребуется.
Критерии удобства выбора подхода фиксации Орглана: мощность языкового инструментария, понятность общеметодологам и организационным методологам. Для всех остальных (администраторов и сотрудников) Орглан будет задаваться другим способом -- уж никак не путем чтения формального описания. Так же, как формальное описание языка программирования используется только разработчиками компиляторов, а программисты этого языка учатся по учебникам и примерам программ, написанных другими людьми, так и в случае Орглана его формальное описание используется только теми людьми, которым оно нужно именно как формальное описание -- его разработчиками, разработчиками систем программной поддержки организации и авторами учебников и тренерами ("программистами людей", делающими из "просто людей" организованных сотрудников).
Дискуссия-2006 в "Электронной России" про выбор подхода к описанию организации свелась к выбору из подходов с семантически-сетемыми "классификаторами и проекциями" и "объектного-процессного" UML-описания (или "ГосМастер против Rational Rose", как это было тогда обозвано). Описания на "просто языке программирования" даже не рассматривались -- ибо инструментарий для рендеринга различных view на описание организаций нужно еще поискать, а системы программирования с разнообразными "браузерами" типа смоллтоковских на тот момент даже не всплывали в разговорах.
Это я пишу через год после постинга http://ailev.livejournal.com/388456.html, с тех пор многое прояснилось -- в том числе понимание того, что на чужой оргонтологии далеко не уедешь. И, конечно, я знаю про работы Непейводы по логической классификации стилей программирования и "адекватности стилей задаче" -- но мы тут про другое. Более того, я догадываюсь, какая кипучая деятельность идет в Domain-Specific Modeling (http://en.wikipedia.org/wiki/Domain-specific_modeling), или даже как склеиваются UML и OWL в рамках document centric engineering (см. пример кратенького описания к http://www.sysmlforum.com/docs/cfps/SoSyM-CfP-MBSE.htm -- обожаю извлекать всякие тренды и определения из call for papers и call for participation).
И сейчас нам нужно быстро перейти от множества слов (текстов и даже схем-картинок) к более-менее формальным описаниям, для чего правильно было бы использовать современную "структурирующую бумагу" -- компьютеры. Более того, нам нужна учетная система, в которой можно будет найти "эталонное описание" и определены правила его изменения.
Есть следующие более-менее распространенные подходы к компьютеризированному описанию окружающего мира:
1. семантические сети и базы знаний, ключевое слово "онтология" -- OWL, CycL, ER-оргмоделлеры типа ОргМастер и многие другие. Сейчас всех напрочь победил OWL, но как раз перед появлением этого подхода появлялись работы типа http://www.cs.man.ac.uk/~ocorcho/documents/ekaw00_CorchoGomezPerez.pdf, которые заставляют более внимательно отнестись к разнообразию разных языков спецификации онтологий (и которые указывают на выразимость в онтологических языках концептов, n-арных отношений, функций, процедур, экземпляров, аксиом, продукционных правил, формальной семантики). А в последнее время ResearchCyc предлагает навороченные альтернативы для knowledge formation and dialog, чем и предполагается заниматься (http://www.cyc.com/cyc/cycrandd/areasofrandd_dir/kfd).
2. объект-ориентированный подход: ключевое слово "модель" -- UML с добавками, все про model-driven development (неожиданно от "моделей предприятия" идет перескок в "генерацию исполняемого кода"), всевозможные ARISы и другие средства реализации "процессного подхода" и "корпоративной архитектуры". Тут нужно еще добавить и IDEF0-IDEF3.
3. "просто язык программирования", даже если это объект-ориентированный язык (но не UML, а Smalltalk/Self или аналогичный) и система браузеров для различного рендеринга кодов. Аспектное и контекстное программирование -- это сюда же. Языки сверхвысокого уровня, а также сверхмощные (т.е. сверхкомпактные, но быстрые) исполняемые языки типа COLA (combined object-lambda) из проекта FONC.
4. сущностые схемы, организационные схемы и прочий инструментарий СМД-методологов (хотя тут вся "компьютерная поддержка" сводится к Visio и спецнабору stensils в лучшем случае).
Кроме выбора "общеметодологического языка" для фиксации Орглана, нужно выбрать для него конкретную реализацию языковой среды.
По-хорошему, так все эти варианты описания равноприменимы -- "конкретный синтаксис" тут неважен. Важным оказывается сама языковая среда (позволяет ли она в конечном итоге использовать эти описания для создания OrgLAN -- скаламбурим тут и скажем, что "организационная сеть" является программной реализацией Orglan как организационного языка).
После опроса самых разных людей выяснилось, что подход 3 (использование какого-то исполнимого выразительного языка и его расширений вкупе с рефлексивными трансформациями, написанными на нем же) нравится всем, хотя и самый ресурсоемкий. Зоопарк "стандартных специализированных языков" (типа OWL, UML, транформационные языки и т.д.) в одной системе почему-то никого не привлекает, хотя в этом случае и возможно использование стандартного инструментария. Все мои собеседники говорили, что если уж и стоит задача фундаментальной разработки в одной из областей (построения предмета организации/администрирования), так тут нужно честно брать такой же фундаментальный инструментарий -- т.е. решать онтологические задачи прямо в целевом языке. Будет и компактнее, и понятнее, и быстрее.
Но ключевым при этом становится тот системный архитектор и "языковед", который будет ответственным за архитектуру этой разработки и элегантность "схватывания" оргонтологии языковыми средствами.
Похоже, что на текущий момент реальной рабочей средой, в которой можно было бы выполнить подобную работу по фиксации организационной онтологии, а затем созданию софта по поддержке организации/администрирования, является Сквик-Крокет.
Поэтому вопрос к уважаемым френдам: не знают ли они кого-то, кто был бы способен выполнить такой амбициозный проект? Ибо дело стремительно катится к стартапу, и нужно подбирать команду.