Author Archives: Robert Alfonsi

Life and death in the internet of everything…

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:

Personal monitoring/fitness e.g. fitbit, nike fuel,
Home automation/optimization e.g. Mihome, Smartthings, Nest, Hive
Personal heathcare/independence e.g. Kinetik, Acticheck

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.

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

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.
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).
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.
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.
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

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.

Summary

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”.

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.

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.

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.

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.

Segmenting the IoT Market, autonomous versus powered

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?

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):

Business transformation is about making fundamental changes in how business is conducted in order to help cope with a shift in market environment.
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

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.

Prioritising development initiatives..part1

Part way through my career, I was asked to work on a change activity. One of its goals was to bring together the business priorities for a suite of about 100 software development initiatives which supported the end offering of products and platforms.

This was a great learning exercise, so part 1 of the post covers “what did I learn?”

Answer the “so what”?

Don’t invest too much time without first gaining a clear understanding of the purpose and intended outcomes from the exercise. Stakeholder contribution to this type of exercise is highly important and although I found stakeholders generally supportive, their main concerns were “What is going to happen in 1 week, 1 month or 6 months’ time as a result of this work?”

Be pragmatic

Projects and program briefs come in all shapes and sizes. Even with best intentions, the result is likely to be imperfect due to misunderstandings and the level of information available. By being pragmatic and giving fast feedback, the value obtained will track the 80/20 rule. As an example, it is very important to get the top 10 project rankings correct, but another thing entirely to try and fine tune project priorities lying in the 50^th to 60^th rankings.

Note, I am not suggesting there should be no clarifying dialogue between parties along the way, just that the act of providing the feedback ‘fast’ is a good way to flush out any major misunderstandings.

Decisions require preparation

It is hard to get time from senior stakeholders and harder still to sync their diaries to meet at the same time. A direct discussion of priorities is a challenge without having first developed the proper context. So, the approach for establishing priorities is likely to be an important point for the senior stakeholders along with the consequences of any decision options.

Therefore it is worth establishing a small core team to build and test a prioritisation framework and drive the significant ground work prior to any proposal. More on this in a later post.

Present versus future

“If we don’t secure today’s business then there is no tomorrow”. People tend to attribute higher value to items appearing in the immediate future rather than those slightly further away. This is natural and also a consequence of the time value of money or NPV. However, it is a bad sign when all risk and change gets pushed forward (delayed) further into the future. A balance is necessary and the core team should take care of the present vs. future investment balance according to the industry change clock cycle.

Prioritising development initiatives..part2

This was a historical exercise, but how might I approach matters now? With the benefit of hindsight, I would consider the approach:

Establish a core team
Map the projects to aid understanding
Interpret the strategy to build a framework
Make trial rankings and test result
Prepare for the senior stakeholder review

1. Core team considerations

Fair representation of the business. Functional area owners want to be consulted on matters that impact on their responsibility areas. If you require strong endorsement of the results, you will need representatives of these different functional owners to take part. Enough representation to build a “wide enough” business view, but not so much as to bring the impression of a fully democratic exercise. The functional representation is there to bring insight into relevant areas of the business, not necessarily to pass judgement on the whole spectrum of activities.

Calibre of resources. The qualities of the resources could be summarized as: motivated, capable, respected, possessing a broad knowledge and impartiality. Do the best that you can in ‘borrowing’ resources.

2. Map and understand the projects

The objective here is to make more sense of the project portfolio prior to ranking. The value is in the discussion for the core team, building an understanding how the initiatives create value for the business, their timing, mutual relationships and how they impact across the business.

The precise approach taken will vary somewhat depending on the nature of the precise question being asked and the stakeholders involved e.g. involving the whole business vs. only the product related functions. Some thoughts on potential candidates to include in mapping:

Project Value

Project Investment

Market risk

Technology Risk

Current project timelines

Future projects pipeline

Independent projects

Projects with dependencies

Mutually exclusive project options

Project duration

Resources

involved

# Independent teams

involved

# New assets created

(or types of assets created)

Product type architecture e.g.

Market type architecture e.g.

Core plat-form

Messag-ing /CRM

Scale data support

Customised visualisations

Professional

Services

tools

Core product

platform

Customisation

enablers

EMEA

projects

APAC

projects

NAM Projects

A couple of project maps to show how visualisation can help understanding:

Value vs. Technology risk and Market risk map.

This is a good method to test the rationality and balance of the project approach against the market opportunity. It captures the business value of projects by the radius of the bubbles, so the most valuable projects stand out.

But it is sometimes hard to give every project a business value. An alternate view is to use project investment to scale the bubble radius.

Projects resource/investment vs. timeline map.

This is a good method for seeing the relative and cumulative project resource in use on deliveries now as well as the anticipated future commitments. It is a useful view for testing portfolio “options”, although with future project estimation a challenge, project categories or templates maybe necessary.

3. Interpret strategy to build a prioritisation framework

The business strategy should provide clear guidelines as to what is important to the business, both now and for a few years into the future. Thus for prioritisation of projects/initiatives, strategic alignment is a key criterion. However, strategy alignment can be captured through a variety of measures, so general guidelines for the prioritisation framework include:

Clear meaning for individual criteria	Readily understood by all of the core team
Independent criteria	Cover clearly separate issues
Criteria have different priorities	Some criteria clearly more important in prioritisation
Individual criterion has “values”	Enables ranking on 1 criterion (even if high/mid/low)
Enough elements as necessary	But as few as possible to avoid fatigue with large portfolio

It is especially important that core team members representing the business function stakeholders are fully understanding and supportive of the framework selected.

4. Issues in trial ranking of projects

Fatigue. Large portfolios take time to discuss and must be split over several sessions. Ideally this happens over consecutive days to maintain a consistent “mind set” for the work. Energy is needed to combat fatigue, so the project content should be ordered so that the most relevant (however judged) projects are dealt with first, creating high value and building confidence in the approach.

Maintaining Cadence. Within sessions, it can be useful to “time box” individual project discussions and place those projects that lack conclusion into an open category. If many projects keep getting put in the open category then this can be a sign of:

Low quality project descriptions
Too complex prioritisation framework
Too many people participating

The project lead can directly address the last two issues e.g. by opening up the framework or using a smaller size team to build the draft proposal & review with the wider core team.

Handling “open” category projects. The lead should judge if it is worth investing more time to clarify “open” projects/ priorities or to prepare to return such projects without overall priority but within some identifying category e.g.

Projects lacking in description/benefits
Projects lacking agreement on business priority

Rationality and balance of the result. The trial project rank result should appear to make sense logically. If there are some anomalies, then it is worth rechecking for consistency of prioritisation criteria. The other test which is less obvious is to look for balance using the earlier project mapping. If only the top 25% of projects are considered, what would the portfolio then look like when mapped? This approach picks up cases when there is not enough in effort anticipating future problems e.g. paying back technical debt.

5. Preparing for the senior stakeholder review

The ultimate approach taken for the review depends on the nature of the original question asked and therefore if any explicit decisions are required. The normal recommendations apply e.g. gaining feedback when possible from impacted functions, ensuring issues have solutions for mitigation and that the consequences for decisions are outlined.

It is important to be able to briefly show the “workings” how the team came to its proposal e.g.

This is the issue e.g. project portfolio load unsustainable
Here are the people / functions engaged in this activity to address the issue
Here is the prioritisation methodology used
And here are the conclusions & key decisions…

The visualisations built used for initially understanding the project portfolio are very valuable as a way of communicating the consequences of different options.