Методсовет по SysMoLan
Вчера провели в Школе методсовет по SysMoLan.
Сначала обсудили тренды в моделировании данных/schema design (см. тут наблюдения Pascal Desmarets, CEO Hackolade -- Agile Data Modeling for NoSQL Databases, https://www.infoq.com/news/2018/10/agile-data-modeling-nosql. Conceptual data model has been replaced by domain-driven design (DDD), logical data model is no longer needed, and physical data model is replaced by physical schema design. It is critical to design data models that are application-specific, so you store information in a way that optimizes query performance. This mind shift can be a challenge for those who have been applying the principles of application-agnostic data modeling for decades. For many of us, the rules of normalization have become second nature, and we have to force ourselves to apply a query-driven approach to schema design for NoSQL databases. И далее там всё в таком же духе. Ведь трёхсхемная архитектура -- это 1987 год, за тридцать лет накопилось претензий).
Второй вопрос -- это отношение к уровню формальности и уровню абстрактности языка. Язык в его ядре должен быть не формальней Архимейта, ибо слишком формальные онтологии очень плохо садятся на предметную реальность. И язык должен быть не абстрактней Архимейта, ибо всякие более абстрактные Upper Ontologies доступны не инженерам, а онтологам -- а прикладные шаблоны, библиотеки и что там ещё может быть в них оказывается всегда "потом". Начинаем с прикладного уровня, а потом переписываем формализацию, если приспичит: так создавались все плохие, но в какой-то момент попсовые языки (UML, XML, HTML и т.д. -- первая версия неформальная, а в какой-нибудь четвёртой версии наводилась формализация).
Что мы закрываем? По диаграмме семи альф мы закрываем область интересов предпринятия/оргпроекта (её закрывает сегодня ArchiMate), область интересов инженерного решения (её закрывает сегодня SysML/AADL в части моделирования целевой системы и ISO 42010, в котором и языка-то нет -- и тут предложено поддержать эти объекты явно, сделать по аналогии с гомоиконными языками программирования гомоиконный язык моделирования. То есть в явном виде поддержать все эти view, viewpoint, model, model kind, correspondence rules и т.д., и на пару-тройку уровней viewpoints, чтобы показывать "гирлянды языков"). Дизайн цель SysMoLan -- чтобы можно было на одной диаграмме показать и целевую систему, и кто чем в этой целевой системе занимается в обеспечивающей системе. Сейчас такого языка нет, а дизайн-цель очень похожа на дизайн-цель Архимейта: тот создавался тоже, чтобы показать на одной диаграмме и организацию, и IT-решение (и в нём и софт, и железо). Область интересов клиента обычно показывается расширением целеполагания Архимейта, и мы это тоже должны поддержать.
Тем самым ставится задача создать по возможности компактный (я целюсь тут примерно на 30 концептов) язык системного моделирования, который будет показывать части системы, части предприятия и как-то отражать другие модели -- и при этом мы от риторики и сленга "моделирования данных", "интеграции данных жизненного цикла" перейдём к более инженерной риторике моделирования, а именно мультимодельного определения и описания системы. То есть мы не "данными" будем заниматься, а инженерными содержательными вопросами. Попробуем избавиться от типичного птичьего модульного языка айтишников и поговорить функциональным содержательным языком системного подхода, инженерным языком, менеджерским языком. Это трудно, но очень хочется этого добиться. Ибо как вы лодку назовёте, так она и поплывёт. Если назовёте "интеграция данных", то сколько не повторяй "жизненного цикла", ни одного инженера рядом не будет, будут сплошные айтишники. Как тут не вспомнить мудрого Захмана, который из архитектуры предприятия версии 3 убрал модели данных, обосновывая это тем, что на эти слова директор немедленно вызывает CIO, после чего умывает руки, и вместо архитектуры предприятия дальше обсуждается только архитектура IT-решения и та самая архитектура данных. А вот нам нужно, чтобы вся эта канитель с данными и онтологами была закопана глубоко внутри, а снаружи был интерфейс к инженерам. Обсуждаем системы и их модели, а не данные про системы и данные моделей. Эту мысль нужно ещё обдумать. AADL (не хочется тут приводить в пример SysML) и ArchiMate -- оба не языки моделирования данных, и поэтому у них был шанс.
Была также высказана осторожная гипотеза, что по пути Upper Ontology (одной на все модели, непобедимой и неусомневаемой) мы вряд ли сейчас пойдём. С одной стороны, все PLM по факту реализовали эту модель -- с точностью до того, что у каждой из них была своя Upper Ontology, и она была а) не слишком хороша, чаще всего объект-ориентирована, б) уровень её был обычно менее абстрактный, чем в ISO 15926, в) всё одно нейтральных по отношению к вендорам онтологий не найти, а свою делать -- запредельно дорого, г) результирующие схемы "интеграции данных" оказываются запредельно дорогими, и итог всё одно -- интеграция "точка-точка". Это дешевле, "микросервисней", не плодит метамодельных монстров, проще дебажить, более инкрементально в плане реализации и т.д. Как с этим быть? Как кодировать смысловое пространство совмещения языковых моделей (это я говорю про ту же проблему, только примерно как это обсуждается в deep learning и NLP)? Это требует дополнительных размышлений. Но проектов, которые без госфинансирования, и с развитой upper ontology (и библиотеками справочных данных, согласованных с этой upper ontology как необходимое продолжение идеи!) -- их по пальцам посчитать можно, и это не случайно. Agile, кругом agile, что не agile, то почему-то не выживает.
Цепочка текстов по SysMoLan -- https://ailev.livejournal.com/1443879.html
UPDATE: комментарии в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10214109582867634
Сначала обсудили тренды в моделировании данных/schema design (см. тут наблюдения Pascal Desmarets, CEO Hackolade -- Agile Data Modeling for NoSQL Databases, https://www.infoq.com/news/2018/10/agile-data-modeling-nosql. Conceptual data model has been replaced by domain-driven design (DDD), logical data model is no longer needed, and physical data model is replaced by physical schema design. It is critical to design data models that are application-specific, so you store information in a way that optimizes query performance. This mind shift can be a challenge for those who have been applying the principles of application-agnostic data modeling for decades. For many of us, the rules of normalization have become second nature, and we have to force ourselves to apply a query-driven approach to schema design for NoSQL databases. И далее там всё в таком же духе. Ведь трёхсхемная архитектура -- это 1987 год, за тридцать лет накопилось претензий).
Второй вопрос -- это отношение к уровню формальности и уровню абстрактности языка. Язык в его ядре должен быть не формальней Архимейта, ибо слишком формальные онтологии очень плохо садятся на предметную реальность. И язык должен быть не абстрактней Архимейта, ибо всякие более абстрактные Upper Ontologies доступны не инженерам, а онтологам -- а прикладные шаблоны, библиотеки и что там ещё может быть в них оказывается всегда "потом". Начинаем с прикладного уровня, а потом переписываем формализацию, если приспичит: так создавались все плохие, но в какой-то момент попсовые языки (UML, XML, HTML и т.д. -- первая версия неформальная, а в какой-нибудь четвёртой версии наводилась формализация).
Что мы закрываем? По диаграмме семи альф мы закрываем область интересов предпринятия/оргпроекта (её закрывает сегодня ArchiMate), область интересов инженерного решения (её закрывает сегодня SysML/AADL в части моделирования целевой системы и ISO 42010, в котором и языка-то нет -- и тут предложено поддержать эти объекты явно, сделать по аналогии с гомоиконными языками программирования гомоиконный язык моделирования. То есть в явном виде поддержать все эти view, viewpoint, model, model kind, correspondence rules и т.д., и на пару-тройку уровней viewpoints, чтобы показывать "гирлянды языков"). Дизайн цель SysMoLan -- чтобы можно было на одной диаграмме показать и целевую систему, и кто чем в этой целевой системе занимается в обеспечивающей системе. Сейчас такого языка нет, а дизайн-цель очень похожа на дизайн-цель Архимейта: тот создавался тоже, чтобы показать на одной диаграмме и организацию, и IT-решение (и в нём и софт, и железо). Область интересов клиента обычно показывается расширением целеполагания Архимейта, и мы это тоже должны поддержать.
Тем самым ставится задача создать по возможности компактный (я целюсь тут примерно на 30 концептов) язык системного моделирования, который будет показывать части системы, части предприятия и как-то отражать другие модели -- и при этом мы от риторики и сленга "моделирования данных", "интеграции данных жизненного цикла" перейдём к более инженерной риторике моделирования, а именно мультимодельного определения и описания системы. То есть мы не "данными" будем заниматься, а инженерными содержательными вопросами. Попробуем избавиться от типичного птичьего модульного языка айтишников и поговорить функциональным содержательным языком системного подхода, инженерным языком, менеджерским языком. Это трудно, но очень хочется этого добиться. Ибо как вы лодку назовёте, так она и поплывёт. Если назовёте "интеграция данных", то сколько не повторяй "жизненного цикла", ни одного инженера рядом не будет, будут сплошные айтишники. Как тут не вспомнить мудрого Захмана, который из архитектуры предприятия версии 3 убрал модели данных, обосновывая это тем, что на эти слова директор немедленно вызывает CIO, после чего умывает руки, и вместо архитектуры предприятия дальше обсуждается только архитектура IT-решения и та самая архитектура данных. А вот нам нужно, чтобы вся эта канитель с данными и онтологами была закопана глубоко внутри, а снаружи был интерфейс к инженерам. Обсуждаем системы и их модели, а не данные про системы и данные моделей. Эту мысль нужно ещё обдумать. AADL (не хочется тут приводить в пример SysML) и ArchiMate -- оба не языки моделирования данных, и поэтому у них был шанс.
Была также высказана осторожная гипотеза, что по пути Upper Ontology (одной на все модели, непобедимой и неусомневаемой) мы вряд ли сейчас пойдём. С одной стороны, все PLM по факту реализовали эту модель -- с точностью до того, что у каждой из них была своя Upper Ontology, и она была а) не слишком хороша, чаще всего объект-ориентирована, б) уровень её был обычно менее абстрактный, чем в ISO 15926, в) всё одно нейтральных по отношению к вендорам онтологий не найти, а свою делать -- запредельно дорого, г) результирующие схемы "интеграции данных" оказываются запредельно дорогими, и итог всё одно -- интеграция "точка-точка". Это дешевле, "микросервисней", не плодит метамодельных монстров, проще дебажить, более инкрементально в плане реализации и т.д. Как с этим быть? Как кодировать смысловое пространство совмещения языковых моделей (это я говорю про ту же проблему, только примерно как это обсуждается в deep learning и NLP)? Это требует дополнительных размышлений. Но проектов, которые без госфинансирования, и с развитой upper ontology (и библиотеками справочных данных, согласованных с этой upper ontology как необходимое продолжение идеи!) -- их по пальцам посчитать можно, и это не случайно. Agile, кругом agile, что не agile, то почему-то не выживает.
Цепочка текстов по SysMoLan -- https://ailev.livejournal.com/1443879.html
UPDATE: комментарии в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10214109582867634