Опора на события: глаз лягушки в моделировании предпринятий
Из чего состоит предпринятие? Если грубо и с минимумом деталей, то из команды, работы, технологии, которые реализуют возможность обеспечить стейкхолдерам определённое воплощение целевой системы(подробности такого рассмотрения в http://ailev.livejournal.com/1159110.html, а ещё больше подробностей в учебнике http://techinvestlab.ru/systems_engineering_thinking):
При моделировании предпринятия мы (в зависимости от превалирующего интереса к технологии, работе или команде) можем выбрать три различных подхода к описанию его деятельности, с акцентами на:
-- метод/технологии деятельности,
-- на выполняемые работы
-- договорённости о разделении труда в команде
Эти же три варианта в Cordys (2008), "Response from Cordys to the OMG Dynamic Business Activity Modeling RFI" называют
-- artifact-based (поскольку альфы/рабочие продукты важны для описания практик),
-- activity-based (процесс или проект как последовательность работ),
-- communication-based (коммуникация о поручениях работы между членами команды).
Wang, J., et al. (2005), "A framework for Document-Driven Workflow System" эти же три варианта называют
-- information-based (поскольку не на заводах рабочие продукты в основном это информационные объекты),
-- process-based (развёртка во времени, последовательность работ),
-- organization-based (полномочия членов команды, разделение труда -- это и есть суть организации, пример такого подхода DEMO, http://ailev.livejournal.com/644440.html).
Системный подход говорит, что нам потребуется отмоделировать и практики, и процессы, и команду. Но с чего начать? Что взять за основу? Практики/технологию, процессы/проекты, или команду/оргструктуру?
Мы рекомендуем за основу брать описание практик, следование которым в работе изменяет продукты. Удобней начинать описание практик с альф, а не с рабочих продуктов -- нас интересует в практике прежде всего описание дисциплины, предметной области, абстрагированное от рабочих продуктов. Хотя и технология тоже интересна, в этой части мы описываем какие рабочие продукты выражают альфу. Опора на дисциплину, а не сразу на технологию экономит мышление: по подсчётам команды Essence одна альфа в среднем выражается 6-10 рабочими продуктами!
Но деятельность не состоит только из рабочих продуктов! Деятельность-то разворачивается во времени, а это процессный аспект! Куда мы денем процессы при описании деятельности? Мы будем учитывать изменения продуктов во времени, но не как в процессном подходе -- не указанием последовательности работ. Это даст нам возможность выполнять работы не друг за дружкой в заранее запланированном порядке, а планируя эти работы в зависимости от ситуации (в том числе используя для ускорения планирования и уменьшения ошибок планирования и учёта выполнения планов информационные системы).
Мы учтём разворачивание деятельности по изменению продуктов во времени через описание смены их состояний -- нас интересуют события, происходящие с альфами.
Мы будем смотреть на предпринятие как лягушка: она видит хорошо только движущиеся предметы. Альфы/продукты увидеть трудно, но легко заметить их важные изменения -- достижения ими каких-то состояний. Если начинать с хорошо заметных важных событий ("поверхность чиста", "деньги пришли", "команда сработалась"), то много легче затем выйти на полноценное моделирование всех других объектов. И это продукт-ориентированный подход, как ни странно.
Событие -- это вполне себе "продукт", это срез мира (или одного продукта, или группы продуктов) в момент изменения состояния. То есть событие это вещь/продукт/альфа/artifact, но в какой-то совершенно определённый момент времени -- момент, когда одно состояние сменилось другим (последний момент предыдущего состояния или первый момент следующего -- смотря как сформулировать). Состояние, конечно, должно быть таким, чтобы мы могли вполне определённо узнать о его смене. DEMO говорит об этом как о координационных фактах (смену состояния должен выразить стейкхолдер -- события "поручил", "обещал сделать", "сделал", "принял", "разрешил" и т.д.) и производственных фактах (изменение состояний продуктов).
Смена состояния обеспечивается работами, но состояния формулируются как желаемый результат работ (состояние мира, определяемое чеклистом, а хоть из одного пункта), а не ведущей к достижению состояния работой: помним разницу между "учил" и "выучил" -- "учил" это про выполненную работу, а "выучил" про достигнутое состояние.
В Essence альфы так и определяются: у них есть состояния, начинающиеся с событий их достижения ("Воплощение системы демонстрируемо: система собрана из её частей и готова к проверке", "Определение системы непротиворечиво: определение системы создано и непротиворечиво") и контрольные вопросы/checkpoints, которые определяют более мелкие детали состояний альф, начинающихся с событий их достижения ("Критические интерфейсы были продемонстрированы", "Описания проверяются").
В 4D онтологии мы могли бы говорить о событиях начала существования полных временнЫх частей экземпляров альф как функциональных индивидов (подробней про 4D см. в разделе "2. Формализмы системной инженерии", подраздел "3D и 4D" учебника http://techinvestlab.ru/systems_engineering_thinking, хотя OMG Essence не слишком чётко выдерживает классическое онтологическое рассмотрение).
В проектном управлении события -- это прежде всего контрольные точки, (вехи, milestones), характеризуемые желаемым состоянием продуктов на момент прохождения вехи. Вехи интересны тем, что в них интересуются не выполненными работами ("учил?!"), а достигнутым результатом ("выучил?!"). Гейты (gates, ворота) -- это те же контрольные точки/вехи, но недостижение результатов которых может остановить весь проект. Современные принципы lean уменьшают количество гейтов, но увеличивают количество вех -- по факту сколько запланировано работ, столько оказывается и вех: выполнение всех работ, причём "вовремя", контролируется.
В управлении делами (case management/issue tracking) главные события -- это открытие и закрытие дела (case, issue). Конечно, внутри может быть много других контрольных точек/событий (формальных типа "менеджер кейса назначен" или содержательных типа "баг воспроизводится").
В процессном управлении события тоже бывают, но чаще всего это просто "закончилась одна работа, начинается другая".
Так что опора на события позволяет нам через изменение состояний изменяемых нашими работами (или внешними силами) альф (продуктов) описывать деятельность на понятном для приверженцев других подходов языке -- языке контрольных точек проекта, событий процесса, состояний альф и чеклистов Essence, координационных и производственных фактах DEMO и т.д.
Опора в моделировании предпринятия на события может черпать полными ладошками из опыта моделирования при разработке софта. По большому счёту, для разработки софта требуется описывать модель использующей системы (а это часто означает моделирование деятельности/практики -- domain, предметной области), а не только модель целевой системы -- собственно программного средства. Ну, и ещё можно заметить, что программирование и моделирование вообще очень близкие деятельности, иногда до неразличимости (особенно, если людей и компьютеры обобщить под общим философским именем "агенты", но не будем тут подначивать гуманитариев).
Вот что даёт нам мировой опыт опоры на события, вот что нужно аккуратно переварить (в том числе перевести на русский, обобщить и как-то компактифицировать), а затем переложить в Соглашении о моделировании и использовать в работе:
позволяет нам немедленно воспользоваться всеми преимуществами популярных практик моделирования, которые пришли к нам из разработки программного обеспечения:
-- практика чеклистов (чеклисты это и есть списки ожидаемых событий!), в том числе чеклисты Essence.
-- практика контрольных точек в параллельной инженерии/concurrent engineering (например, у Airbus порядка 1000 контрольных точек верхнего уровня, и всего три гейта -- http://www.amazon.com/Commercial-Aircraft-Projects-Hans-Henrich-Altfeld/dp/0754677532). Хитрость в том, что все контрольные точки привязаны к структуре самолёта, к состоянию продукта! У российских атомщиков очень похожая методика планирования работ в строительстве (привязка контрольных точек к информационной модели) называется Multi-D. И она в свою очередь была подсмотрена на примере методики Toshiba 6D. В системной инженерии сейчас это общее место: формальная привязка контрольных точек activity-проекта к состоянию продукта.
-- DDD (domain-driven design, https://en.wikipedia.org/wiki/Domain-driven_design) в сочетании (http://www.infoq.com/news/2015/02/bdd-ddd) с BDD (behavior-driven development, http://dannorth.net/introducing-bdd/ и есть русский перевод http://habrahabr.ru/post/216923/).
-- выходящие в мейнстрим корпоративной работы с "процессами" (несмотря на весь шум с BPMN 2) -- https://en.wikipedia.org/wiki/Complex_event_processing и https://en.wikipedia.org/wiki/Event_correlation, тут можно вспомнить и о Business Rules (организационных нормах: http://ailev.livejournal.com/693597.html).
-- описанием сложных поведений через "машину состояний" (вот тут даже "программирование с явным выделением состояний" предлагается на роль "серебряной пули" -- http://is.ifmo.ru/works/mirk/, а вообще -- автоматное программирование, событийно-ориентированное программирование -- там много общего и для программирования и для моделирования деятельности).
Для наших целей интересно указать на вышедшую из DDD/BDD практику Event Storming (событийный штурм), предназначенную для скорейшего раскрытия структуры предметной области. Она заключается в том, что экспертов этой предметной области просят зафиксировать на стикерах основные события предметной области и операции (там их называют "приказы", Command -- выражение намерения стейкхолдеров), приводящие к этим событиям. Плюс выделяются какие-то части системы (Aggregates, "агрегаты"), которые получают команды и производят события -- http://ziobrando.blogspot.ru/2013/11/introducing-event-storming.html#.VaVs25fp_Nw, http://ziobrando.blogspot.ru/2014/06/eventstorming-recipes.html#.VaVtjJfp_Nw, http://www.ebookxp.org/verraes.net/2015/05/towards-modelling-processes/?b=4
Помним, что несмотря на всю кажущуюся процессно-ориентированность Event Storming (как части DDD), там опора на продукты/альфы предметной области -- ибо события прежде всего выражают изменение состояния мира, изменение состояния вещей, четырёхмерных индивидов.
Как проявляется событийность в ArchiMate? Понятно, что там впрямую есть элемент Event (событие), но в ArchiMate это не столько состояние объекта, сколько "почти процесс" (activity, не object и не subject)! Как я понимаю, это сделано для облегчения показа запуска процесса каким-то событием (ибо запустить/trigger процесс или практику объектом там нельзя, у объекта в ArchiMate нет состояния. А процессы влёгкую запускают друг друга, их окончание "неявное событие", невзирая на неопределённость и неназванность состояния мира, к которому процессы привели).
Можно, конечно, ещё спекулировать что в ArchiMate motivation extension выставление Оценки это тоже событие, а Цель -- это Приказ, выражающий намерение по реализации фрагмента архитектуры. Если Приказ не провалился (в DDD/BDD один из важных моментов -- это анализ рисков, почему Приказ может провалиться, какие события к этому могут привести), то должно пройти изменение оценки в соответствии с Целью. Оценка "мы не растём" (похоже на событие по формулировке, хотя и не привязано к изменению ситуации), цель/контрольная точка (SMART) "Вырасти вдвое к Новому Году" (желаемое событие -- "выросли вдвое" на момент "Новый Год". Теперь можно мерять не "процесс вырастания", а сам рост -- и для начала придётся точно определить, что именно должно вырасти, чтобы было событие. Думать не процессами, а вещами/продуктами/альфами/артефактами/объектами и отслеживать контрольные точки -- смены их состояний).
Итого: начинайте моделировать деятельность не с операций. Начинайте с событий -- именно к ним приводят (или от них уводят) самые разные операции самых разных практик, а происходят они с альфами/продуктами, это замаскированные альфы/продукты. Хотите вы, или не хотите, а для формулирования события вам придётся найти и назвать альфу/продукт, который меняет состояние. Планируются же события как чеклисты (к продуктам) и контрольные точки (состояния продуктов в проектах).
При моделировании предпринятия мы (в зависимости от превалирующего интереса к технологии, работе или команде) можем выбрать три различных подхода к описанию его деятельности, с акцентами на:
-- метод/технологии деятельности,
-- на выполняемые работы
-- договорённости о разделении труда в команде
Эти же три варианта в Cordys (2008), "Response from Cordys to the OMG Dynamic Business Activity Modeling RFI" называют
-- artifact-based (поскольку альфы/рабочие продукты важны для описания практик),
-- activity-based (процесс или проект как последовательность работ),
-- communication-based (коммуникация о поручениях работы между членами команды).
Wang, J., et al. (2005), "A framework for Document-Driven Workflow System" эти же три варианта называют
-- information-based (поскольку не на заводах рабочие продукты в основном это информационные объекты),
-- process-based (развёртка во времени, последовательность работ),
-- organization-based (полномочия членов команды, разделение труда -- это и есть суть организации, пример такого подхода DEMO, http://ailev.livejournal.com/644440.html).
Системный подход говорит, что нам потребуется отмоделировать и практики, и процессы, и команду. Но с чего начать? Что взять за основу? Практики/технологию, процессы/проекты, или команду/оргструктуру?
Мы рекомендуем за основу брать описание практик, следование которым в работе изменяет продукты. Удобней начинать описание практик с альф, а не с рабочих продуктов -- нас интересует в практике прежде всего описание дисциплины, предметной области, абстрагированное от рабочих продуктов. Хотя и технология тоже интересна, в этой части мы описываем какие рабочие продукты выражают альфу. Опора на дисциплину, а не сразу на технологию экономит мышление: по подсчётам команды Essence одна альфа в среднем выражается 6-10 рабочими продуктами!
Но деятельность не состоит только из рабочих продуктов! Деятельность-то разворачивается во времени, а это процессный аспект! Куда мы денем процессы при описании деятельности? Мы будем учитывать изменения продуктов во времени, но не как в процессном подходе -- не указанием последовательности работ. Это даст нам возможность выполнять работы не друг за дружкой в заранее запланированном порядке, а планируя эти работы в зависимости от ситуации (в том числе используя для ускорения планирования и уменьшения ошибок планирования и учёта выполнения планов информационные системы).
Мы учтём разворачивание деятельности по изменению продуктов во времени через описание смены их состояний -- нас интересуют события, происходящие с альфами.
Мы будем смотреть на предпринятие как лягушка: она видит хорошо только движущиеся предметы. Альфы/продукты увидеть трудно, но легко заметить их важные изменения -- достижения ими каких-то состояний. Если начинать с хорошо заметных важных событий ("поверхность чиста", "деньги пришли", "команда сработалась"), то много легче затем выйти на полноценное моделирование всех других объектов. И это продукт-ориентированный подход, как ни странно.
Событие -- это вполне себе "продукт", это срез мира (или одного продукта, или группы продуктов) в момент изменения состояния. То есть событие это вещь/продукт/альфа/artifact, но в какой-то совершенно определённый момент времени -- момент, когда одно состояние сменилось другим (последний момент предыдущего состояния или первый момент следующего -- смотря как сформулировать). Состояние, конечно, должно быть таким, чтобы мы могли вполне определённо узнать о его смене. DEMO говорит об этом как о координационных фактах (смену состояния должен выразить стейкхолдер -- события "поручил", "обещал сделать", "сделал", "принял", "разрешил" и т.д.) и производственных фактах (изменение состояний продуктов).
Смена состояния обеспечивается работами, но состояния формулируются как желаемый результат работ (состояние мира, определяемое чеклистом, а хоть из одного пункта), а не ведущей к достижению состояния работой: помним разницу между "учил" и "выучил" -- "учил" это про выполненную работу, а "выучил" про достигнутое состояние.
В Essence альфы так и определяются: у них есть состояния, начинающиеся с событий их достижения ("Воплощение системы демонстрируемо: система собрана из её частей и готова к проверке", "Определение системы непротиворечиво: определение системы создано и непротиворечиво") и контрольные вопросы/checkpoints, которые определяют более мелкие детали состояний альф, начинающихся с событий их достижения ("Критические интерфейсы были продемонстрированы", "Описания проверяются").
В 4D онтологии мы могли бы говорить о событиях начала существования полных временнЫх частей экземпляров альф как функциональных индивидов (подробней про 4D см. в разделе "2. Формализмы системной инженерии", подраздел "3D и 4D" учебника http://techinvestlab.ru/systems_engineering_thinking, хотя OMG Essence не слишком чётко выдерживает классическое онтологическое рассмотрение).
В проектном управлении события -- это прежде всего контрольные точки, (вехи, milestones), характеризуемые желаемым состоянием продуктов на момент прохождения вехи. Вехи интересны тем, что в них интересуются не выполненными работами ("учил?!"), а достигнутым результатом ("выучил?!"). Гейты (gates, ворота) -- это те же контрольные точки/вехи, но недостижение результатов которых может остановить весь проект. Современные принципы lean уменьшают количество гейтов, но увеличивают количество вех -- по факту сколько запланировано работ, столько оказывается и вех: выполнение всех работ, причём "вовремя", контролируется.
В управлении делами (case management/issue tracking) главные события -- это открытие и закрытие дела (case, issue). Конечно, внутри может быть много других контрольных точек/событий (формальных типа "менеджер кейса назначен" или содержательных типа "баг воспроизводится").
В процессном управлении события тоже бывают, но чаще всего это просто "закончилась одна работа, начинается другая".
Так что опора на события позволяет нам через изменение состояний изменяемых нашими работами (или внешними силами) альф (продуктов) описывать деятельность на понятном для приверженцев других подходов языке -- языке контрольных точек проекта, событий процесса, состояний альф и чеклистов Essence, координационных и производственных фактах DEMO и т.д.
Опора в моделировании предпринятия на события может черпать полными ладошками из опыта моделирования при разработке софта. По большому счёту, для разработки софта требуется описывать модель использующей системы (а это часто означает моделирование деятельности/практики -- domain, предметной области), а не только модель целевой системы -- собственно программного средства. Ну, и ещё можно заметить, что программирование и моделирование вообще очень близкие деятельности, иногда до неразличимости (особенно, если людей и компьютеры обобщить под общим философским именем "агенты", но не будем тут подначивать гуманитариев).
Вот что даёт нам мировой опыт опоры на события, вот что нужно аккуратно переварить (в том числе перевести на русский, обобщить и как-то компактифицировать), а затем переложить в Соглашении о моделировании и использовать в работе:
позволяет нам немедленно воспользоваться всеми преимуществами популярных практик моделирования, которые пришли к нам из разработки программного обеспечения:
-- практика чеклистов (чеклисты это и есть списки ожидаемых событий!), в том числе чеклисты Essence.
-- практика контрольных точек в параллельной инженерии/concurrent engineering (например, у Airbus порядка 1000 контрольных точек верхнего уровня, и всего три гейта -- http://www.amazon.com/Commercial-Aircraft-Projects-Hans-Henrich-Altfeld/dp/0754677532). Хитрость в том, что все контрольные точки привязаны к структуре самолёта, к состоянию продукта! У российских атомщиков очень похожая методика планирования работ в строительстве (привязка контрольных точек к информационной модели) называется Multi-D. И она в свою очередь была подсмотрена на примере методики Toshiba 6D. В системной инженерии сейчас это общее место: формальная привязка контрольных точек activity-проекта к состоянию продукта.
-- DDD (domain-driven design, https://en.wikipedia.org/wiki/Domain-driven_design) в сочетании (http://www.infoq.com/news/2015/02/bdd-ddd) с BDD (behavior-driven development, http://dannorth.net/introducing-bdd/ и есть русский перевод http://habrahabr.ru/post/216923/).
-- выходящие в мейнстрим корпоративной работы с "процессами" (несмотря на весь шум с BPMN 2) -- https://en.wikipedia.org/wiki/Complex_event_processing и https://en.wikipedia.org/wiki/Event_correlation, тут можно вспомнить и о Business Rules (организационных нормах: http://ailev.livejournal.com/693597.html).
-- описанием сложных поведений через "машину состояний" (вот тут даже "программирование с явным выделением состояний" предлагается на роль "серебряной пули" -- http://is.ifmo.ru/works/mirk/, а вообще -- автоматное программирование, событийно-ориентированное программирование -- там много общего и для программирования и для моделирования деятельности).
Для наших целей интересно указать на вышедшую из DDD/BDD практику Event Storming (событийный штурм), предназначенную для скорейшего раскрытия структуры предметной области. Она заключается в том, что экспертов этой предметной области просят зафиксировать на стикерах основные события предметной области и операции (там их называют "приказы", Command -- выражение намерения стейкхолдеров), приводящие к этим событиям. Плюс выделяются какие-то части системы (Aggregates, "агрегаты"), которые получают команды и производят события -- http://ziobrando.blogspot.ru/2013/11/introducing-event-storming.html#.VaVs25fp_Nw, http://ziobrando.blogspot.ru/2014/06/eventstorming-recipes.html#.VaVtjJfp_Nw, http://www.ebookxp.org/verraes.net/2015/05/towards-modelling-processes/?b=4
Помним, что несмотря на всю кажущуюся процессно-ориентированность Event Storming (как части DDD), там опора на продукты/альфы предметной области -- ибо события прежде всего выражают изменение состояния мира, изменение состояния вещей, четырёхмерных индивидов.
Как проявляется событийность в ArchiMate? Понятно, что там впрямую есть элемент Event (событие), но в ArchiMate это не столько состояние объекта, сколько "почти процесс" (activity, не object и не subject)! Как я понимаю, это сделано для облегчения показа запуска процесса каким-то событием (ибо запустить/trigger процесс или практику объектом там нельзя, у объекта в ArchiMate нет состояния. А процессы влёгкую запускают друг друга, их окончание "неявное событие", невзирая на неопределённость и неназванность состояния мира, к которому процессы привели).
Можно, конечно, ещё спекулировать что в ArchiMate motivation extension выставление Оценки это тоже событие, а Цель -- это Приказ, выражающий намерение по реализации фрагмента архитектуры. Если Приказ не провалился (в DDD/BDD один из важных моментов -- это анализ рисков, почему Приказ может провалиться, какие события к этому могут привести), то должно пройти изменение оценки в соответствии с Целью. Оценка "мы не растём" (похоже на событие по формулировке, хотя и не привязано к изменению ситуации), цель/контрольная точка (SMART) "Вырасти вдвое к Новому Году" (желаемое событие -- "выросли вдвое" на момент "Новый Год". Теперь можно мерять не "процесс вырастания", а сам рост -- и для начала придётся точно определить, что именно должно вырасти, чтобы было событие. Думать не процессами, а вещами/продуктами/альфами/артефактами/объектами и отслеживать контрольные точки -- смены их состояний).
Итого: начинайте моделировать деятельность не с операций. Начинайте с событий -- именно к ним приводят (или от них уводят) самые разные операции самых разных практик, а происходят они с альфами/продуктами, это замаскированные альфы/продукты. Хотите вы, или не хотите, а для формулирования события вам придётся найти и назвать альфу/продукт, который меняет состояние. Планируются же события как чеклисты (к продуктам) и контрольные точки (состояния продуктов в проектах).