Я сам голосовать не иду: что толку крутить ручку, которая никак с исполнительным механизмом не связана?! А символические связи меня не волнуют, я ведь не религиозен и в ритуалы подобного сорта не верю (подробности про ритуальность выборов -- http://kuznetsov.livejournal.com/104425.html, я расхожусь с автором этого текста только в том, что само христианство и прочие мировые религии я считаю тоже язычеством, только версии 2.0).

У меня про выборы только два вопроса, и оба про то, что правды ждать вообще неоткуда:

1. Многие школы в понедельник будут отмываться от выборов -- в буквальном смысле (http://vvagr.livejournal.com/1685393.html). В нашей школе выборов нет, но понедельник таки будет выходым. Вот какую бумажку приклеили дитёнку в дневник: "Уважаемые родители! Во исполнение приказа Департамента образования города Москвы от 22 ноября 2011 года №912 "Об организации образовательного процесса в государственных образовательных учреждениях города Москвы в период ограничительных мероприятий по гриппу и ОРВИ в 2011-2012 учебном году", в соответствии с СП 3.1.2.1319-03, письмом Управления Роспотребнадзора по городу Москве от 21.11.2011 года №17-06-03/615 и приказа начальника управления образования центрального округа В.И.Лопатиной от 24.11.2011 № 1519 информируем Вас о том, что 5 декабря 2011 года (в понедельник) в нашей школе -- "День здоровья", дети не учатся. Учащиеся в этот день пребывают дома, выполняют задания, которые задали учителя на дом, проводят профилактические мероприятия по предупреждению ГРИППА (по усмотрению родителей). Выход в школу -- 06 декабря 2011 года".

Речь, конечно, не о выборах, просто дети должны будут сидеть дома и проводить "профилактические мероприятия по предупреждению ГРИППА (по усмотрению родителей)".

2. В ЖЖ выполнили "принуждение к дню предвыборной тишины". Будут ли продолжать ддосить Живой Журнал и после выборов? Хотя официально выборы тут не при чем, просто чистое хулиганство, никакой политики! ЖЖ, скорее всего, поднимется уже после подсчета голосов -- тоже ведь будет проводить профилактические мероприятия по предупреждению компьютерного ГРИППА (по усмотрению менеджмента). И Коммерсантъ тоже будет сидеть дома лишний день, разве что мы в его случае номера письма и имени чиновника не знаем...

С понедельника начнется неделя образования по информатике -- разные люди из 130 стран с 4 по 10 декабря 2011 года будут пропагандировать важность computer science в школьных и вузовских образовательных программах, уговаривать чиновников обратить на это внимание (а то и деньжат подкинуть), обмениваться опытом преподавания, проводить олимпиады и прочие соревнования для школьников и студентов и т.д..

К этой неделе делается много полезного и интересного. Вот, например, американский вебсайт этой недели составил список образовательных ресурсов по информатике: http://www.csedweek.org/resources (очень интересный, кстати, список).

Мой личный план в рамках мероприятий этой недели:

1. Приму участие в научно-практическом семинаре "дошкольная алгоритмика". Особо обращу внимание, что в мире дошкольной алгоритмикой вообще мало кто занимается -- это фронтир. Сначала алгоритмике нигде не учили, затем учили только в ВУЗах, затем в старших классах, а теперь уже и в средней школе. Я тут не имею ввиду те задачки "рассортируй птичек и рыбок на две кучки" и "какой предмет лишний на этой картинке", которые сейчас выдают за информатику для младшеклассников. Я тут имею ввиду написание настоящих программ, в которых есть и циклы, и условия, и подпрограммы с параметрами. Так что это будет вполне себе фронтир. Кстати, я в 2009г. уже писал про Михаила Долинского и его школу программирования для младшешкольников со слоганом "программировать раньше, чем читать!" -- они вполне себе работают, и тоже тем самым находятся на фронтире: http://dl.gsu.by/NForum/forum/list/16.dl

2. Буду заниматься с собственным сыном-третьеклассником -- на сегодня осталась последняя задача 14 урока, а на "образовательной неделе" начнем решать задачи 15 урока курса http://server.179.ru/wiki/?page=DenisKirienko/Kumir

3. Сделаю постинг о том, как учить премудростям ISO 15926, это ведь тоже информатика.

Это ответ на коммент ttfna в треде http://ailev.livejournal.com/965124.html?thread=9717252#t9717252 к моему постингу про четыре поколения перехода от документ-центричности к датацентричности. Получилось много, и в коммент не поместилось. Собственно, я всё это уже в разное время у себя в ЖЖ писал -- разве что разноски по поколениям не делал.

1. Многие современные как гибридные, так и датацентричные PLM (системы product lifecycle management) используют всё то же самое, что ECM (enterprise content management), по факту используемые в крутой документоцентрике -- наличие "объектов" в них не является критерием отличия. Я бы сравнивал современные ECM с более ранними PDM (product data management) системами, где самое важное было как-то управляться с многочисленными файлами разной природы -- понимая при этом, что физическое представление "файла" не так важно, как его "объектная" сущность и поэтому собственно работа ведется с "карточками" этих файлов -- а сами эти карточки вполне себе "объекты".

2. Как в ECM и PDM, любые современные PLM имеют какой-нибудь item с атрибутами и associations/relations этих items в основе, поддерживающая наследование и прочие прелести объект-атрибутной модели. Никакой предметной области нет, кроме просто развитой работы с данными. Эта объект-атрибутная модель опирается на какую-нибудь реляционку под ними -- все они "нашлёпки" над каким-нибудь Ораклом.

3. Но далее в PLM уже над items строится некоторая (у кого более богатая, у кого менее богатая) онтология, которая подразумевает мэппинг структур данных на объекты реального мира: фишка не в том, что довольно быстро в этой модели мира мы выходим на "оборудование", важное для PLM, а в том, что сама эта модель мира начинается с thing (почувствуйте разницу с item!) и принципиально расширяема в этой описывающей мир, а не описывающей структуры данных части -- причем "из коробки". В отличие от ECM настройка на предметную область производится не только разработчиками "плагинов" (это тоже есть), но и предварительно в PLM существует уже некоторая связная модель инженерного мира.

4. В этих PLM опять же "из коробки" даны слитые воедино модели данных/онтологии разнопредментых authoring tools, это нормальный стиль. Эти разные модели данных принципиально сливаются в одну модель данных, что гарантируется общей онтологией, а не общей схемой данных из items и relations.

5. Эта архитектура была выработана после того, как выяснилось, что работа с plugins как в ECM (это было в ходе разработки стандарта STEP, закончившейся не "единым языком инжиниринга", как предполагалось, а кучей application protocols для разных предметных областей) не гарантирует, что модели данных всех эти plugins сольются в одно красивое целое -- если при этом не основывать все эти предметные модели данных на беспредметной общемировой (еще раз повторюсь: "беспредметная модель данных" моделирует мир -- вещи, время, пространство, отношения, свойства, атомы, молекулы, живое-неживое и т.д., что нельзя путать с абсолютно другой природы айтемами, записями, атрибутами, объектами и прочими формализмами данных).

6. Конечно, уже начинаются интересные примеры, как из разных ECM пытаются делать PLM: для этого берут огромного размера рашпиль и доводят более-менее удачную ECM до состояния PLM -- например, это произошло с MatrixOne и Enterprise Bridge после их приобретения разработчиками САПР. Но это переход в уже другой класс систем, и фишка в существенной доработке модели данных -- т.е. огромный объем программирования как раз в терминах этих айтемов и записей, но этот объем программирования выполняется еще до всяких там "плагинов", как раз для того, чтобы потом данные самых разных заранее даже неизвестных еще плагинов слились в одну информационную модель. Это совсем другой стиль, нежели обычная работа с плагинами в ECM.

7. Именно необходимость объединять данные разных предметных областей и authoring tools ставит запрет на использование объект-атрибутной модели: что для одного authoring tool объект, для другого authoring tool атрибут. Отсюда и переход к факт-ориентированной модели, в которой все те же фрагменты мира выражаются в формализме классов (теории множеств), а не в субстанциональной аристотелевской парадигме объектов-свойств.

8. Люди из мира PLM, естественно, знают про происходящее в мире ECM, идиотов-то сейчас нет. Другое дело, что они когда-то сами таким занимались -- но ввиду много бОльшей сложности их задач они пошли дальше.

9. Масла в огонь подливает то, что ECM и связанный с ними MDM обычно внутрикорпоративны, а вот для PLM обычно данные и справочные данные должны быть отраслевыми -- проекты выходят далеко за границы любой инжиниринговой компании, и с самого начала архитектура и способы работы должны поддерживать работу комьюнити. Именно поэтому ISO 15926 сразу подразумевает для интеграции данных использование федерации библиотек справочных данных, а не "корпоративное решение MDM".

10. Файл, конечно, не эпицентр современных ECM -- но так уж получается. То есть потенциально современные ECM могут быть использованы не как средства второго поколения (где главное -- это обеспечивать ссылки на файлы из паутины классификаторов), а средства третьего поколения (где главное -- это поддержание модели предметной области, из которой уже и идут ссылки на "первичку"). Но модели предметной области, где задействованы ECM получаются жидковаты. Мы в 1998 году затеяли разработку онтологического движка Communiware, это как раз была попытка сделать ECM с отрывом от файлов -- ибо мы целились на рынок интернетов и интранетов, где важны были не столько файлы, сколько статьи, постинги, комментарии, рубрики и прочие нехитрые предметные сущности. Мы сделали онтологический движок, и на нём нехитрую обобщенную модель того самого веб-контента. На этой совсем нехитрой модели всё и закончилось, ибо при выходе на хитрые модели потребовалось бы принимать абсолютно другие архитектурные и онтологические решения. На этом же заканчивается сейчас "семантик веб": множество нехитрых онтологических моделей отнюдь не слипаются в полноценную хитрую модель куска реальности. Финансовые модели мира -- при всём к ним уважении -- оказываются много менее хитрыми, нежели модели продукции, достаточные инженерам для производства. Инженерам потребовалось двадцать лет для осознания этого факта неслипания их моделей данных в ходе работы разных консорциумов и групп по стандартизации (прежде всего -- консорциума EPISTLE) и необходимости поэтому использования какой-то общей верхнеуровневой онтологии для разных authoring tools.

11. Итого: ECM обычно относятся ко второму поколению крутой датацентрики, ибо несмотря на всю их пригодность к вышиванию на них крестиком сложных моделей данных никто этого не делает. PLM как раз "из коробки" содержат весьма сложные схемы данных инжиниринга, и поэтому относятся к третьему (гибридному) и четвертому (датацентрическому) поколениям.

12. Я ожидаю, что пятое поколение -- это будет про федерацию датацентричных систем.

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

1. Электронная бумага. Бумажная бумага в ассортименте форматов, растровые сканы документов (хорошо, если .pdf -- но часто бывают и .tiff), штрих-коды на бумаге как высшее достижение цивилизации, в компьютерах реестры документов, попытки распознавать сканы обламываются на том, что бывают самые разные authoring tools кроме Ворда -- хотя я слышал, что уже некоторые типы чертежей тоже умудряются распознавать. Все ругают такие системы, все от них избавляются. Это наше радостное настоящее.

2. Электронный инженерный документооборот. Документ -- это всегда электронный документ в формате authoring tool. Если это чертеж, то это электронный чертеж со всеми связями и атрибутами. Если это текст, то это вордовый документ. Если это P&ID диаграмма, то это она. В проекте много-много таких документов. Документ = файл. Система хвастается, что ей все форматы нипочём, и в ней есть смотрелки для всех форматов. Ведет "любое количество классификаторов для любого числа типов документов". Документоцентрика в чистом виде, апофеоз и апофигей. Это то, что многие "внедряют" прямо сейчас -- светлое завтра сегодняшних проектов.

3. Гибридные системы. Очень хочется иметь какую-то навигацию и визуализацию упрощенной (чтобы хоть как-то проворачивалась в маломощном компьютере) информационной модели, а затем переходить уже к полным документам. То есть у нас есть маленькая базка данных с упрощенной информационной моделью, где плотно перевязаны данные из разных authoring tools -- но основной объем информации в электронных документах, как в обычном электронном инженерном документообороте. Документы тут являются "первичкой", а базка данных -- как бы "выпиской" из документов. Лет десять назад это были самые передовые системы! То есть и документы есть от десятка разных authoring tools, и вроде как "датаориентированность" появляется -- в той мере, в какой эти authoring tools могут ее обеспечить. Беда в том, что authoring tools кладут в свои документы много меньше, чем знают. И при любых усилиях базка данных информационной модельки остаётся базкой модельки, не более -- при всех заклинаниях про "датацентрику" это поколение гибридно по своей сути. Полную же информационную модель ни выколупать из authoring tools, ни перевязать между собой, ни гранулировать разным образом (кроме как в момент выгрузки из этих tools в виде документов) нельзя. Гибридные системы -- это те, что собираются освоить в будущих проектах.

4. Датацентричные системы. Намаявшись со своими гибридами, некоторые разработчики PLM сделали страшное: они объявили базу данных информационной модели "первичкой", потребовали перевязанности всей информационной модели разных authoring tools с самого начала и на этом основании заставили работать authoring tools прямо с общей для всех базой данных (а не каждый со своей собственной, как в предыдущих поколениях). Это означало резкий отход от привычных форм работы: документы стали выписками, они привязывались к информационной модели (первичке), а не информационная модель привязывалась к ним. Недостатки этой архитектуры являются продолжением достоинств: привыкшие к документам люди страшно теряются -- в базе данных нет листов, томов, к ней неприменимы ГОСТы документоориентированной разработки, в полной растерянности ориентированные на документы технадзоры (хотя им выгружают тонну выписок -- и они тоже становятся довольны), трудно юридически обосновывать "кому сидеть", невозможно цеплять authoring tools старых поколений -- ведь они тоже документоориентированы! Это не вполне еще отлаженное будущее сейчас осваивают только "лидеры рынка", а остальные в благоговейном ужасе к нему готовятся -- от датацентрической судьбы-то не уйдешь, гони ее сегодня хоть в дверь, она завтра всё одно влетит в окно.

У меня ко всему этому только одна претензия: не нужно гибридным системам говорить о том, что они полностью датацентричны, а электронному инженерному документообороту произносить какие-то слова про ISO 15926. Каждый сверчок пусть знает свой шесток. Управление технологиями должно происходить осознанно -- при всём понимании, что лучшая система предыдущего поколения может оказаться лучше и худшей системы следующего поколения по огромному числу характеристик. Но вот лучшие системы этих поколений обычно и сравнить-то уже нельзя, разница очевидна -- если, конечно, знаешь на что смотреть.

А скандальчик с трансмутацией никеля в медь в присутствии высокой температуры и водорода продолжается, не утихает. Основная интрига: греческая Дефкалион обвинила Росси в том, что у него технология работает неустойчиво, и что разрыв контракта произошёл по инициативе Дефкалион, когда Росси не смог продемонстрировать работу реактора 48 часов, а продержался только 24 часа. А теперь у Дефкалион технология сильно лучше, чем у Росси, и они обгоняют его на год (описывая технические детали того, за счет чего у Росси всё плохо -- зона тепловыделения была у него в центре трубки, а не по всей длине!). В ответ Росси говорит, что ему в кайф работать с опытным техническим специалистом-теплотехником, которого ему дал "неназываемый заказчик" (и уже понятно, что заказчики тут -- военные) -- и вот как раз сейчас у них там произошел технический прорыв, и они понимают уже, как не только тепло генерировать, но и обеспечивать генерацию электричества.

Сегодня очередная серия этой эпопеи: Дефкалион раскрыла спецификацию своего продукта, который обещают выпустить на рынок в 2012г. -- http://www.defkalion-energy.com/files/Press_Release_30Nov2011_Praxen_Defkalion_Green_Technologies.pdf

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

Пять минут назад там была только одна запись по этому поиску -- http://blogs.yandex.ru/search.xml?text=%22liviejournal%22 -- а сейчас уже много. И хоть бы кто написал, как лечить. Рестартом моей мозиллы это почему-то не лечится...

UPDATE: понятно, что произошло -- спамовый коммент, в нем фрагмент кода.
UPDATE2: как-то самовылечилось -- даже не понимаю, от каких моих действий...

Сегодня проводил семинар по Архимейту, вот слайдомент:

Понедельник-вторник (28-29 ноября) я опять в Нижнем Новгороде, а вот в среду 30 ноября уже в Москве прочту небольшой доклад на семинаре IBM по капитальному строительству (www.ibm.com/events/11ecmr). Поскольку формат предполагает слайды, то я их даже сделал (хотя я уже несколько лет предпочитаю разговаривать с людьми при помощи флип-чарта, формат подобных "семинаров" почему-то предполагает слайды -- и лучше дать такой слайдомент, чем просто проигнорировать вопрос о слайдах. Эти мои слайдоменты полезны прежде всего тем, что люди потом будут искать по ним материалы в Яндексе и Гугле: всё ж лучше, чем записывать слова со слуха -- флип-чарта-то на таких семинарах обычно не бывает):

Если поискать в Гугле.ком "партия жуликов воров", то правильный вебсайт (официальный "Единой России") выдаётся первой же ссылкой. А Яндекс на такой же поиск выдаёт первой ссылку на порносайт.

Это у Яндекса бага или фича?

Увы, современные информационные технологии зачастую поддерживают не суть дела, а только форму дела. Форма дела обычно заключается в том, что принятое каким-то чудом в результате сущностной содержательной работы решение, изложенное по всей форме проходит цепочку согласований и утверждений. Согласования и утверждения видимы для информационной системы и менеджеров, а содержательный ход дела -- невидим. Даже инженеры, когда дело доходит до айтишных систем, теряют свой инженерный нюх и обсуждают только административные аспекты -- утверждения уже известного, изменения уже понятного и т.д.. Именно на этой подмене сути дела формой дела и процветают системы процессного управления с их длиннющими цепочками последовательностей операций (каждая из которых обозначает не столько саму сложную работу, сколько факт утверждения полученных результатов этой работы). Если задумываться, что как поддержать содержательную работу, а не утверждение ее результатов, то неизбежно приходишь к необходимости ввести понятие кейса (а не документа), изменить границы кейса (момент открытия кейса оказывается гораздо раньше, чем момент начала согласования), и поддержать коллективную работу над кейсами не системой документооборота (а хоть и инженерного документооборота), а системой класса adaptive case management -- в которой многие действия можно проводить не согласно заранее спланированным регламентам, а по мере возникающей содержательной необходимости.

Вот только несколько примеров из моей практики:

1. Обычно правление крупных компаний разделяется примерно поровну, когда я задаю ключевой вопрос по выбору системы документооборота: вам нужно, чтобы всегда формально знать, кто виноват -- или вам нужно обеспечить продуктивную работу? В первом случае вам нужна именно система документооборота, и она автоматически попадает в ведение канцелярии, которая драконовски нагибает всех на выполнение ГОСТов делопроизводства. Во втором случае вам нужно ставить issue tracker (самая распространенная форма groupware для промышленной коллаборации -- предыдущее поколение адаптивного управления кейсами). В первом случае у вас всё будет юридически корректно задокументировано, и соблюдены все регламенты. Во втором случае работа будет идти не столько по регламентам (хотя и это возможно), сколько по уму -- ибо отнюдь не вся работа умещается в регламенты.

Обращу особое внимание, что даже не все знают про использование issue trackers как систем управления процессами -- а ведь они не только могут выполнять пересылки и уведомления, определенные в design time, но и делать то же самое в runtime (да еще и хитрыми способами -- не только push, но и подписками/pull). Новые поколения issue trackers интегрируются с wiki, системами управления конфигурацией/ведения версий (в случае САПР такое объединение называется PLM-системой), системами проектного управления и учета времени и т.д.. Но это не канцелярский документооборот, которого не интересует содержательное решение вопроса (и тем самым привлечение к issue/case самых разных людей, итерации, эксперименты, дополнительные совещания и прочее, что не отражено ни в одном регламенте), а интересуют только предписанные в design time визы.

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

Системы управления жизненным циклом можно рассматривать двояко: как системы, позволяющие отследить инженерную коллизию, и далее поддерживать работу с ней вплоть до формулирования снимающего коллизию инженерного решения и последующего утверждения этого решения в составе инженерного базиса (baseline) -- или просто как системы, которые формально проводят заранее предписанные ГОСТами согласования. Разница тонкая, ибо в какой-то момент инженеры начинают думать не в терминах своих инженерных систем, а в терминах подписываемых ими бумаг -- далее весь содержательный разговор и все содержательные обмены информацией происходят абсолютно неподдержанные софтом ("на коленке"), ибо софт в силу самой постановки задачи поддерживает только подписание бумаг.

3. Обсуждение ППР (плана производства работ) сооружения, получаемого по технологии Multi-D на последнем заседании Русского отделения INCOSE (http://incose-ru.livejournal.com/31246.html). Как и в предыдущих случаях, столкнулись два разных рассмотрения: административно-бюрократически речь идет о разработке ППР как документа со многими подписями, а потом внесение в этот ППР четко согласованных изменений (полагающихся готовыми к тому моменту, когда их начнут согласовывать). Но ведь есть и содержательное инженерное рассмотрение, при которой ППР сначала разрабатывается, а потом непрерывно приводится в соответствие с жизнью. Эти два взгляда вполне совместимы, если непрерывно актуализируемая модель производства работ время от времени выплёвывает бюрократам выписки, которые они затем утверждают в полном соответствии с их старинными бюрократическими правилами бумажной работы. Бюрократов ведь не волнует, из какого сора получаются те документы, которые они потом согласуют -- а инженеров как раз интересует поддержка способа, которым они эти документы для согласования производят. Ибо нет способа -- нечего оказывается и согласовывать. Ужас в том, что ход получения начального согласовываемого документа в знаниевой работе чрезвычайно похож на согласование и редактирование в ходе согласования -- но айтишники не поддерживают общение инженеров, они поддерживают только общение инженеров с начальниками.

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