Един свързан продукт може да изглежда завършен много преди да е завършено инженерното проектиране около него. Прототипът е стабилен, данните достигат до облака, приложението показва правилните стойности и първата партида устройства вече е в ръцете на потребителите. В този момент бекендът може все още да е достатъчно опростен, така че екипът да познава почти всяко устройство поотделно. Осигуряването може да се обработва със скрипт, промените в конфигурацията могат да се правят ръчно и ако нещо се обърка, инженерът обикновено може да проследи проблема директно.
След това трябва да започне да живее в реалния свят. Появява се втора хардуерна ревизия. Някои клиенти все още използват първата ревизия. Версиите на фърмуера започват да се различават. Необходима е нова конфигурация за различен клиент или пазар, докато по-старите устройства все още се нуждаят от актуализации и поддръжка.
Нищо не е непременно счупено. Софтуерът зад устройството просто е придобил собствен жизнен цикъл.
Този преход е лесно да се пропусне, защото прототипът може да продължи да работи перфектно. Но след като множество версии на един и същ физически продукт трябва да съществуват едновременно на практика, бекендът вече не е просто инфраструктура зад хардуера. Той става част от самата архитектура на продукта.
Работещият свързан прототип все още не е мащабируем продукт
Прототипът има важна задача: да докаже, че системата работи от край до край. Устройството изпълнява основната си функция, фърмуерът комуникира с backend-а, телеметрията пристига там, където трябва, командите се връщат, а мобилен или уеб интерфейс предоставя функционалността на потребителя.
Това, което обикновено не е доказало, е колко добре една и съща система се справя с разнообразието.
Първите двадесет устройства може да работят с един и същ фърмуер, да са изградени с една и съща хардуерна версия и да са конфигурирани от едни и същи инженери. На този етап ръчната регистрация, директните промени в конфигурацията или малък скрипт за внедряване могат да бъдат напълно разумни. Създаването на инструменти за производствено ниво, преди продуктът да се е доказал, може да е преждевременно.
Мащабът променя проблема. Устройствата остават офлайн, подменят се, работят с различен фърмуер и изискват различни клиентски конфигурации. Поддръжката трябва да прави разлика между устройство, което никога не е било правилно обезпечено, и такова, което е неправилно конфигурирано или просто недостъпно.
Дългът на прототипа често започва по този начин: не с лошо решение, а с временно такова, което остава в сила, след като продуктът е преместен. И едно от първите неща, които налагат този преход да се появи, е самият хардуер. Новата ревизия не просто замества старата; тя трябва да съществува едновременно с нея.
Всяка хардуерна ревизия създава проблем с жизнения цикъл на софтуера
Нова хардуерна ревизия рядко се появява като чист заместител на старата. На практика и двете версии остават на пазара, понякога с години. Добавете преходен пакет, няколко клона на фърмуера и специфични за клиента конфигурации и флотът бързо става по-разнообразен, отколкото предполага оригиналният модел на продукта.
Софтуерният слой вече не може да третира всяко устройство като абстрактно „устройство“. Той трябва да знае какво е способно да прави това конкретно устройство.
Ревизирана платка може да използва различен сензор, комуникационен модул или контролер. Команда, която е валидна за най-новата версия, може да не се поддържа от по-ранна. Калибровъчните стойности могат да се променят. Ограниченията на конфигурацията могат да се изместят. Пакет фърмуер, подходящ за едно поколение, може да е опасен за друго.
Инженерите, разработващи физически продукти, вече работят по този начин. Два компонента, които изглеждат почти еднакви, не са взаимозаменяеми, ако техните ревизии, допустими отклонения или спецификации се различават. Свързаните продукти създават същия проблем от страна на софтуера: платформата се нуждае от надежден начин да разбере с коя версия на физическия продукт комуникира и какви правила важат за нея.
Да разгледаме продукт, чиято първа версия използва една процедура за калибриране, докато втората въвежда нов сензор и различен набор от параметри. За клиента и двата уреда може все още да са един и същ продукт. За платформата те не могат да бъдат.
Ако тези разлики не са представени изрично, те са склонни да проникнат в логиката на приложението като специални случаи. Един работен процес проверява диапазон от серийни номера. Друг използва версия на фърмуера като заместител за генериране на хардуер. Трети съдържа изключение, добавено след като екипът за поддръжка откри по-стара партида, която се държи различно на място. Нито една от тези корекции не изглежда особено опасна сама по себе си, но заедно те правят всяка бъдеща промяна по-трудна за обмисляне.
По-старият хардуер рядко изчезва по график. Продуктовите екипи естествено се фокусират върху най-новата ревизия, докато клиентите често запазват по-ранните версии много по-дълго от очакваното. Следователно платформата трябва да поддържа няколко поколения едновременно, вместо да се приема, че инсталираната база някога ще се сведе до едно-единствено текущо състояние.
След като това се случи, еволюцията на хардуера и управлението на жизнения цикъл на софтуера стават неразделни. Платформата трябва да знае не само къде се намира устройството и дали е онлайн, но и какво представлява то, какво може да изпълнява, как трябва да бъде конфигурирано и кои промени са безопасни за прилагане.
И преди да може да се отговори надеждно на който и да е от тези въпроси, всяко устройство трябва да влезе в системата по последователен начин.
Осигуряването е мястото, където ръчното инженерство спира мащабирането
Осигуряването изглежда лесно, когато паркът от устройства е малък: създаване на запис на устройство, въвеждане на сериен номер, генериране на идентификационни данни, присвояване на устройството на клиент, прилагане на конфигурация и продължаване напред. За няколко десетки устройства, ръчното обработване на част от това може все още да е правилният избор.
В производствен мащаб обаче, осигуряването се намира на пресечната точка на идентичността на устройството, идентификационните данни, собствеността, конфигурацията и състоянието на жизнения цикъл. Грешка, допусната по време на внедряването, може да повлияе на начина, по който устройството се управлява и поддържа дълго след като напусне фабриката.
Електронна таблица може вече да не съответства на това, което е действително инсталирано. Заменящото устройство се нуждае от правилната клиентска асоциация, без да наследява грешна идентичност. Фабричните нулирания създават друг път през процеса. Инсталаторът може да присвои устройство към грешен акаунт, оставяйки поддръжката да определи дали е офлайн, неправилно е осигурено или просто има грешна конфигурация.
След като отговарянето на тези въпроси рутинно изисква от разработчика да провери база данни или да изпълни вътрешен скрипт, процесът е спрял да се мащабира с продукта.
Дублирането е друг предупредителен знак. Всеки вариант на продукта започва да придобива собствен скрипт за внедряване, инструмент за конфигуриране или работен процес на инсталатора. Тези разлики може да изглеждат малки, но основната отговорност е една и съща. Осигуряването се е превърнало в инфраструктура на платформата за многократна употреба, а не в задача за настройка, прикрепена към конкретно устройство.
И рядко е единствената възможност, която трябва да стане повторно използваема.
Платформеният слой трябва да се превърне в инфраструктура за многократна употреба
След като няколко продукта или хардуерни версии споделят едни и същи основни нужди, някои софтуерни възможности престават да бъдат специфични за даден продукт. Идентичността на устройството, осигуряването, свързаността, телеметрията, доставката на фърмуер, състоянието на жизнения цикъл, видимостта на парка от устройства и диагностиката са добри примери. Преизграждането им за всеки нов вариант създава повече код и повече оперативни пътища за поддръжка, без самият продукт да прави по-отличителен.
Екипите рядко се заемат с това дублиране. Малки разлики се натрупват около всеки продукт, докато екипът не започне да поддържа няколко реализации на това, което се е превърнало в една и съща инженерна отговорност.
По-ясна граница е да се отдели продуктовият слой от платформения слой. Продуктовият слой съдържа поведението, работните процеси, интерфейсите, интеграциите и логиката на домейна, които правят дадено устройство ценно. Платформеният слой обработва механиките, които трябва да останат последователни дори при промяна на хардуера.
С напредването на първото пускане на свързаните продукти, осигуряването на устройства, управлението на жизнения цикъл на устройствата, управлението на флота от устройства и инструментите за поддръжка се превръщат в споделена инфраструктура, а не в еднократни детайли на проекта. IoT PaaS за предприятия може да осигури този многократно използваем платформен слой в множество продукти или варианти на продукти, като обработва стандартни устройства и управление на данни чрез многократно използваеми градивни елементи, докато инженерните екипи фокусират своите персонализирани усилия върху хардуера, работните процеси и потребителското изживяване.
Общата основа все пак трябва да остави място за реални продуктови разлики. Ново устройство може да се нуждае от различен модел на данни, конфигурационен поток, интеграция или логика на управление и тези разлики трябва да останат лесни за въвеждане. Целта е просто да се избегне всяка разлика да се влачи за поредния регистър на устройства, телеметричен канал, механизъм за осигуряване или набор от инструменти за управление на флота.
Платформата може да изглежда като излишна, докато екипът изгражда първия продукт, и като ценен актив при втория или третия. След като общите оперативни механизми са налице, нов вариант може да наследи работеща основа, вместо да се появи с друг бекенд, който екипът ще трябва да поддържа до края на жизнения цикъл на този продукт.
Запазете персонализирано инженерство там, където продуктът е действително различен
Платформата за многократна употреба не бива да прави свързаните продукти по-общи. Нейната задача е да премахне повтарящото се инженерство от частите, които не създават диференциация.
Персонализирането все още е свързано с поведението на устройството, специфичната за домейна логика, работните процеси, потребителското изживяване, специализираните интеграции и начина, по който даден продукт взаимодейства с физическия свят. Това са точно областите, в които инженерните решения могат да направят един продукт значително по-добър от друг.
Това, което рядко заслужава еднакво отношение, е околната оперативна ВиК инсталация. Базовата версия и индустриалната версия на една и съща машина може да се нуждаят от различни сензори, контролери и интерфейси, но не би трябвало да изискват отделни начини за идентифициране на устройства, проследяване на версиите на фърмуера или управление на парк от устройства.
Предпочитам инженерите да прекарат това време в усъвършенстване на поведението на продукта на практика, отколкото да преработват механиките, които екипът вече има за друг продукт. Споделената основа не намалява обхвата на персонализираното инженерство; тя предпазва тези усилия от това да бъдат погълнати от инфраструктурата.
Истинското изпитание идва, когато екипът започне продукт номер две.
Добрата платформа прави следващия продукт по-лесен от първия
Ако продукт номер две изисква почти същата работа на платформата като продукт номер едно, много малко всъщност е било използвано повторно.
Новият вариант би трябвало да може да наследи частите от оперативния модел, които не са се променили: потоци за осигуряване, идентичност, механика на жизнения цикъл, инструменти за управление на автопарка, процеси на фърмуер, видимост на поддръжката и общи интеграции. След това инженерните усилия се насочват към разликите – може би нов сензорен пакет, друг работен процес за управление или специфична за клиента интеграция – вместо да се реконструира основата.
Новото поколение хардуер поставя същата идея под по-голям натиск. Възможностите му могат да се променят значително, докато по-старите устройства останат активни на пазара. Една зряла платформа може да поддържа и двете, без да принуждава екипа да поддържа два отделни платформени стека за това, което клиентите все още възприемат като едно продуктово семейство.
Нищо от това не изисква един монолитен бекенд. Различните продукти все още може да се нуждаят от ясни архитектурни граници. Важното е да се избегне повторно внедряване на същата инженерна отговорност без основателна причина.
Тогава платформата се превръща в актив, а не в натрупани разходи. Поддръжката има по-малко паралелни инструменти за разбиране, изданията следват по-последователни пътища и добавянето на друг продукт се превръща в контролирано разширение, вместо още един бекенд, който компанията наследява за неопределено време.
Третирайте платформата като част от продуктовата архитектура
Физическите продукти са проектирани с оглед на ревизиите, възможността за обслужване, производствените възможности и бъдещите промени. Свързаните продукти се нуждаят от същата дисциплина от страна на софтуера.
Първият бекенд може да бъде временен. Същото важи и за първия скрипт за осигуряване или инструмент за поддръжка. В това няма нищо лошо по своята същност. Проблемите започват, когато тези временни механики тихо се превърнат в постоянна архитектура, докато самият продукт продължава да се развива.
Дотогава свързаният продукт вече не е просто хардуер, фърмуер и приложение. Той зависи и от инфраструктурата, която идентифицира всяко устройство, разбира неговите възможности, прилага правилната конфигурация, поддържа актуализации и помага на екипите да диагностицират проблеми години след доставката.
След като този слой се третира като продуктова архитектура, разделението става по-ясно: стандартните механики остават за многократна употреба, докато персонализираната работа се фокусира върху това, което всъщност отличава един продукт или продуктово семейство от друг.
Най-силната платформа не е просто тази, която прави възможен първия свързан продукт. Тя е тази, която позволява на инженерния екип да изгради втория, третия и четвъртия, без да наследява нов бекенд всеки път.
