Справочные, конфигурационные, трансакционные данные
Похоже, что деления на два типа данных (справочные и проектные как в смысле design так и в смысле project) недостаточно. Более осмысленное деление такое:
-- справочные данные: картина мира, как он устроен везде -- учебники, классификаторы, справочники, стандарты, законы, upper и middle ontology и т.д.. В общем, НСИ в ассортименте, правила и ограничения живут тут. Знайте, в каком мире живёте, здесь вам не тут.
-- конфигурационные данные: функциональное и конструктивное знание о целевой и обеспечивающих системах (это и есть design и организационная часть от project -- то бишь organizational design). Инженер, знай свою систему-железку. Менеджер, знай свою систему-организацию. Знайте, с чем работаете.
-- трансакционные данные: данные об изменениях (временные ряды в ходе operations, первичка для внесения изменений в конфигурацию design, в том числе обеспечивающие системы и системы в операционном окружении). Это, по большому счёту, информация разных сообщений.
Скажем, у меня счёт депозита у провайдера в рублях, на счету 100 рублей. Справочные данные -- про то, какой счёт, про то, что на счету рубли. Состояние счёта -- конфигурационные данные. Конфигурация счёта сейчас -- 100руб. А рядом горка сведений по приходам и расходам за последний месяц. Это трансакционные данные, они были важны только для того, чтобы зафиксировать изменяющие конфигурацию трансакции. Ну, и (как всегда) что для одного трансакция (а хоть и длиной в год), для другого -- вполне себе конфигурация. ISO 15926 и его 4D экстенсионализм в помощь для решения этой проблемы.
Фишка в том, что управление конфигурацией легко объяснять финансистам. А вот в российском инженерном укладе оно как-то не развито. Оно некоторое время назад и в западном инженерном укладе было не развито (так, одну из штатовских атомных станций остановили именно потому, что управление конфигурацией там было потеряно: не смогли объяснить инспекторам, какое оборудование реально стоит на станции, и какой набор чертежей является описанием реально установленного оборудования -- финансовый аналог тут "не смогли сказать, сколько у них на счёте"). Но на западе инженеры хотя бы знают такое слово, а в России и слова такого не знают (есть, конечно, инженерный учёт, но он устроен по-другому при взгляде на полный жизненный цикл сложной инженерной системы).
Я косвенно проверил это. Примерно год назад я спросил в ACDM (http://acdm.org, Association for Configuration and Data Management), есть ли там ещё члены из России, кроме меня. Мне ответили, что я первый. То есть управление конфигурацией на плечах каких-то наших кулибиных где-то как-то выезжает (иначе вообще бы всё загнулось), но как дисциплина и профессия не живёт, да и слова такого нету.
То же, что и с системной инженерией: слова такого нету (не называть же это "генеральным конструкторством" -- в институтах ведь такому не учат!), профессии нету, учебных курсов нету, явного обсуждения и связанного с явным обсуждением улучшения практик нету, конференций нету. То же для управления конфигурацией (ну, и по причастности -- управления данными).
Но чёрт с ним, с отсутствующим управлением конфигурацией, фрагментарными и неактуальными данными о конфигурации. Не буду плакаться о том, что западные цветочки цивилизации плохо сеять в нашу каменистую почву. Если на всю страну найдутся несколько предприятий, которые сообразят, что им это нужно, мне на кусочек хлеба с маслом хватит, а мегаломанией по преобразованиям в геополитических масштабах одной седьмой части суши пусть страдают экспертократы.
Мораль этого моего поста такая: онтологии (в том числе и технологии semantic web) позволяют, конечно, существенно снять важность различения справочных, конфигурационных и трансакционных данных -- но только в отношении их однообразного представления. А вот практики работы со всеми этими данными на предприятии разные, и типология "справочные -- конфигурационные -- трансакционные" отражает именно эти практики. Поэтому "инженерия справочных данных" устроена одним образом, управление конфигурацией -- другим образом, а обработка трансакций -- третьим. Разные практики, разные слова, разные данные. Одно представление данных.
UPDATE: программистам просьба расслабиться. Я тут про нефтеперерабатывающие заводы и атомные станции, а не про управление конфигурацией в программной инженерией. Есть многое на свете, друг Горацио, что и не снилось нашим программистам. Большинство российских программистов про управление конфигурацией откуда-то знают (хотя не всегда успешно этой конфигурацией управляют). Но вот что касается российского "реального сектора" (конфигурации железа и бетона), то именно там проблемы.
-- справочные данные: картина мира, как он устроен везде -- учебники, классификаторы, справочники, стандарты, законы, upper и middle ontology и т.д.. В общем, НСИ в ассортименте, правила и ограничения живут тут. Знайте, в каком мире живёте, здесь вам не тут.
-- конфигурационные данные: функциональное и конструктивное знание о целевой и обеспечивающих системах (это и есть design и организационная часть от project -- то бишь organizational design). Инженер, знай свою систему-железку. Менеджер, знай свою систему-организацию. Знайте, с чем работаете.
-- трансакционные данные: данные об изменениях (временные ряды в ходе operations, первичка для внесения изменений в конфигурацию design, в том числе обеспечивающие системы и системы в операционном окружении). Это, по большому счёту, информация разных сообщений.
Скажем, у меня счёт депозита у провайдера в рублях, на счету 100 рублей. Справочные данные -- про то, какой счёт, про то, что на счету рубли. Состояние счёта -- конфигурационные данные. Конфигурация счёта сейчас -- 100руб. А рядом горка сведений по приходам и расходам за последний месяц. Это трансакционные данные, они были важны только для того, чтобы зафиксировать изменяющие конфигурацию трансакции. Ну, и (как всегда) что для одного трансакция (а хоть и длиной в год), для другого -- вполне себе конфигурация. ISO 15926 и его 4D экстенсионализм в помощь для решения этой проблемы.
Фишка в том, что управление конфигурацией легко объяснять финансистам. А вот в российском инженерном укладе оно как-то не развито. Оно некоторое время назад и в западном инженерном укладе было не развито (так, одну из штатовских атомных станций остановили именно потому, что управление конфигурацией там было потеряно: не смогли объяснить инспекторам, какое оборудование реально стоит на станции, и какой набор чертежей является описанием реально установленного оборудования -- финансовый аналог тут "не смогли сказать, сколько у них на счёте"). Но на западе инженеры хотя бы знают такое слово, а в России и слова такого не знают (есть, конечно, инженерный учёт, но он устроен по-другому при взгляде на полный жизненный цикл сложной инженерной системы).
Я косвенно проверил это. Примерно год назад я спросил в ACDM (http://acdm.org, Association for Configuration and Data Management), есть ли там ещё члены из России, кроме меня. Мне ответили, что я первый. То есть управление конфигурацией на плечах каких-то наших кулибиных где-то как-то выезжает (иначе вообще бы всё загнулось), но как дисциплина и профессия не живёт, да и слова такого нету.
То же, что и с системной инженерией: слова такого нету (не называть же это "генеральным конструкторством" -- в институтах ведь такому не учат!), профессии нету, учебных курсов нету, явного обсуждения и связанного с явным обсуждением улучшения практик нету, конференций нету. То же для управления конфигурацией (ну, и по причастности -- управления данными).
Но чёрт с ним, с отсутствующим управлением конфигурацией, фрагментарными и неактуальными данными о конфигурации. Не буду плакаться о том, что западные цветочки цивилизации плохо сеять в нашу каменистую почву. Если на всю страну найдутся несколько предприятий, которые сообразят, что им это нужно, мне на кусочек хлеба с маслом хватит, а мегаломанией по преобразованиям в геополитических масштабах одной седьмой части суши пусть страдают экспертократы.
Мораль этого моего поста такая: онтологии (в том числе и технологии semantic web) позволяют, конечно, существенно снять важность различения справочных, конфигурационных и трансакционных данных -- но только в отношении их однообразного представления. А вот практики работы со всеми этими данными на предприятии разные, и типология "справочные -- конфигурационные -- трансакционные" отражает именно эти практики. Поэтому "инженерия справочных данных" устроена одним образом, управление конфигурацией -- другим образом, а обработка трансакций -- третьим. Разные практики, разные слова, разные данные. Одно представление данных.
UPDATE: программистам просьба расслабиться. Я тут про нефтеперерабатывающие заводы и атомные станции, а не про управление конфигурацией в программной инженерией. Есть многое на свете, друг Горацио, что и не снилось нашим программистам. Большинство российских программистов про управление конфигурацией откуда-то знают (хотя не всегда успешно этой конфигурацией управляют). Но вот что касается российского "реального сектора" (конфигурации железа и бетона), то именно там проблемы.