Тезисы к архитектуре софта PraxOS
Еще пару лет назад софт PraxOS казался недостижимой утопией (http://ailev.livejournal.com/701355.html), а сейчас (после выхода .15926 browser, http://community.livejournal.com/dot15926/21895.html) он кажется утопией уже вполне достижимой, хотя для этого нужно сильно потрудиться. Данные архитектурные тезисы дают основные направления требуемых трудов, как они понимаются сегодня:
1. Главный артефакт, который создаёт софт PraxOS -- это архитектурное описание организации (enterprise architecture, и тут особый привет J.Dietz, http://ailev.livejournal.com/920634.html).
Это описание связывает функцию (цели) и конструкцию (ответственности и полномочия акторов) организации -- http://ailev.livejournal.com/920248.html
Его также можно трактовать как (мета)модель организации (без исторических данных).
Можно считать это архитектурное описание справочными данными, задающими проектные данные (в данном случае -- данные продуктных и коммуникативных фактов, т.е. фактов о транзакциях, если говорить в терминах DEMO. Они же -- исторические данные).
2. Каталог методов организационной работы (как организовано дело, основной предмет PraxOS как набора лучших организационных практик) -- это часть организационной архитектуры. Описание предпринятий этих методов -- это уже исторические данные.
Хотя, как всегда, в этих описаниях есть многоуровневость специализации и экземпляризации (instantiation) метода. Так, начальный каталог методов PraxOS создаётся при помощи софта PraxOS и поставляется вместе с ним для использования в КонкОрге (http://praxos.ru/index.php/Конкорг). Затем происходит специализация организационных методов для условий КонкОрга -- и это тоже происходит при помощи софта PraxOS.
3. Тем самым самым софт PraxOS поддерживает архитектурный язык (в смысле ISO 24744 -- набор концепций), позволяющий выразить:
-- функции организации (в том числе цели) и конструкцию (в том числе акторов, инструменты, информационные системы и т.д.) во взаимосвязи с функциями -- тут, похоже, будет много DEMO
-- каталог организационных методов (думаем об ISO 24744 и OMG SPEM/SEMAT)
-- процессы-workflow (думаем o BPMN)
-- описать информационные системы, поддерживающие работу организации (что традиционно для enterprise architecture: объединение описаний деятельности и описаний информационных систем в рамках одного архитектурного описания).
Именно тут обсуждается вопрос о том, какие группы описаний, какие в этих группах описаны сущности, какие правила соответствия (correspondence rules), если считать, что архитектурное описание строится по ISO 42010. Тут нужно обсуждать, почему все эти Zachman, TOGAF и т.д. с их десятками предначертанных групп описаний не работают. Продуктивный ход -- это деятельностный: каждый метод организационного действия требует удобных для него описаний, а других описаний не требует.
Можно считать, что речь идет о каком-то architectural framework PraxOS, который закрывает описательные потребности организационных методов (текущий начальный список орг.методов см. в http://community.livejournal.com/praxos/7722.html).
Архитектурный язык (в смысле ISO 24744) мы выражаем в терминах специализированных шаблонов ISO 15926.
4. Тем не менее, есть еще понятие архитектурного языка для архитектурных фреймворков (язык в смысле ISO 42010, думаем об UML/SysML/AADL/ArchiMate) можно строить, исходя из следующих выборов:
-- модульный язык, расширяемый нужными DSL (с использованим инструментария language workbench)
-- включающим онтологическую часть (критика UML со стороны команды OPDM)
-- включающим возможность выразить мэппинг его понятий в существующие информационные системы.
Можно считать, что метамоделью (типа MOF для UML/SysML) для этого языка будет ISO 15926-2. Дальше вопрос, каким будет сам язык (набор понятий), и какие диаграммы для него будут простроены.
Скорее всего, это будет модульный онтологический язык .15926L, который будет поддерживать разные организационные DSL (например, виды диаграмм) для поддержки определенных организационных методов.
Тем самым выделяется две работы:
-- создание .15926L (язык шаблонов в нотации Prover9, или язык диаграмм части 7 -- как раз такие языки. Можно ли сделать лучше?)
-- определение первоочередного набора организационных DSL (для чего нужно определить методы, и понять необходимые для них DSL -- например, разобраться диаграммными техниками/DSL для описания жизненных циклов http://ailev.livejournal.com/917251.html и орг.методами, их использующими; диаграммами "сэндвич" из http://ailev.livejournal.com/920248.html и орг.методами, их использующими -- и т.д., причём начиная с методов, а не диаграмм).
Понятно, что как архитектурный язык (базовый), так и определяемые в нём языковые модули-DSL включают не только набор поддерживаемых им понятий и их семантику/прагматику, но и нотацию (а то и несколько эквивалентных -- например, графическую и текстовую).
5. Трансакционные данные (координационные и производственные факты, описания конкретных изделий и т.д. -- исторические данные, данные предпринятий) поддерживаются различными корпоративными информационными системами, имеющими каждый своего производителя и поддерживаемую схему данных, соответствующую какому-то обобщенному методу орг.работы: мы понимаем, что в корпоративных информационных технологиях уже давно нет greenfield проектов, мы всегда приходим уже на истоптанную brownfield инструментальную площадку. Тем самым, в проектах освоения новых организационных методов нужно обеспечить два действия в сфере информационных технологий:
-- дополнение существующих информационных систем новыми, соответствующими требуемой организационной архитектуре видами данных и связанными с ними операциями. Например, это нужно в части обеспечения явного учёта всех необходимых коммуникационных фактов на предприятиях -- то есть установления какого-то аналога VISI протокола для основных транзакций (http://www.demo.nl/practical-case-studies/why-visi). Можно думать об этом как о "настройке" вновь закупаемого и "донастройке" уже эксплуатирующегося софта.
-- интеграция данных уже имеющегося софта, в том числе с созданием (настройкой) нового workflow, соответствующего этой интеграции данных.
Обе этих функции требуют возможности мэппинга справочных данных PraxOS к справочным данным (схемам данных) различного корпоративного софта.
6. Тем самым для софта PraxOS используется комбинация методов "ISO 15926 Inside" и "ISO 15926 Outside" для двух стадий организационной работы PraxOS:
а) определение организационной системы (system definition в V-диаграмме), т.е. использование софт PraxOS начальниками (B-organization): поддержка дискуссии о том, как должно быть (обеспечение дискурса, в терминах DEMO). Сейчас обеспечивается флипчартом, PowerPoint и разными видами оргдиаграмм. Это создание справочных данных, т.е. архитектура организации оригинально разрабатывается и ведется как "ISO 15926 Inside", для чего используется .15926 language workbench, со всей наличной онтологической поддержкой для работы со множеством DSL и возможностями проверки целостности. Это вожделенный "универсальный моделлер", который позволяет создать необходимые организационные модели, необходимые модели методов работы и т.д.
б) воплощение организационной системы (system realization в V-диаграмме), т.е. использование софта PraxOS программистами (D-organization): поддержка интеграции данных, справочные данные как шаблоны ISO 15926 и их аналитические диаграммы. Сейчас обеспечивается IRING или "обменом данных точка-точка". Так как транзакционные данные (производственные и коммуникативные факты,) храним в корпоративных информационных системах, и их используем для разработки, то используем подход "ISO 15926 Outside" в части организации мэппинга: универсальный моделер служит для предоставления справочных данных, позвляющих как настроить и донастроить корпоративные информационные системы для их соответствия разработанной организационной архитектуре, включая выбранные методы организационной работы, так и для целей обмена данными -- т.е. создания адаптеров к корпоративным информационным системам.
Хотим мы, или не хотим, но для полноценного внедрения софта PraxOS в нём должна быть достигнута вся полнота функциональности "ISO 15926 Outside" (т.е. мы в какой-то степени повторим IRING), никакой "развилки" между этими двумя путями нет.
7. Требование к проекту praxos со стороны проекта dot15926 -- к осени (когда завершим поддержку "ISO 15926 Outside") иметь набор организационных DSL (набора понятий плюс видов нотаций), которые нужно будет поддержать в качестве начального набора для "ISO 15926 Inside". Это можно создавать методом претотипирования (например, используя Excel, PowerPoint и Word в качестве "универсального моделера"), но к осени эти языковые модули ОргЛана должны быть готовы (поностальгируем о том, как мы определяли ОргЛан в 2007г.: тут, или в том же 2007г. "выразить сущность организации на Орглане" из http://ailev.livejournal.com/485066.html -- какая поэзия! Тем не менее, многие мысли из тех времен вполне сохранили актуальность).
Так что это у нас будет весьма языко-ориентированное лето, в том числе лето нотационной инженерии (http://ailev.livejournal.com/546301.html, http://ailev.livejournal.com/548756.html, http://ailev.livejournal.com/549681.html, http://ailev.livejournal.com/613067.html) -- впрочем, это я тут уже повторяю кусочками "Еще раз о планах релиза 2.1 PraxOS" годичной давности http://community.livejournal.com/praxos/1719.html
1. Главный артефакт, который создаёт софт PraxOS -- это архитектурное описание организации (enterprise architecture, и тут особый привет J.Dietz, http://ailev.livejournal.com/920634.html).
Это описание связывает функцию (цели) и конструкцию (ответственности и полномочия акторов) организации -- http://ailev.livejournal.com/920248.html
Его также можно трактовать как (мета)модель организации (без исторических данных).
Можно считать это архитектурное описание справочными данными, задающими проектные данные (в данном случае -- данные продуктных и коммуникативных фактов, т.е. фактов о транзакциях, если говорить в терминах DEMO. Они же -- исторические данные).
2. Каталог методов организационной работы (как организовано дело, основной предмет PraxOS как набора лучших организационных практик) -- это часть организационной архитектуры. Описание предпринятий этих методов -- это уже исторические данные.
Хотя, как всегда, в этих описаниях есть многоуровневость специализации и экземпляризации (instantiation) метода. Так, начальный каталог методов PraxOS создаётся при помощи софта PraxOS и поставляется вместе с ним для использования в КонкОрге (http://praxos.ru/index.php/Конкорг). Затем происходит специализация организационных методов для условий КонкОрга -- и это тоже происходит при помощи софта PraxOS.
3. Тем самым самым софт PraxOS поддерживает архитектурный язык (в смысле ISO 24744 -- набор концепций), позволяющий выразить:
-- функции организации (в том числе цели) и конструкцию (в том числе акторов, инструменты, информационные системы и т.д.) во взаимосвязи с функциями -- тут, похоже, будет много DEMO
-- каталог организационных методов (думаем об ISO 24744 и OMG SPEM/SEMAT)
-- процессы-workflow (думаем o BPMN)
-- описать информационные системы, поддерживающие работу организации (что традиционно для enterprise architecture: объединение описаний деятельности и описаний информационных систем в рамках одного архитектурного описания).
Именно тут обсуждается вопрос о том, какие группы описаний, какие в этих группах описаны сущности, какие правила соответствия (correspondence rules), если считать, что архитектурное описание строится по ISO 42010. Тут нужно обсуждать, почему все эти Zachman, TOGAF и т.д. с их десятками предначертанных групп описаний не работают. Продуктивный ход -- это деятельностный: каждый метод организационного действия требует удобных для него описаний, а других описаний не требует.
Можно считать, что речь идет о каком-то architectural framework PraxOS, который закрывает описательные потребности организационных методов (текущий начальный список орг.методов см. в http://community.livejournal.com/praxos/7722.html).
Архитектурный язык (в смысле ISO 24744) мы выражаем в терминах специализированных шаблонов ISO 15926.
4. Тем не менее, есть еще понятие архитектурного языка для архитектурных фреймворков (язык в смысле ISO 42010, думаем об UML/SysML/AADL/ArchiMate) можно строить, исходя из следующих выборов:
-- модульный язык, расширяемый нужными DSL (с использованим инструментария language workbench)
-- включающим онтологическую часть (критика UML со стороны команды OPDM)
-- включающим возможность выразить мэппинг его понятий в существующие информационные системы.
Можно считать, что метамоделью (типа MOF для UML/SysML) для этого языка будет ISO 15926-2. Дальше вопрос, каким будет сам язык (набор понятий), и какие диаграммы для него будут простроены.
Скорее всего, это будет модульный онтологический язык .15926L, который будет поддерживать разные организационные DSL (например, виды диаграмм) для поддержки определенных организационных методов.
Тем самым выделяется две работы:
-- создание .15926L (язык шаблонов в нотации Prover9, или язык диаграмм части 7 -- как раз такие языки. Можно ли сделать лучше?)
-- определение первоочередного набора организационных DSL (для чего нужно определить методы, и понять необходимые для них DSL -- например, разобраться диаграммными техниками/DSL для описания жизненных циклов http://ailev.livejournal.com/917251.html и орг.методами, их использующими; диаграммами "сэндвич" из http://ailev.livejournal.com/920248.html и орг.методами, их использующими -- и т.д., причём начиная с методов, а не диаграмм).
Понятно, что как архитектурный язык (базовый), так и определяемые в нём языковые модули-DSL включают не только набор поддерживаемых им понятий и их семантику/прагматику, но и нотацию (а то и несколько эквивалентных -- например, графическую и текстовую).
5. Трансакционные данные (координационные и производственные факты, описания конкретных изделий и т.д. -- исторические данные, данные предпринятий) поддерживаются различными корпоративными информационными системами, имеющими каждый своего производителя и поддерживаемую схему данных, соответствующую какому-то обобщенному методу орг.работы: мы понимаем, что в корпоративных информационных технологиях уже давно нет greenfield проектов, мы всегда приходим уже на истоптанную brownfield инструментальную площадку. Тем самым, в проектах освоения новых организационных методов нужно обеспечить два действия в сфере информационных технологий:
-- дополнение существующих информационных систем новыми, соответствующими требуемой организационной архитектуре видами данных и связанными с ними операциями. Например, это нужно в части обеспечения явного учёта всех необходимых коммуникационных фактов на предприятиях -- то есть установления какого-то аналога VISI протокола для основных транзакций (http://www.demo.nl/practical-case-studies/why-visi). Можно думать об этом как о "настройке" вновь закупаемого и "донастройке" уже эксплуатирующегося софта.
-- интеграция данных уже имеющегося софта, в том числе с созданием (настройкой) нового workflow, соответствующего этой интеграции данных.
Обе этих функции требуют возможности мэппинга справочных данных PraxOS к справочным данным (схемам данных) различного корпоративного софта.
6. Тем самым для софта PraxOS используется комбинация методов "ISO 15926 Inside" и "ISO 15926 Outside" для двух стадий организационной работы PraxOS:
а) определение организационной системы (system definition в V-диаграмме), т.е. использование софт PraxOS начальниками (B-organization): поддержка дискуссии о том, как должно быть (обеспечение дискурса, в терминах DEMO). Сейчас обеспечивается флипчартом, PowerPoint и разными видами оргдиаграмм. Это создание справочных данных, т.е. архитектура организации оригинально разрабатывается и ведется как "ISO 15926 Inside", для чего используется .15926 language workbench, со всей наличной онтологической поддержкой для работы со множеством DSL и возможностями проверки целостности. Это вожделенный "универсальный моделлер", который позволяет создать необходимые организационные модели, необходимые модели методов работы и т.д.
б) воплощение организационной системы (system realization в V-диаграмме), т.е. использование софта PraxOS программистами (D-organization): поддержка интеграции данных, справочные данные как шаблоны ISO 15926 и их аналитические диаграммы. Сейчас обеспечивается IRING или "обменом данных точка-точка". Так как транзакционные данные (производственные и коммуникативные факты,) храним в корпоративных информационных системах, и их используем для разработки, то используем подход "ISO 15926 Outside" в части организации мэппинга: универсальный моделер служит для предоставления справочных данных, позвляющих как настроить и донастроить корпоративные информационные системы для их соответствия разработанной организационной архитектуре, включая выбранные методы организационной работы, так и для целей обмена данными -- т.е. создания адаптеров к корпоративным информационным системам.
Хотим мы, или не хотим, но для полноценного внедрения софта PraxOS в нём должна быть достигнута вся полнота функциональности "ISO 15926 Outside" (т.е. мы в какой-то степени повторим IRING), никакой "развилки" между этими двумя путями нет.
7. Требование к проекту praxos со стороны проекта dot15926 -- к осени (когда завершим поддержку "ISO 15926 Outside") иметь набор организационных DSL (набора понятий плюс видов нотаций), которые нужно будет поддержать в качестве начального набора для "ISO 15926 Inside". Это можно создавать методом претотипирования (например, используя Excel, PowerPoint и Word в качестве "универсального моделера"), но к осени эти языковые модули ОргЛана должны быть готовы (поностальгируем о том, как мы определяли ОргЛан в 2007г.: тут, или в том же 2007г. "выразить сущность организации на Орглане" из http://ailev.livejournal.com/485066.html -- какая поэзия! Тем не менее, многие мысли из тех времен вполне сохранили актуальность).
Так что это у нас будет весьма языко-ориентированное лето, в том числе лето нотационной инженерии (http://ailev.livejournal.com/546301.html, http://ailev.livejournal.com/548756.html, http://ailev.livejournal.com/549681.html, http://ailev.livejournal.com/613067.html) -- впрочем, это я тут уже повторяю кусочками "Еще раз о планах релиза 2.1 PraxOS" годичной давности http://community.livejournal.com/praxos/1719.html