June 14th, 2009

2019

OMG, стандарты для организаций

Oh my god, я уже достаточно разобрался, чтобы проникнуться восхищением к тому, что делает OMG (http://www.omg.org). Мне кажется, что в организационном моделировании (business modeling) сейчас лидеры именно они -- несмотря на огромное количество конкурирующих подходов. Единственное, что меня напрягает, так это опора на UML-модели и удивительная запутанность принятого там мета-мета-мета-подхода с поминанием слова "модель" всуе по любому поводу, но и UML там не догма (судя по SBVR с ORM и CL представлениями), и даже мета-мета-мета необязательно 4-уровневые. В любом случае, они сейчас проделывают титаническую работу по получению нотаций, которые были бы понятны непрограммистам, но вместе с тем были бы формально точны для обработки их компьютером.

Какие интересные у них планы: http://www.omg.org/schedule/ -- чего стоит только dynamic business activity model. Одно из замечаний про все эти "бизнес-процессы" -- это то, что 80% времени коллаборации может уходить как раз на то, чтобы определить, что и как делать дальше. Это означает, что процессная часть много более динамична, чем могут себе представить аналитики, пытающиеся нарисовать оркестровку и хореографию заранее.

И отдельные группы тоже хороши, вот minutes архитектурной группы от 29 марта 2009г.: http://bawg.omg.org/BAWG-Wash_DC-2009_-Report.pdf. Как я понял, в задумке модель value chain, а также capability modeling, OSM планируют зафайлить как раз в июне, голосовать в сентябре. Что особо интересно, в планах есть засунуть в Организацию Initiative & Project (possibly Program). Как раз сейчас должна быть готова бумажка по Business Architecture Ecosystem -- как я понимаю, это вариант Enterprise Architecture в исполнении OMG. Крайне, крайне интересно.

Интересный тьюториал годичной давности по MOF 2 -- http://www.metadataopenforum.org/download.php?e0a71038c215efdbebc3c5a175134ca1. Подробненько разъясняется про M0-M3, разные значения слова "мета", а также поминаются разные штучки типа "class + object = clabject".

SPEM -- это будет ISO/IEC 27474.

ISO/IEC 42010 тоже обзывается метамоделью, за которой нужно внимательно смотреть (наряду с SysML, BPDM и IMM -- information management metamodel). Недаром я обращаю на этот стандарт такое внимание!

Учет как таковой -- ISO/IEC 11179 с кучей частей (тьюториал -- http://www.metadataopenforum.org/download.php?d359687e04386dba9ff4a65c856b4e27). Понятно, что в 11179-3 (MDR, meta data registry) тоже общая метаметамодель, хотя не MOF. Этих метаметамоделей куча (тот же Express, ORM, CL и так далее со всеми остановками).

Есть впечатление, что OMG ODM сознательно задумана для экспорта-импорта онтологий, и какой-нибудь транзит SBVR-ODM-OWL-15926 можно сделать на раз. А KDM служит для описания той самой "софтверной архитектуры", которую мы регулярно рисуем для одного из клиентов.

Почему именно у OMG лучшая enterprise architecture? Потому что
а) они активно сливают оркестровку с хореографией в одно нотационное целое, модель формальна и использует понятную человекам семантику ("А после Б, В во время Г"), а не "передачу токенов" или "машину состояний".
б) они разобрались с организационными нормами (business rules), причем про сами нормы только 13% спецификации, а остальное посвящено разборкам с терминологией в мультинациональных корпорациях. Крайне важно, что сюда попали те люди, что заботятся о понимаемости нотаций оргнормирования непрограммистами, а не отвязанные айтишники.
в) они не забыли про SPEM, что крайне важно.
г) они рассказывают, как все это положить на софт, хотя это и не самая интересная часть. С другой стороны, поглядите, как выглядит софт от активистов OMG -- http://www.knowgravity.com/eng/value/knowEnterprise.htm. Это ведь только начало!

Я думаю, что софт от PraxOS вполне может пойти по этому OMG-пути, только
а) генерировать будет не код, а настроечные файлы для разных и всяких систем (впрочем, для нынешнего программирования эти настроечные файлы и есть код, большей частью декларативный и в синтаксисе XML). Или даже не генерировать, а читать и позволять редактировать (это сейчас модно: знания извлекают из legacy-софта, прямо из настроек).
б) совершенно необязательно метамодель будет на UML. Все эти стандарты метамоделирования отлично мэппятся и на другие языки метаметамоделирования (надеюсь, я не перепутал число "мета" -- хоть эту четырехуровневость и сняли, но разговаривают все до сих пор в этих рамках M0-M3). Да и "модель" тут слово необязательное, бывают и другие метафоры для "мета" (прежде всего метафора языка и IDE). Тут я бросаю долгий и задумчивый взгляд на COLA и предлагаемые там механизмы работы с объектами, функциями, знаниями и абстрагирование синтаксиса.
в) будет учитывать гипотезу DEMO, что практически все процессы в организации являют собой хореографию, а не оркестровку. Люди не машины, по нотам играть не любят.
г) сможет работать с динамическими процессами (не нарисованными заранее, а получаемыми в коллаборации по ходу дела)
д) будет иметь "из коробки" готовые модели практик -- логистика проектов/процессов по Голдратту, построение деревьев результатов и действий, throughput accounting и т.д.
е) будет свободным софтом, пусть весь мир исправляет ошибки и делает плагины
ж) будет также и по-русски, и это самое трудное.
2019

Фемтошагами в будущее

SSD опустились ниже $3 за 1Гбайт (http://www.engadget.com/2009/06/10/ocz-intros-2-5-inch-agility-ssd-line-120gb-for-349-99/), OSZ выпустила 120Gb SSD за $349.99 -- с двухлетней гарантией.
* * *
Уже в маркетинговых текстах начинают появляться "японские технологии"-- но пока Гугль выдает их всего 138тыс.. Для сравнения: 643тыс. итальянских дизайнов, 207тыс. русского балета. Можно сравнивать и дальше: японский балет 6тыс., итальянский балет 9тыс., итальянские технологии 32тыс., русские технологии 66тыс. (всего вдвое меньше от японских -- выглядываю в окошко и сильно удивляюсь), русский дизайн 43тыс., японский дизайн 231тыс..

Из последних новостей японских технологий -- http://www.dpreview.com/news/0906/09061101casioexh10.asp, суперкомпакт суперзум (оптика со стабилизацией x10 с 24мм), который умеет снять 1000 кадров на одну батарейку. И все это счастье за примерно $400.

Или вот лампочка от Sharp с дистанционным управлением -- http://sharp-world.com/corporate/news/090611_2.html. Не так интересно, что лампочка с пультом, как то, что этим пультом можно настраивать, кроме яркости. Настраивать можно цветовую температуру. Потому как лампочка светодиодная. У нее 40тыс. часов службы при яркости 560 люмен, мощности 4Вт и цене от $40 до $82 (с пультом управления).
* * *
Жестовый интерфейс с телефоном в руке (писать телефоном по воздуху, http://synrg.ee.duke.edu/media.htm, используется датчик ускорения) -- это вчерашний день. Парень, который восхитительно хакал Wii (Johnny Chung Lee), был принят на работу "по профилю", в майкрософтовский project natal (http://www.engadget.com/2009/06/12/johnny-chung-lee-joins-project-natal-team-puts-wii-hacking-expe/). А кто не знает, что это за такой проект , поглядите коротенькое видео с демонстрашкой: http://www.latenightwithjimmyfallon.com/blogs/2009/06/kudo-tsunado-demos-project-natal/. Игровая приставка типа Wii, только без контроллеров вообще -- понимает пантомиму. Изобразите пустыми руками, что вы крутите автомобильный руль, и этого будет достаточно, чтобы управлять игрой-автосимулятором. Махните рукой, и этого будет достаточно, чтобы отбить в аркаде летящие в вас нарисованные мячики. Правда, Nintendo сознательно отвергла распознавание жестов камерой, когда выбирали контроллеры для Wii (http://www.engadget.com/2009/06/10/iwata-says-nintendo-tried-and-rejected-camera-based-motion-contr/), но ведь это не вся история.

Камера моего ноутбука смотрит сейчас прямо мне в лоб, хотя и выключена -- как и у многих миллионов других ноутбуков. Скоро (через два-три года) эта камера будет включена по умолчанию -- чтобы задействовать жестовый интерфейс. А еще года через три такая же камера начнет устойчиво распознавать микровыражения (http://en.wikipedia.org/wiki/Microexpression), оставаясь в том же сверхдешевом ценовом диапазоне. Тогда близкие нам люди покажутся бесчувственными чурбанами по сравнению с подчеркнуто внимательными компьютерами.
* * *
Опенсорс 3В-принтеры: http://www.makerbot.com/. Цена принтера в собранном виде $2500, а разобранном -- до $1000. Это не предел, вот http://3dreplicators.com/ -- Tommelise 3.0, Sampo, is a desktop factory that you can make with a very few hand tools for about $150-250. Once you've built it you can use it to make ... more or less anything, including another Tommelise. Строителей таких машин много -- http://builders.reprap.org/

Социальная сеть для 3D-графоманов любителей что-то эээ... напечатать -- http://www.thingiverse.com/. Блог про то, как это движение потихоньку развивается: http://blog.thingiverse.com/. Ребятки просто эээ... печатают свои 3D-принтеры, новое поколение на старом. Это все, конечно, вырастает из http://reprap.org, где сейчас эксперименты идут со скоростью печати -- http://blog.reprap.org/.

Копирайты, говорите? Патенты? Ну-ну, размечтались. У Cory Doctorow на этот счет есть пара страничек текста -- http://rapmanv3.blogspot.com/2009/05/print-crime.html

Это все, конечно, упрется в CAD -- и там тоже потихоньку идет работа. Вот, например: http://www.pythonocc.org/. Цель у этого проекта provide an easy-to-use, deploy, maintain and industrial quality python CAD package. Неважно, что python, важно что industrial quality.

А лет через десять они спроектируют и напечатают термоядерный реактор -- исключительно ради лулзов (http://lurkmore.ru/Lulz).
* * *
Четвертое состояние вещества (твердое, жидкое, газообразное, плазма) было использовано для лечения зубных инфекций -- http://www.physorg.com/news163903949.html. 100нс импульс раз в миллисекунду дает 2W расход энергии, и результат получается не слишком горячий -- зуб под такой импульсной плазмой нагревается на 5 градусов за 10 минут экспозиции.

Я считаю это не столько работой с плазмой, сколько продолжением работы со сверхкороткими импульсами. Так, предыдущая работа со сверхкороткими импульсами, о которой говорили буквально десяток дней назад -- это возможность чтения-записи в HDD на скорости в 100тыс. раз быстрее, чем сегодня: http://www.tomsguide.com/us/Laser-HDD-Read-Write,news-4028.html. Но там честно замечали, что фемтосекундный лазер, который при этом используется, сегодня размером 12"*4", что пока не для бытовых применений. Однако, лиха беда начало.
2019

Манифест организационных норм (The Business Rules Manifesto)

The Business Rules Manifesto (http://www.businessrulesgroup.org/brmanifesto.htm, 2003г., редакция Ronald G.Ross):

Статья 1. Первостепенные, а не второстепенные требования
1.1. Нормы -- первосортные граждане мира требований.
1.2. Нормы существенны для, и составляют отдельную часть организационных и технологических описаний.

Статья 2. Отдельно от процессов, не содержатся в них
2.1. Нормы являются явно выраженными ограничениями поведения и/или обеспечивают поддержку поведению.
2.2. Нормы не являются ни процессом, ни процедурой. Они не должны в них заключаться.
2.3. Нормы применяются поперёк процедур и процессов. Должен быть один связный набор норм, соблюдение которых единообразно во всех значимых областях деятельности организации.

Статья 3. Спланированное знание, не побочный продукт
3.1. Нормы строятся из фактов, а факты строятся из концептов, выражаемых терминами.
3.2. Тремины выражают организационные концепты; факты делают утверждения об этих концептах; нормы ограничивают и поддерживают эти факты.
3.3. Нормы должны быть явными. Ни одна норма не подразумевается для любого концепта или факта.
3.4. Нормы являются основным, что организация о себе знает -- то есть основное организационное знание.
3.5. Нормы должны быть взращены, защищены, управляемы.

Статья 4. Декларативные, не процедурные.
4.1. Нормы должны быть выражены декларативно в предложениях естественного языка для организационной публики.
4.2. Если что-то нельзя выразить, то это не норма.
4.3. Набор утверждений декларативен, только если он не имеет подразумеваемой последовательности.
4.4. Любые утверждения о нормах, что требуют описателей иных, чем термины и факты, подразумевают предположения о реализующей их системе.
4.5. Норма отлична от любого определенного для нее принуждения к исполнению. Норма и ее соблюдение -- разные соображения.
4.6. Нормы должны быть определены независимо от ответственности за кто, где, когда или как их будет соблюдать.
4.7. Исключения к нормам определяются другими нормами.

Статья 5. Хорошо сформулированные выражения, не как придется.
5.1. Организационные нормы должны быть выражены таким способом, что они могут быть валидированы на правильность людьми из организации.
5.2. Организационные нормы должны быть выражены таким способом, что они могут быть верифицированы на непротиворечивость друг другу.
5.3. Формальная логика, такая как логика предикатов, является основой для хорошего формулирования норм в терминах организации, равно как для технологий, которые реализуют организационные нормы.

Статья 6. Нормо-ориентированная архитектура, не косвенная реализация
6.1. Организационно-нормативное приложение намеренно построено, чтобы приспособиться к непрерывным изменениям в организационных нормах. Платформа, на которой работает приложение, должна поддерживать такое непрерывное изменение.
6.2. Выполнение норм непосредственно -- например, в нормовом "движке" -- реализационная стратегия, которая лучше по сравнению с перепиской норм в какую-то процедурную форму.
6.3. Организационно-нормативная система должна всегда быть способна объяснить рассуждение, по которому она пришла к заключению или предприняла действие.
6.4. Нормы базируются на истинностных значениях. Как истинностное значение нормы определяется или обрабатывается является скрытым от пользователя.
6.5. Отношение между событиями и нормами в общем случае "много-ко-многим".

Статья 7. Направляемые нормами процессы, не основанное на исключениях программирование
7.1. Нормы определяют границы между приемлемым и неприемлемым организационным действием.
7.2. Нормы часто требуют специальной или избирательной обработки замеченных нарушений. Такие действия по нарушениям норм являются действиями подобными любым другим действиям.
7.3. Чтобы обеспечить максимальную непротиворечивость и повторноиспользуемость, обработка неприемлемых организационных действий должна быть отделена от обработки приемлемых организационных действий.

Статья 8. Ради организации, не технологии
8.1. Нормы -- это про организационные практики и руководства; поэтому нормы мотивируются организационными целями и задачами и формируются под разными влияниями.
8.2. Нормы всегда что-то стоят организации.
8.3. Стоимость принуждения к выполнению норм должна быть сбалансирована относительно организационных рисков, равно как и организационных возможностей, которые в противном случае могут быть потеряны.
8.4. "Больше норм" это не лучше. Обычно меньше "хороших норм" лучше.
8.5. Эффективная система может основываться на малом числе норм. Вдобавок, более уточняющие нормы можно добавить потом, так что со временем система станет умнее.

Статья 9. От, через и для людей организации, не айтишников
9.1. Нормы должны появляться от знающих людей организации.
9.2. Люди организации должны иметь доступные инструменты, чтобы помочь им сформулировать, валидировать и управиться с нормами.
9.3. Люди организации должны иметь доступные инструменты, чтобы помочь им верифицировать организационные нормы на непротиворечивость друг ко другу.

Статья 10. Управляя организационной логикой, не аппаратно-программными платформами
10.1. Организационные нормы являются важным организационным имуществом.
10.2. В долгосрочной перспективе, нормы более важны для организации, чем программно-аппаратные платформы.
10.3. Организационные нормы должны быть систематизированы и храниться таким способом, чтобы быть готовыми к переводу на новую программно-аппаратную платформу.
10.4. Нормы, и возможность их изменять эффективно, являются основополагающими для улучшения организационной адаптируемости.
2019

Организационная семиотика и нормы

Организационная семиотика -- в целом ничего интересного, но вот явное пересечение с миром business rules: http://www.orgsem.org/2009/pictures/PPTs/4-12/keynote%20Speeches/The%20Chemistry%20of%20Society---Organisational%20Semiotics%20as%20an%20Empirical%20Social%20Science.pdf. Это keynote с конференции 2009г. (http://www.orgsem.org/2009/index.html). Основная идея -- попробовать определить объект организационной семиотики так, чтобы получить эмпирически фальсифицируемую науку. Для этого он предлагает сделать то же самое, что сделали авторы SBVR: в одну упаковку сложить гипотезы и теории как для знаков (собственно семиотику), так и для норм. Вот гипотезы, которые им сформулированы насчет норм, и которые он надеется проверить эмпирически:
H1: signs only create value when people’s attitudes change
H2: attitude changes are governed by norms shared across a community
H3: all norms exhibit a common structure: IF subject UNDERSTANDS THAT condition OBTAINS THEN subject ADOPTS attitude TOWARDS object
H4: an organizaton can be specified by its norms

[и так далее, включая, например,]

H10: knowledge ≡ norms
Там есть и рассуждения про 4D-онтологии в применении к нормам и агентам (ибо нормы меняются, причем теми же агентами, которые их потом выполняют -- что требует каких-то онтологических мер безопасности в формальных рассуждениях).

Там есть и практический выход: метод извлечения требований MEASUR -- http://www.orgsem.org/sedita.htm (в Сети на эту тему можно много чего найти). "Информационное поле" вместо "информационного потока", круто. И вывод: вместо технического анализа потока анализировать человеческие аспекты. Как я понимаю, просто от перехода к декларативным представлениям от процедурных айтишники со своими процедурными "прямоугольниками и стрелочками" отрубаются, и далее можно спокойно разговаривать с простыми людьми, которые вполне поддерживают декларативный разговор. Остается только разобраться, как декларативные представления (ежели речь идет о рефлексивных и интроспективных системах) разбираются со временем -- но этими 4D-онтологиями (по сути, эти "онтологии" и есть декларативный способ изложения картины мира, включая процессы) сейчас не озабочен только ленивый и дремучий онтолог.

Кстати, Terry Halpin (автор ORM) как раз закончил серию публикаций по temporal modeling -- http://www.brcommunity.com/halpin.php. Почитав это все, понимаешь, что процессы все-таки лучше изображать и обсуждать в специально для этого предназначенных процедурных языках (типа того же BPMN), и иметь средства мультипарадигмального отражения картины мира. Далее опять см. проект COLA/STEP/IDS/FONC...
2019

Организационные нормы и организационные требования

По материалам http://www.brcommunity.com/b290.php:
  • Организационные нормы -- это списки утверждений, которые говорят вам, можно или нельзя что-то сделать, или дают критерий и условия для принятия решения.

  • организационные требования -- это что вам нужно, чтобы обеспечить усвоение и выполнение этих норм.

  • Может быть множество различных организационных требований, чтобы люди усвоили или были принуждены к выполнению организационных норм.

  • Организационные нормы -- это то, что они есть. Они не должны изменяться, чтобы удовлетворить организационным требованиям.

  • Изменение в норме может означать различные или дополнительные требования.
Например, норма "клиент должен иметь email" имеет поддерживающее требование "возможность ввести адрес клиента". Это требование легко реализуется предоставлением нужного поля в графическом интерфейсе. При небольшом изменении нормы "клиент должен иметь Правильный email" потребуется ввести еще одну норму "email должен считаться Правильным, если посланное на него письмо не вернулось в течение часа". Дополнительное организационное требование: возможность немедленно послать письмо клиенту, после получения его адреса. Изменение одного слова в норме приводит к изменению и появлению дополнительных требований.

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

Это все разговор про организацию, а не про IT. Чем отличается разговор про организацию от разговора про IT? Пример (из http://www.brcommunity.com/b467.php):

Business rule (based on SBVR-RuleSpeak):                   

A discount of 15% must be applied on the shopping cart if the shopping cart contains between 2 and 4 items and one of the following conditions are met:     -  the purchase value is greater than $100 and           the customer category is gold     -  the purchase value is greater than $200 and           the customer category is silver

IT rule (based on PRR-OCL):

Rule discount ruleVariable:   ?customer: Customer = Customer->any()   ?shoppingCart: ShoppingCart = ShoppingCart->any(c: customer | c=?customer) Condition:   (?shoppingCart.containsItemsInRange(2, 4)   and     (((?shoppingCart.items->collect(i:Item|i.value))->sum()>100 and           ?customer.category == "Gold")     or ((?shoppingCart.items->collect(value))->sum() > 200 and       ?customer.category == "Silver"))) Action: shoppingCart.discountValue = shoppingCart.discountValue+15

Это основная разница: организационное правило для людей из организации, т.е. на человечьем языке (для верности controlled natural language -- это немалая проблема получить такое для русского), а business rule -- это традиционный способ айтишников указать на важность чего-то для их клиентов, добавляя слово "бизнес" к любым сущностям (например, "бизнес-процесс", "бизнес-приложение", "бизнес-требование", и, конечно, "бизнес-правило").

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

С другой стороны, вся эта терминология "норм" и "требований" существенно пересекается с requirements engineering, и тут придется повозиться, чтобы хоть как-то унифицировать организационные разговоры в рамках organizational engineering и "инженерные" разговоры в рамках system and software engineering. К тому же что для одних требование, для других -- норма, и эти "мета" тоже нужно учитывать.

Решение одних проблем всегда порождает другие, хотя и на новом уровне. С концепцией организационных норм все то же самое.