June 6th, 2007

2019

Организационные паттерны как архитектурные паттерны софта

Я уже поднимал (вслед за Alan Kay) тему про аналогичность задач, возникающих в IT и у организаторов. В частности, я поминал про "координационное программирование" (http://ailev.livejournal.com/472764.html), про глубокую аналогичность программирования и производственного планирования, обучения и программирования (недаром -- "нейро-лингвистическое программирование"!), базовость программистского (т.е. планировочного, или дизайнерского) образования для организаторов и методологов организации и много чего еще из этой области пересечения организационной теории и программирования.

Вот пример работы группы, где пересекаются (намеренно и осознанно) темы паттернов дизайна и организационных паттернов: в качестве архитектурных паттернов современного софта (напомню: клиент-сервер, клиент-брокер-сервер, pipes-and-filters и т.д.) предлагается впрямую брать организационные паттерны, отмоделированные на реальных бизнес-организациях по идеям работ организационной теории. Утверждается, что эти организационные паттерны для сложных софтверных систем лучше будут соответствовать нефукнциональным требованиям (безопасность, производительность, доступность и т.д.).

Полюбуйтесь:
http://www.cs.toronto.edu/~mkolp/troposstyles.ppt -- красивая цветная презентация с перечислением всевозможных паттернов и намеком, для чего это все. Cоответствующая ей статья -- http://www.cs.toronto.edu/~mkolp/ICEISorgmas.pdf

http://www.cs.toronto.edu/~mkolp/wp28.pdf -- как использовать организационные архитектуры при проектировании роботов Lego Mindstorms.

http://www.cs.toronto.edu/~mkolp/ICEISadlfull.pdf -- агентский архитектурный язык описания для информационных систем (на базе агентской модели Belief-Desire-Intention).

http://www.cs.toronto.edu/~mkolp/sbes.pdf -- язык для социальных паттернов (booking, subscription, call-for-proposal, bidding), паттернов медиации (monitor, broker, matchmaker, mediator, embassy, wrapper). Система для поддержки языка таких паттернов -- http://www.isys.ucl.ac.be/skwyrl/ и пример системы eMedia, сделанный с этим подходом -- http://www.isys.ucl.ac.be/skwyrl/emedia/Files/report.pdf. Booking паттерн -- http://www.cs.toronto.edu/~mkolp/seke03.pdf

Довольно много материала можно вытащить из хитрого запроса в Гугль, выдающего все, что лежит на сайте руководителя этой исследовательской группы http://www.cs.toronto.edu/~mkolp.

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

Я думаю, мы еще похлебаем разницу между объект-ориентированным антропоморфным подходом и агент-ориентированным подходом, в котором даже не требуется особо говорить про антропоморфность, это и так всем ясно. Нужно будет поразмышлять над всем этим. Все-таки агентщики долго думали над минимальными языками, в которых можно описывать организацию, цели, роли, планы и все остальное, что нам интересно. Что-то мне подсказывает, что в этом месте велосипед изобретать неправильно. А уж организационные паттерны в терминах этого базового языка мы предложим -- у нас опыт именно в этом, ужо насмотрелись у клиентов и начитались в книжках.
2019

Capabilities, полномочия, озадачивание Исполнителя, Начальник сам себе.

Как правило, знакомство с capabilities начинается с -- http://www.eros-os.org/essays/capintro.html (1999). Концепт в ходу с 1966 года, массовый переход на capabilities происходит только-только. Так, Second Life делает переход на capabilities прямо сейчас, в 2007 году, до этого у них была другая модель. Croquet имеет capabilities security в планах, но у них настолько отличающаяся от типовой архитектура, что этот переход они и сами не знают, как делать (http://www.croquetconsortium.org/index.php/Road_Map#CapabilitiesSecurity) и имеют его в low приоритетах (по сравнению с документированием уже наработанного ;)

Интересно, что в словарях перевода capabilities как "полномочие" отсутствует. Но это, конечно, общепринято.

Важно понимать, что capabilities используют отнюдь не только для обеспечения безопасности. Это общий дизайн-паттерн, который можно использовать для всякого, но чаще всего его используют именно в секьюрити.

Полномочия -- это отдельная сущность, а не свойство таска или исполнителя. Исполнитель может иметь полномочия, или не иметь их. Исполнитель может получить полномочия от другого Исполнителя, и тут уж можно разбираться -- в силу ли "проектного/продуктного менеджерства" матричной структуры управления, или в силу иерархии основной должностной структуры, или неформальной корпоративной культуры, дающей эту возможность "фамилиям", а не должностям. Формальная передача полномочий -- это и есть административная линия. Это и есть линия Вышестоящих.

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

На близкие темы написано тут: http://vvagr.livejournal.com/1029595.html

Интересно мы вчера обсуждали с meatreach про open source проекты, в которых ошибочно кажется отсутствует административная структура (власти и подчинения), и выглядит это как сплошные уговоры и влияние. В лучших проектах административная система вполне себе работает, даром что должности не называются "вице-президент" и оргструктура не может быть показана строгой иерархией. Но с capabilities там все в порядке.

Главная capabilities, которая нас волнует -- это вопрос о полномочии назначения таска (как особо волновался meatreach -- в том числе назначения таска самому себе, ибо это ковровая дорожка к паттерну Эрика Берна "Загнанная домохозяйка" -- "Женщина берет на себя все дела, которые попадаются под руку, и даже сама как бы напрашивается на новые занятия. Она соглашается со всеми замечаниями мужа и выполняет все требования детей. Если ей нужно устроить званый обед, то она чувствует необходимость сыграть роль не только Безупречной собеседницы, но и столь же Образцовой экономки и Распорядительницы, а также роли Художника по интерьеру, Шеф-повара, Обольстительной элегантной женщины и обязательно Дипломата. Более того, утром она решит испечь пирог и сводить детей к зубному врачу. В результате она не знает, за что хвататься, но все равно старается сделать свои день еще более сумасшедшим, поэтому к середине дня у нее есть достаточно оснований, чтобы выйти из строя и бросить все дела на произвол судьбы. Женщина в результате ставит в неловкое положение гостей, подводит мужа и детей, добавляя ко всем своим несчастьям еще и угрызения совести". Лечить это, конечно, нужно не по паттернам Эрика Берна -- он только хорошо описал проблему. Озаботиться же проблемами "самоозадачивания" в ходе разделения труда нужно. Люди не ангелы -- особенно если "общественное мнение" буквально подталкивает их взять на себя лишнее, причем добровольно и с громкой песней. Последствия -- крупные срывы, затрагивающие критическую цепочку).

Случай с самоназначением работ лишний раз говорит о том, что Исполнитель и Начальник -- это две разные роли, возможно одного и того же лица. Я не буду погружаться сейчас в рассуждения о том, что НазначениеТаскиИсполнителю -- это тоже работа, у которой есть Исполнитель, и она занимает ресурс этого Исполнителя. Меня интересует только одно: полномочия по ее проведению. Я даже готов обсуждать отдельно работу по ПланированиюНазначенияТаски и НазначениюТаски. Первое не требует полномочий (мало ли кто предлагает послать директора копать огородик!) а второе требует тех самых Полномочий.

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

Вот я и думаю, не поможет ли концепция capabilities разобраться с выражением этих полномочий по озадачиванию. Равно как агентские организационные языки, о которых я поминал в http://ailev.livejournal.com/490333.html

Это все очень, очень сырые мысли. Любая обратная связь приветствуется.