Category: производство

2019

Доклад "Будущее инженерии"

Сделал сегодня доклад "Будущее инженерии" на стратегической сессии лаборатории робототехники "Сбербанка", вот слайды доклада: https://yadi.sk/i/u4ObuTYbbPgf-g (видео не писалось).

Многое я уже рассказывал в других местах, но кое-что было и новое. Например, цикл жизни технологий (обсуждалось недавно в https://us13.campaign-archive.com/?u=67bd06787e84d73db24fb0aa5&id=320c223523):
-- Standardisation [deep learning – ONNX, и весь AI сейчас по факту ещё и этой фазы не достиг, то есть это всё ещё игрушки и эксперименты, а не промышленность]
-- Usability (удобные интерфейсы)
-- Consumerization (массовое потребление)
-- Foundationalization (изо всех утюгов, «потребление незаметно»)

Один из ведущих трендов в AI сегодня: «индустриализация» -- уменьшение затрат (в том числе денег, энергии, материалов, времени) на единицу пользы. Гипотеза Rich Sutton: прогресс определяется доступной вычислительной мощностью при простых алгоритмах. Вот максимизировать использование вычислительной мощности -- это и есть задача индустриализации. Ускорить сетку вдесятеро, или уменьшить потребную мощность вдесятеро -- вот это всё и есть индустриализация. Сегодня AI очень дорогой по времени и ресурсам, вот это и решается индустриализацией -- переход к массовости возможен после обрушения цены. И вот эти standardisation-usability-consumerization-foundationalization и есть стадии, по которым лабораторная технология становится промышленной.

Вот ещё модифицированная V-диаграмма с парой трендов на ней:
Vtwins

Штука в том, что digital twin идёт из воплощения системы в обеспечение (традиционное обсуждение того, зачем нужен digital twin -- диагностика, эксперименты what if, данные для дообучения алгоритмов управления, данные для улучшения варианта следующей конструкции и т.д.), а документация системы из обеспечения в воплощение (автономность, resilience, самодиагностика, самодонастройка и прочее для resilience).
2019

Слова-термины важны, и не важны

Вчера мы с участниками моего шестидневного тренинга разбирали парадокс "обращайте внимание на слова, не обращайте внимания на слова". У нас письменная или устная речь -- это основной канал получения информации о чьей-то стейкхолдерской роли, интересе этой роли, предпочитаемых методах описания для удовлетворения интереса, описаниях систем (stakeholder -- concern -- viewpoint -- view). Но обольщаться цепочками букв нельзя: в разных словарных сообществах они означают разное, так что те или иные термины просто позволяют иметь гипотезы про используемое стейкхолдером "пространство имён", и ещё обозначают какое-то место в пространстве смыслов. Обращаем внимание на слова как флажки, которые указывают на какие-то места в пространстве смыслов, но ищем обозначаемый словами смысл в пространстве смыслов (подробней про пространство смыслов в моей книжке "Визуальное мышление" -- https://ailev.livejournal.com/1437344.html).

Помогут ли нам в этом определения? Нет, не помогут (подробней тут: https://ailev.livejournal.com/1365963.html). Но поможет разбирательство с окружением слов: концепты редко используются поодиночке, поэтому и слов-терминов обычно встречается довольно много и можно дальше строить гипотезы о том, как концепты соотносятся между собой (Витгенштейн: ничего нельзя сказать об объекте самом по себе, кроме того, как он соотносится с другими объектами). Для этого нужно поглядеть, какие термины используются рядом (буквально: рядом по тексту) с интересующим вас термином. Определение тут не поможет, а разбирательство с какой-нибудь диаграммой или отрывком текста, набором развёрнутых высказываний -- поможет.

Так что разбираемся со словами-терминами (обращаем на них внимание!), определяем их смысл, вытаскиваем из этих слов безымянный концепт, который на разных профессиональных языках самых разных сообществ имеет самые разные имена -- и дальше работаем с концептом (не обращая на слова-термины внимания!).

Вот вам говорят: "возможности" (для вящей убедительности добавляя "бизнес" -- "бизнес-возможности"). Первый же тест: пытаетесь перевести, например, на английский -- это будет opportunity, или capability? В предпринимательстве обычно opportunity, в оргстроительстве -- capability. Слово business в IT просто означает "организационный". Так что это, скорее всего, "организационные возможности", то есть capability. И учитываем, что capability бывают и в IT (например, обсуждение capabilities в их отличии от tokens см. в 2007 году -- https://ailev.livejournal.com/490654.html).

Но что это означает? Что в голове говорящего? Правильный ответ: неизвестно! Но можно строить гипотезы, ибо вероятность того, что "ихние доллары -- это наши баксы" обычно довольно велика. Их "capability" -- это антагонист для разворачивающихся во времени процессов, уход от засилья процессного подхода, это функциональные объекты предприятия, практики, это ход к жизненному циклу 2.0: функциональное описание жизненного цикла, компетентностное разделение труда по разным практикам-деятельностям, а не разделение работ как супер-процессов. Вот я писал ровно это ещё в 2013 году, когда всё это начиналось (но писал довольно мутно): https://ailev.livejournal.com/1068096.html. А вот по итогам всех дискуссий год назад, в августе 2017 (https://ailev.livejournal.com/1369625.html): "capability -- это поставленная практика, возможность осуществления функции (т.е. готовность предоставления сервиса какими-то модулями, поддерживающими практику)". И там же слова, что необязательно пользоваться всеми значками Архимейта, в том числе значком capability. Это же мнения Максим Смирнов, указывающий на неудачку Архимейта в определении capability: он рекомендует сравнить постановку проблемы в 2012 году https://archimatemusings.wordpress.com/2012/12/27/missing-from-archimate-business-capability/ и получившийся результат в 2016 http://pubs.opengroup.org/architecture/archimate3-doc/chap07.html#_Toc489946034 в своём посте "Что не так с TOGAF 9.2" https://mxsmirnov.com/2018/07/27/togaf-9-2/ (я, кстати, давно говорю, что не ходите люди, в TOGAF, добра от этого не будет). Я вот тоже в 2011 году описывал вселенскую путаницу между использованием слов function и capability в чуть ли не десятке разных методов описания предприятий -- https://ailev.livejournal.com/938820.html.

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

1. Внимание к словам стейкхолдера. Нужно смириться и считать, что стейкхолдер говорит не столько на иностранном языке, сколько уж точно на диалекте с хитрыми значениями некоторых знакомых вроде бы слов. Это миф, что под словом "capability" или "function" (если уж они из одного естественного языка) скрывается одно и то же место в пространстве смыслов -- особенно, если речь идёт о переводах на русский. Переспрашивайте про разные примеры (не определения!), заставьте стейкхолдера попродуцировать разные тексты на его профессиональном диалекте, чтобы было понятно, как именно употребляет стейкхолдер эти якобы всем понятные слова. Подтвердите гипотезы, какие концепты системного подхода наиболее близки к употребляемым концептам стейкхолдера. Так, клиент сказал про "организационные возможности" -- переспросите прямо: может ли он привести пару примеров. Подтвердите ваши гипотезы, используя концепты системного подхода. Например, имеет ли он ввиду работы/процессы/развёртку во времени (динамическое описание), или речь идёт о функциональном описании? Это внешнее поведение для какого-то модуля (сервис, оказываемый на интерфейсе), или внутреннее (функция?).

2. Слова для вас неважны, важны концепты. Так что продолжайте говорить со стейкхолдером на его языке. Переучивать и нельзя, и вредно: вы разрушите язык, на котором стейкхолдер имеет максимальную интуицию про свою предметную область -- если у него есть эта интуиция. Если играет роль стейкхолдера случайный человек, то он не стейкхолдер, внятного интереса у него нет, "роль не выучил", слов не знает, то есть профессиональным диалектом не владеет, интуиции его нет, а если и есть, то ошибочна и т.д. -- тогда или меняйте представителя стейкхолдера на другого исполнителя, или уж учите какому хотите диалекту, дайте ему любимую вашу практику. Но вы теперь знаете, о чём говорит стейкхолдер в системной картине мира. И поэтому понимаете, чего в этой картине мира не хватает: об этом можно спросить и этого стейкхолдера, и других стейкхолдеров. Например, можно спросить, что там с работами и управлением работами, если стейкхолдер зациклен на своих "оргвозможностях". Потому как с "оргвозможностями" может быть полный порядок, но вот с управлением работами будет полный беспорядок. Или наоборот: скрупулёзное выполнение бессмысленных и бесплодных работ, ибо "оргвозмножности" окажутся непроработанными, неполными.

Если речь идёт о предпринятии (это не опечатка, см. учебник "Системное мышление"), то при таком подходе теряет смысл сама дискуссия о "правильных переводах", например, для понятий языка ArchiMate: можете использовать оригинальные английские термины -- но всё одно ваши клиенты не будут вас понимать. Поэтому смело меняйте эти термины на термины клиентского диалекта, тем не менее оставляя суть концепта, наиболее близкую к концептам системного подхода.

Например, вы пришли в организацию, в которой люди говорят на диалекте, заимствованном из Banking Industry Architecture Network (BIAN) "How-to Giude", http://bian.org/deliverables/bian-how-to-guide/, и узнаёте, что там различают capability и processes, это подробно разъясняется в пункте 1.2 "BIAN How-to Guide Design Principles & Techniques V6.0" http://bian.org/wp-content/uploads/2018/02/BIAN-How-to-Guide-Design-Principles-Techniques-V6.0-Final-V1.0.pdf. Ага, понятно: речь идёт о практиках против работ. Хуже того, они поясняют, что слово capability они тоже не используют, а вместо него для отделения (partitions) разных оргвозможностей друг от друга они используют слова Service Domain. Ага, тоже понятно: сервисный подход (то есть речь идёт о системе, оказывающей сервис), при этом речь идёт о предметной области (не об определении сервиса, а о воплощении сервиса). Так что имеется ввиду сервис, реализующий какую-то практику. Обсуждаем назначение, дисциплину, инструменты и рабочие продукты, исполнители с их компетенциями. Управление жизненным циклом. Поскольку дисциплина (предметная область) определяется тут, то хорошо говорить о переносе знаний. BIAN так и говорит, что Capability Model (про Service Domains) отлично служит для стандарта описания деятельности (слово "деятельность" ещё один словесный маркер для "практики", для функционального описания) банка. Моделировать в Архимейте это хорошо "орг.сервисом" (business service), ибо это внешнее представление для практики.

А вот BIAN Business Scenario -- это процесс, последовательность выполнения практик. Обсуждаем оркестровку, время выполнения, требуемые для выполнения ресурсы, операционный менеджмент. И, конечно, процессы с их винегретом участвующих практик плохи для работы со знаниями предметной области, с их описанием в стандарте. Они уникальны для каждой организации, это практики похожи. Так и пишут: process models due to their very flexibility are not good for defining canonical standards for anything but the most commodity and predictable type of behavior. Моделируем в Архимейте "оргпроцессом" (business process).

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

Теперь берём другой стандарт описания деятельности, в этот раз APICS Supply Chain Operations Reference model (SCOR, http://www.apics.org/apics-for-business/frameworks/scor), SCOR Overview -- https://www.apics.org/docs/default-source/scor/scor_overview-participant-workbook.pdf?sfvrsn=2

Там processes с показываемым между ними material flow, последовательность операций. И менеджерские practices (их там 170 штук, и дальше они оркеструются в процессы). Вау, тут по факту та же терминология, что использована в OMG Essence -- но речь идёт не о сервис-ориентированном подходе, а о просто функциональном рассмотрении, когда речь идёт о практиках. Не внешнее представление (организационная инкапсуляция важна), а внутреннее. Так что моделировать в архимейте эти практики можно сразу оргфункциями (business function), а сервисы будут инкапсулировать выполнение этих практик на каких-то организационных интерфейсах.

В любом случае мы понимаем, что все эти capability и practices это про одно, а process, stages, tasks -- про другое, это разные системные view.

Мы обязаны их найти в самых разных Body of Knowledge, деятельностных стандартах, архитектурных языках. Нам всё равно, как они там называются, но они должны быть. Мы должны найти слова, которыми обозначаются эти концепты системного подхода в соответствующих профессиональных диалектах (слова важны!), но нам неважно, какие именно будут эти слова (слова неважны!). Если мне нравится какой-то котёнок, то мне неважно, как его зовут (слово неважно!). Но важно, чтобы хоть как-то звали, чтобы я мог отличить его от других. Если хозяева никак котёнка не зовут, я сам его назову приятным мне именем. А если хозяева его уже назвали, то я буду пользоваться именем, которое ему уже дали, но внутри себя я могу его и по-своему называть, это моё дело. Главное, чтобы это своё имя в коммуникацию не лезло. А если это котёнок по имени "Гав!" (слова важны!), то я лишний раз должен убедиться, что речь идёт именно о котёнке, а не о собаке. И если это таки котёнок -- ну что же, будем морщиться, но называть его "Гав!" (про себя называя Муркой или Мурзиком).

Но зачем нужны примеры? Почему нельзя опираться только на определения. Ну, например, чтобы лучше понимать, что обычно (но не всегда!) capabilities и practices это про одно, а процессы про другое. Вот вам capability map (https://bizzdesign.com/blog/archimate-3-0-capability-mapping/) для ArchiSurance:
Blog-ArchiMate_3_Capability_Mapping

А вот Microsoft Industry Reference Architecture for Banking (https://bizzdesign.com/blog/reference-architecture-models-with-archimate/):
The_Business_Reference_Model

Видно, что никакой развёртки во времени, никакой стадийности. И видно, что по большому счёту неважно, какими значками Архимейта это показывать. Если хочется сделать акцент на внутренних практиках в работе каких-то подразделений, то оргфункции. Если хочется сказать, что выполнение этих практик доступно извне, то это можно дать оргсервисами. А можно и использовать значок capability, помня, что дискуссий по поводу этого значка множество, и пройти по линии оргсервиса было бы надёжней. Можно поиграться, сказав, что capability -- это оргсистема, оказывающая сервис (но почему-то не совпадающая по границам с оргзвеном/ответственным/actor). Можно всё, если вы понимаете, что а) вы говорите в рамках концепций системного подхода, и б) как это будет услышано на профессиональном диалекте тех стейкхолдеров, с которыми вы будете разговаривать.

Помним, что даже слово "процесс" сегодня очень часто означает ту самую "практику" и не подразумевает никакой оркестровки выполнения практик во времени, а оркестровка практик тогда будет описываться другим словом -- оркестровка, или "процедура", или "сценарий". Так что не обольщайтесь, что вы сразу понимаете, услышав знакомый термин, о чём идёт речь.

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

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

Встраивание проекта в программу: анонс курса

Вот видеоанонс доклада А.Турханова по встраиванию проекта в программу, который будет 8 февраля 2018 года на заседании сообщества Школы системного менеджмента (https://www.facebook.com/alex.turkhanov/videos/10215024391140284/):


Мы обсуждали этот материал на заседании методсовета Школы 25 февраля 2018, и обратите внимание на русскоязычную терминологию -- там есть много интересных наших находок последнего времени.

Сейчас много говорится про "нужно уметь встраиваться в технологические цепочки", "нужно уметь вписываться в бизнес-эко-системы", так вот доклад как раз об этом -- как вообще про это думать. И это уже второй доклад по теме. В первом бралось DEMO и препарировалась альфа "Работа" -- https://ailev.livejournal.com/1386628.html. Через некоторое время я надеюсь на полноценный прикладной курс по этой теме "наш проект в их программе" (ну, или "наша программа в их программе", или "как нам воткнуться в промышленную кооперацию", у этой типовой ситуации много имён).

Увы, содержание доклада без прохождения курса онто-логического фитнеса (или аналогичной самоподготовки) и системного мышления (или аналогичной самоподготовки) просто не понять. Все эти "обеспечивающие системы" да "онтики". Поэтому доклад главным образом будет для сообщества выпускников Школы (http://system-school.ru/event/seminar-soobshtestva-shkol-kak-polyzovatysya-spektrom-mshleniya-vo-vsm-diapazone-ot-intuitivnogo-do-formalynogo-2018-02-08/). Они поймут. Это не сектантство, это не эзотерика. Все слова из международных стандартов, ничего сами не выдумываем. Просто за пару часов доклада и обсуждения нужно обсудить довольно много материала, и нужно его уметь компактно излагать. Без "умных слов" получится впятеро дольше, обсуждения "на пальцах" займут два дня. Собственно, и сам доклад во многом про это: без специальных знаний по инженерии предприятия и знаний по системной инженерии втыкаться в более-менее сложные промышленные кооперации уже сложно, а будет ещё сложней. Так что придётся садиться за парту и осваивать все эти многочисленные практики, а в них хитромудрые дисциплины и навороченные технологии. Никто не обещал, что в 21 веке с бизнесом будет легко.
* * *
А пока потихоньку готовится этот новый тренинг (или даже не тренинг, а практикум -- не только новый материал, упражнения и решения задач, но и рабочие сессии на реальном материале участников), Александр будет вести 10-11 февраля 2018 очередной поток тренинга "Основы системного лидерства": http://system-school.ru/event/kurs-osnov-sistemnogo-liderstva-2018-02-10/.
2019

WiFi роутер как радиолокатор

Самые интересные фразы в современных работах по WiFi-локации, так это typical household Wi-Fi transmitters operating in the 2.4 and 5 gigahertz bands were sufficient ... Even Bluetooth and cell phone signals can be used. The wavelengths of these devices correspond to a spatial resolution of a few centimeters. ... Future Wi-Fi frequencies, like the proposed 60 gigahertz IEEE 802.11 standard will allow resolutions down to the millimeter range -- https://www.tum.de/en/about-tum/news/press-releases/detail/article/33897/. И речь идёт не просто о радиолокации, а о построении трёхмерной голограммы.

И применения WiFi-локаторов могут быть самые необычные. Ссылка вверху говорит про отслеживание движения заготовок по цеху. Но могут быть и более оригинальные применения, типа эмоции-радиолокатор. Измеряют ритм сердцебиения и дыхания по отражениям WiFi сигнала, из них определяют эмоции с 87% вероятностью -- http://eqradio.csail.mit.edu/, http://bigthink.com/robby-berman/new-tech-can-accurately-read-the-emotions-you-may-be-hiding

И это в тот самый момент, когда алгоритмы компьютерного зрения на базе deep learning показывают чудеса в оптическом диапазоне. Как будто мало этих чудес, ещё давай! Микроволновую голограмму давай, от WiFi роутера, и чтобы через стену видел и под одеждой!

UPDATE: обсуждение https://www.facebook.com/ailevenchuk/posts/10210258988045170
2019

Автомагическое моделирование данных

Сегодня с одним из западных инженеров обсуждали странное: он утверждал, что любые попытки автоматизировать инженерную работу будут наталкиваться на саботаж со стороны инженеров -- ибо общепринятый способ оплачивать инженерный труд это почасовка, а автоматизация эту почасовку значительно уменьшает. Про конкуренцию ему, похоже, ничего не известно, "все инженерные компании во всех странах не хотят автоматизировать работу с данными -- там везде технологии 80-х, большие стройки идут на эксель-таблицах". Он считал, что "не хотят". Моя точка зрения -- "не могут".

Разнообразные PLM-системы крайне трудно осваиваются (практики управления конфигурацией и изменениями контринтуитивны и трудоёмки), но не в этом дело. Дело в том, что такие системы крайне трудно интегрируют в себя разные виды инженерных данных, особенно если речь идёт о небольших компаниях. Этот западный инженер сказал, что в его знакомой компании вся инженерия обслуживается главным образом пятью сотнями эксель-табличек, связь между которыми есть только в головах людей. И если где изменить одну цифирьку, то это потом нужно отразить ещё в 10-15 местах, о которых люди должны помнить -- само там ничего не изменится, а должно бы. Но тратить время на выкладывание из головы связей между таблицами экселя никто не будет, "нас и так неплохо кормят" -- так не только российские инженеры говорят, но и многие западные.

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

Я рассказал про интересные новости в части прохода от формального языка к естественному языку для работы с данными -- Naturalizing a Programming Language via Interactive Learning, https://arxiv.org/abs/1704.06956. we start with a core programming language and allow users to "naturalize" the core language incrementally by defining alternative, more natural syntax and increasingly complex concepts in terms of compositions of simpler ones. ... Over the course of three days, these users went from using only the core language to using the naturalized language in 85.9\% of the last 10K utterances.

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

Например, ещё есть заход Wolfram language с попыткой принимать запросы на естественном языке (с переспросами, если что-то неочевидно).

Экспериментов много, но промышленного прорыва, как с тем же самым экселем или реляционными базами данных, нет. Таблицы вместо текста оказались killer application. Графы вместо текста много, много богаче таблиц. Они радуют глаз, когда они на страницу. А когда они в промышленных масштабах, то глаз радуется, а мозг огорчается. А таблицы в промышленных масштабах мозг не расстраивают, хотя таблицы и не так красивы для глаза. Следствие: нерасстроенный и радостный мозг не знает, как все эти таблицы объединять! Поэтому строит граф, но "в уме", а не "в компьютере".

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

Искусственный интеллект, решающий задачи моделирования, выделения важного из неважного, абстрагирования (специально не пишу тут слова "автоматизация", потому как речь не идёт о замене человека -- тут будет какой-то совсем другой набор практик. Так, персональный компьютер не автоматизировал работу секретарей и операторов ЭВМ, хотя и отнял у них работу. То же самое будет и с моделированием данных: ИскИн не автоматизирует работу сегодняшних модельеров-онтологов, он предложит совсем другие способы решения проблем.

А зачем вообще нужна эта формализация в инженерных проектах? Зачем моделировать данные и интегрировать затем эти модели данных? Для управление конфигурацией, отслеживания конфигурационных коллизий, организации проверок непротиворечивости и полноты описания системы. Все формализмы нужны прежде всего для гарантирования этой "правильности", "целостности", "непротиворечивости", "актуальности". Если мы хотим что-то воплотить в жизнь, получить хорошо работающее в реальном физическом мире, то описание этого чего-то в мире виртуальном должно быть непротиворечиво и полно. Легче всего это описание проверить, если его делать на языке без неоднозначностей, и этот язык должен выражать всё самое важное для создания системы и опускать неважное. То есть язык должен быть формальным, или формальным оестествлённым (но не естественным с его неоднозначностью и склонностью смешивать в тексте собственно содержание и множество ассоциаций, которые иногда могут быть полезны, но чаще только отвлекают).

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

Разговор с тем инженером закончился приятно: он похвалил наш инструмент -- .15926, https://github.com/TechInvestLab/dot15926. Славный был проект, мы многому в ходе этой работы научились.

UPDATE: дискуссия в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10210042527753798
2019

Об отрасли

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

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

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

Опять же слово "профиль" для фирмы тут не о чём, но явно лучше "отрасли" -- не вызывает ненужных ассоциаций принадлежности или подчинённости, но только ассоциации временной специализации, которую ежели чего можно и сменить. И понимание, что одна фирма часто отличненько работает на многих рынках, а не только в одной "отрасли".

Это я опять поругал профессии (напомнил про "закат профессий" http://erazvitie.org/article/zakat_professij), и заодно коснулся отраслей вот тут, в дискуссии про "Атлас профессий": https://www.facebook.com/shperk/posts/10157628132965153. В этой дискуссии Павел Лукша заметил, что и отраслей в будущем не будет -- и этому там удивились. Моя же точка зрения, что отраслей давно уже нет, фиктивное это понятие. Подведение предприятия под "отрасль" обычно непродуктивно и отражает не производственные, а регуляторные или прикладные маркетинговые реалии. Хотя в речи слово есть, и будет использоваться ещё много лет, как и слово "профессия", но его использование обычно не добавляет понимания. Нужно менять язык.

Хотя я сам раньше пользовался словом "отрасль", как и все -- ибо жил бок о бок с регуляторами. Вот, поглядите, например на мой текст 2004г., где я критиковал отраслевую концепцию развития ("рынка IT"): http://ailev.livejournal.com/246534.html. Там отрасль на отрасли и отраслью погоняет. Но уже в 2010 году я и использовал слово "отрасль" и возражал против этого (например, в пункте 1): http://ailev.livejournal.com/843404.html. А сейчас и вовсе избегаю, вполне сознательно. Слово "рынок" тут и то лучше. Ибо на рыке платежей сейчас и банки (по регулированию), и провайдеры сотовой связи с их телефонными платежами, и фирмы типа QIWI, а говорить об "отрасли" уже трудно -- ибо кто в эту "отрасль" из перечисленных попадает?!

UPDATE: в фейсбуке обсуждение тут -- https://www.facebook.com/ailevenchuk/posts/10208471452517899
2019

lytdybr

Обновил список системных мышлем в http://ailev.livejournal.com/1278600.html (по итогам обсуждений curriculum learning http://ailev.livejournal.com/1282190.html и с учётом предложений vvagr). До сих пор не могу определиться, как лучше: литературней, вроде, "мыслемы", но мне-то не мысль нужно, а мышление тренировать -- и язык всё время хочет говорить "мышлемы", элементы мышления.

В фейсбуке ввязался дискуссию про системную инженерию в СССР (и как сладко и державно в СССР было жить) по мотивам цитаты из моего учебника: https://www.facebook.com/mikhail.sofonov/posts/10210276152965443. Как всегда, набежали системотехники и начали рассказывать про великость системного подхода 1.0 и достижения отечественной системотехники.

В deep learning ложное затишье. Просто раньше было кап-кап-кап -- и каждая капелька была событием. А сейчас идёт бурный поток, и не понимаешь уже, что отслеживать -- героический период уже заканчивается, начинаются промышленные будни. Ну, типа полупроводниковой промышленности через пару лет после выхода Intel 4004. Дальше нужно придумать аналог закона Мура, типа "удвоения IQ вдвое за год" -- что бы там это IQ ни значил для слабого искусственного интеллекта. Помним, что этот IQ определяется как скорость решения множества мелких разнородных тупых задачек -- он на низкоуровневый процессинг. Вот тут трёхдневной давности список likely AI andvancements in the next 5 to 10 years от Yan LeCun, и по каждому направлению там кипит-бурлит: https://www.quora.com/What-are-the-likely-AI-advancements-in-the-next-5-to-10-years (и добавьте туда causal и counterfactual inference из https://www.quora.com/What-are-some-exciting-but-overlooked-developments-in-ML-research, а я ещё считаю, что уменьшение размерности плавающих в обучении, AutoML и аппаратный разгон ещё добавят жару). В любом случае, отслеживать происходящее уже очень сложно. Вон, почитайте ленту: https://vk.com/deeplearning.

Отрок осваивает синусы-косинусы, но шутки типа "в военное время синус до трёх доходил" понять пока не может. И вообще, вернулся из каких-то странствий Виталик, поэтому сегодня никакой геометрии и физики не было, был полный день Space Engineers, до состояния невменяемости. Завтра опять без геометрии и физики: тёща берёт его и жену за шкирку и отвозит на десять дней в Светлогорск (я опять вежливо выслушал традиционную тёщину лекцию про йод в воздухе из Балтийского моря, его безусловную пользу для подрастающих организмов, но сам останусь в Москве: у них троих уже сейчас коренные разногласия про времяпрепровождение в тамошних краях, я не буду им в этом мешать. Пусть тёща повоспитывает дочку и внучка эти десять дней без моего участия).

Вчера умер Сеймур Пейперт -- https://habrahabr.ru/company/edison/blog/277799/. Я в какой-то мере считаю себя прямым наследником каких-то его идей -- по лини Пейперт-Ершов-группа Аттик мехмата МГУ-я. Вот буквально пару дней назад поминал его в дискуссии, http://ailev.livejournal.com/1282836.html.
2019

Архимейт 3.0, теперь со стратегией и физикой

Cмотреть новую спецификацию (формально вышла позавчера) ArchiMate 3.0 вот тут: http://pubs.opengroup.org/architecture/archimate3-doc/

Авторский коммент "что там нового": http://blog.bizzdesign.com/archimate-3.0-the-next-step-in-the-evolution-of-the-standard, формальный список изменений -- http://pubs.opengroup.org/architecture/archimate3-doc/apdxe.html#_Toc451758153 (в частности, отношение used_by изменено на serving, к motivation elements добавлен outcome, infrastructure переименовали в technology и т.д.).

Из главных новинок -- выполнение стратегии (элементы resource, capability и course of action -- используется в связке с motivation elements) и физический слой для IoT и Industrie 4.0. (то есть стандарт из кибер стал киберфизическим -- элементы equipment, facility, material, distribution network -- и communication path стал просто path, чтобы включить сюда и физику).

Конечно, много ещё не столь инновационной полировки напильником по тексту. Хотя добавленный механизм кастомизации нельзя сказать, что "мелкое дополнение". Факт-ориентированность Архимейта закончилась, можно добавлять атрибуты. Специализировать элементы можно было и раньше, но появились в количестве informative примеры этой специализации (типа business collaboration может быть специализирована до social network -- A social structure made up of social actors (individuals or organizations) and the connections between these actors. Пример специализаций Course of Action как раз Strategy и Tactic). И появились "профили", что по факту означает возможность препрограммирования в моделерах каких-то специализированных для тех или иных применений версий языка на базе предопределённых наборов специализированных элементов языка с их атрибутами.

Редакторы для всех этих новаций пока платные, Archi будет попозднее (разработчик ищет денег на разработку апгрейда -- http://forum.archimatetool.com/index.php?topic=229.0, "If funding is successful we are aiming for around October/November 2016").

Одновременно иметь стратегию и (кибер)физику в ArchiMate -- это очень сильный ход. Понятно, что версию 3.1 с корретировкой ошибок нужно ждать очень скоро (ибо наверняка там противоречий при добавлении физики осталось предостаточно), но и текущий вариант вдохновляет и открывает новые горизонты.
* * *
Мои посты по русификации Архимейта (версии 2.1) по ссылкам тут: http://ailev.livejournal.com/988360.html
2019

lytdybr

Смог сегодня знатный, впрочем, как и вчера (яркое солнце весь день, но Останкинской башни было совсем не видно), и так уже пару месяцев. Это означает, что промышленное производство и торговля наконец-то на подъёме -- самый существенный провал у них был летом и ранней осенью: я за последние 10 лет таких чистых пейзажей и яркой линии горизонта никогда не видел. Это мой такой экономический индикатор: в кризисы воздух чистый и в речках рыба появляется. Если воздух грязен и в речках промышленные отходы, значит экономическая жизнь на подъёме. Если природа девственно чиста, то это просто все умерли.

Домашняя ёлка потихоньку пилится и идёт на корм и точение зубов зайцу. У зайца от ёлки полное счастье, остаются только хорошо обглоданные палки, даже без мелких сучков. Ещё выяснилось, что заяц охотно кушает сыр Маасдам. Ёлка с сыром, хм.

Подписался на месяц бесплатного http://zvooq.ru (месяц пробный, потом нужно платить), подписанным выдают HQ звук. Вроде как HQ слушается получше. Вроде как. Может быть. Музыка всё больше и больше уходит в фон, так что не до смакования качества. Рассказали бы мне двадцатилетнему, как я буду относиться к музыке в далёком будущем, и сколько у меня этой музыки будет в доступе -- я б это счёл ненаучной фантастикой и долго бы злился, писал бы себе записки в будущее и расстраивался от разбазаривания и пренебрежения.

Пришёл спам: мне готовы организовать трёхчасовую персональную экскурсию на Серова, за 1500 рублей помимо стоимости билетов. Вежливо предупреждают, что выставка только до 31 января. Звонить Гюльнаре (Гуля). Вдобавок к Серову с выломанными дверями, палатками МЧС и полевой кухней, теперь ещё от него и нигерийские письма.
2019

Робототехнические промыслы есть, ждём-с робототехнической промышленности.

У Алексея Корнилова гениальное по поводу RoboticsExpo 2015: "российская робототехника как промысел" (https://www.facebook.com/alx.kornilov/posts/1688695584675337).

Роботехнический промысел, точно! Из википедии (https://ru.wikipedia.org/wiki/Промысел) -- "Про́мысел — занятие, с целью получения выгоды, каким-либо делом в объёме, который может обеспечить, полностью или частично, доход, необходимый для жизни занимающегося промыслом и его семьи. Промыслом можно заниматься в одиночку или группой, которая называется чаще артелью, или, что встречается реже, бригадой. «Промышлять» — означает «заниматься каким—либо промыслом». Промыслы по характеру своей деятельности можно подразделить на те, в которых производится что-либо и те, в которых добывается что-либо, созданное природой. Производственные промыслы обыкновенно называются ремёслами, а вторые зовутся либо «добычей» либо, в каждом конкретном случае имеют своё специфическое название".

И дальше там: " С появлением в каком-либо ремесле всё большего количества сложных и энергоёмких машин и механизмов, и, особенно, с привлечением достижений науки, промысел перерастал в промышленность. Наличие сложных и многочисленных машин и механизмов и наукоёмких процессов — именно та грань, за которой кончается промысел и начинается промышленность."

Робопромыслы по факту уже есть (вон, у меня отрок в кружке тоже робота делает, вот прямо сейчас!), они повсеместны, ждём-с теперь появления всё большего количества сложных и энергоёмких машин и механизмов, а также наукоёмкости, чтобы можно было говорить о промышленности!