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

Посмотрим, как эти принципы сегодня реализуются в высоких и «умных» технологиях, в частности — при разработке решения на основе технологий интернета вещей (Internet of Things - IoT).

В русском языке «вещи» чаще ассоциируется с конкретными физическими объектами; английское things шире и может включать абстрактные понятия. В контексте IoT под «вещью» подразумевают любой объект физического или информационного мира, который можно идентифицировать и подключить к сети.

По определению МСЭ‑T Y.2060, интернет вещей — это инфраструктура и экосистема, в которой физические и виртуальные вещи идентифицируются, интегрируются и взаимодействуют в сетях связи. Суть перехода от «интернета людей» к «интернету всего» —  любые объекты — как материальные, так и информационные — могут между собой взаимодействовать. Соответственно, можно строить не только иерархические системы или их цифровизировать, но и создавать горизонтальные и распределенные системы со всеми вытекающими выгодами.

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

Здесь концепция интернета вещей прямо пересекается с концепцией умных вещей. Пусть мы оснастим, к примеру, счётчик электроэнергии устройством, передающим данные в интернет, а информационную систему учёта электроэнергии — доступом к данной информации. И вот у нас датчик становится уже «достаточно умным», чтобы отправлять эти данные, а информационная система — «достаточно умной», чтобы их использовать.

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

Соответственно, основная задача разработчика решений на такого рода технологиях — создать устройство, которое придает «вещи» способность к коммуникациям, но при этом не абстрактно, а исходя из видимых целей, достигая требуемого решения.

Предполагается, что, имея задачу, разработчик должен понять, где есть резон при реализации использовать данные технологии, и какие здесь выгоды, возможности монетизации, перспективы и т.д.

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

Таким образом, в отличие от упоминавшихся выше продуктов, где есть «материальная» и «информационная» составляющие, у нас в решении составляющих будет, как минимум, три:

И при этом сама вещь может еще иметь свои материальную и информационную составляющие.

Тут рассмотренная выше дилемма «проектный vs гибкий подход» в IoT усложняется трехкомпонентной структурой:

Такая структура IoT-системы часто приводит к конфликту парадигм и причиной провалов проектов.

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

Обычный сценарий:

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

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

Поэтому разработчику надо понимать, к примеру:

Переиспользование существующей инфраструктуры имеет огромные преимущества с точки зрения экономии затрат, быстрого внедрения решений, минимизации рисков, повышения эффективности, однако есть и подводные камни переиспользования существующей инфраструктуры, к примеру:

и так далее.

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

Парадокс IoT: в то время как чистая IT-разработка освободилась от ограничений серийного производства, IoT возвращает эти ограничения через программизацию физических объектов:

Вывод: IoT-разработка не может использовать экономику «нулевых потерь», характерную для чистого ПО, но и не может полностью опираться на экономику высоких затрат традиционного производства.

Ключевая разница: эффективная IoT-разработка происходит не на уровне планирования действий, а на уровне планирования архитектур взаимодействия.

Традиционное планирование:

IoT-планирование (метапланирование):

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

Необходимость гибридных методологий, требуются новые методологические подходы, которые: