Balancing Hardware and Software release cycles is hard enough. Keeping up with release interoperability has buried many a roadmap alone, but today we add rapid manufacturing, an update hungry market, new technologies and new sensor concepts to Moores’ law.
I am working today with a company that has had a core Selling/Value proposition for some time “Peripheral Agnostic” we are struggling with the question of can this be maintained? Sadly the answer is no. The new question is what expectations can be set with the market.
Integrating the top 50% of the sensor methodologies in the market today requires a team of SW developers and testers. For the newer technologies there is a pay to play pricing scheme in place and the User Group is a life saver as they are the architects of the peripheral roadmap!
Still IoT growth is sensor/data growth and the company vision of being agnostic to the data/event capture technology has become clearly unsustainable. Matching HW/SW releases alone consumes dev ops planning. The IoT market as all early markets fights against and needs protocol standardization. I am reminded of the early days of MRP monitoring/automation, the ZIGBEE never ending back and forth and so many more.
As a software company it is important to focus on user value creation over block and tackle backlog. But is that realistic as more resources get pulled away? Yes and the answer is not being everything to everybody. Early IoT start-ups produced their own sensors mostly in medical and security applications. These first versions were more a HW product then SW.
Today customers are less interested in the HW as the “Ok now I have data how I can use this for alerts or decision support?” Device evolution moves from functional to fashion and has a threshold in the middle that is good enough. The SW needs to continue to create value and ease of use. Think of the iPod/iTunes evolution, the device has changed little in the last few years while the SW has morphed to other Apple devices and evolved less on the desktop but more at the device.
SW lives at the user level and HW may or may not. This alone determines release schedules but not updates and integration points. If you make a device the market expects HW to last as long as the utility of that device, so your supporting SW needs to integrate as long as the device works. If partners in the market make the HW the market may accept some gap integration.
Finally the big concerns are:
1) Market – who do you partner with and why? What expectations do you establish and if you need to change how do you communicate that.
2) Who are you? – A Software company? A hardware device company? Or Hybrid? Establish this early internally and in the market.
3) Partnering across the HW/SW divide. – If you integrate across a broad market then tier who you work with first and why. Again here you will never satisfy all.
4) Your Product release and development procedures. – My experience with most is they all work in the right time and place. This means be flexible in how for each effort but not a process of the moment approach that may work when you are small but as complexity grows Policy not Process is required.