Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Categories:

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 и т.д.
е) будет свободным софтом, пусть весь мир исправляет ошибки и делает плагины
ж) будет также и по-русски, и это самое трудное.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 4 comments