Tuesday, November 24, 2015

Beacon Essentials You Must Quickly Learn

Our resident Cognizant digital/mobile expert, Peter Rogers, asked me to recommend a digital strategies topic to share, and I suggested Beacons for this week.  I confess to reading about them daily without knowing much about them, so I want to thank Peter for this article!  Enjoy!
Digital & Mobile Expert
Peter Rogers

Let's start with a Basic Beacons 101 class:

  1. Beacons do not push out notifications. They broadcast an advertisement of themselves (traditionally their UUID, major and minor values) and can be detected by Bluetooth Low Energy (BLE) devices.
  2. The proximity from a number of Beacons can be measured using typical triangulation techniques in order to get a (very) rough idea of (typically) indoor location.
  3. The Beacon UUID, major and minor version values are typically used for identification and used to map to either a message, service, media content, website, application or location inside the Native App.
  4. Beacons can have their UUID, major and minor versions (and indeed power level) modified statically before deployment or dynamically using WiFi connectivity. A Beacon Management App is often provided by a Beacon Platform Vendor to allow you to manage these values dynamically.
  5. Updating the Beacon major and minor values can be used to update the identity of the Beacons and subsequently change what they map to inside the Native App. This does mean there is a security risk of somebody remotely hacking your Beacons and changing their values to take down or corrupt your service.
  6. iBeacon is Apple’s proprietary BLE profile but their patents seem to cover more than just the profile aspect. There were Beacons before iBeacons. Apple did not invent the Beacon. What they did is an incredibly good job of integrating Beacon support into iOS. iBeacon is not a piece of hardware. It is a BLE profile that is loaded onto a piece of hardware. This profile makes the Beacon an iBeacon.
  7. There are many Beacon vendors who offer various capabilities such as: BlueCats; BlueSense; Gelo; Kontakt.io; Glimworm; Sensorberg; Sonic Notify; beaconstac; mibeacon (Mubaloo); estimote; Gimbal (Qualcomm); Apple; and Google, etc. 

Beacon vendors offer various difference offerings such as:

  • hardware
  • proprietary BLE Beacon profiles
  • support for popular profiles
  • remote Beacon management
  • analytics
  • associated content management
  • marketing campaigns
  • software version management
  • profile switching
  • client side SDKs
  • professional support services
Most do not offer the whole solution, and so it was interesting to see Apple and then Google throw their hat into the ring. Most people are still really excited about Apple’s iBeacons, but they look like they will become a closed eco-system which could possibly even include being able to be physically undetectable to non-Apple hardware.  Today Beacon vendors are just not allowed to provide library based support for iBeacons on Android hardware (http://beekn.net/2014/07/ibeacon-for-android/).

At the start of 2015 Google created a new form of Beacon called UriBeacon (http://uribeacon.io/) which was able to actually advertise a URL pointing to a website or a URL that could be processed locally. This was in stark contrast to all the previous forms of Beacon which could only advertise their identity (UUID, minor, major). UriBeacons also promised to be cheaper and easier to configure, which was largely down to their more limited use case of just being used to advertise a URL/URI. The killer concept, however, was that of The Physical Web. The Physical Web is an approach to unleash the core superpower of the web: interaction on demand. People should be able to walk up to any smart device and not have to download an app first. A small pre-installed App (like the Web Browser or something Operating System level) on the phone scans for URLs that are nearby. Google previously used the UriBeacon format to find nearby URLs without requiring any centralized registrar.

This was a major breakthrough because having to download an App for each Beacon vendor completely breaks the organic, intelligent, evolutionary Smart City model. Notice that I used the words ‘without having to download an App’. You still need an App to process the UriBeacons, however, this can be built into the Web Browser (Chrome offers this for iOS) or the Operating System (Android M offers this). The following vendors offer UriBeacons: Blesh; BKON; iBliO; KST; and twocanoes, etc.  

Recently Google updated their single-case UriBeacon specification to that of Eddystone. Eddystone is an open-source cross-platform beacon solution that supports broadcasting of UUID, URL, EIDs and Telemetry data. Previously Beacons had only supported UUID until UriBeacons offered the single option of URL advertisement. Eddystone offers an additional two frame types: Ephemeral ID is an ID which changes frequently and is only available to an authorised app; Telemetry is data about the beacon or attached sensors: e.g. battery life, temperature, humidity. Unlike iBeacons, which must be approved by Apple, anyone can make an Eddystone-compatible beacon. Current beacon manufacturers include: Estimote; Kontakt; and Radius Networks, etc.

The Eddystone-URL frame broadcasts a URL using a compressed encoding format in order to fit more within the limited advertisement packet. Once decoded, the URL can be used by any client with access to the internet. For example, if an Eddystone-URL beacon were to broadcast A URL then any client that received this packet and with an Internet connection could choose to visit that URL (probably over WiFi). You can use an App to manage that experience and either take you directly to the URL or process a URI internally to perform some other function without network connectivity. Better still The Physical Web initiative has moved away from UriBeacon to the open initiative of Eddystone.

Now one thing to realise is that Eddystone may support iOS but that obviously does not include integration with CoreLocation as per iBeacons. Eddystone beacons only interact with iOS devices via CoreBluetooth which means you have more work to do. Likewise, on Android M there are a whole bunch of new APIs and those will not be available on iOS.

  • The Nearby API makes it easy for apps to find and communicate with beacons to get specific information and context. Apparently it uses a combination of Bluetooth, Wi-Fi, and inaudible sound.
  • Nearby provides a proximity API called Nearby Messages in which iOS devices, Android devices and Beacons can discover, communicate and share data/content with each other.
  • The Proximity Beacon API helps developers to manage data and content associated with Beacons. Once Beacons are registered with Google's Proximity Beacon API then we can map data and content that can be pulled from the Cloud using a REST interface. This makes Content Management Solutions much easier and gives us the ability to dynamically map content available to Beacons. This functionality will most probably be supported in the Physical Web through Web Browsers clients that support this API through JavaScript.  
  • Place Picker is an extension of Places API that can show Beacons in your immediate vicinity. The Places API is also able to read and write Beacon positioning information (GPS coordinates, indoor floor level, etc.) from/to the Google Places database using a unique Place ID based around the Beacon UUID and then have the Beacons navigable though Google Maps. This would provide a much better retail solution where customers could literally Google “Hair Shampoo” inside a Boots store and be taken directly to the product using indoor positioning.

I am sure you have many questions such as, can a Beacon run iBeacon and Eddystone simultaneously. At the moment the Beacon vendors offer the ability to support both profiles but not simultaneously. This is apparently due to battery usage. Most vendors do seem to support simultaneous broadcast of UUID, URL and Telemetrics within Eddystone though. For any other questions then here is a fantastic Q&A on Eddystone from Kontakt.io (http://kontakt.io/blog/eddystone-faq/).

The Physical Web has now moved away from UriBeacon and onto Eddystone-URL frames. A few months ago, Chrome for iOS added a Today widget. The new Chrome for iOS integrates the Physical Web into the Chrome Today widget, enabling users to access an on-demand list of web content that is relevant to their surroundings. The Physical Web displays content that is broadcasted using Eddystone-URL format. You can add your content to the Physical Web by simply configuring a beacon that supports Eddystone-URL to transmit your URL of choice. When users who have enabled the Physical Web open the Today view, the Chrome widget scans for broadcasted URLs and displays these results, using estimated proximity of the beacons to rank the content.

The Physical Web also support finding URLs through Wifi using mDNS (and uPnP). The multicast Domain Name System (mDNS) resolves host names to IP addresses within small networks that do not include a local name server. It is a zero-configuration service, using essentially the same programming interfaces, packet formats and operating semantics as DNS. While designed by Stuart Cheshire to be stand-alone capable, it can work in concert with DNS servers. The mDNS protocol is implemented by the Apple Bonjour and by Linux nss-mdns services. In other words rather than waiting for your client to discover a Beacon advertising a UUID or URL then you could actually start searching for local services hosted on Beacons using a multicast form of DNS. Beacons are actually more powerful than most people realise and can often run micro-services on them. In fact if we think about it then Beacon based services are the ultimate form of a micro-service architecture. Brillo is an upcoming Android-based operating system for IoT devices and this lightweight OS could theoretically run on a Beacon which would enable a portable way of deploying a Beacon based micro-service architecture.

When you woke up this morning did you honestly think that Beacons were that powerful?

Kevin Benedict
Writer, Speaker, Analyst and World Traveler
View my profile on LinkedIn
Follow me on Twitter @krbenedict
Subscribe to Kevin'sYouTube Channel
Join the Linkedin Group Strategic Enterprise Mobility
Join the Google+ Community Mobile Enterprise Strategies

***Full Disclosure: These are my personal opinions. No company is silly enough to claim them. I am a mobility and digital transformation analyst, consultant and writer. I work with and have worked with many of the companies mentioned in my articles.

Monday, November 23, 2015

The 18 Laws for Winning with Data, Speed and Mobility

I have given nine presentations in the past 10 days on mobile and data strategies.  I have met with companies in the energy, media, insurance and banking industries.  I have brainstormed and discussed these laws for winning with data, speed and mobility, and they have held up.  In the age of mobile me, where information is the prize, a new set of laws and strategies are required to win.  In my new report, "Cutting Through Chaos in the Age of Mobile Me," I discuss many of these laws and how they are applied in mobile apps and mobile commerce.
  1. Data is the modern commercial battlefield.
  2. Information dominance is the strategic goal.
  3. Real-time operations and tempos are the targets.
  4. Advantages in speed, analytics, business operational tempos determine the winners.
  5. Real-time business speed is enabled by advances in mobile information, sensors and wireless communications.
  6. Competition is now focused on optimizing information logistics systems (the systems involved in maximizing information advantages).
  7. Businesses that can “understand and act with speed” dominate those which are slower. 
  8. In order to win or gain superiority over competitors in the age of information, you must operate  information logistics systems at a faster tempo, and get inside your competitor's decision curves. (Adapted from John Boyd)
  9. Situational awareness enables insights, innovations and operations to be conducted faster and at lower cost .
  10. Principle of Acceleration & Mobility – As demand for mobile apps increases, an even greater demand for changes will occur across business processes, operations and IT.
  11. The more data that is collected and analyzed, the greater the economic value and innovation opportunity it has in aggregate.
  12. Data has a shelf-life, and the economic value of data diminishes quickly over time.
  13. The economic value of information multiplies when combined with context and right time delivery.
  14. Mobile apps provide only as much value as the systems behind them.
  15. Full Spectrum Information: Winners will dominate by collecting, transmitting, analyzing, reporting and automating decision making faster and better.
  16. The size of opponents and their systems and platforms are less representative of power today, than the quality of their sensor systems, mobile communication links and their ability to use information to their advantage.
  17. Information is a new asset class, in that it has measurable economic value.  There are significant strategic, operational and financial reasons for investing in it, and optimizing it. (Douglas Laney, Gartner)
  18. If I can develop and pursue my plan to defeat you faster than you can execute your plan to defeat me, then your plan in unimportant. ~ Robert Leonard
These laws need to be known, and their relevance intimately understood and applied to every aspect of business and IT today.

Download the new report "Cutting Through Chaos in the Age of Mobile Me" - http://www.cognizant.com/InsightsWhitepapers/Cutting-Through-Chaos-in-the-Age-of-Mobile-Me-codex1579.pdf

Kevin Benedict
Writer, Speaker, Analyst and World Traveler
View my profile on LinkedIn
Follow me on Twitter @krbenedict
Subscribe to Kevin'sYouTube Channel
Join the Linkedin Group Strategic Enterprise Mobility
Join the Google+ Community Mobile Enterprise Strategies

***Full Disclosure: These are my personal opinions. No company is silly enough to claim them. I am a mobility and digital transformation analyst, consultant and writer. I work with and have worked with many of the companies mentioned in my articles.

Tuesday, November 17, 2015

Data Collection and the Modern Battlefields of Business

Dr. John Snow's Map
In 1854 Cholera broke out in the Soho neighborhood of London.  Hundreds of people were struck down and died within days.  No one, at the time understood where the disease came from, how to treat it or how it was transmitted.

A local physician, Dr. John Snow spent every possible moment of his day studying the victims and data in an attempt to understand the disease.  His biggest challenge was a lack of data.  He had only the list of the dead and a blank map of the neighborhood.  What he needed was more data.  This was solved when he met the local priest, Henry Whitehouse.  Whitehouse had recorded the time of death, and the location where all the families lived and died.  When these sources of data where combined, and then overlaid on a map, visual patterns emerged which ultimately led the two to see the common denominator for all the victims was drinking contaminated water from the Broad Street water pump.

The pump handle was removed, people stopped drinking its water, and the disease burned out.  Dr. John Snow is now recognized as one of the fathers of modern epidemiology.  The data that led to his discoveries were:
  • Victims
  • Relationships
  • Locations
  • Time of illness
  • Time of death
  • Behaviors and patterns of life
Adding all of these data sources to a map, for visual reference and clarity, enabled the insight that ultimately revealed the source and means of transmission of the disease.  Minus key data sources, the disease would have remained a mystery and many more people would have died.

In business, many challenges and obstacles today can also be solved with better data collection strategies and enhanced analytics.  We have all heard the phrase, "knowledge is power."  Knowledge comes from data, so data is power.

I sincerely believe that the battlefields of business today are around data.  The winners of today and tomorrow will be those better able to collect, analyze, understand and apply data to the customization and personalization of digital interactions.  My colleagues Malcolm Frank, Paul Roehrig and Ben Pring wrote the book "Code Halos" last year to dive deep into these ideas.

Last week I published a new thought leadership whitepaper on the application of real-time data strategies and analytics to mobile commerce and consumer facing mobile applications.  The paper is titled, "Cutting Through Chaos in the Age of Mobile Me."  You can download the whitepaper here http://www.cognizant.com/InsightsWhitepapers/Cutting-Through-Chaos-in-the-Age-of-Mobile-Me-codex1579.pdf.

Kevin Benedict
Writer, Speaker, Analyst and World Traveler
View my profile on LinkedIn
Follow me on Twitter @krbenedict
Subscribe to Kevin'sYouTube Channel
Join the Linkedin Group Strategic Enterprise Mobility
Join the Google+ Community Mobile Enterprise Strategies

***Full Disclosure: These are my personal opinions. No company is silly enough to claim them. I am a mobility and digital transformation analyst, consultant and writer. I work with and have worked with many of the companies mentioned in my articles.

Thoughts on Delivering Digital Transformation with Agile

My colleague the digital expert and programming guru Peter Rogers share his insights on the role of Agile in digital transformation, and the major debates around methodology.  WARNING!  This article dives deep into programming strategies, so go NO further if this frightens you.  Enjoy!
Peter Rogers
Most digital projects are going to end up being run as Agile. With that said it is well worth knowing which style of Agile you are actually using to ensure that: it is indeed a recognised style; and that you play to its strengths. Often projects fall between different styles or offer a random approximation of what the team thinks an Agile project should look like. In either case you may find the project goes inexplicably sideways.

XP (or Extreme Programming) is a suite of practises, principles and values invented by Kent Beck in the late 90s. A lot of people remember XP for the controversies such as pair-programming fights to the death over curly brace placement and confusion over 40 hours a week being a Sustainable Pace.

What people forget about XP is that is actually came up with most of the practises that we use today in Agile:

-Planning Poker
-Collaborative multi-discipline teams
-Acceptance Tests
-Continuous Integration
-Test Driven Development
-Simplest Design

XP is one of many Agile methods but it still remains the most well defined, broadest and well disciplined. Am I suggesting you use XP? I think you probably do use a few of its practises already. It is certainly interesting that what you probably considered Agile is actually an XP practise that you have bolted onto your chosen Agile method.

In 2000 a large developer summit took place in Utah and the result was a manifesto for Agile Software Development.

This created 4 values:

-Individuals and interactions over processes and tools
-Working software over comprehensive documentation
-Customer collaboration over contract negotiation
-Responding to change over following a plan

The set of values was accompanied by a set of 12 principles which you can find at www.objectmentor.com who offer great debate on this topic.

Now those of us who live in the real-world are already laughing at the third point, "Customer collaboration over contract negotiation".

Sadly in a world of fixed price, fixed deliverable, fixed time,  fixed capacity, heavily negotiated digital contracts then it makes it hard to see how Agile even has room to breath. One solution in this situation is to use longer term Agile Planning techniques (Agile Planning Onion) as opposed to software estimation techniques (like UCP). You plan how to deliver the high level work packages inside of the shell of an agreed set of sprint / release based payment milestones. When most of the variables are already fixed then you look towards planning as opposed to estimation, as a beacon for delivery confidence.

At this junction as a technologist, solution architect and offshore/nearshore specialist, I must take issue with two of the Agile principles:

(1) The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

The world has moved on since the year 2000 and there is no reason to believe Agile projects have to be run in all in one room. We live in a time of offshoring and nearshoring that just wasn't considered back then.  That said I do believe (from personal experience) that teaching is far more effective face to face. So maybe I partly agree but I object to the implications of the wording.

(2) The best architectures, requirements and designs emerge from self-organizing teams

Unfortunately I do not subscribe to the theory that we do not need subject matter experts and specialists, and anyone should be able to do any role and a team can self-repair without any external guidance. This is not what I have seen in the real-world.

I equally disagree that teams can autonomously find and complete training as and when required, in order to self-heal and repair themselves during a project without any external influence.

Instead I believe in mentors and subject matter experts who train the team in order to improve them as a collective. If these people are in the team, then that's great but there is nothing wrong with external mentors. This is not a communist state and everyone does not have to be equal in anything other than respect. There have to be knowledge leaders to help spread the knowledge and in most cases there is an external support framework.

Seal Team 6 has repeatedly proven that a small specialist team can do what a thousand generalists could not even hope to achieve. I certainly believe in empowering developers and motivating a team, but everybody has roles. If you give a job to somebody who isn't good at that job, then it will take much longer. I certainly do not believe in emerging architectures and emergent problem solving either.

Indeed I feel solution architects will probably agree with me on these two points, but feel even stronger about some of the concepts in Lean.

Lean originates from Lean Manufacturing where you eliminate waste and The Toyota Way where you improve flow or smoothness of work.

This is achieved through the following principles:

-Pull Processing
-Perfect First Time Quality
-Waste Minimization
-Continuous Improvement
-Long Term Relationships
-Production Flow
-Visual Control

Mary and Tom Poppendieck adapted the principles from Lean Manufacturing to create Lean Software Development with the following premises:

-Eliminate Waste
-Build Quality In
-Create Knowledge
-Defer Commitment
-Deliver Fast
-Respect People
-Optimise The Whole

Lean tells us to eliminate anything not adding value at this moment in time. That can mean eliminating features, documents, meetings and even future known requirements. If it doesn't add immediate value then its out.

One thing Lean gets spot on is the concept of optimising the whole. Too many companies reward partial goals like lines of code or defects found. These goals are often mutually exclusive as many managed service organisations found out a few years back. Focus your goals and reward system around optimising the whole system and not part of it.

The first thing I disagree with Lean on is that it expects teams to miraculously self-heal without any external intervention. I personally believe there is a difference between healthy respect and failing to intervene when a team is clearly struggling and needing help. Some would disagree but I don't agree with teams operating in a bubble as they are always surprised by the effects of what lives outside.

A second thing I adamantly disagree with Lean on as a solution architect is the notion of deferring decisions to the last minute and waiting for an emergent solution to appear. Never in my life has such an emergent solution appeared. Those who fail to plan, plan to fail. I doubt I am the only solution architect to take issue with this point if only for fear of job security.

A third and final point is if you can show me a Lean project that can work with reusable components on separate delivery timescales then I will literally buy and eat a hat.

Lean appears to promote a lack of future planning, risk management and dependency management. Its "live in the moment" style is popularised by Lean Start Up which promotes Continual Deployment and Fail Fast. Originally developed in 2008 by Ries with high tech companies in mind it does remain a good technique for Start Ups to test a product on a target audience without burning all their VC money in month one.

Ries offers these lean startup principles:

-A Minimum Viable Product
-Continuous Deployment
-A/B Testing
-Actionable Metrics
-Pivots (course correction)
-Innovation Accounting
-Build, Measure and Learn loop

Later business model templates arose:

-Business Model Canvas
-Lean Canvas
-Crowdfunding Canvas

I like Lean Startup although I take issue with some of the Lean thinking, because it offers some solid principles straight out of the Extreme Programming domain. That said outside of Start Ups you will rarely find companies doing Continual Deployment (as opposed to Continual Delivery), willing to float an unpolished MVP or able to accept the financial risk of a failed product.

So where does that leave us? I believe we need to pick an Agile methodology, and there are three main contenders:


We all know and love Scrum. The Sprint Backlog details the User Stories (or Features in BDD) to do and the Product Owner provides a prioritisation based on the business needs. Each Sprint is fixed in duration (normally 2 weeks) with its content decided just before using Story Points or Ideal Days in a game of Agile Planning Poker.

The benefit of the fixed Sprint sizes is that you can work out the Velocity of the team based on the completed Story Points in order to fit just enough User Stories into the next Sprint with a few Stretch Targets. Burndown charts visualise the Story Point progress and a Scrum Master is in charge of keeping the team motivated and clear of distractions. We show the Product Owner a fully working product at least every Sprint and so we get regular feedback and validation.

I must say that I love Scrum but I do agree with some of points raised by the Kanban Camp. Fixed Sprint sizes can be too long to get validation, and during those 2 weeks the business may have changed direction. If you are working with a highly dynamic business, then you may need to either adopt 1 weeks Sprints or consider Kanban.

The second problem with Scrum is that there are no measure of how long it takes for a feature to go live. If you are doing Behaviour Driven Development (BDD) and/or Continual Delivery then Feature Cycle Time is a particularly useful measure of efficiency.

The third and final problem with Scrum is that often the Product Owner role is part-time and does not have a strong connection with the business, and the Scrum Master role is part-time or doesn't exist for cost reasons.

Kanban is the second popular approach, although I must admit here and now that I have often seen this border precariously on chaos. Kanban has no time boxed Sprints but instead it limits how many features a team can work on at any given time. There is no Product Owner or Scrum Master and the team just decide priorities collectively.

When a feature is completed then it can be made immediately available to release into production (or a suitable safer environment) and the Cycle Time can be recorded as a measure of team efficiency. The team can then collectively choose to work on whatever the next highest priority item is in the Backlog.

The cool part is that we can use simple tools like Trello which offer a customisable Kanban board as opposed to heavy weight tools like Jira. Traditionally we would have something like 'To Do', 'In Progress' and 'Done' columns. We normally break 'In Progress' into some workflow states but you get the general picture of simplicity offered here.

We now limit the number of items in each column of the Kanban board. This is critically to avoid multi-tasking and context switching which is highly inefficient. The Kanban board gives us a visualisation of the team's workflow and it keeps them prioritised without a Scrum Master role.

Seeing as we can release a feature whenever we want then we tie into Continual Delivery much more closely. We also get much faster feedback from the customer which allows us to roll back badly thought out features and feature correct rapidly without destroying the product.

There are also some very nice Kanban visualisation techniques for Feature Cycle Time and Accumulative Status.

My first issue is how the team democratically chooses the next item to work on. The second issue is that without Sprints then there is no guarantee of what will actually be delivered at any stage in the progress.  The third issue is that there is a even stronger notion of unmanaged teams without the Product Owner or Scrum Master to offer a helping hand if things go south.

The solution is my view is the third option which is Scrumban. This takes Scrum with the fixed Sprint sizes, Product Owner and Scrum Master but adds in a few concepts from Kanban.

-Kanban Feature Cycle Time
-Kanban Feature Limits

If I were to personalise this further into "Peter's Real World Scrumban" then I would add the following:

-Remove the Scrum Master role and use Feature Limits to stop context switching if cost is an issue
-Make sure you have a 100% Product Owner role
-Ignore Lean advice about not planning for the future
-Use internal or external mentors for team learning don't expect this to happen magically overnight
-Use both Sprint Burndown Charts and Kanban Cycle Time Graphs
-Add in some of the best Extreme Programming practises like TDD and Continual Delivery
-Avoid Continual Deployment unless you are in a Start Up that can afford to Fail Fast
-Embrace some of the BDD features like Gherkin, Three Amigos and Automated Acceptance Tests
-Add in some of Lean Start Up's best practises like MVP, A/B testing and Pivots
-If a process isn't working for you then fix the process before you try to fix the people
-It isn't an Agile project just because somebody decides to call it that. Embrace the Agile values rather than a few bullet points

Special thanks to the amazing Abby Fichtner for her excellent website at hackerchick.com that gave me a lot of inspiration for this debate.

Good luck and I hope this helps you make the right choice in your Agile adventures.

Kevin Benedict
Writer, Speaker, Analyst and World Traveler
View my profile on LinkedIn
Follow me on Twitter @krbenedict
Subscribe to Kevin'sYouTube Channel
Join the Linkedin Group Strategic Enterprise Mobility
Join the Google+ Community Mobile Enterprise Strategies

***Full Disclosure: These are my personal opinions. No company is silly enough to claim them. I am a mobility and digital transformation analyst, consultant and writer. I work with and have worked with many of the companies mentioned in my articles.

Monday, November 02, 2015

Cutting Through Chaos in the Age of Mobile Me - New Report

Supporting real-time enterprise mobility that is personalized and contextually relevant takes a lot of work. In fact, it takes digital transformation. We have all grown accustomed to using personal consumer apps that know and understand us (think airline apps and Netflix), our preferences and provide contextually relevant content. Today, we expect the same from all of our apps both consumer and enterprise.

Download the full report here "Cutting Through Chaos in the Age of Mobile Me".

Ninety percent of mobile users highly value personalized mobile experiences. In order to deliver these experiences one must have real-time data collection, analytics, personalization engines and mobile applications capable of supporting real-time personalization. One must also have an operational tempo within their IT systems and business processes capable of supporting real-time. These capabilities make possible innovative new business processes that provide significant competitive advantages for businesses that embrace them.

Delivering a personalized experience, however, requires data and lots of it. We have identified three key information rich sources of this data we call 3D-Me data sources:

  1. Digital – online activities, preferences, sentiment and profiles
  2. Physical – data collected from IoT sensors (on vehicles, buildings, equipment, wearables, smartphones, etc.)
  3. Personal – user preferences, roles, jobs, skills, locations, etc.
3D-Me data sources enable enterprises to collect the right data to gain an understanding of real-time activities, and insights into the needs of their users. One of the key ingredients of a 3D-Me data source strategy is users must agree to share personal data in exchange for value. This requires a new kind of enterprise/user relationships we call MME Data Partnerships.
Personalized experiences are not the whole story. End users want contextually relevant personalization. Personalization becomes relevant when you add time, context and location to it. Sending me an SMS alert that my local coffee shop is offering my favorite hot drink at a 50% discount for the next 45 minutes is not relevant if I am on the other side of the country. Relevant personalization requires the use of data triggers that identify contextually relevant opportunities, moments and environments (CROME). CROME triggers are bits of data that provide context, which can be used to provide relevant personalization at a specific time and place. Think geo-fencing jobsites.

These CROME triggers provided the data that when analyzed, understood and integrated with relevant personalization engines, can optimize the user's experience and productivity on the job.

CROME triggers can automatically deliver the right content at the right time. They can be connected to tasks, jobs, timesheets, etc. There are at least six tasks/challenges when implementing a CROME strategies:
  • Identify the required CROME triggers
  • Understand the meaning of each CROME trigger
  • Understand where and how CROME triggers can be placed, collected and transmitted
  • Monitor and analyze CROME triggers in real-time
  • Connect specific CROME triggers to specific personalization options and business value
  • Provide CROME powered personalization in mobile experiences
CROME triggers inform that something different and perhaps significant is happening. Finding the meaning, and then relating it to a particular personalization task or action follows.

The implementation of 3D-ME enabled data and personalization strategies and CROME triggers, all supported by IT systems and business processes running at real-time operational tempos will help companies deliver to the highest expectations of mobile users today and tomorrow.

Download the full report here http://www.cognizant.com/InsightsWhitepapers/Cutting-Through-Chaos-in-the-Age-of-Mobile-Me-codex1579.pdf.
Kevin Benedict
Writer, Speaker, Analyst and World Traveler
View my profile on LinkedIn
Follow me on Twitter @krbenedict
Subscribe to Kevin'sYouTube Channel
Join the Linkedin Group Strategic Enterprise Mobility
Join the Google+ Community Mobile Enterprise Strategies

***Full Disclosure: These are my personal opinions. No company is silly enough to claim them. I am a mobility and digital transformation analyst, consultant and writer. I work with and have worked with many of the companies mentioned in my articles.