Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Category:

Эволюция иженерной практики интеграции данных жизненного цикла

Я 27 апреля 2011 выступал в МИСиС на конференции "Сложные технические системы: развитие современных инженерных практик" (http://misis.ru/ru/ctl/Details/mid/3194/ItemID/5379) с докладом "Эволюция инженерной практики интеграции данных жизненного цикла". Знай наших, системных инженеров: аплодисменты сорвали только я и тоже член INCOSE Виктор Батоврин (а всего из членов Русского отделения INCOSE на этой конференции выступало аж трое человек).

Сегодня организаторы выложили стенограмму выступлений. Я слегка отредактировал свой текст, а слайдов у меня и не было. Вот этот доклад:


Итак, уважаемые дамы и господа, я понимаю, что оказался последним докладчиком. Я в полном ужасе, потому что если в предыдущих докладах мы хотя бы могли совместно обсуждать такие слова как «риск» (хотя и оказалось, что риск тут все по-разному понимают), «надежность» или «информатизация жизненного цикла», то сейчас (уж так повезло в процессе эволюции темы моего доклада) мне придется рассказать об эволюции инженерной практики интеграции данных жизненного цикла. Если я вам начну сейчас рассказывать про интеграцию данных жизненного цикла (а я начну!), то, боюсь, многие тут просто не будут понимать, о чем речь. Но это моя задача, поэтому давайте я медленно начну, и самое непонятное будет в середине.

Я начну с заголовка, поскольку название конференции и предмет моего доклада связано с инженерными практиками. Что такое «практики»? Я понимаю практики как почти синоним к "дисциплине" и "процессу" (не тому, который разворачивается во времени, а к тому логическому процессу, который понимается как "что обычно делают люди"). В учебном заведении это соответствует "предмету". То есть я должен вам рассказать эволюцию [учебного] предмета "интеграция данных жизненного цикла".

Хитрость в том, что "процесс" обычно делают люди, а люди никогда не делают "процесс" независимо, а только всегда в составе метода. То есть, все эти "практики" -- это только часть полного метода работы. А о чем еще рассказывается в методах, кроме практик? В методах еще рассказывается про организации, которые состоят из людей, закупленных для этих людей инструментов, как эти люди расставлены и взаимодействуют друг с другом. Продукты работы – это то, над чем работают эти практики. И еще есть жизненный цикл, потому что практики воплощаются в жизнь в ходе жизненного цикла, и эта их реализация в жизни называется «предпринятием». Практики представляют из себя такую библиотечку, и мы берем знания из этой библиотечки и далее их выполняет человек, который в ходе жизненного цикла в каждый конкретный определенный момент времени что-то делает. Вот так практика и воплощается в жизнь.

Дальше речь идет о практике интеграции данных жизненного цикла. Некоторое время назад было бы даже трудно себе представить, чтобы мы говорили об интеграции данных жизненного цикла, потому что никто не знал, что есть такой "жизненный цикл". Многие и сейчас не догадываются, что такое «данные жизненного цикла». Они определяются очень просто, как данные, которые появляются и потребляются в любой точке жизненного цикла, лишь бы они были связаны с целевой системой нашей работы. Тем самым мой доклад о том, как эволюционировали наши знания о том, как работать с данными, которые появляются и потребляются в любой точке жизненного цикла.

Тут надо сказать, что не всё так просто, потому что иногда данные появляются на стадии эксплуатации, а потребляются во время проектирования (можно пообсуждать, того же жизненного цикла или следующего его прохождения). Иногда это бывает наоборот, как описывали другие докладчики: данные проектирования потребляются много позже, на стадии вывода из эксплуатации. Но, вообще говоря, мы должны сейчас рассматривать вот эту практику интеграции данных жизненного цикла.

И тут я далеко отойду от области собственно инженерных практик и скажу, что как только я произнес слово «эволюция», к тому же эволюция того, что делают люди (ведь сами практики без людей мертвы, это просто библиотека, и практики в ходе конкретного жизненного цикла каким-то образом проявляются в деятельности людей), то это уже не инженерия, а инженерный менеджмент, а именно та его часть, которая называется управление технологиями (technology management). Иногда это управление технологиями настолько важно, что его вытаскивают как «engineering and technology managment". Таким образом, в ходе эволюции инженерных практик мы меняем поколения технологий, подразумеваемых поколениями этих практик.

Я долго говорил, что из INCOSE (это ассоциация системных инженеров, и я там до сих пор директор по исследованиям Русского отделения), но вот сейчас я выступаю как пока единственный в России член ASEM -- Американской ассоциации инженерного менеджмента, которая как раз и изучает эти вопросы инженерного менеджмента и управления технологиями. То есть, есть ассоциация, которая должна заниматься эволюцией инженерных практик, и не столько "эволюцией практик вообще в мире", но и на конкретном предприятии: как нам выполнить проект по эволюции текущих используемых на предприятии практик на их следующее поколение. Поэтому у нас вопрос сложный: эволюцию практик мы можем рассмотреть в двух вариантах, 1) как вообще в мире менялись практики интеграции данных жизненного цикла, и 2) как нам сделать смену этих практик, провести их эволюцию на конкретном предприятии. Сразу скажу, что это были бы два совершенно разных доклада. Что делать, не знаю, но, давайте, продолжим говорить на эту тему.

Вот интересный момент из жизни. Года три назад на одной из встреч в Росатоме представитель АЭП, который там заведовал САПРами, вышел и сказал: «Ой, а кто я? Я из айтишников точно вышел (занимался-то он САПРами, и тем самым данными жизненного цикла), а к инженерам так и не дошел. И кто же я после этого? В чем же, собственно, моя практика, в чем мой предмет, кто я по профессии?» И было видно, что он действительно задумался, немножко растерялся -- он свой среди чужих, и чужой среди своих, в общем, ничейный и болтается профессионально не пойми где. Дальше задается вопрос, если мы, занимающиеся данными жизненного цикла, такие профессионально ничейные, то откуда взяться учебникам, по которым надо учиться практикам интеграции данных жизненного цикла? Какие вузы готовят этих профессионалов? И вообще, эти профессионалы интеграции данных жизненного цикла инженеры или нет?

В заголовке доклада интеграция справочных данных -- практика инженерная, и я бы на этом настаивал. Например, наша (TechInsevLab) методика, которую мы одной из последних выпустили, так и называется: «инженерия справочных данных». Это, вообще говоря, интересный вопрос -- инженерные корни специалистов по интеграции данных жизненного цикла. Приглядимся к людям, которые занимаются интеграцией данных жизненного цикла и носят гордый титул «чёрный пояс». В этом международном сообществе интеграторов данных жизненного цикла договорились, что будут квалификацию людей условно обозначать цветом поясов, как в восточных единоборствах: «жёлтый пояс» это те, кто могут принимать решения в масштабе предприятия, а вот те, которые объединились в мировом масштабе и обсуждают вопросы смены поколений своих технологий интеграции данных, у них «чёрный пояс». Люди из команды «чёрных поясов», которые в мире занимается развитием интеграции данных жизненного цикла, кочуют по разным консорциумам по стандартизации. В команде сохраняются одни и те же люди, фамилии их всем известны, и более двадцати лет как они занимаются любительством в области интеграции данных, за это время совсем перестав быть любителями. У них теперь такие титулы, которые позволяют им этим заниматься профессионально, и они как раз и проводят эту эволюцию практики интеграции жизненного цикла, меняют поколения технологии интеграции. Вот эти «чернопоясники» они, на самом деле, раньше были кем? Инженерами, которые занимались трубопроводами. Оттуда и вырастают «черные пояса» по интеграции данных жизненного цикла, а не из айтишников, как можно подумать.

А айтишники почему сейчас в этой сфере в таких количествах? Помните, я в реплике на первом пленарном заседании говорил, что современному инженеру требуется большая подготовка в дисциплине "современная логика"? Если у вас есть эта логическая подготовка, а у айтишников она есть, то сразу будет легче и с данными, и с их интеграцией.

Итак, эти «чёрные пояса» собрались и сказали: «это у нас раньше была "автоматизация", а теперь мы уже наавтоматизировались вволю, и теперь у нас "островки автоматизации", и теперь нужно не столько автоматизировать дальше, сколько надо эти островки друг с другом соединить, т.е. интегрировать данные».

Как до этого интегрировали данные? Переписывали функциональность систем так, чтобы новая система выполняла и функцию одной системы, и функцию другой системы -- то есть, тратили лет десять на это переписывание. Конечно, это нехорошо. Надо, наверное, просто передать данные из одной системы в другую. А эта "другая система" переданных данных вовсе не ждёт, они ей не подходят ни по формату, ни по содержанию. Более того, а иногда эта "другая система" активно сопротивляется, потому что у неё есть свой вендор, и он принципиально не хочет объединения с чужой системой, а говорит, "купите у меня другой мой же модуль, поставьте себе, там будут данные, которые ваша уже купленная система возьмёт как родные". Эта ситуация очень жизненная, и это сопротивление поставщиков программных средств интеграции данных своих систем с чужими является существенным фактором.

Вся нынешняя дисциплина, вся практика интеграции данных – это сегодня борьба с поставщиками программного обеспечения, как раз теми, которые нам поставляет системы PLM, то есть системы интеграции данных жизненного цикла. Этот тезис я готов отстаивать. Еще раз: эволюция интеграции данных жизненного цикла, как практики, это эволюция того, как поставщики PLM выкручивают руки своим клиентам. Поставщики PLM под лозунгом того, что они интегрируют данные жизненного цикла, делают островки автоматизации искблючительно вокруг своих систем, то есть они превентируют эту самую интеграцию островков автоматизации.

Когда-то молодые «чёрные пояса» собрались, и сказали: "мы сейчас всё сделаем, у нас будет стандарт STEP (ISO 10303), в котором мы любые данные жизненного цикла передадим из любой одной точки в любую другую". И всё это с грохотом <вырезано цензурой>… Нет, не с грохотом, но под фанфары: до сих пор у оборонщиков идет реклама «STEP – это наше всё». В основном этот лозунг популярен среди конструкторов, потому что среди проектировщиков STEP относительно неизвестен, ибо уж совсем не справляется, там как-то развиваются только конструкторские данные, ибо STEP отнюдь не со всеми данными справляется. Суровая действительность пришла и сказала: "вообще, все данные вы не сможете проинтегрировать, вы будете интегрировать маленькими кусочками: вот эти данные отдельно, вот эти данные отдельно, а еще вот эти. Назвали эти интегрируемые кусочки в дальнейшем «протокол», и вместо того, чтобы иметь такой большой "англо-любых языков разговорник", мы получили разномастные разговорники отдельно для требований, отдельно для авиаторов, отдельно для автомобилистов. В STEP этих «протоколов» уже пятьдесят или шестьдесят -- много-много маленьких разговорников вместо одного большого.

Вожделенная мечта интеграции данных -- это замена схемы множества уникальных интерфейсов обмена данных "каждый с каждым" на хоть какое-то подобие интеграции со схемой "звезда": от каждого в один и тот же нейтральный формат, а уже из нейтрального формата ко всем, и точно также от всех к каждому через нейтральный формат. В случае STEP для каждой точки мы должны выбрать свой протокол приложения STEP, и поэтому имеем всё то же самое, что в схеме "каждый с каждым", только в этот раз обмен идёт по одному из многочисленных протоколов приложения STEP, но уж ни как не в одном и том же нейтральном формате. "Звезды" не получилось, только модифицированный вариант "каждого с каждым". "Ой!!!", -- сказали практикующие, и на этом "поколение STEP" интеграции данных жизненного цикла закончилось.

Примерно в этот же момент произошло следующее: поставщики САПР выросли и начали развиваться экстенсивно, а не интенсивно. Что это значит? Они от концепции органического роста, когда их программисты кодируют их постепенно растущую модульную программную систему, перешли к тупой скупке более мелких САПР-фирм с успешными разнородными продуктами. И теперь головная боль связать их якобы "линейку продуктов" стала уже не у их клиентов, а у них самих. Вы понимаете, что вы покупаете три разных САПР (вместе с тремя независимыми фирмами их разработчиков), и выясняется, что эти продукты не дружат между собой, а вам надо клиенту показать, что они дружат. Вы быстро-быстро изобретаете концепцию PLM, и пытаетесь делать интеграцию этих САПР через PLM-систему.

Выяснилось, что та тусовка инженеров-трубопроводчиков, которая делала протокол AP221 для непрерывных производств (process plant) стандарта STEP, быстро разошлась по поставщикам PLM, и они там сделали новое поколение практики интеграции данных. На основе выводов доводившего до ума протокол AP221 консорциума EPISTLE эти люди предложили новую интересную архитектуру PLM-системы.

Вот тут и начинается страшное, ибо консорциум стандартизации EPISTLE, который занялся вот этими стандартами, имел нетривиальные выводы.

Я убеждаю всех, что самые интересные разработки происходят в консорциумах по стандартизации, поскольку туда приходят сотрудничать конкуренты, и там возникает взрыв идей -- и самая сильная идея должна победить в ходе её обсуждения конкурентами по бизнесу, а ведь еще эту идею надо уметь письменно изложить в форме стандарта, и убедить людей, чтобы этим добровольно применяемым стандартом пользоваться.

Итак, EPISTLE сделал выводы из своей работы с протоколом AP221 STEP. Один из этих нетривиальных выводов звучал примерно так: "мы должны вместо моделей данных разных предметных областей иметь одну на всех нейтральную общую модель данных, она должна представлять «картину мира»". Тут впервые появляется слово «онтология» (чего раньше в моделировании данных для САПР не было). Бабах! -- и мы опять в современной логике, как дисциплине, в том числе в философской логике. EPISTLE заметил, что, поскольку разные программисты в голове имеют разную картину мира, то неплохо, чтобы при интеграции данных эти частные картины мира программистов соотносились с какой-то общей (разделяемой многими людьми) картиной мира, которая должна быть нейтральна и приложима к разным предметным областям, и именно эту онтологию интеграторы данных и должны разработать. Выяснилось, что дисциплина интеграции данных связана с производством каких-то «картин мира», которые живут не внутри интегрирующих данные предприятий, а как бы "между предприятиями", тем самым будучи нейтральны по отношению к этим предприятиям и нейтральны по отношению к поставщикам средств интеграции данных. И первое, чем занялись эти интеграторы данных -- это не интеграцией данных в рамках одного предприятия, и даже не интеграцией данных в рамках отрасли. Ибо трудно сказать, где у нас граница интеграции данных, если речь зашла о "картине мира" и "онтологии".

Следующее, что есть в выводах EPISTLE: "если у вас картины мира разные, то то, что у вас было атрибутом в одной предметной области, в одном производстве, то в другом производстве это будет объектом. И, наоборот". И вывод этот был страшен, потому что эти "чернопоясники" тем самым сказали, что объекто-ориентированная картина мира, (которой учат сейчас всех, которая является родной для всех айтишников, ибо это и объект-ориентированное программирование, и объектная база данных), этот объектный взгляд на жизнь, о котором нас учат, что это самое естественное -- мы этот объектный взгляд на жизнь выкидываем. Практическое следствие из этого вывода консорциума EPISTLE в том, что современного программиста, поскольку он всегда объектоориентированный, легче убить, чем научить интегрировать данные. Сами программисты говорят, кто начал с Basic, тот никогда не будет настоящим объектоориентированным программистом. А выводы EPISTLE ведут к тому, что если вам свезло для интегрирования данных получить настоящего объект-ориентированного программиста, то сразу убейте его. Лучше берите инженера и учите интегрировать данные этого инженера, у него пока мозги не загажены вот этой айтишной объект-ориентированностью.

Вы понимаете, что я говорю немножко неконвенционально. Но я твердо придерживаюсь темы доклада, я показываю эволюцию инженерной практики интеграции данных. Эта практика после выводов EPISTLE пришла к тому, что она должна бытовать на каких-то других принципах, нежели раньше.

Эта новая архитектура, как ни странно, была отработана примерно в 94-97 годах, и окончательные выводы были в 97 году учтены в тех самых нарождающихся PLM-системах, которые должны были интегрировать скупленные САПР поставщиков инженерного софта. И с тех пор все системы PLM имеют эту архитектуру, в которой существует общая для всех "картина мира". Понятия этой "картины мира" поставщики PLM вводят в свои собственные схемы данных, некоторые эти схемы данных называют «библиотека справочных данных», как и ISO 15926. Документация у них начинается так: «Здравствуйте, уважаемые господа, вы купили софт сервера ISO 15926, и«библиотеку справочных данных» к нему". Начинаешь интересоваться, а там что, в этой библиотеке? Там снимок (snapshot) того, что в 97-м году сделали люди из ЭПИСТЛа как раз в тот момент, когда они сказали «каюк» объектоориентированному подходу.

И этот объект-ориентированный подход в современных PLM, как вы понимаете, остался с того самого 97 года, потому что "нейтральная объект-оринетированная картина мира" для нескольких разных САПР -- это был высший взлёт объект-ориентированного подхода для целей интеграции данных. Одно и то же было практически у всех поставщиков PLM. Тут в зале сидят люди, которые со словом «PLM» знакомы, вы можете залезть под капот вашей системы, и обнаружить, что там 1997 год, изредка 1998, 1999-й и не старше.

Итак, люди из EPISTLE на основании этих выводов начали делать стандарт ISO 15926. Они сказали, что теперь они не объект-ориентированные, а факт-ориентированные. И далее начинается очередная страшилка, потому что -- как только они заинтересовались общей для всех картиной мира, выяснились принципиально разные мнения на этот счёт.

В части 2 стандарта ISO 15926 в качестве учебника указан учебник метафизики, а в других частях там есть еще и доказательства с леммами. Мой партнер по TechInvestLab, когда увидел в стандарте ISO 15926 лемму, сильно удивился, он никогда такого не встречал. И лемма есть, и учебник метафизики – это чтобы нескучно было людям, которые идут заниматься интеграцией данных.

Это и есть сегодняшнее поколение интеграции данных, которое занимается философией логики в полной мере. Это поколение интеграции данных жизненного цикла говорит: "мы принимаем модель времени не 3D (или 3D+1), то есть бытовую модель времени, а с точки зрения необходимости управления конфигурацией и управления изменениями в инженерном проекте мы принимаем модель времени 4D". Что это означает? Единое пространство-время по Эйнштейну, где время это только одна из координат -- такая же, как координата в пространстве. Почему сделан такой необычный выбор? А как в компьютере вы хотите показать, что вот этот "нарисованный насос на чертеже" и вот этот "железный насос, который установлен на объекте", и тот "насос, который поломался" и стоит поэтому незадействованным, и тот "насос, который через двадцать лет будет заказан, причем другой марки" – это всё один и тот же насос, который на чертеже имеет один и тот же функциональный код. Объекты-то в мире разные, хотя назыываются они часто одинаково -- и эту разницу объектов вы должны как-то объяснить компьютеру. Так вот, вы не можете описывать бытовым философским языком это компьютеру, вы должны "повернуть" себе мозги и принять концепцию 4D-времени в целях интеграции данных жизненного цикла -- ибо жизненный цикл разворачивается как раз во времени.

Далее выясняем: кто занимается разработкой теорий 4D-времени? Я нашел логико-философский кружок на философском факультете ГУ ВШЭ, и начал там задавать вопросы про 4D-время. А ведь на заседания этого кружка приезжал Юрий Балашов -- русский ученый, давно уехавший на Запад и много лет там живущий, он как раз один из ведущих в мире ученых по 4D-времени. Наши лучшие физики (Балашов был когда-то из МФТИ) приезжают сюда с докладами, пока еще говоря не с сильным акцентом. И вот я тоже на эти заседания приезжаю, говорю: "вот у вас тут изучается David Lewis, его модальный реализм, как вы тут к этому относитесь? Вот мы тут инженеры, очень интересуемся!". Они мне говорят: "Какие такие инженеры? Мы тут логики-философы! Как, у вас программное обеспечение поддерживает идеи David Lewis? Но это же только чистая теория!".

Вот это и есть сегодня такое состояние практики интеграции данных жизненного цикла, когда суть практики обсуждается в логико-философском кружке философского факультета ГУ ВШЭ. А софт, который стоит в инженерных фирмах, работает как раз вот с этой логико-философской сутью. И нет людей, которые соединяют все это друг с другом. То есть такие люди, соединяющие логико-философские основания с программным обеспечением интеграции данных жизненного цикла, конечно есть, но в мире их еще не очень много.

Это есть сегодняшнее состояние в эволюции инженерной практики интеграции данных жизненного цикла. Нужна работа по получению интеграторов данных то ли из инженеров, то ли из логиков-философов, то ли еще откуда-то. Это и есть текущая наша работа.

Спасибо за внимание. (Аплодисменты.)
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 5 comments