Технологический стек, вертикальная интеграция, расширенное предприятие и нейронет-стек
Вертикальная интеграция у меня тут понимается почти традиционно (а хоть и по определению в википедии -- "степень владения одним холдингом инфраструктурой, бизнес-процессами, технологиями, компетенциями и т. д. в цепочке процессов производства товара или услуги (направление к поставщикам сырья - назад; направление к потребителям - вперёд"). Слово "почти" -- это уход от рассмотрения только холдингов с общим владельцем и переход к рассмотрению расширенных предприятий (работа на один результат в supply chain). Расширенное предприятие может существовать и на "рамочных соглашениях" (постоянные поставщики, "по потребности"), и на отдельных договорах -- это очень динамическая структура.
Лучшая схема, на которой видно ограничение подобного подхода и неприменимость слова "вертикальная интеграция" (там ведь отнюдь не одна "вертикаль", там огромные развесистые "деревья"!) -- это знаменитая древняя схема производства карандаша (кликабельно, а полный текст можно найти в http://www.trendfollowing.com/whitepaper/I-Pencil-2006-edition.pdf):
Из этой схемы и попытки представить что-то подобное не для карандаша, а для какого-нибудь большого Dreamliner или небольшого робота становится ясно, что и "вертикаль" (передел одного какого-то продукта) и "холдинг/предприятие" -- это слишком большая натяжка, переупрощение.
Если обсуждать инженерную сторону дела, то нам нужно представить, как из модулей собирается конечный продукт -- и тут ставится задача модульного синтеза, в этом огромном дереве нужно выделить какие-то "модули". Напомню, что "модули" -- это рассмотрение устройства системы с точки зрения её реализации, а "компоненты" -- это рассмотрение системы с точки зрения её работы (подробней см. учебник "Системноинженерное мышление", http://techinvestlab.ru/systems_engineering_thinking).
Модули появляются там и тогда, где и когда связи имеют стоимость (http://arxiv.org/abs/1207.2743) и более того -- если уменьшить связность модулей в системе, то проще добиваться её улучшений (http://www.pnas.org/content/108/22/9008.full). Итого: вся эта вертикальная интеграция -- это про то, каким образом нам наиболее рационально разбить систему на модули с наименьшим числом связей, чтобы потом устроить сборочный конвейер:
-- чтобы каждая функция была реализована в модуле наилучшим образом (чувствительность, скорость, надёжность работы, производительность, энергоёмкость и т.д. -- чтобы всё было на-ура!)
-- чтобы каждый модуль имел правильный интерфейс, минимизирующий общее число связей между модулями и облегчающий проектирование, сборку и отладку системы. Внутри модуля плотность связей должна быть большая, а вот межмодульных соединений должно быть мало -- модули должны быть как можно более автономны. При одинаковом уровне качества выигрывает тот набор модулей, у которых интерфейс лучше.
Межмодульные интерфейсы решают всё: это границы, которые из мира мелких объектов вырезают модули так, чтобы они могли исполнить роли функциональных элементов (компонент) на какой-то принципиальной или технологической схеме, описывающей функционирование целевой системы.
Pedro Domingos разбирает необходимость модуляризации на примере задач искусственного интеллекта, приводит множество примеров (http://homes.cs.washington.edu/~pedrod/papers/ai100.pdf) -- он ищет "интерфейс" (в его варианте -- interface layer) алгоритма самого искусственного интеллекта, внутри которого функции вывода (inference) и обучения (learning), а использовать этот интерфейс будут программы планирования, обработки естественного языка, зрения, робототехники. Вот его слова: "Интерфейс позволяет каждой инновации ниже его автоматически становиться доступной всем приложениям выше его, без того, чтобы инфраструктурные исследователи знали все детали приложения или даже вообще предполагали какие приложения существуют или возможны".
Группа модулей, имеющих какой-то общий интерфейс -- это платформа, само название предполагает, что в ней много модулей для реализации какого-то целевого набора функций, и что эти модули могут быть использованы для построения на их основе самых разных других целевых систем. Платформы собираются в "стеки", каждый уровень модулей в которых разделён интерфейсом в определённом стандарте/протоколе -- интернет-стек, стек семантического веба, интеллект-стек (http://ailev.livejournal.com/1210678.html краткий текст, и подробное видео доклада http://ailev.livejournal.com/1222210.html).
Pedro Domingos ратует за то, чтобы иметь "платформу" (набор модулей, с общим интерфейсом) искусственного интеллекта. И если ему удастся удачно определить интерфейс для такой платформу (как в свое время удачно определили интерфейсы интернета и семантического веба), то дальше не нужно заботиться о том, чтобы тщательно подгонять каждый набор модулей платформы этого искусственного интеллекта под каждое новое приложение, залезая к ним внутрь и меняя их конструкцию.
Процессоры, библиотеки программ, винтики и насосы, и даже искусственные интеллекты не должны подгоняться и кастомизироваться под каждое их использование! Они должны браться готовыми, с полочки, по описанию в строчке каталога -- и эта строчка содержит ссылку на стандарт интерфейса, что и позволяет использовать модули той или иной платформы при проектировании, не заглядывая к ним внутрь.
С точки зрения вертикальной интеграции это всё равно: сырьё перерабатывается постадийно, или одни модули изготавливаются из других. Просто термин "вертикальная интеграция" отражает интерес (stakeholder concern) собственника производства тех или иных модулей, а "технологический стек" отражает интерес инженера, собирающего какое-то очередное программное приложение или выпускающего какой-то очередной "передел".
Проблема в том, что победа в конкуренции и инновации обеспечиваются на несколько уровней ниже по технологическому стеку -- победа алгоритмов deep learning в интеллект-стеке была обеспечена после того, как платформа CPU была заменена платформой GPU. Победа спортивных яхт и самолётов над конкурентами обеспечивается использованием композитных материалов для их строительства -- по крайней мере, так это было совсем недавно. Ибо сейчас это общее место, как и использование GPU для deep learning. Вертикальная интеграция тем самым --- обоюдоострый меч: либо спасение (если инновация случилась в том уровне стека, который контролируешь ты), либо беда (ты владеешь фирмой, которая реализует предыдущий уровень стека). В любом случае, контроль над несколькими уровнями технологического стека, над несколькими переделами позволяет не только получить бОльшую долю прибыли от заплаченных за конечную систему денег потребителя, но и воспользоваться инженерным преимуществом "подстройки интерфейса" именно под свои приложения -- снизу доверху, по всему контролируемому участку стека.
Ужас в том, что каждый уровень стека обычно -- это отдельная профессиональная тусовка, отдельные журналы, отдельные конференции, отдельные средства производства, отдельные учебные заведения, всё разное! Владеть большой "вертикалью" могут позволить себе только большие холдинги, и только у них может хватить запаса средств пережить пересборку стека по мере появления инноваций (им ведь для этого нужно избавиться от одного производства и заполучить другое -- а это время и инвестиции). К счастью, в наше интернет-время доступ к информации о продуктах и услугах всё лучше и лучше, и наслаждаться пониманием ситуации на довольно больших "вертикалях" могут и не очень большие компании, просто "вертикальная интеграция" происходит в рамках расширенного предприятия. Хотя да, "наслаждаться пониманием ситуации" -- это не наслаждаться всей прибылью от продаваемого продукта, она будет уходить разным поставщикам в составе "вертикали".
В любом случае, поставщик конечных систем должен быть очень внимателен ко всему стеку, чтобы не пропустить новаций на нижних уровнях -- когда появились приемлемые цифровые видеоматрицы и убогая флеш-память, Kodak и Polaroid не обратили на это внимания, а Canon и Nikon обратили. Результат всем известен.
Упражнение:
-- нарисуйте технологический стек (в терминах продуктов, или практик по созданию этих продукта -- дисциплин и технологий, или наборов протоколов) для вашей целевой системы.
-- сколько уровней технологического стека контролируете вы?
-- на каком уровне технологического стека вы ожидаете приход той молодой шпаны, которая снесёт ваш текущий продукт с лица земли?
Я вот предложил в http://ailev.livejournal.com/1227614.html в рамках нейронета задачу создания виртуального помощника для коллектива, который будет особенно полезен на той стадии, когда коллектива ещё почти нет. Этот виртуальный (т.е. представленный аватаром, но сразу многим людям -- как в фильме "Her") помощник работает как заправский нейролингвистический программист, помогая людям осознать (вывести на уровень сознания, перевести из глубокой в поверхностную структуру) их интересы, намерения, опасения, идеи и тем самым помогая начать проект.
Эта задача создания виртуального интеллектуального коллективного помощника требует прежде всего:
-- инженерной отрисовки технологического стека (набора технологических стеков -- помним, что там не "вертикали", а "деревья") целевой системы,
-- затем предложения жизненного цикла по созданию такой системы (т.е. нужно определить набор практик -- дисциплин и технологий, которые необходимы для создания каждого уровня стека),
-- а дальше нужно согласно inverse Conway maneuver (https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver) предложить организационный вариант "вертикальной интеграции" -- производственной кооперации, способной реализовать эти практики для всех недостающих на сегодня элементов стека (а в нейронете там почти все уровни стека сегодня "недостающие"),
-- и уже после этого, приняв все предпринимательские решения (какие уровни стека нам нужно контролировать и каким способом -- где просто "участвовать в работе", где "закупать готовое", где "обязательно быть собственником"), начинать стартап-деятельность -- где-то налаживать контакты, где-то организовывать компании с нуля, где-то покупать уже имеющиеся на рынке компании, где-то просто брать готовые open source продукты, а где-то влезать в соразработчики таких продуктов, а где-то и закупать коммерческие продукты и сервисы.
На данный момент я вижу в таком нейронет-проекте несколько совсем разных платформ:
-- методологии концептуального проектирования (предпроектной работы), "как из ничего появляется проект". Интересы, определение системы, майевтика и т.д.. Тут может быть отмоделирован exellence известных успешных методологий формирования проектов и концептуального проектирования.
-- концептуальный моделер с возможностью включения неформальных описаний -- разнообразные концептуальные (может быть, основанные не только на категориальных, но и на некатегориальных представлениях -- http://ailev.livejournal.com/1228029.html) визуализации определений использующей, целевой и обеспечивающей системы. Это САПР -- система автоматизация предпроектной работы
-- управление конфигурацией и изменениями (CLM -- управление жизненным циклом концептуальной модели, а после формирования проекта там будет PLM/ALM).
-- нейролингвистическая работа: выявление интересов, ассоциаций, синестезий, биообратная связь по состояниям и т.д.. Вот тут основное "нейро", причём в обе стороны (восприятие-понимание в сторону "ассистента", и его аватаризация в сторону членов целевой команды -- коммуникация двусторонняя). Не уверен, что в первой же версии тут будет нейрофизиология -- может быть, на первых порах будет классическое "нейролингвистическое программирование", где "оператором" выступает наш "ассистент", использующий только видеокамеру и микрофон. Какие-то движения в этом направлении идут в openmeta.
-- "железо" (устройства отображения информации и датчики, вычислительные мощности, помещения и т.д.).
Это только самый-самый первый подход к формулированию нейронет-стека, но уже видна запредельная его сложность. Каждая платформа определяется своим технологическим стеком, и требует кооперации очень разных коллективов разработчиков, использования знаний и наработок самых разных предметных областей.
* * *
Ровно такую же уже готовую систему неплохо бы иметь для проведения самой этой работы -- концептуального проектирования этого самого коллективного ассистента. Но, увы, её ещё нет, так что будем обходиться обычными сегодняшними средствами поддержки коллективной разработки на ранних стадиях. Например, вот этой записью в моём блоге и возможностями по её комментированию. ;)
Лучшая схема, на которой видно ограничение подобного подхода и неприменимость слова "вертикальная интеграция" (там ведь отнюдь не одна "вертикаль", там огромные развесистые "деревья"!) -- это знаменитая древняя схема производства карандаша (кликабельно, а полный текст можно найти в http://www.trendfollowing.com/whitepaper/I-Pencil-2006-edition.pdf):
Из этой схемы и попытки представить что-то подобное не для карандаша, а для какого-нибудь большого Dreamliner или небольшого робота становится ясно, что и "вертикаль" (передел одного какого-то продукта) и "холдинг/предприятие" -- это слишком большая натяжка, переупрощение.
Если обсуждать инженерную сторону дела, то нам нужно представить, как из модулей собирается конечный продукт -- и тут ставится задача модульного синтеза, в этом огромном дереве нужно выделить какие-то "модули". Напомню, что "модули" -- это рассмотрение устройства системы с точки зрения её реализации, а "компоненты" -- это рассмотрение системы с точки зрения её работы (подробней см. учебник "Системноинженерное мышление", http://techinvestlab.ru/systems_engineering_thinking).
Модули появляются там и тогда, где и когда связи имеют стоимость (http://arxiv.org/abs/1207.2743) и более того -- если уменьшить связность модулей в системе, то проще добиваться её улучшений (http://www.pnas.org/content/108/22/9008.full). Итого: вся эта вертикальная интеграция -- это про то, каким образом нам наиболее рационально разбить систему на модули с наименьшим числом связей, чтобы потом устроить сборочный конвейер:
-- чтобы каждая функция была реализована в модуле наилучшим образом (чувствительность, скорость, надёжность работы, производительность, энергоёмкость и т.д. -- чтобы всё было на-ура!)
-- чтобы каждый модуль имел правильный интерфейс, минимизирующий общее число связей между модулями и облегчающий проектирование, сборку и отладку системы. Внутри модуля плотность связей должна быть большая, а вот межмодульных соединений должно быть мало -- модули должны быть как можно более автономны. При одинаковом уровне качества выигрывает тот набор модулей, у которых интерфейс лучше.
Межмодульные интерфейсы решают всё: это границы, которые из мира мелких объектов вырезают модули так, чтобы они могли исполнить роли функциональных элементов (компонент) на какой-то принципиальной или технологической схеме, описывающей функционирование целевой системы.
Pedro Domingos разбирает необходимость модуляризации на примере задач искусственного интеллекта, приводит множество примеров (http://homes.cs.washington.edu/~pedrod/papers/ai100.pdf) -- он ищет "интерфейс" (в его варианте -- interface layer) алгоритма самого искусственного интеллекта, внутри которого функции вывода (inference) и обучения (learning), а использовать этот интерфейс будут программы планирования, обработки естественного языка, зрения, робототехники. Вот его слова: "Интерфейс позволяет каждой инновации ниже его автоматически становиться доступной всем приложениям выше его, без того, чтобы инфраструктурные исследователи знали все детали приложения или даже вообще предполагали какие приложения существуют или возможны".
Группа модулей, имеющих какой-то общий интерфейс -- это платформа, само название предполагает, что в ней много модулей для реализации какого-то целевого набора функций, и что эти модули могут быть использованы для построения на их основе самых разных других целевых систем. Платформы собираются в "стеки", каждый уровень модулей в которых разделён интерфейсом в определённом стандарте/протоколе -- интернет-стек, стек семантического веба, интеллект-стек (http://ailev.livejournal.com/1210678.html краткий текст, и подробное видео доклада http://ailev.livejournal.com/1222210.html).
Pedro Domingos ратует за то, чтобы иметь "платформу" (набор модулей, с общим интерфейсом) искусственного интеллекта. И если ему удастся удачно определить интерфейс для такой платформу (как в свое время удачно определили интерфейсы интернета и семантического веба), то дальше не нужно заботиться о том, чтобы тщательно подгонять каждый набор модулей платформы этого искусственного интеллекта под каждое новое приложение, залезая к ним внутрь и меняя их конструкцию.
Процессоры, библиотеки программ, винтики и насосы, и даже искусственные интеллекты не должны подгоняться и кастомизироваться под каждое их использование! Они должны браться готовыми, с полочки, по описанию в строчке каталога -- и эта строчка содержит ссылку на стандарт интерфейса, что и позволяет использовать модули той или иной платформы при проектировании, не заглядывая к ним внутрь.
С точки зрения вертикальной интеграции это всё равно: сырьё перерабатывается постадийно, или одни модули изготавливаются из других. Просто термин "вертикальная интеграция" отражает интерес (stakeholder concern) собственника производства тех или иных модулей, а "технологический стек" отражает интерес инженера, собирающего какое-то очередное программное приложение или выпускающего какой-то очередной "передел".
Проблема в том, что победа в конкуренции и инновации обеспечиваются на несколько уровней ниже по технологическому стеку -- победа алгоритмов deep learning в интеллект-стеке была обеспечена после того, как платформа CPU была заменена платформой GPU. Победа спортивных яхт и самолётов над конкурентами обеспечивается использованием композитных материалов для их строительства -- по крайней мере, так это было совсем недавно. Ибо сейчас это общее место, как и использование GPU для deep learning. Вертикальная интеграция тем самым --- обоюдоострый меч: либо спасение (если инновация случилась в том уровне стека, который контролируешь ты), либо беда (ты владеешь фирмой, которая реализует предыдущий уровень стека). В любом случае, контроль над несколькими уровнями технологического стека, над несколькими переделами позволяет не только получить бОльшую долю прибыли от заплаченных за конечную систему денег потребителя, но и воспользоваться инженерным преимуществом "подстройки интерфейса" именно под свои приложения -- снизу доверху, по всему контролируемому участку стека.
Ужас в том, что каждый уровень стека обычно -- это отдельная профессиональная тусовка, отдельные журналы, отдельные конференции, отдельные средства производства, отдельные учебные заведения, всё разное! Владеть большой "вертикалью" могут позволить себе только большие холдинги, и только у них может хватить запаса средств пережить пересборку стека по мере появления инноваций (им ведь для этого нужно избавиться от одного производства и заполучить другое -- а это время и инвестиции). К счастью, в наше интернет-время доступ к информации о продуктах и услугах всё лучше и лучше, и наслаждаться пониманием ситуации на довольно больших "вертикалях" могут и не очень большие компании, просто "вертикальная интеграция" происходит в рамках расширенного предприятия. Хотя да, "наслаждаться пониманием ситуации" -- это не наслаждаться всей прибылью от продаваемого продукта, она будет уходить разным поставщикам в составе "вертикали".
В любом случае, поставщик конечных систем должен быть очень внимателен ко всему стеку, чтобы не пропустить новаций на нижних уровнях -- когда появились приемлемые цифровые видеоматрицы и убогая флеш-память, Kodak и Polaroid не обратили на это внимания, а Canon и Nikon обратили. Результат всем известен.
Упражнение:
-- нарисуйте технологический стек (в терминах продуктов, или практик по созданию этих продукта -- дисциплин и технологий, или наборов протоколов) для вашей целевой системы.
-- сколько уровней технологического стека контролируете вы?
-- на каком уровне технологического стека вы ожидаете приход той молодой шпаны, которая снесёт ваш текущий продукт с лица земли?
Я вот предложил в http://ailev.livejournal.com/1227614.html в рамках нейронета задачу создания виртуального помощника для коллектива, который будет особенно полезен на той стадии, когда коллектива ещё почти нет. Этот виртуальный (т.е. представленный аватаром, но сразу многим людям -- как в фильме "Her") помощник работает как заправский нейролингвистический программист, помогая людям осознать (вывести на уровень сознания, перевести из глубокой в поверхностную структуру) их интересы, намерения, опасения, идеи и тем самым помогая начать проект.
Эта задача создания виртуального интеллектуального коллективного помощника требует прежде всего:
-- инженерной отрисовки технологического стека (набора технологических стеков -- помним, что там не "вертикали", а "деревья") целевой системы,
-- затем предложения жизненного цикла по созданию такой системы (т.е. нужно определить набор практик -- дисциплин и технологий, которые необходимы для создания каждого уровня стека),
-- а дальше нужно согласно inverse Conway maneuver (https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver) предложить организационный вариант "вертикальной интеграции" -- производственной кооперации, способной реализовать эти практики для всех недостающих на сегодня элементов стека (а в нейронете там почти все уровни стека сегодня "недостающие"),
-- и уже после этого, приняв все предпринимательские решения (какие уровни стека нам нужно контролировать и каким способом -- где просто "участвовать в работе", где "закупать готовое", где "обязательно быть собственником"), начинать стартап-деятельность -- где-то налаживать контакты, где-то организовывать компании с нуля, где-то покупать уже имеющиеся на рынке компании, где-то просто брать готовые open source продукты, а где-то влезать в соразработчики таких продуктов, а где-то и закупать коммерческие продукты и сервисы.
На данный момент я вижу в таком нейронет-проекте несколько совсем разных платформ:
-- методологии концептуального проектирования (предпроектной работы), "как из ничего появляется проект". Интересы, определение системы, майевтика и т.д.. Тут может быть отмоделирован exellence известных успешных методологий формирования проектов и концептуального проектирования.
-- концептуальный моделер с возможностью включения неформальных описаний -- разнообразные концептуальные (может быть, основанные не только на категориальных, но и на некатегориальных представлениях -- http://ailev.livejournal.com/1228029.html) визуализации определений использующей, целевой и обеспечивающей системы. Это САПР -- система автоматизация предпроектной работы
-- управление конфигурацией и изменениями (CLM -- управление жизненным циклом концептуальной модели, а после формирования проекта там будет PLM/ALM).
-- нейролингвистическая работа: выявление интересов, ассоциаций, синестезий, биообратная связь по состояниям и т.д.. Вот тут основное "нейро", причём в обе стороны (восприятие-понимание в сторону "ассистента", и его аватаризация в сторону членов целевой команды -- коммуникация двусторонняя). Не уверен, что в первой же версии тут будет нейрофизиология -- может быть, на первых порах будет классическое "нейролингвистическое программирование", где "оператором" выступает наш "ассистент", использующий только видеокамеру и микрофон. Какие-то движения в этом направлении идут в openmeta.
-- "железо" (устройства отображения информации и датчики, вычислительные мощности, помещения и т.д.).
Это только самый-самый первый подход к формулированию нейронет-стека, но уже видна запредельная его сложность. Каждая платформа определяется своим технологическим стеком, и требует кооперации очень разных коллективов разработчиков, использования знаний и наработок самых разных предметных областей.
* * *
Ровно такую же уже готовую систему неплохо бы иметь для проведения самой этой работы -- концептуального проектирования этого самого коллективного ассистента. Но, увы, её ещё нет, так что будем обходиться обычными сегодняшними средствами поддержки коллективной разработки на ранних стадиях. Например, вот этой записью в моём блоге и возможностями по её комментированию. ;)