Nokia – a good time to make a come back?

Nokia 6

After largely disappearing from the mobile phone market following its acquisition by Microsoft, 2017 will see the re-emergence of the Nokia brand with products managed by HMD Global in partnership with FIH Mobile (part of Hon Hai Precision) and brand licensed from Nokia. As someone deeply involved with portfolio management at Nokia during the growth and glory days, I would like to take the opportunity to explore whether this is a good time for them to make a comeback?
In a previous blog I analysed the dynamics of the mobile phone market in terms of what facets of the overall business need to be optimised at a given point in time. In brief, my view is that the smart phone market has moved into a plateauing phase where the key strengths needed are brand, distribution and cost efficiency. So the question is whether this new Nokia set-up is well placed for this challenge?
First of all where is the Nokia brand today? Ten years ago Nokia was the leading mobile phone brand across the world except in North America, South Korea and Japan. This position had been built on fifteen years of growth – how much can this legacy be drawn on now? At its zenith Nokia stood for a perhaps contradictory combination of high technology and reliability – you could expect to get the very latest from Nokia and the products would be really tough in real life. The challenges of the 2008-2013 period largely stripped Nokia of the high technology association but today you still hear stories of how good and tough my Nokia was. The UK press has been full of stories about the resurrection for the 3310 over the last week, all very positive. So if I was to describe the Nokia brand today from a European perspective I would use words like: honest, tough and sentimental.
Distribution is the next major part of competing in today’s market scenario as with any fast moving goods business. Here HMD take responsibility for sales and FIH Mobile for manufacturing and logistics. This has the promise of being a good combination with a lot of personnel coming over from Microsoft devices business while FIH are of course a well-established world class manufacturer. Access to market in countries where operator distribution is critical will depend on the right deals being made but there is no obvious reason why this may not be the case. While a split company setup may struggle in a period where the market is changing fast with product innovation at the fore, since this is not the case at the moment there is no reason to believe this cannot succeed well.
Cost efficiency is the key to offering the value for money proposition essential in a plateauing market and in this case to compete against mainly Chinese companies which offer very keen price points. Clearly the advantage of the resonance of the Nokia brand will give the new venture an edge but as a challenger there can be no expectation of premium pricing at the beginning of sales. With the mobile phone chipset business dominated by only a few suppliers, the size of FIH/Hon Hai as a manufacturer will be important to get good pricing as well as the potential of Nokia branded goods making even a fraction of historical volumes.
So in a nutshell it would appear that the timing for a comeback looks good. Leaving re-entry any later would see the continuing in the decline of Nokia as a consumer brand – furthermore the operational mode of separate sales and manufacturing companies in partnership can work when product innovation is not the main route to success.

London Tech Expo 2017, IoT products and enablers

London Olympia, site of IoT Tech Expo 2017This is a modified version of an article originally published on LinkedIn here.

I made a worthwhile trip to the IoT London event (23-24th Jan) recently to test the pulse of IoT and find out about some new and upcoming IoT product companies.

In general, I would say it felt like the scale and activity around IoT seems to have increased with a large number of participants and presentations on offer.  With so much to see and businesses to talk to, it would have been useful to have a few more chairs to sit down and catch one’s breath…

Having said that, it is appropriate that this is called the Tech Expo as I could see a lot of product innovation, but also some challenges for businesses in finding their best channels for growth. Notwithstanding, I will mention here a few of the physical product companies that captured my interest..

Nanolike is a French company taking advantage of nanotechnology to create a tiny force sensor which uses a fraction of the power of existing sensing technologies. These size and power advantages mean that there is a wide scope of deployment opportunities, perhaps new products in the quantified self area that become feasible?

BeanIoT is based in Cambridge, UK and has created a range of small autonomous “bean” sensors which can connect to and through mobile phones and other low power bluetooth based devices. The beans have batteries and can be charged wirelessly, with the battery life depending on the number and rate of measurements requested by the bean. There is a quite a wide range of sensing available in the beans: accelerometer (step counter), temperature, pressure, air quality, humidity etc. It is interesting to see such a “Swiss army knife” type proposition being brought forward, as opposed to a more single purpose accessory like a fitness tracker or a wireless weather station. The team is integrating their own cloud storage and ‘bean’ data visualisation platform so as to provide an out of box solution and broaden its appeal toward business.

OpenTRV is a UK company aiming to make a big dent in the costs of domestic heating to cash constrained consumers along with the UK’s CO2 emissions. Their products are a connected and a standalone smart radiator valve that detect presence/occupancy in a room and learn when to turn on and off the radiator. Now existing thermostatic radiator valves can be bought for about £5, but many do not work particularly well nor do they offer the same heat saving potential, with up to 30% saving being claimed. The company is looking at the most affordable product options in order to make a 1 year repayment case to also appeal to people in rental accommodation. The connected option of the valve is more expensive, but can offer “telemetry data” on energy savings e.g. for large scale housing landlords.

The last company I mention is Neurofox, a German company with a product dedicated to helping stressed people achieve a state of mental relaxation in minimum time. The product comprises a headband with 5 brain activity sensors feeding into a controller unit with a headphone audio output and a wireless connection to a pc. The idea is to use the audio feedback path to help train the users to fall into a relaxed state. Over a period of time, through personalised hints and customised feedback, the solution gets better – but how this is achieved i.e. the IoT feedback path is not quite clear yet.

In summary, the show offered an interesting mix of product innovation along with end-end IoT solution companies, data visualisation offerings, multi and wide-area sensor connectivity and connectivity management solutions.  Bearing in mind that google search does not generate a uniform distribution of winners, then for those interested in IoT companies, the list of exhibitors can be found here.

Life and death in the internet of everything…

Time progression of hype cycle for IoT/IoE

The Internet of Things (IoT) or Internet of everything, hereafter IoE, is an incredibly hyped phenomenon at present viz IoT/IoE at the peak of the hype cycle. Source: Gartner 2014, 2015.

Nevertheless, within the massively wide scope of IoE, there have been clear opportunities within selected verticals. Businesses have been deploying IoE like solutions to optimise their process and realise significant cost savings. The example I like best is “Enevo”, a Finnish company involved in waste management, often described as the “internet of shit”, which has helped waste collection companies save huge costs, circa 40% by optimising the frequency and routing of collections.

There are a wide range of industry sectors looking at IoE, but can we say that the offers and solutions really belong to the same stable, or are they so custom they should be viewed within their own silo? Right now, this situation reminds me somewhat of the “bowling alley phase” from Michael Moore’s book, “Inside the tornado” (successor book to “Crossing the chasm”). In this phase, solutions are highly customised around individual businesses’ needs and there is not a vanilla platform offer suitable for all. Happy to hear other opinions on this.

Switching tack to the consumer product angle, what potential product categories do we see where people are going to pay out for an IoE augmented experience? It is happening here:

Of course there is then the catch all of the “closed loop” internet experience, embedded into  part of an existing product category/product experience:

  • Providing a basic service e.g. music/video/other digital goods delivery & consumption
  • Providing feedback to the vendor or service provider of the product usage patterns and product maintenance/wear and tear e.g. Aviva drive car driving style, General motors Onstar

From a technical architecture point of view, when you consider the IoE across most of the categories, you are left with some common elements:

  • A sensor for gathering data. Most often wireless for convenience & background operation.
  • An aggregation point to bring together different sensor data streams and send to the internet. This could be a mobile phone or a home automation control hub.
  • A Cloud platform for the capture, processing and provision of service for the system e.g. visualisation of data, providing recommendations, remote activation/update etc.

To this end, at All about the Product, we have decided to take a look at a few contemporary solutions for elements of the system, to build a solution and then get a sense of the different strengths of the various options  for the system elements.

We will be posting more information about our IoE product and voyage in the coming weeks.

IoT use cases & initial AWS IoT platform experience

In our initial internet of things (IoT) opening post,  we said that many of the existing IoT solutions shared a common architecture. This post looks at the challenges in using one of those pieces of the architecture – the ease of use of an “off-shelf” cloud compute platform.

Basic Iot use cases

The essentials of an IoT system comprise of a few basic epics/user stories:

  1. As a system owner, I want to be able to give my individual IoT endpoints their own unique identities so I can discriminate between them.
  2. As a system owner, I want to be able to secure & restrict access to my IoT system to the endpoints that belong to me (and vice-versa).
  3. As a system owner, I want to be able to define both individual and bulk policies for what IoT endpoints are allowed to do with their data when they connect.
  4. As a system owner, I want to be able to define on both an individual and bulk basis what actions are to be taken as a result of IoT endpoint data transactions.
  5. As a system owner, I want to be able to remotely “maintain” all of my IoT endpoints in terms of configurations and software versions.

In this initial approach to the AWS IoT platform, I concentrated on topics 1-3 and left aside the practical deployment issues for the present.

In summary, I would say that I like the Amazon approach to addressing these issues, as in a way they are the table stakes, with the main IoT value creation around what is being measured/monitored and how the data obtained is being intelligently used and combined to provide benefits.

My experience of the Amazon IoT system has focused on the IoT SDK and backend, specifically the python and embedded C versions and trialling the basic data publish/subscription over MQTT. In terms of positives & negatives:

  • No special setup required to start using AWS IoT, provided you already have an AWS account. It is also free to use (at present), provided you don’t go crazy and start using millions of messages per month.
  • Good initial impression of the documentation & code samples, but this soured slightly over time as a LOT of the examples & setup are tailored for the AWS IoT button as opposed to e.g. linux desktop for doing a quick test drive.
  • Bit of confusion over which “C” SDK to use for the desktop test drive. It seems it should be a separate download of linux_mqttmbedtls2.1.1.tar, which is a shame as I only found this out after downloading the embedded C SDK and discovering it within the readme file.
  • Very easy to “create” a new IoT device as well as certificates and keys to associate with the device to enable authenticated access to system.
  • Less great in terms of specifying precisely what to use in the header files for the code samples for the device ID and access points for pub/sub testing versus e.g. long identity string for the device shadow.
  • Not too well explained IoT policy concept i.e. [3] in the user stories. It is absolutely mandatory to create one of these and associate it with the certificate in order even to get connected to the IoT server.
  • IoT policies are poorly documented. I had to create a very permissive policy to enable the basic publish and subscribe examples to work: with ANY of my devices I can connect / publish/ subscribe to anything.
  • Calling out on the policies:
    • The documentation on identifying *which* specific IoT node in the policy is somewhat lacking. I am not able to make restrictions adequately without affecting something else.
    • Also the documentation on *what/where* the IoT device can publish/subscribe to is also lacking. There needs to be a better definition of the vocabulary & syntax for the policy statement.
AWS IoT console showing certificates and policies

AWS IoT console

Other than these initial problems, probably due as much to my own specific knowledge base, the AWS offering looks good in terms of getting started fast and providing the basic plumbing for an IoT system. Ian Massingham gave a good presentation on AWS IoT at Hardware pioneers in October.

Naturally AWS are looking to monetise IoT through use of their other cloud assets, storage, processing, machine learning and it will be interesting to compare in another blog against Windows Azure IoT which requires a chargeable server reservation for the right to use IoT.

Jan 2017 – update

I can now take back some of what I said earlier about the difficulty of finding the allowable policy definitions for IoT devices interacting with AWS’s backend. They were there in the documentation if you looked for them.

Excluding the “shadow” (Amazon’s virtual copy of the IoT device to use when e2e connections are broken), there are 4 fundamental actions and 3 different types of resource to query the action against.

Action

Resource query

Iot: Connect (enable basic connection from iot device to backend) Client ID ARN e.g. to enable iot device “clientid1” to connect.

arn:aws:iot:us-east-1:123456789012:client/clientid1

 

Iot: Receive (permission checked for messages to be sent to the device, essential to enable subscription) Topic ID ARN e.g. for receiving from foo/bar

arn:aws:iot:us-east-1:123456789012:topic/foo/bar

 

Iot: Publish (enables the device to send data to a topic, and/or filter allowable topics) Topic ID ARN e.g. for publishing to foo/bar

arn:aws:iot:us-east-1:123456789012:topic/foo/bar

Iot: Subscribe (restricts allowable topics for iot devices to subscribe to) Topic filter ID ARN e.g. for subscribing to foo/bar

arn:aws:iot:us-east-1:123456789012:topicfilter/foo/bar

In summary of the policies:

  • We can restrict connections according to the IoT device ID.
  • We can prevent messages being sent to the IoT device(s) or limit them to certain topic groups.
  • In a combined policy statement with connect, we can limit the IoT devices able to receive messages from certain topic groups.
  • We can limit the topics where IoT devices are able to publish to.
  • In a combined policy with connect, we can link the device id-topic pair publishing combination e.g. a destination specific to each client.
  • Ditto for subscriptions.

And there seem to be plenty more policy resource query variations in the documentation available using “variables” for some more advanced use cases.

Experience with AWS IoT platform, part 2

This is the second blog in a series looking at the complexity of using well known cloud compute platforms for building solutions for the Internet of Things.

Amazon Web Services Internet of Things (IoT) setup and configuration block diagramSummary

The IoT “rules” and “actions” within AWS IoT are what allow you to bring your IoT data to life within the cloud through associated AWS services.

My first observations about setting these up gave me the sense that this was going to be quite tricky- using the AWS command line interface to craft new roles and policies to be able to use different AWS services.

However, this setup work is now starting to get a whole lot easier, with the introduction of a set of guided UI steps in the IoT suite which make it easier to accomplish the end goal. I was able, with relatively little effort, to setup publishing using an IoT program on a client to create IoT data files in the AWS storage cloud and make these publically visible on the web.

Whilst saying this, I experienced a few odd quirks from the platform e.g. when trying to configure IoT automated actions. Whilst I can’t claim strong knowledge of the platform, the reasons for the issues were far from clear and it may well be that there is just one way of doing things.

My feeling is however, that it would be a small step from here to have the client program running on a reasonable scale embedded platform e.g. one with Wi-Fi/IP stack. Indeed, the AWS IoT button is a good example and AWS themselves reference a number of other suitable hardware platforms.

AWS have a number of services to connect with the IoT platform e.g. database and simple notification services which are bundled under a somewhat “vertical” navigation scheme; it is a shame that the service “worked examples” are rather spread around the AWS documentation, meaning that the problem you are trying to solve may have an answer, but you can’t always see it from your current silo.

AWS IoT platform rules & actions

In a previous blog, I looked at the basic epics and user stories for an IoT system and cross referenced the experience with the AWS IoT platform. This previous blog only touched on the basic connection experience with AWS IoT: configuring end-points with identity certificates, setting up the target internet access point and enabling the basic data publish policy on the cloud end. These are represented by the greyed out boxes in the initial block picture.

This piece is an initial look at the next step operations possible with the AWS IoT system:

  • Defining a rule to filter all the published IoT topic data
  • Creating an action related to the rule e.g. data file/database update

Note: As a company looking to make a solution with a number of real “autonomous” IoT end points, quite a number of other tasks remain beyond what I have mentioned in the blogs so far e.g. visualisation, endpoint update, non-functional performance, alternate wireless connectivity (BT, LoRa) etc.

Initial thoughts

The rules and actions seem to be the most quirky part of the IoT system so far: I noticed that one of my new rules/actions stored in the cloud seems to have disappeared/deleted itself and then re-instated itself on the following day. Strange.

From my experience in trying to use AWS IoT rules and actions, it is best to follow AWS’ precise recommendations.

  • Setup an account with AWS (account “owner” – access all areas including billing)
  • Set up an administrator account under AWS IAM (all areas w/out billing)
  • Make/configure everything else whilst logged in as administrator i.e. all AWS IoT, “thing”/ device names, certificates & access policies.
    • After creating devices/certificates as the account owner, and other items as the admin, I had some odd behaviour with rules/actions not being executed and files being created yet not being visible to me as “administrator”.

Amazon web services Internet of Things (IoT) creation of a rule for processing IoT data

The picture shows some of the SQL syntax used for specifying the topic of interest to work with and a SQL “WHERE” condition can provide further filtering on the topic data content – it is typically looking for key-value pairs with more details in the IoT developer guide.

Amazon Web Services Internet of Things (IoT) creation of an action on IoT data

The next stage in the dialogue, the selection of an action to result from an IoT rule is shown in the picture above e.g. creating files in S3 storage.

AWS Internet of Things (IoT) configuration of an action on IoT data

The selected action must be configured and the above picture shows the s3 action configuration. The first boxes are to specify or create the S3 bucket where the IoT data will be written along with the sub-directory/key. If a new bucket is needed then an s3 management console is opened to enable this.

The lower box enables the selection of a “role” with an appropriate associated permissions policy to execute the action. Interestingly the “create a new role” most often did not work for me i.e. fails to load the IAM management console. To work around, I used an existing role which had the s3PutObject policy, and used the “update role” button to add the new s3 bucket/subdirectory to the role permission – see the picture below.

AWS Internet of Things (Iot) workaround for role definition for IoT actions

This odd behaviour is an example of there is perhaps just one way of doing things at present i.e. when using the rule wizard, it appears to prefer to re-use existing roles with s3 access as opposed to creating additional roles.

Having been through the setup experience, it is clear to me that to get most value from AWS IoT rule and action deployment, you need to get to know the rest of AWS’ solution offering e.g.

  • Identity access and management (IAM) as an enabler
  • Simple storage service (s3) for storing data
  • Lambda (“serverless” execution) for manipulating data
  • Simple notification service for messaging and alarm notifications

This should not be surprising as most of these solutions are also “chargeable services” in their own right, with the IoT providing the on ramp for customers. This familiarisation process is going to involve a certain amount of time investment, but the payback potential is evident and the examples within each service silo are generally good and worthwhile to try out.

A future blog will contrast our experiences with Microsoft Azure IoT with those of AWS IoT.

Radio technologies for the internet of things

This article reviews the issues when considering the choice of radio technologies when building Internet of Things systems. Our previous article proposed there were two radio technology selections to be made:

  • An ultra-low power technology to connect sensor nodes with gateway nodes to enable battery powering for ultra small devices.
  • A longer range technology to connect gateway nodes with the internet.

Ultra low power radio technologies

Given that a typical sensor node will be battery powered without re-charge over a period of the order of years, there is massive requirement for an extremely low power solution. Several radio technologies have been developed with this application in mind – of particular note Bluetooth Low Energy and Zigbee/Thread.

The case for Bluetooth is built on the universal availability of this standard in smart phones so allowing these devices to act as either gateways to cloud application, control points for the IoT system or data aggregation/display nodes for non-cloud connected cases.

The case for Zigbee and its Thread variant is built on their optimised design for connecting sensors and particularly their ability to create a mesh network which potentially extends the effective operating range of a gateway node.

Bluetooth SIG is aiming to close these functional gaps in the Bluetooth 5 release which is due late 2016 early 2017, promising in addition to mesh networking increased range. Timing is often critical for the process of choosing winning technical standards, but in this case it seems the whole IoT market has been dormant in a state of great expectation already for a number of years and therefore not a critical issue for Bluetooth.

Ultimately the winning radio standard in this case is likely to be decided by the role of the smart phone in the IoT ecosystem – if it plays an important role then Bluetooth solutions will dominate, if not then it is likely there will be less consolidation into  a single radio type.

Longer range radio technologies

For the RF connection between the gateway node and the ‘internet’, the availability of a local WLAN network has typically between the key factor driving choices as a Wi-Fi signal will usually mean lower costs and power consumption than using cellular. Indeed, Ericsson has estimated that nearly 90% of IoT devices will NOT be connected over cellular. However 5G is being designed with IoT in mind and therefore it may offer a more cost effective and robust communication solution than today’s cellular solutions, yet expectations are that this technology will not be widely available until after 2020*.

Long range IoT is currently dominated by a number of proprietary solutions such as SigFox and LoRa which have emerged to fill a gap of combining long range and low power. The price of this combination is to really cutback on data rates offered to a single node, which suits a lot of the contemporary machine to machine applications. Because of the very low bandwidth per node and their relatively long range, these solutions can be made to be a very economic solution for many applications.

Looking at past experience with mobile telephony, standardised radio solutions drive opportunities to create economies of scale and if operators create economic packages of IoT users then it is likely 5G will dominate in the long term.

*Verizon in the USA is aggressively driving 5G wireless trials and targets some early commercial deployments in 2017 for fixed site application i.e. fibre/cable replacement role, not mobility and not necessarily the scope of 5G required for lowest power IoT.

Segmenting the IoT Market, autonomous versus powered

Consumer versus business IoT deployments

In a previous blog, we looked at the one of the issues of using off the shelf modules for IoT endpoints. The linked commercial question is what is the volume and value of the opportunities for autonomous (battery) versus powered IoT endpoints?

Hypothesis

Given that there are going to be over 1 billion new mobile phones coming to market every year and that the majority of these will support BT smart (BT LE etc.), it is a reasonable bet that there will be a healthy market for autonomous IoT devices that are capable of interacting with these phones. The autonomous endpoints are battery powered and using the lowest energy connectivity possible. This is the IoT mobile driven market assumption.

What wisdom exists on the internet?

There are a wealth of IoT market papers and surveys out on the web and I am going to sample a couple of them, to try and make sense of the question above. Good source for different studies and forecasts:

http://www.postscapes.com/internet-of-things-market-size/

Whilst acknowledging there are discrepancies between them, what do these reports tell us?

  • The volume of connected devices will be about 20-30 Billion by the end of 2020 which is a growth rate of 20-25%.
  • Most of the “value” created, with varying definitions of economic value add, will be in the business sector (2/3) as opposed to the consumer sector (1/3).
  • However, most of the end-point deployments (2/3) are in the consumer segment i.e. 13.3-20Bn and the rest in business, 6.7-10Bn.
  • The investment in device/software/integration will be a small chunk of the overall economic value created (~10%).
  • Only 10% of devices will be connected over cellular, 90% non-cellular
  • Average cost for a consumer endpoint is $100 and this is flat to 2020; By contrast the business average is $400 falling to $250-300 by 2020.
    • Likely to be considerable variation as some end points are already <£10
  • Opinions differ on the share of the device vs. system cost and reflect perhaps different expectations in business environments compared to consumer and scenarios where different systems are becoming interconnected.

Guesswork.. and plenty of assumptions

If we are interested in device based business cases then the volume is in the consumer segment. Within *consumer there can be home, personal transport and personal technology.

  • Home: home hub, lighting, remote thermostats, remote controls, radiator valves, RC sockets, fire/smoke detectors, movement detectors, video surveillance, energy usage monitoring, humidity sensors, smart bed etc.
  • Transport: car/motorbike charge point, bicycle light charging
  • Personal technology: PC, tablets, game console, game controllers, smart phones, smart watches, smart clothing (generic), smart health (BP/glucose monitoring) etc.

Next, some guesswork and assumptions…

Environment

Consumer segment share

Autonomous share in segment

Home

50%

35%

Transport

10%

5%

Personal

40%

80%

In the assumptions in the table above, “autonomous” refers to devices which are designed to operate from battery over the main course of their operation/use cases. This can refer to low interaction devices e.g. humidity sensor, temp monitor/controller as well as high rate ones e.g. a game controller.

Plugging this table of our assumptions on top of the forecasts and assumptions of others, we have 50% share for autonomous IoT devices in the consumer segment i.e. 6-7Bn devices in 2020 and value at $6-700Bn.

Conclusion: autonomous IoT devices look attractive enough to consider.

*I note that some reports consider devices with a “human data input” interface not to be part of IoT, but part of general internet evolution i.e. PCs, tablets and the primary usage mode of smartphones.

In many ways, I like this definition, but given the fast pace of technology evolution it seems too binary to be sustained. For example, consider a simple autonomous sensor but with a button to enable voice interaction. I believe that the voice interface will have a hugely disruptive impact on the design of and our perception of the capabilities of simple autonomous sensing devices.

Here is the link to Amazon’s Alexa offering which is available to be integrated into 3rd party devices, offering natural language parsing and the possibility to define a custom set of actions (skills kit) according to the spoken phrase. Talking toothbrush anyone?

Internet of Things: Challenges using standard hardware modules

There is a huge amount of hype related to the internet of things as we have already explored in a previous blog.

However in its current state the IoT market consists primarily of a myriad of proprietary solutions optimised for a given application; with these conditions it does not seem likely that IoT will deliver on the hype around it. If that situation changed and standardised radio interfaces were used along with general purpose hardware modules which could be purposed for  application by software alone then the market could explode.

In order to make the internet of things realise its potential it is imperative that the creation of networks is both straight-forward and low cost.

The availability of wireless enabled computing elements such as the Raspberry Pi or ultra-low power elements such as the Nordic nRF52 promise to enable the creation of Internet of Things systems with very low cost and great configurability. However the reality of creating such systems is more complex than it might be.

Raspberry pi 3 with built-in wireless capability

Types of wireless compute elements

There are fundamentally two types of autonomous compute elements in IoT networks:

  • Battery powered without frequent re-charging. The over-arching design objective is minimise energy and power consumption (to use primary cells or perhaps solar charging) which prevents the use of current WLAN technologies and drives a demand to minimise processing on-board. The relevant RF communications candidates for these devices are Bluetooth and ZigBee/Thread. Generally speaking these elements require an intermediate gateway to connect to the internet. These elements will be referred to as sensor nodes.
  • Mains powered or battery with frequent re-charges. In this category ultra-low power is not a driver, RF link technologies such as standard Wi-Fi, proprietary (e.g. SigFox) or cellular are most appropriate to connect to the internet. Included in this category potentially are smart phones. These devices may either gather data themselves or else harvest it from the ultra-low power devices detailed above; in which case as well as possessing radio technology to connect to the internet, they must also contain radio technologies such as Bluetooth or ZigBee. These elements will be referred to as gateway nodes.

 

Connecting up

For a typical IoT application in addition to the elements detailed above the following are required:

  • A wireless router or a cellular base station connected to the internet.
  • A cloud application to aggregate, analyse and display data. In addition this application can also monitor and control the nodes in the network.

For this system to work in a ‘fully horizontal’ manner the interfaces between each element should be well defined and published and could therefore be connected like ‘lego’. However there are certain challenges which need to be overcome. The key questions which need to be initially addressed are:

  1. Choice of radio technology to connect the nodes.
  2. Choice of higher level communications protocol to gather/deliver information between the nodes and the internet based cloud application.

These two questions will be addressed in further blog posts appearing here.

 

 

Business transformation, meet product portfolio management..

Business transformation is a much bandied term these days and in practice is often used to cover business change activities. This article is to make some comparisons between the goals & activities of transformation against those of a product portfolio planning and management process.

First, a reasonable definition of product portfolio management (PPM):

The process by which business strategy is converted into a product roadmap which delivers corporate goals and optimally utilises the business’ product making and marketing abilities in relation to the market opportunity.

Next, a couple of definitions for business transformation (BT):

  1. Business transformation is about making fundamental changes in how business is conducted in order to help cope with a shift in market environment.
  2. Business Transformation is a change management strategy which has the aim to align People, Process and Technology initiatives of a company more closely with its business strategy and vision.

In summary then, business transformation is an external market and business strategy driven process with the goal of creating change in the organisation to enable it to execute the business strategy and align it to compete in the new market reality.  This is now sounding rather like the definition for product portfolio management…

So, are there any real differences between business transformation & PPM?

  • Transformation scope covers situations where major cultural change is required
  • PPM builds upon reasonably well working functional processes. Functional competence needs to be in good enough order for PPM e.g. functional capacity planning
  • PPM has built-in “closed loop” feedback to adapt and sustain in the face of continued change as opposed to transformation which is about initiating & driving a big change
  • PPM generates risk/return options for business decision e.g. between long and short term gain and taking technology risk or market risk or a balance of both.
PPM vs. business transformation

PPM vs. business transformation

If we were to try and make an analogy of personal health to these two approaches then business transformation “treatment” might be required in the most extreme situations to shock the patient to help them survive and then guide them toward a more healthy way of living. By contrast, PPM might be seen as a combined exercise and dietary approach which avoids the risk of extreme intervention and helps the person achieve their best health and fitness.

Personal reflection

In my own experience of working for a large corporate (Nokia) over many years, I have seen both transformations in action and then also contributed toward the formalisation of product portfolio management. My perception would be:

  • The transformations galvanised the organisation into “change mode” and caused for example the creation of new  business units with unique missions
  • Whilst the initial phases of the transformation mostly bore fruit in line with their mission, often the nature of the transformation challenge could make the timing of the first fruit quite unpredictable
  • Real value was only generated further through the transformation. This might be partly attributed to the benefits of the learning curve but the main value transition was co-incident with product portfolio management practices becoming bedded in
  • The big value add of PPM was in its ability to hedge both technology risk through different delivery paths to market and market risk through an offering of mainstream and niche/discovery products.

I am interested to hear other views from others on PPM vs. business transformation, but for today, I am an advocate for benefits of PPM and indeed our company offers the Portgenie PPM framework to those interested in learning more.

References

[1] https://en.wikipedia.org/wiki/Business_transformation

[2] https://rapidbi.com/what-is-business-transformation-3/

[3]”Leading Change, Why Transformations Efforts Fail”, John P. Kotter, Harvard business Review.

When two worlds collide: Integrated Business Planning & Product Portfolio management.

As a long term practitioner of Product Portfolio Management (PPM), I was really interested to analyse the principles of Integrated Business Planning and compare it to the practises which I was familiar with. In the first place I must declare that in my career rather than labelling practices and processes, the modus operandi was to extend existing ways of working to become more holistic and drive higher overall business value. When looking at Integrated Business Planning, or IBP, I quickly recognised business processes which I had been operating for in excess of a decade.

The same problem from two different ends

The origins of Product Portfolio Planning lie in the desire to transform company strategy into an executable roadmap to deliver the corporate goals. In simple terms, it is about understanding the market opportunity and making decisions which maximally utilise the company’s ability to develop and market products. On the other hand, IBP was born from the world of Sales and Operations Planning (S&OP) which originated with the goal of balancing product sales and product manufacturing delivering the mantra of ‘one set of numbers’ – in other words, delivering operational excellence.

The collision between these two process philosophies is therefore natural once each has developed excellence in its original field of application: product sales performance is key intelligence for Portfolio Management whilst driving change in the selection of products is a key extension for S&OP.

The term, “Integrated Business Planning”, was originally coined by the consultants Oliver Wright who have a foundation in advising on S&OP. The aim of IBP is the integration of more company functions than S&OP, of particular relevance finance and product development, into a single regular planning cycle. The result being very similar to the regular cycles advocated in the portfolio management context.

A personal reflection

At Nokia in 2007 we implemented an organisational change which was characterised as an ‘integrated company’, the aim of which was to bring sales and operations into the same planning and decision making processes as product development. In reality this change had already started to happen ten years previously as operational excellence had developed as well as more structured product line management. Working in an integrated way had already become a way of life with functional decision taking a supporting role to the over-arching process driven, cross functional structures.

So overall it does not matter if the change to integrate a company into a common decision-making, shared-goal oriented organisation comes from S&OP or the Product Portfolio management end. Fundamentally, it makes sense for a company to operate as a single team which was our goal at All about the Product when we created our “Portgenie” Product Portfolio Management process framework.

In the end, so what?

You might accuse me of some bias, but my strongly held opinion is that there is no greater opportunity for medium and large scale businesses, than to look at how to jointly maximise product making and marketing capabilities in relation to market opportunities. Thus, I am really interested to hear the experiences of others in utilising IBP or PPM based approaches to deliver this benefit.