Промышленные каталоги методов (2)
Ассорти мыслей про каталог методов (продолжение http://community.livejournal.com/praxos/9600.html и еще более раннего http://ailev.livejournal.com/849563.html).
1. В части управления предприятием один и тот же паттерн рефакторинга (вынесения за скобки) находится в самых разных областях:
-- управление эволюцией портфолио продуктов как одной системой (слайд 32 из http://jcse.org.za/upload/events/100/product_lines_2_0_jcse_30apr2010presentation.pdf, и там же помянут ряд других паттернов в терминах "продуктовых линий" -- эволюция сервисов в SOA как одна система, MBE как одна точка в спектре самых разных стратегий продуктовых линий, SoS/FoS высокоадаптивные системы и т.д.).
-- ситуационная инженерия методов предполагает по факту method line и управление эволюцией портфолио методов обеспечивающей системы как целого (непротиворечивый "репозиторий фрагментов методов")
-- движение НСИ в его ERP-изводе (MDM)
-- каталоги комплектующих, из которых создается продукция
Смысл один: иметь каталог высокосовместимых между собой деталей "малой связности снаружи" (четко определенные интерфейсы) и "высокой связности внутри", из которых создаются продуктовые линии, сервисные линии, инструментальные линии, линии методов и т.д.
Общее знание выносится "за скобки", и далее специальное знание верстается/набирается (compose) уже из него. Каталоги чего угодно -- это про рефакторинг информации, получение знаний (знания характеризуются прежде всего их многократной приложимостью в разных ситуациях/контекстах).
Компоненты каталога "эволюционируют", чтобы поддерживать непротиворечивость каталога (возможность собрать из каталога его целевую систему).
Все это про "рефакторинг для программирования-в-большом". Это рефакторинг корпоративных информационных систем.
2. Разные каталоги по сути являются частями "каталога методов" -- ибо метод включает в себя компоненты необходимых работ/сервисов, связанные с сервисами/акторами (людьми и инструментами), а также описание пула продуктов работы (начальных -- "комплектующих", промежуточных, и конечных -- "продукции").
3. Язык, о котором говорится про управление знаниями и создание каталогов крайне разнится:
-- каталоги/справочники в САПР и PLM (много реже -- тоже используется термин НСИ, например для продукта "Вертикаль" от АСКОН).
-- мастер-данные (MDM) и НСИ в сфере ERP
-- репозиторий (в ситуационной инженерии методов).
-- библиотека справочных данных (в моделировании данных)
Но технологии с точки зрения IT используются одни и те же:
-- раньше это были -- как правило -- реляционные базы данных
-- сейчас это преимущественно объектные базы (получаемые как нашлепка над реляционной базой). Характерная черта объектной базы -- это работа в терминах классов (с наследованием, в том числе множественным) и их атрибутами.
Современный сервер MDM, репозиторий САПР и ERP -- это объектная (постреляционная) база данных.
Для начальства лучше всего про рефакторинг корпоративных информационных систем научились рассказывать люди из MDM (master data management). У них самые лучшие презентации, самые лучшие примеры и налаженный лучше всего маркетинг. С учетом того, что они оккупировали ERP-приложения, пользователями которых очень часто являются менеджеры и финансисты, максимальное количество IT-денег на подобный "рефакторинг для программирования в большом" уходит именно в сторону MDM. Поэтому люди даже из CAD/CAM/CAE/PLM задумываются, не начать ли им говорить на этом языке MDM (а пока у них язык PDM/PLM).
4. Сегодняшний этап "рефакторинга" (то есть интеграции приложений с "выносом за скобки" одинаковых знаний) всех этих мастер-данных, НСИ, приводит к следующим проблемам:
-- требуется интегрировать знания/каталоги/справочные данные для всего жизненного цикла, т.е. собирать эти данные из всех частных приложений CAD/PLM, PIM (product information management), ERP и т.д.. Для структурирования этих знаний нужна новая парадигма, ибо тут задействуются и "процессы", и "продукты", и "акторы" (организации -- роли и инструменты) и модели/метамодели и многое другое. По факту нужно принять подход каталогов методов, как интегрирующих другие каталоги (продуктов, сервисов, инструментов и т.д.).
-- работа с системой, элементом системы (в каталоге!) и физическим продуктом. Явное введение "тега" для использования этого системного языка (см. презентацию Мэтью Веста -- http://www.vniiaes.ru/files/RuSEC%202010.rar).
-- объектные схемы определяются даталогически (т.е. игнорируя прикладное значение классов и их атрибутов): значение определяется логикой приложений, а выбираемые для наименования классов и атрибутов слова ситуативны и многозначны. Например, "модификатор" -- типичное название атрибута, но смысл "модификации" будет понятен только прикладной программе. Поэтому при объединении всех этих MDM, справочников и репозиториев возникают огромные проблемы соотнесения. Эти проблемы относятся не столько к традиционной для MDM проблеме "разницы в написании одинакового", сколько в "разном значении одинаково написанного" -- плюс разные средства валидизации целостности (например, как в физике: "контроль размерности при вычислениях", т.е. контроль типов). Решением этой проблемы является наличие независимой от отдельных приложений "связной картины мира" (upper ontology), к которой подвязываются все приложения -- тем самым происходит контроль типов.
-- как верно было замечено в работах консорциума EPISTLE, "что для одного приложения атрибут, то для другого приложения класс". Общая объектная база данных не получается из объединения нескольких объектных баз. Для решения этой проблемы нужно перейти к безатрибутной, т.е. факт-ориентированной модели данных. Это трипл-стор, OWL, SPARQL.
Тем самым очередное продвижение в "рефакторинге" корпоративных информационных систем интеграции данных состоит в их вышеописанной семантизации:
- каталоги методов (а не только продуктов и акторов), структурирование в соответствии с метамоделью ISO 24744 [но этот извод деятельностного подхода пока не нашел отражения в промышленности, разве только как переход к "процессному подходу", чего явно недостаточно].
-- использование системного подхода и тегов, чтобы отследить связь между каталогами элементов системы, системой и физическим продуктом.
-- использование upper ontology (конкретного продукта или нейтральной -- типа ISO 15926, расширенного средствами представления методов и систем
-- использование факт-ориентированного хранилища данных (т.е. трипл-стор), позволяющего организовать онтологическую работу.
5. Это смена парадигмы с "объектной" на "семантическую". В центре этого мира уже не база данных, не "репозиторий/хранилище данных", а "справочная библиотека" (то бишь, как ее обозвали в ISO 15926 -- "библиотека справочных данных", то есть повторно используемых данных, т.е. знаний).
6. Даже SOA с объектной должна стать семантической! И тут нужно обязательно добавить, что SOA отражает ход от "продуктов" и "объектам" к методам работы, учитывающим также собственно работы (процесс, происходящий во времени). Так что SOA явление не временное, а постоянное: это попытка перейти к комплексным описаниям метода, составленного из элементарных компонент метода. Каталоги сервисов -- это полноправные каталоги методов, только в их зачаточной стадии, и ограниченные строго IT-составляющими. Так что неизбежна как семантизация SOA, так и выход понятия "сервис" за рамки чисто айтишного сервиса. Другое дело, что ситуационная инженерия методов говорит про все то же самое, что SOA, только более внятным языком.
7. Из существенных препятствий для построения полноценных каталогов методов нужно отметить
а) необходимость разбирательства с текущей множественностью представления работ (ибо со множественностью представления продуктов уже кое-как учатся справляться):
-- жизненные циклы/процессы разработки
-- workflow/процессы в смысле BPMN 2.0 (включая issue tracking/поручения)
-- проекты (в смысле управления проектами)
-- сервисы (попытка перейти от акторов/producers (люди, инструменты -- организация) к выполняемым ими работам, то есть шаг от акторов-объектов к их процессной стороне)
-- организационные транзакции (в смысле DEMO)
Понятно, что тут нужно использовать подход ISO 42010, и никаких "суммы атрибутов" -- только аккуратные correspondence rules между различными viewpoints.
б) разобраться с иерархизацией метода-для-системы (с тегами), т.е. сделать мереологию для методов.
1. В части управления предприятием один и тот же паттерн рефакторинга (вынесения за скобки) находится в самых разных областях:
-- управление эволюцией портфолио продуктов как одной системой (слайд 32 из http://jcse.org.za/upload/events/100/product_lines_2_0_jcse_30apr2010presentation.pdf, и там же помянут ряд других паттернов в терминах "продуктовых линий" -- эволюция сервисов в SOA как одна система, MBE как одна точка в спектре самых разных стратегий продуктовых линий, SoS/FoS высокоадаптивные системы и т.д.).
-- ситуационная инженерия методов предполагает по факту method line и управление эволюцией портфолио методов обеспечивающей системы как целого (непротиворечивый "репозиторий фрагментов методов")
-- движение НСИ в его ERP-изводе (MDM)
-- каталоги комплектующих, из которых создается продукция
Смысл один: иметь каталог высокосовместимых между собой деталей "малой связности снаружи" (четко определенные интерфейсы) и "высокой связности внутри", из которых создаются продуктовые линии, сервисные линии, инструментальные линии, линии методов и т.д.
Общее знание выносится "за скобки", и далее специальное знание верстается/набирается (compose) уже из него. Каталоги чего угодно -- это про рефакторинг информации, получение знаний (знания характеризуются прежде всего их многократной приложимостью в разных ситуациях/контекстах).
Компоненты каталога "эволюционируют", чтобы поддерживать непротиворечивость каталога (возможность собрать из каталога его целевую систему).
Все это про "рефакторинг для программирования-в-большом". Это рефакторинг корпоративных информационных систем.
2. Разные каталоги по сути являются частями "каталога методов" -- ибо метод включает в себя компоненты необходимых работ/сервисов, связанные с сервисами/акторами (людьми и инструментами), а также описание пула продуктов работы (начальных -- "комплектующих", промежуточных, и конечных -- "продукции").
3. Язык, о котором говорится про управление знаниями и создание каталогов крайне разнится:
-- каталоги/справочники в САПР и PLM (много реже -- тоже используется термин НСИ, например для продукта "Вертикаль" от АСКОН).
-- мастер-данные (MDM) и НСИ в сфере ERP
-- репозиторий (в ситуационной инженерии методов).
-- библиотека справочных данных (в моделировании данных)
Но технологии с точки зрения IT используются одни и те же:
-- раньше это были -- как правило -- реляционные базы данных
-- сейчас это преимущественно объектные базы (получаемые как нашлепка над реляционной базой). Характерная черта объектной базы -- это работа в терминах классов (с наследованием, в том числе множественным) и их атрибутами.
Современный сервер MDM, репозиторий САПР и ERP -- это объектная (постреляционная) база данных.
Для начальства лучше всего про рефакторинг корпоративных информационных систем научились рассказывать люди из MDM (master data management). У них самые лучшие презентации, самые лучшие примеры и налаженный лучше всего маркетинг. С учетом того, что они оккупировали ERP-приложения, пользователями которых очень часто являются менеджеры и финансисты, максимальное количество IT-денег на подобный "рефакторинг для программирования в большом" уходит именно в сторону MDM. Поэтому люди даже из CAD/CAM/CAE/PLM задумываются, не начать ли им говорить на этом языке MDM (а пока у них язык PDM/PLM).
4. Сегодняшний этап "рефакторинга" (то есть интеграции приложений с "выносом за скобки" одинаковых знаний) всех этих мастер-данных, НСИ, приводит к следующим проблемам:
-- требуется интегрировать знания/каталоги/справочные данные для всего жизненного цикла, т.е. собирать эти данные из всех частных приложений CAD/PLM, PIM (product information management), ERP и т.д.. Для структурирования этих знаний нужна новая парадигма, ибо тут задействуются и "процессы", и "продукты", и "акторы" (организации -- роли и инструменты) и модели/метамодели и многое другое. По факту нужно принять подход каталогов методов, как интегрирующих другие каталоги (продуктов, сервисов, инструментов и т.д.).
-- работа с системой, элементом системы (в каталоге!) и физическим продуктом. Явное введение "тега" для использования этого системного языка (см. презентацию Мэтью Веста -- http://www.vniiaes.ru/files/RuSEC%202010.rar).
-- объектные схемы определяются даталогически (т.е. игнорируя прикладное значение классов и их атрибутов): значение определяется логикой приложений, а выбираемые для наименования классов и атрибутов слова ситуативны и многозначны. Например, "модификатор" -- типичное название атрибута, но смысл "модификации" будет понятен только прикладной программе. Поэтому при объединении всех этих MDM, справочников и репозиториев возникают огромные проблемы соотнесения. Эти проблемы относятся не столько к традиционной для MDM проблеме "разницы в написании одинакового", сколько в "разном значении одинаково написанного" -- плюс разные средства валидизации целостности (например, как в физике: "контроль размерности при вычислениях", т.е. контроль типов). Решением этой проблемы является наличие независимой от отдельных приложений "связной картины мира" (upper ontology), к которой подвязываются все приложения -- тем самым происходит контроль типов.
-- как верно было замечено в работах консорциума EPISTLE, "что для одного приложения атрибут, то для другого приложения класс". Общая объектная база данных не получается из объединения нескольких объектных баз. Для решения этой проблемы нужно перейти к безатрибутной, т.е. факт-ориентированной модели данных. Это трипл-стор, OWL, SPARQL.
Тем самым очередное продвижение в "рефакторинге" корпоративных информационных систем интеграции данных состоит в их вышеописанной семантизации:
- каталоги методов (а не только продуктов и акторов), структурирование в соответствии с метамоделью ISO 24744 [но этот извод деятельностного подхода пока не нашел отражения в промышленности, разве только как переход к "процессному подходу", чего явно недостаточно].
-- использование системного подхода и тегов, чтобы отследить связь между каталогами элементов системы, системой и физическим продуктом.
-- использование upper ontology (конкретного продукта или нейтральной -- типа ISO 15926, расширенного средствами представления методов и систем
-- использование факт-ориентированного хранилища данных (т.е. трипл-стор), позволяющего организовать онтологическую работу.
5. Это смена парадигмы с "объектной" на "семантическую". В центре этого мира уже не база данных, не "репозиторий/хранилище данных", а "справочная библиотека" (то бишь, как ее обозвали в ISO 15926 -- "библиотека справочных данных", то есть повторно используемых данных, т.е. знаний).
6. Даже SOA с объектной должна стать семантической! И тут нужно обязательно добавить, что SOA отражает ход от "продуктов" и "объектам" к методам работы, учитывающим также собственно работы (процесс, происходящий во времени). Так что SOA явление не временное, а постоянное: это попытка перейти к комплексным описаниям метода, составленного из элементарных компонент метода. Каталоги сервисов -- это полноправные каталоги методов, только в их зачаточной стадии, и ограниченные строго IT-составляющими. Так что неизбежна как семантизация SOA, так и выход понятия "сервис" за рамки чисто айтишного сервиса. Другое дело, что ситуационная инженерия методов говорит про все то же самое, что SOA, только более внятным языком.
7. Из существенных препятствий для построения полноценных каталогов методов нужно отметить
а) необходимость разбирательства с текущей множественностью представления работ (ибо со множественностью представления продуктов уже кое-как учатся справляться):
-- жизненные циклы/процессы разработки
-- workflow/процессы в смысле BPMN 2.0 (включая issue tracking/поручения)
-- проекты (в смысле управления проектами)
-- сервисы (попытка перейти от акторов/producers (люди, инструменты -- организация) к выполняемым ими работам, то есть шаг от акторов-объектов к их процессной стороне)
-- организационные транзакции (в смысле DEMO)
Понятно, что тут нужно использовать подход ISO 42010, и никаких "суммы атрибутов" -- только аккуратные correspondence rules между различными viewpoints.
б) разобраться с иерархизацией метода-для-системы (с тегами), т.е. сделать мереологию для методов.