Bugs are everywhere. This statement holds true whether in the wild or on the world wide web. The latter is what this article focuses on…
A few weeks ago, I published what I thought at the time was a fairly innocuous article: How I replicated an $86 million project in 57 lines of code.
I’ll admit — it was a rather click-bait claim. I was essentially saying that I’d reproduced the same license plate scanning and validating technology that the police in Victoria, Australia had just paid $86 million for.
Since then, the reactions have been overwhelming. My article received over 100,000 hits in the first day, and at last glance sits somewhere around 450,000. I’ve been invited to speak on local radio talk shows and at a conference in California. I think someone may have misread Victoria, AU as Victoria, BC.
Although I politely declined these offers, I have met for coffee with various local developers and big name firms alike. It’s been incredibly exciting.
Most readers saw it for what it was: a proof of concept to spark discussion about the use of open source technology, government spending, and one man’s desire to build cool stuff from his couch.
Pedants have pointed out the lack of training, support, and usual enterprise IT cost padders, but it’s not worth anyone’s time exploring these. I’d rather spend this post looking at my results and how others can go about shoring up their own accuracy.
Before we get too deep into the results, I’d like to go over one thing that I feel was lost in the original post. The concept for this project started completely separate from the $86 million BlueNet project. It was by no means an attempt to knock it off.
It started with the nagging thought that since OpenCV exists and the VicRoads website has license plate checks, there must be a way to combine the two or use something better.
It was only when I began my write-up that I stumbled upon BlueNet. While discovering BlueNet and its price tag gave me a great editorial angle, with the code already written. There were bound to be some inconsistencies between the projects.
I also believe part of the reason this blew up was the convenient timing of a report on wasteful government IT spending in Australia. The Federal Government’s IT bill has shot up from $5.9 billion to $10 billion, and it delivered dubious value for that blow out. Media researchers who contacted me were quick to link the two, but this is not something I am quick to encourage.
In the spirit of transparency, I must declare something that was also missing from the original post. My previous employer delivered smaller (less than $1 million) IT projects for Victoria Police and other state bodies. As a result, I’ve undergone police checks and completed the forms required to become a VicPol contractor.
This may imply I have an axe to grind or have some specific insider knowledge, but instead I am proud of the projects we delivered. They were both on time and on budget.
The following is a video representation of my results, composited in After Effects for a bit of fun. I recorded various test footage, and this was the most successful clip.
I will go into detail about ideal camera setups, detection regions, and more after the video. It will help you better understand what made this iPhone video I took from through the windscreen a better video than a Contour HD angled out the side window.
If you saw the hero graphic of this article or watched the video above, you may have noticed a very interesting development: I caught someone.
Specifically, I caught someone driving a vehicle with a canceled registration from 2016. This could have happened for many reasons, the most innocent of which is a dodgy resale practice.
Occasionally, when the private sale of a vehicle is not done by the book, the buyer and seller may not complete an official transfer of registration. This saves the buyer hundreds of dollars, but the vehicle is still registered to the seller. It’s not unheard of for a seller to then cancel the registration and receive an ad hoc refund of remaining months, also worth hundreds of dollars.
Alternatively, the driver of the vehicle could well be the criminal we suspect that they are.
So, although I jokingly named the project plate-snitch when I set it up on my computer, I’m now faced with the conundrum of whether to report what I saw.
Ultimately, the driver was detected using a prototype of a police-only device. But driving on a 2016 registration (canceled, not expired) is a very deliberate move. Hmm.
Of the many reactions to my article, a significant amount were quite literal and dubious. Since I said I replicated the software, they asserted that I must have a support center, warranties, and training manuals. One even attempted to replicate my results and hit the inevitable roadblocks of image quality and source material.
Because of this, some implied that I cherry-picked my source images. To that I can only say, “Well, duh.”
When I built my initial proof of concept (again, focusing on validating an idea, not replicating BlueNet), I used a small sample set of less than ten images. Since camera setup is one of, if not the most, important factors in ALPR, I selected them for ideal characteristics that enhance recognition.
At the end of the day, it is very simple to take a fragile proof of concept and break it. The true innovation and challenge comes from taking a proof of concept, and making it work. Throughout my professional career, many senior developers have told me that things can’t be done or at least can’t be done in a timely manner. Sometimes they were right. Often, they were just risk averse.
“Nothing is impossible until it is proven to be.”
Many people bastardize this quote, and you may have seen or heard one of it’s incarnations before. To me, it neatly summarizes a healthy development mindset, in which spiking and validating ideas is almost mandatory to understanding them.
This project is so exciting and different for me because it has a clear success metric — whether the software recognizes the plate. This can only happen with a combination of hardware, software, and networking solutions. After posting my original article, people who sell ALPR cameras quickly offered advice.
The most obvious solution in hindsight is the use of an optical zoom. Though I explore other important factors below, none lead to such a sheer increase in recognition as this. In general, professional ALPR solutions are offset at an angle, trained on where the license plate will be, and zoomed into the area to maximize clarity.
This means the more zoom, more pixels to play with.
All the cameras I had at my disposal were of a fixed lens. They included:
The featured test run was recorded on my phone. My only method of replicating an optical zoom was using an app to record at 3K instead of 1080p, and then digitally zooming and cropping. Again, more pixels to play with.
The viewing angle of 30° is often referenced as the standard for ideal plate recognition. This is incredibly important when you learn that BlueNet uses an array of cameras. It also makes sense when you consider what a front facing camera would generally see — not very much.
If I had to guess I’d say a mostly forward-facing array would be the ideal setup. It would consist of a single camera pointed dead center as above, two off-center at 30° each side, and a single rear-facing camera. The value in having most of the cameras pointed forward would come from the increased reaction time if the vehicle is traveling in the opposite direction. This would allow a quicker scan, process, and U-turn than if the rear facing cameras picked up a suspect vehicle already ten meters past the police vehicle.
When compositing the video, I thought about stabilizing the footage. Instead I opted to show the bumpy ride for what it was. What you saw was me holding my phone near the windscreen while my wife drove. Check out that rigorous scientific method.
Both the attempt to replicate my project and my recordings since then explored the same misconception that ALPR sampling frame rate may be linked to success. In my experience, this did nothing but waste cycles. Instead, what is incredibly important is the shutter speed creating clean, crisp footage that feeds well into the algorithm.
But I was also testing fairly low-speed footage. At most, two vehicles passing each other in a 60km/h zone created a 120km/h differential. BlueNet, on the other hand, can work up to an alleged 200km/h.
As a way of solving this, a colleague suggested object detection and out-of-band processing. Identify a vehicle and draw a bounding box. Wait for it to come into the ideal recognition angle and zoom. Then shoot a burst of photos for asynchronous processing.
I looked into using OpenCV (node-opencv) for object recognition, but I found something simpler like face detection, taking anywhere from 600–800ms. Not only less than ideal for my use, but pretty poor in general.
Hype-train TensorFlow comes to the rescue. Able to run on-device, there are examples of projects identifying multiple vehicles per frame at an astounding 27.7fps. This version could even expose speed estimations. Legally worthless, but perhaps useful in every day policing (no fps benchmark in readme).
To better explain how high-performance vehicle recognition could couple with slower ALPR techniques, I created another video in After Effects. I imagine that the two working hand-in-hand would look something like this:
A different manifestation of frame rate is largely influenced upon shutter speed, and more specifically, the rolling shutter issues that plague early or low end digital movie recorders. The following is a snapshot from some Contour HD footage. You can see at only 60km/h the rolling shutter issue makes the footage more or less unusable from an ALPR point of view.
Adjusting frame rate on both the Contour HD and my iPhone did not result in noticeably less distortion. In theory, a higher shutter speed should produce clearer and crisper images. They’d become increasingly important if you were to chase the 200km/h BlueNet benchmark. Less blur and less rolling shutter distortion would ideally lead to a better read.
One of the more interesting discoveries was that the node-openalpr version I was using is both out-of-date and not nearly as powerful as their proprietary solution. While an open source requirement was certainly a factor, it was amazing how accurately the cloud version could successfully read frames that I couldn’t even identify a plate on.
I also found that the main node-openalpr package defaults to US country processing with no way of overriding it. You have to pull down someone else’s fork which allows you to then provide an extra country parameter.
But this doesn’t always help. Using the default US algorithm I was able to produce the most results. Specifying the Australian data set actually halved the number of successful plate reads, and it only managed to find one or two that the US algorithm couldn’t. Providing the separate “Australian Wide Plate” set again halved the count and introduced a single extra plate.
There is clearly a lot to be desired when it comes to Australian-based data sets for ALPR, and I think that the sheer number of plate styles available in Victoria is a contributing factor.
Open ALPR comes with one particular tool to reduce the impact of distortion from both the camera angle and rolling shutter issues. Planar warp refers to a method in which coordinates are passed to the library to skew, translate, and rotate an image until it closely resembles a straight-on plate.
In my limited testing experience, I wasn’t able to find a planar warp that worked at all speeds. When you consider rolling shutter, it makes sense that the distortion grows relative to vehicle speed. I would imagine feeding accelerometer or GPS speed data as a coefficient might work. Or, you know, get a camera that isn’t completely rubbish.
Numerous readers reached out after the last post to share their own experiences and ideas. Perhaps one of the more interesting solutions shared with me was by Auror in New Zealand.
They employ fixed ALPR cameras in petrol stations to report on people stealing petrol. This in itself is not particularly new and revolutionary. But when coupled with their network, they can automatically raise an alert when known offenders have returned, or are targeting petrol stations in the area.
Independent developers in Israel, South Africa, and Argentina have shown interest in building their own hacked-together versions of BlueNet. Some will probably fare better than others, as places like Israel use a seven digit license plates with no alphabet characters.
There is simply too much that I’ve learned in the last few weeks of dabbling to fit into one post. While there have been plenty of detractors, I really do appreciate the support and knowledge that has been sent my way.
There are a lot of challenges you will face in trying to build your own ALPR solution, but thankfully a lot of them are solved problems.
To put things in perspective, I’m a designer and front end developer. I’ve spent about ten hours now on footage and code, another eight on video production, and at least another ten on write-ups alone. I’ve achieved what I have by standing on the shoulders of giants. I’m installing libraries built by intelligent people and have leveraged advice from people who sell these cameras for a living.
The $86 million question still remains — if you can build a half-arsed solution that does an okay job by standing on the shoulders of giants, how much more money should you pour in to do a really really good job?
My solution is not even in the same solar system as the 99.999% accurate scanner that some internet commenters seem to expect. But then again, BlueNet only has to meet a 95% accuracy target.
So if $1 million gets you to 80% accuracy, and maybe $10 million gets you to 90% accuracy — when do you stop spending? Furthermore, considering that the technology has proven commercial applications here in Oceania, how much more taxpayer money should be poured into a proprietary, close-sourced solution when local startups could benefit? Australia is supposed to be an “innovation nation” after all.
Remember the $86 million license plate scanner I replicated? was originally published in A Cloud Guru on Medium, where people are continuing the conversation by highlighting and responding to this story.
The Victoria Police are the primary law enforcement agency of Victoria, Australia. With over 16,000 vehicles stolen in Victoria this past year — at a cost of about $170 million — the police department is experimenting with a variety of technology-driven solutions to crackdown on car theft. They call this system BlueNet.
To help prevent fraudulent sales of stolen vehicles, there is already a VicRoads web-based service for checking the status of vehicle registrations. The department has also invested in a stationary license plate scanner — a fixed tripod camera which scans passing traffic to automatically identify stolen vehicles.
Don’t ask me why, but one afternoon I had the desire to prototype a vehicle-mounted license plate scanner that would automatically notify you if a vehicle had been stolen or was unregistered. Understanding that these individual components existed, I wondered how difficult it would be to wire them together.
But it was after a bit of googling that I discovered the Victoria Police had recently undergone a trial of a similar device, and the estimated cost of roll out was somewhere in the vicinity of $86,000,000. One astute commenter pointed out that the $86M cost to fit out 220 vehicles comes in at a rather thirsty $390,909 per vehicle.
Surely we can do a bit better than that.
Before getting started, I outlined a few key requirements for product design.
Streaming live video to a central processing warehouse seemed the least efficient approach to solving this problem. Besides the whopping bill for data traffic, you’re also introducing network latency into a process which may already be quite slow.
Although a centralized machine learning algorithm is only going to get more accurate over time, I wanted to learn if an local on-device implementation would be “good enough”.
Since I don’t have a Raspberry Pi camera or USB webcam, so I’ll be using dashcam footage — it’s readily available and an ideal source of sample data. As an added bonus, dashcam video represents the overall quality of footage you’d expect from vehicle mounted cameras.
Relying upon a proprietary software means you’ll get stung every time you request a change or enhancement — and the stinging will continue for every request made thereafter. Using open source technology is a no-brainer.
At a high level, my solution takes an image from a dashcam video, pumps it through an open source license plate recognition system installed locally on the device, queries the registration check service, and then returns the results for display.
The data returned to the device installed in the law enforcement vehicle includes the vehicle’s make and model (which it only uses to verify whether the plates have been stolen), the registration status, and any notifications of the vehicle being reported stolen.
If that sounds rather simple, it’s because it really is. For example, the image processing can all be handled by the openalpr library.
This is really all that’s involved to recognize the characters on a license plate:
A Minor Caveat
Public access to the VicRoads APIs is not available, so license plate checks occur via web scraping for this prototype. While generally frowned upon — this is a proof of concept and I’m not slamming anyone’s servers.
Here’s what the dirtiness of my proof-of-concept scraping looks like:
I must say I was pleasantly surprised.
I expected the open source license plate recognition to be pretty rubbish. Additionally, the image recognition algorithms are probably not optimised for Australian license plates.
The solution was able to recognise license plates in a wide field of view.
Although, the solution would occasionally have issues with particular letters.
But … the solution would eventually get them correct.
As you can see in the above two images, processing the image a couple of frames later jumped from a confidence rating of 87% to a hair over 91%.
I’m confident, pardon the pun, that the accuracy could be improved by increasing the sample rate, and then sorting by the highest confidence rating. Alternatively a threshold could be set that only accepts a confidence of greater than 90% before going on to validate the registration number.
Those are very straight forward code-first fixes, and don’t preclude the training of the license plate recognition software with a local data set.
To be fair, I have absolutely no clue what the $86M figure includes — nor can I speak to the accuracy of my open source tool with no localized training vs. the pilot BlueNet system.
I would expect part of that budget includes the replacement of several legacy databases and software applications to support the high frequency, low latency querying of license plates several times per second, per vehicle.
On the other hand, the cost of ~$391k per vehicle seems pretty rich — especially if the BlueNet isn’t particularly accurate and there are no large scale IT projects to decommission or upgrade dependent systems.
While it’s easy to get caught up in the Orwellian nature of an “always on” network of license plate snitchers, there are many positive applications of this technology. Imagine a passive system scanning fellow motorists for an abductors car that automatically alerts authorities and family members to their current location and direction.
Teslas vehicles are already brimming with cameras and sensors with the ability to receive OTA updates — imagine turning these into a fleet of virtual good samaritans. Ubers and Lyft drivers could also be outfitted with these devices to dramatically increase the coverage area.
Using open source technology and existing components, it seems possible to offer a solution that provides a much higher rate of return — for an investment much less than $86M.
Part 2 — I’ve published an update, in which I test with my own footage and catch an unregistered vehicle, over here:
Remember the $86 million license plate scanner I replicated? I caught someone with it.
How I replicated an $86 million project in 57 lines of code was originally published in A Cloud Guru on Medium, where people are continuing the conversation by highlighting and responding to this story.
Werner Vogels launched the 2017 AWS Summits in Sydney with his typical non-conformist approach that transcends both keynotes and strategy. The Amazon CTO took center stage wearing a custom T-shirt emblazoned with “Werner Against the Machine” — the chest insignia of a modern superhero.
As the ultimate committed change agent disguised as a CTO, Werner is using his AWS superpowers to save businesses worldwide — using speed, analytics, flexibility, the skill to adapt, and the power to take flight from ‘hostile’ database vendors.
TL;DR — speed matters
For most other enterprises, supersonic speed is the most elusive superpower for a heroic cloud journey — and the most necessary to harness.
During my 20-year career at Capital One, speed at scale was the modus operandi of the lean enterprise. Accelerated by an agile mindset and DevOps culture, the rapid rate of adoption enabled a cloud journey that transformed Capital One into what is now essentially a large FinTech startup.
achieving supersonic speed is the real superpower for companies like @CapitalOneDevEx #AWSSummit @Werner
Capital One’s accelerated technology transition is powered by the API-driven cloud computing services from AWS, enabled by real-time access to big data, and fueled by a commitment to the open source community. While technology plays a leading role, the hardest part of that transition and ultimate superpower is really a talent transformation.
Gaining the supersonic speed to achieve escape velocity from on-premise data centers requires bold leadership with a long-term dedication to innovation. There is no magic pill for enterprises — although going all-in with AWS is a leap in the right direction.
Cloud computing has posed a disruptive threat for years, but short-term incentive structures provide little reason for large corporations to invest in the disruptive technology. Many enterprises continue to be anchored by the weight of their own internal processes and platforms — and paralyzed by the FUD of vendors in survival mode contributing noise to their echo chambers.
“It’s not the big that eat the small … it’s the fast that eat the slow.“
— Laurence Haughton
The gravitational pull is preventing many enterprises from gaining momentum and advantage in the cloud — at least not at the speed required to avoid death by the fast and hungry. The only way out of the dilemma is to adopt a new approach — where continuous innovation is the new bottom line and speed is the name of the game.
For enterprises that are serious about cloud adoption and aspire to achieve supersonic speed, the executive leadership team must invest their time, resources and budget into the sponsorship of a Cloud Center of Excellence (CCoE).
starting your enterprise cloud adoption journey? please don't pass go and collect $200 without a cloud center of excellence #AWSSummit
The CCoE is an essential mechanism for large organizations planning to achieve the velocity required to escape the gravitational pull of their own death star — a private cloud or an on-premise data center.
TL;DR — transition matters
The Cloud Center of Excellence will continually evolve in order too keep pace with the rate of innovation associated with cloud adoption. Modern enterprises should be very purposeful with the organization design principles of their cloud program structure.
The leaders of cloud programs should observe the flow of their value within the organization, and design an adaptive structure that evolves alongside the internal needs of the enterprise. Simon Wardley infuses these concepts of flow and transition within his value chain mapping strategies — and his design principles apply as much to organizational design as they do towards product evolution.
All of this stuff - bimodal / two speed IT / dual operating - de-emphasises that important transition, the middle - https://t.co/hgpEvMurt5
Applying Simon’s design principles of Pioneers → Settlers → Town Planners (PST) toward an organization’s cloud adoption program offers an innovative approach for effectively navigating the evolving journey. Guided by astute situational awareness, organizations learn to continuously pivot through the cycle — from the exploration stage, through expansion, toward the enhancement of industrialized components and patterns.
The Pioneers Explore
Embarking on a cloud journey requires a tremendous amount of iterative experimentation with the underlying AWS utility compute services. During this stage of early adoption, the core team is focused on pioneering engineers with plenty of aptitude and attitude.
The two-pizza team leverages agile techniques to break things daily — and collect the data which will determine the patterns of future success.
The core team is stacked with battle-tested engineers with deep experience in understanding how critical functions currently operate, and know how to translate existing data center platforms into cloud services. These engineers have plenty of scars and war stories from previous tours of duty with security, network, and access control.
ProTip 1: An executive sponsor is absolutely essential during the early phases of the cloud adoption. The sponsor must be a strong advocate, provide plenty of air-cover, and actively engage with the core team for the purpose of removing impediments from the board.
The Settlers Expand
Once the pioneers solidify early successes into identified patterns, the focus turns toward scaling the prototypes into products and services that are consumable by the enterprise. By listening to a broad range of internal customers, the settlers refine the patterns and help the understanding grow.
When the cloud services start to scale across an enterprise, it’s natural to place a heavier emphasis on governance and controls. A key advantage of AWS is the ability to engineer your governance by leveraging the API-driven services to access real-time controls and compliance.
How we know what is knowable, or epistemology, is much different in the cloud versus on-premise. — adrian cockcroft
At this stage, it’s imperative to focus on scaling the early understanding of AWS to the enterprise — achieving critical mass of cloud fluency is the only way an organization can sustain a transition to the new operating model.
Social Consensus Through the Influence of Committed Minorities shows that when just 10% of randomly distributed committed agents holds an unshakable belief, the prevailing majority opinion in a population can be rapidly reversed.
Invest the time and money into a multi-dimensional cloud education program. An engaged workforce armed with compelling context and content will dramatically accelerate your organization through the ‘trough of despair’ and ensure more attraction versus attrition.
During the enablement phase, the core team should no longer be considered the most cloud savvy department in the organization. By unleashing cloud superpowers upon thousands of developers throughout the enterprise, the core team should pivot and begin harvesting new and improved patterns from other divisions.
Elevating other departments beyond your core team’s existing capabilities is a key early indicator of achieving escape velocity.
ProTip: Instead of outsourcing your cloud training to Human Resources, tightly integrate cloud education as a core function on your program team. Leverage the AWS certifications as a benchmark for cloud fluency and set a minimum goal of 10% enterprise-wide.
The Town Planners Enhance
As the cloud journey matures, it should lead toward the commoditization of services that result in more cost efficient, faster, and industrialized platforms. In highly regulated industries like financial services, the organization depends on these town planners to ensure customers and regulators can trust what’s built.
Innovation it’s not just limited to the early stages and pioneers — it’s also found in the operational stages of cloud adoption. For example, Capital One’s Terren Peterson is evolving the mindsets of their engineering teams by embracing the concepts of Site Reliability Engineering using innovative approaches to manage operations.
Their SRE teams leverages industrialized utility functions to manage compliance and controls with Cloud Custodian. The SRE’s also contribute new functions to the ever expanding platform — completing the cycle as higher order services continuously evolve.
Cloud Custodian is a function-based policy rules engine. The origin of the service demonstrates the PST design principles at work. Originally developed internally by their pioneers, it was scaled across the entire enterprise by settlers, and finally driven toward open source commoditization by the town planners.
ProTip: Involve your operational teams starting on day one of the cloud journey. Since operations is 24x7, consider a shift-and-lift for a subset of workloads. Leverage a cloud capable MSP for interim support to lighten the load during their talent transition.
Using these organizational design principles, a cloud program team can begin to continually cycle through the explore-expand-enhance stages. Over time, this approach will begin to harness Werner’s superpowers and accelerate cloud adoption at supersonic speeds.
Drew is an AWS Community Hero, Alexa Champion, and maker of dad jokes.
Follow on Twitter @drewfirment. #WePowerTech
Design your cloud center of excellence for constant evolution was originally published in A Cloud Guru on Medium, where people are continuing the conversation by highlighting and responding to this story.
“There’s gold in them thar hills and there’s millions in it.” — M. F. Stephenson
The recently published 2017 Voice Report from Adam Marchick is a solid “state of the union on voice platforms” — and you’ll really appreciate the effort and intellectual rigor that VoiceLabs put into their analysis.
Here are my two takeaways from this report:
In the new space of voice analytics, VoiceLabs is a standout startup offering services that “provide accurate, real-time data to developers about how consumers use their Amazon Alexa skills and Google Assistant Actions.”
The emerging strategy to collect real-time data was referenced in a recent article which describes how analytics startups like VoiceLabs are Scrambling for Alexa Data from Amazon — and rightfully so.
The private questions that consumers “ask” voice platforms generates an extremely valuable data set. At the very least, the consumer data derived from the voice skills provides can be used to create highly accurate profiles of consumers for marketing purposes.
For now, Amazon is keeping the majority of the voice data to themselves. And since Amazon has quickly attracted a massive ecosystem to feed the accumulation of that data set, they have a strategic advantage over competing voice platforms — one they know exactly how to exploit.
The most obvious way for Amazon to leverage the voice analytics is feeding the data into their existing consumer models for targeted pricing and and promotions. For example, if someone asks “Alexa, what are the signs of pregnancy” — the customer should also expect to see diapers as an item on their suggested wish-list the next time they go shopping on Amazon.
But the consumer line of smart-speaker devices and the developers building custom skills are just a pawn in Amazon’s longer-term strategy. Amazon is playing chess and positioning Alexa as the Queen — while everyone else is getting played, or at best, playing checkers.
With over 5M units of Amazon’s smart-speaker devices sold in the past two years, there is an army of users interacting daily with custom-developed Alexa skills. As Amazon builds toward critical mass, it’s hard to bet against their domination of the voice platform — just as Amazon’s AWS has dominated the cloud industry since 2007.
Similar to how Amazon’s cloud strategy evolved from the developer community to the enterprise, AWS will follow a similar pattern from consumer to enterprise dominance with their Alexa voice platform.
When AWS introduced their first set of cloud services, they were geared almost exclusively toward the 180,000 members of their development community. Since 2007, AWS has grown exponentially as it’s strategically cycled iteratively through a series of innovate → leverage → commoditize (ILC) cycles. Each cycle create new services — enabling AWS to move up their value chain and step closer to the needs of enterprise customers.
And with the introduction of Lambda, it’s now possible for AWS to move services even faster through the ILC cycle since underlying functions supporting new services are essentially commoditized as they’re innovated.
After years of moving up the value chain with higher level abstraction of services, AWS is now clearly focused on features that woo the enterprises instead of the developers — such as Snowmobile and Managed Services Program. Nobody should be surprised when the exact same strategy plays out with Alexa.
While Amazon harvests usage patterns and strategic insight from their voice platform, the flow through the Innovate-Leverage-Commoditize (ILC) cycle should seem very familiar to the early days of AWS.
Every time an Alexa skill is invoked, Amazon learns — each utterance sharpening the machine learning and artificial intelligence capabilities.
With feature-rich IaaS and PasS offerings now available from AWS, migrating a corporations on-premise data centers into their cloud is not a matter of ‘if “ — but “when”. Everyone knows that customer’s don’t give a shit about your data centers.
In similar fashion, AWS will leverage the voice data analytics from consumer Alexa skills to fuel their longer-term strategy — enterprise call centers.
With voice services, their target just moves down the street from the data center — to corporate call centers. The recent AWS releases of the Polly, Lex, and Rekognition services services offer compelling features that are early indicators of a viable strategy.
In the coming years, expect to hear lots of familiar Fear, Uncertainty, and Doubt (FUD) derived from cloud adoption and reapplied to the call center industry as thought leaders declare all the reason why this won’t work — probably starting with security issues. This phase will be followed by nervous sales teams casting doubt on the viability of machine learning and artificial intelligence for call centers.
Ultimately, we’ll know when the AWS strategy has succeed when incumbent vendors start proposing hybrid call-center solutions. The final sign of success is when all the engineers are arguing about the term callcenterless — and every article starts with “first and foremost, there are still call centers in a callcenterless architecture”.
Let’s just hope the companies we are patronizing have already migrated their call centers to AWS voice platforms at that point. Then we can all finally stop yelling “representative” to get actual service through voice channels — instead we can just ask Alexa.
Alexa Data Analytics are a Gold Mine was originally published in A Cloud Guru on Medium, where people are continuing the conversation by highlighting and responding to this story.
If software is eating the world, then the forward progress of companies is directly related to their ability to develop software effectively. — Joe Emison
Software is eating the world — and many businesses are being served for dinner by the fast and furious who leverage Amazon Web Services’ ever-expanding infrastructure and platform services.
The adoption of cloud is now mainstream, and AWS makes it possible for progressive companies to focus on their marketplace differentiators — while AWS does the heavy-lifting of utility compute.
Enterprise like @CapitalOneDevEx are using #AWS in meaningful ways to focus on differentiators and not the heavy lifting @ajassy #AWSSummit
With every release of new features and services, AWS is creating even more opportunities for companies to enjoy the benefits of frictionless innovation. And for what it’s worth, the opportunities to feast at the table of AWS applies as much to enterprises as it does to start-ups.
Emerging serverless architectural patterns are accelerating the insane pace of innovation, along with the ability for a business to efficiently disrupt at scale.
The endless opportunities are now only limited by your imagination — especially as serverless seamlessly integrates with maturing AWS machine learning and artificial intelligence services such as Polly, Lex, and Rekognition.
The race is on for artificial intelligence. Here's who is winning." - @Terren_in_VA https://t.co/ax9Ern6rJI
As Joe Emison highlights in his series on modern programming practices, a company’s forward progress is directly related to their ability to effectively develop software — and take advantage of infrastructure and platform services from cloud providers like Amazon Web Services.
In the blog, Joe references the famous Wall Street Journal essay published in 2011 by Marc Andreessen — Why Software Is Eating the World — that outlines the shift toward an economy dominated by software-based companies.
Most notable in Marc’s essay is the now cliché statement that “every company needs to become a software company” — regardless of your industry. He correctly predicted that companies who fail to embrace the transition should prepare to be disrupted by the next Uber.
While most organizations are focusing on the bright and shiny aspects of the technology disruption outlined in the essay, very few heard Andreessen’s most important call to action for overcoming the challenges of the technology transition—education.
Overcoming the lack of skills is the most critical — and often overlooked — prerequisite for a company to participate in the software revolution.
Many people in the U.S. and around the world lack the education and skills required to participate in the great new companies coming out of the software revolution. […] This problem is even worse than it looks because many workers in existing industries will be stranded on the wrong side of software-based disruption and may never be able to work in their fields again. There’s no way through this problem other than education, and we have a long way to go.
There’s a simple path to determining the success of a company trying to compete in today’s software-driven marketplace: assess how much they are investing in a meaningful talent transformation program that focuses on modern software development skills and cloud fluency.
With over 25% of corporations identifying the lack of cloud expertise as the #1 challenge with cloud adoption, there’s no other way through this problem other than education.
And we have a long way to go.
A company’s success will be measured by their investment in talent transformation was originally published in A Cloud Guru on Medium, where people are continuing the conversation by highlighting and responding to this story.
