Sunday, December 27, 2015

IoT Consortiums, IoT Standards and IoT Adoption



Introduction
As the IoT finds more use cases across initiatives for ‘Connected Home’, ‘Connected Body’, ‘Connected Transportation’, ‘Connected City’, ‘Connected Enterprise’ and Industrial IoT Applications across verticals, there is a recognized need to make the IoT work better than it does in light of the immense potential the IoT holds with these and other areas still-to-be envisioned.

 

Even as IoT opportunities have shown themselves to be compelling, so too have numerous challenges, not the least of which are funding, manufacturing, distribution, marketing, sales but rather, issues spanning interoperability, usability and development platforms, prompting formations of groups of industries to come together to collaborate cautiously and not run blindly into this new era of  connected devices without defining some operating guidelines, frameworks and standards.

 

Inevitability of the IoT Market
It doesn’t matter whose numbers are right - Cisco claims 50BN devices by 2020, IDC quotes 7.1 trillion $ 2020 and Gartner estimates $300 B by 2020 - and other claim that these numbers could be low as they tend to focus more on the Home/Hub model and not the emerging p2p model, and because several industries e.g. Media companies are not yet represented. When cartoonists like Scott Adams poke fun at IoT, you can assume it is real. But IoT adoption has not taken off in a big way as there is a rethinking among industry leaders for establishing standards,frameworks and certifications, and to incorporate learnings from some IoT players who bootstrapped their way to some products in some vertical markets (Connected Home, Body, City/Buildings, Transportation, Industrial applications), although in silos,  and yet,  have only barely scratched the surface of the market potential.

 

On the flip side, some analysts have gauged IoT's bubble-like growth and blamed the lack of adoption based on irrational industry hype that has lead to overestimated appeal to mainstream consumers of connected devices. Mainstream investors haven’t pitched in to define the bubble. Even if a only few leaders survive and rise to the top it has not stopped startups from unveiling new wearables products and investors and venture capitalists backing them. Only the industrial IoT market seems to be attracting NO flak as that segment is geared toward automating tasks and analyzing data to cut costs and boost efficiency.

 

Standards
If you are old enough to recall VHS vs Betamax  (JVC vs. Sony) - the deciding factors included cost of video equipment and tape, recording time, ease of use, consumer preferences on quality of playback etc - consumer needs trumped incumbent standard. But in the 70s & 80s, the video cassette player/recorder was a standalone modular piece of electronic equipment. There is a lot more at stake in the IoT standards war with a lot more contributors delivering value to actualize the IoT, like device manufacturers who build different types of appliances (personal, in-home, transport, healthcare)  after embedding sensors to enable experiences, manufacturers of sensors, developers, cloud providers etc. Important considerations include low-power consumption low latency,  self-healing ability, reliable enough for applications that have to work all the time, fail-safe redundancies, extensibility, security and to be interoperable with a myriad of other appliances to bring forth the improved experience to end- consumers. This implies compatibility with a plethora of technologies, formats, protocols, networks, appliance manufacturer chipsets and a platform for developers to easily, quickly write software to manage communications and security within a wide ecosystem to create meaningful connected experiences. Security frameworks and standards need to be defined and enforced to eliminate the risk of in-transit data hacks. (While we have all heard of YouTube but not of h.265 or H.NGVC...because it bewilders most of us to talk about the soooo many video formats out there in use or those that litter the codec bone yard. So we’ll skip those somnolent pieces and focus on the gist).

 

Motivation behind the IoT Consortiums
Several IoT consortiums have formed to solve qualitative problems that these early attempts at IoT exposed, and each in their own right have positioned themselves as framework providers for solutions that would purportedly makethings work better in unison, reliably within the ecosystem, utilizing light-weight protocols that have low-power requirements and support low-latency interoperability. Each consortium supports open membership cross-industry, distributes open-source code and technical documentation, protects IP and device certification. With all the rethinking going on, there isn’t (yet) a single common IoT standard for enabling infrastructure - in fact, even traditional approaches to IoT connectivity using web and cloud devices, is being questioned with the emergence of peer to peer (P2P) architectures to take advantage of low-power & quicker operations. Thread, Zigbee,  AllSeen, Open Interconnect Consortiums have formulated specifications and standard approaches to bring connections between the various areas of IoT, across different forms of technologies and protocols, to define common standard for connectivity and service discovery so different vertical areas of IoT can come together.

 

Historically, the process of consolidation and standardization to provide orderliness to the chaos amongst industry partners to come together under a common umbrella has been no less challenging than what the IoT consortiums are faced with. The challenges are being addressed in two broad layers - network and application. The initial incarnations of IoT solutions seems to have addressed the IoT client-to-cloud communications, but not so much the peer-to-peer (P2P) bridging and forwarding for things like wearables. There seems to be renewed interest by IoT consortiums to make it easy for developers to implement efficient P2P communications as it is for a  client to connect to a server on the cloud. Service providers will need to be the client-facing entity that manages differing end-user expectations for usability and administration. Even if the plumbing for IoT devices is standardized, the services would still need to be differentiated on the application layer, standards for which would have to be architected on top of the framework.

 

IoT consortium benefits
IoT consortiums are differentiating themselves by stating their value-add differently and touting their membership ranks, but the common denominator is that they all have a broad representation of industry partners and have developed a specification for reliable discovery, connectivity and interoperability and a reference implementations of the same. They support an open-source project & code-base that they distribute and manage via a source governance model. Device makers can take the code and change it to meet custom needs. Their framework specification are stated as being flexible across vertical markets and extensible to address new specifications for markets that are not there yet. They all have a certification body and provide intellectual property and branding protection as a benefit of certification. Additionally, they provide a platform for developers to build IoT applications and services, and to list the services provided, to test if their applications are compliant and if the devices can share data securely. The objective is to make it easier for developers, manufacturers to implementing interesting experiences for end users who can adopt the solution easily.

 

Zigbee focus on Connected Home, Industrial use cases and have ample representation and backing from Industry logos like , Samsung, Google Brillo. OIC backed by Intel and Microsoft focusses on peer-to-peer communications. Thread is designed as a secure wireless networking stack, for connected home products is not  a framework, uses IEEE and other existing standards, IPV6 compatible and supports at least 250 devices. Thread already collaborates with the ZigBee Alliance’s application layer work. In mid-2015, The Qualcomm backed AllSeen Alliance that manufactures AllJoyn devices for the IoT, joined Google’s thread and that seems to augur well for collaboration between the Thread, AllJoin and Zigbee. OIC’s framework could also work on top of Thread’s networking layer. The Thread Group is not a standards body rather, it creates market awareness of what Thread provides for the connected home and the associated benefits. Its certification program ensures security and interoperability between devices and ensures that the right experience is given to the end-users via devices with the Thread logo.

 

PoV & Conclusion
Along with the big players, as nimbler & innovative companies take advantage of the evolving IoT marketplace by identifying a niche and running with it, sub-par IoT solutions & devices could become available to consumers without enough testing, causing issues that impact usability and security. IoT consortiums are ushering in the needed orderliness to facilitate the way in which the world will need to be connected with a completely rehashed set of IoT standards. Standards while influencing usability of connected devices, can reduce if not eliminate the risk of security issues cascading into ‘bigger’ problems like the recent hacks that impacted the NASDAQ stock exchange, Netflix streams, United airlines groundings. The IoT marketplace would in its own right, be self-regulating in its adoption of IoT devices & solutions with increased understanding.  

 

To conclude loftily, Obama’s vision about a new world order operating with a different set of principles and based on a sense of common humanity is based on economies that work for all people and put together a government that actually can function in the face of ongoing terrorist threats etc. Would it be a stretch to wonder if  this goal  can only be implemented if the word is connected and standardized ? And if Internet.org and IoT could be a step in the right direction to realize this?

Saturday, May 3, 2014

Unica Campaign scores over the competition.....

Here is where I have posted my personal thoughts and considerations on how unica campaign stacks up against other solutions http://www.trustradius.com/reviews/ibm-unica-2014-05-03-09-54-28Unica Campaign - Where it wins !!

Wednesday, May 8, 2013

Examples of Functional Capabilities that were custom built on IBM/Unica Campaign v8.x ...


Here are some ideas for your company's investment in IBM/Unica Campaign to make it workable for your Marketing team - Here are some functional requirements that
required me to customize IBM/Unica Campaign for Marketing Execution, Planning/CRM and Analytics teams.
and delivered enabling "INFRASTRUCTURE" capabilities ... by leveraging subtler aspects of the tool.
These capabilities dont come "out-of-the-box" and were custom built combining Unica features, data mart, command line functions on the listener/unix host etc.
Search through flowcharts for any attribute, column, domain value references for performing Impact Analysis across flowcharts.
e.g Give me a list of flowcharts that use a particular variable/value/column and tell me the campaign, the process box, the logic in that process box or df/pdf/user variable/custom macro/ other component
Flowchart Logic/Domain Value TEXTUAL CAPTURE using XML parser
 
Strategic segment automation & Accelerated Flowchart build Campaign Execution analyst would "Toggle Switches" to bring in the chosen strategic segments that Execution Analysts can use to execute
within flowcharts (in lieu of building w/ process boxes - Useful for static or near-static rules)
 
External File-import broker mechanism to bring in Non-Production Data into a campaign flowchart (in a standardized way + Governance)
High-availability Datamart and DB Performance Management [Throttling Mechanism] for tackling late arriving marketing data from ETL jobs
in the Marketing Datamart. You load into the Inactive table and switch it out with the active table when the loading is done.

Perform Pre-Run-Validations & Terminate flowchart with reasons (emailed to executor /others) a.k.a kill switch
Utilizes Campaign & UMO metadata Rules to ensure error-free Mktg Operations & fulfillment processes

Flowchart stop-n-go - Campaign Execution analysts should be able to preview the output (if it is a file) by going to my Fulfillment Engine one last time … and after preview, hit Submit …
Strategic-Segment optimization, persistence, switching.
Personalized Offers, Auto-Segmentation (reducing data entry , automatic segmentation based on Audience Attributes)
Trigger-campaign Optimization (Predominantly Data-Mart level actions taken to provide the right Aggregation & recency )
Project the future runs of a Flowchart on Platform Scheduler using custom built scheduler cron-parser
System-table navigation layer flattened at the Treatment Instance, Run id , cell and/or Campaign w/offer metadata
Enhanced Table Catalog Usability by incorporating lookups for "Offer attributes"
Can the flowchart capture which Model Scores it utilized in the body of the flowchart so this can be used to track Model Utilization and Model Effectiveness (Flowchart log parser)
Strategic segments as a predictor of data quality in run-time - You can track counts over n days by looking at Segment membership
(Operational Data Analysts would know when data is wrong)