Less is More
There’s nothing more deflating than the faux rally-cry of a desperate manager: “we need to do more with less.” We all know what that means.
However, the moment of doing more with less has finally arrived: less IT, less assets, less office space, less employees. And not because budgets are tight, but because digital transformation just hit a tipping point.
Designers and visionaries rely upon a similar maxim - Less is More - although with an entirely different and more elevated meaning. The ability to remove excess baggage, distractions and fat is what allows true art, or product value, to shine.
Most organizations do the opposite. They follow a more-is-more mindset: more resources, more people, more ideas, and so on, despite desperate ambitions to achieve product elegance.
Here at Interpret, where my co-founder Rick Lewis is a long-time devotee of the Less is More design school, we argue that organizations need to think anew about resources. They need to take the path to a new operating model that we call continual digital transformation.
In this series of articles, we consider what an IT-less, office-less, employee-less and even asset-less business looks like. In later articles we will explore the operating model for such a business, which is radically different to today’s models.
Here, in part one, we explore the role that a server-less future has to play in enabling continual digital transformation.
One of the most intriguing twitter tags right now is #ServerLess. It is tracking what might turn out to be the biggest revolution in IT and what many of us had already predicted was the inevitable future of computing.
At Interpret, we recently encountered a remarkable story about Rolls Royce Aerospace, an engineering and innovation powerhouse about to be outfoxed by an unlikely competitor.
In true think-again fashion, an interlocutor told us how Rolls Royce were not afraid of GE or Pratt & Whitney, but Amazon!
In case that makes no sense whatsoever, read on.
You see, Amazon are one of the inventors of the serverless future. And the future is not only server-less, but IT-less. If you’re paying a dime on IT, you’re already paying a dime too much.
What has this got to do with jet engines? To answer that, we’ll need to dig a little deeper into what serverless means.
Functions on Demand
We are currently riding the 8th wave of innovation here in Silicon Valley.
No. It is not the mobile-apps wave, keeping in mind that I wrote the industry bible “Next Generation Wireless Applications” way back in 2006.
The current wave is the tsunami of all Silicon Valley waves and is driven by a new method of software that shifts the game from deploying IT resources, like servers, to deploying algorithms.
You can call it machine learning, artificial intelligence or even the Internet of Things, but the core currency of innovation at the heart of this wave is algorithms.
So what has this got to do with doing more with less?
Well, we’ve all heard of servers, those bulky computers that have been the basic unit of IT infrastructure for decades. However, computer programs do not understand servers. These are merely a necessary evil to contain and run what the programs are trying to do: useful business functions.
The basic unit of a program is a function, like: “With inputs A and B, give me A times B.”
This is a trivial example. A more interesting function might be: “For this customer, predict the optimal profit margin.”
Let’s say that this function exists somewhere in the cloud and only gets called every time a customer visits your website, store, airline ticketing site, or whatever. And let’s say that I only pay for when the function is run, whether it’s called once a day, an hour, a minute, or thousands of times per second.
Actually, I don’t care about any of that stuff because the cloud will scale and manage the running of the function for me, without any concept (internal to the program) of servers, or even CPUs. I only pay each time my function is run.
Welcome to the world of “Function as a Service” or server-less computing, as currently led by Amazon Web Services and their revolutionary Lambda service.
Ignore the strange name. It’s a tip of the hat to a mathematical idea (Lambda Calculus) wherein the core concern is stringing functions together like a sausage factory.
Value as a Service
But there’s an even more exciting twist to this story.
Functions, by themselves, aren’t all that useful. Most of the functions that software engineers write don’t really do anything that interesting or directly relevant to the core concern of the program, which let’s assume for this example is predicting precisely when a jet engine should be serviced in order to maximize safety and minimize disruption.
Most software is concerned with the vast overheads of getting the data to the right place at the right time, and with all the right storage, transport, governance and security, so that the core value function(s) can be performed.
Think of a chef who goes to the market to research and buy ingredients, and then spends time preparing them, sharpening knives and oiling pans until there is a flourish of creativity at the key moment of bringing all this effort together in a nuanced dish.
Most software is “oiling the pans” kind of functions.
If I run an airline, I don’t care about such utility functions as: “With this data, store it.”
What I really care about is a value function like: “For this jet engine, predict the best time to service it.”
Imagine if Southwest Airlines could access such a value function and only pay for its execution. This is what they really want, similar to the maxim that customers don’t really want a drill, they want a hole in the wall.
And now imagine that a company like Amazon offers such a function to Southwest Airlines because Amazon’s cloud infrastructure is architected in a way not to run servers, nor even functions, but algorithms as the basic unit of computation, pushing all the “oiling pans” services down into the basic underlying apparatus of IT in such a way that it only serves the execution of value functions rather than occupies the bulk of IT attention and investment.
In such a world, Southwest Airlines no longer pays for IT.
They pay for algorithms.
They become an IT-less organization. Their technological innovation is no longer built upon IT networks. The core task of innovation is how to architect a network of optimized algorithms.
Perhaps it is becoming clearer how a company like Amazon might threaten a jet engine company. You see, Rolls Royce doesn’t really sell jet engines. They haven’t done so for some time. They sell “Engines as a Service” where much of value proposition is delivered by software despite Rolls Royce’s unparalleled ability to engineer physical objects, namely engines.
But, consider the likely scenario wherein the cost of those software smarts is mostly tied up in “oiling the pan” utilities that don’t deliver any real data-transforming value directly.
(By the way, in case you haven’t figured it out, Rolls Royce probably hires an army of software engineers to build and maintain those functions. We'll get the people problem in part 2 of this post.)
If Amazon were able to offer Southwest Airlines a “predict engine performance as a function” service, then why buy anything from Rolls Royce other than the engine itself. In which case, why buy from Rolls Royce at all and not Made-in-China Aerospace?
Of course, this is grossly simplified, but you get the point.
And whilst you mull it over and prepare to dismiss this anecdote as a whimsical futurist’s tail, consider that most of the dramatic shift to “functional computing” has taken place in the space of the last 12 months. This thing is moving faster than jet propulsion!
Algorithms as a Service
If, like me, you are a well-trained skeptic, then you might have some questions.
For example, perhaps you feel that my dismissal of “oiling pans” was mostly a conjuring trick. After all, it’s still necessary, right? Surely we haven’t reinvented the fundamentals of systems.
And what’s all this talk of “predict engine performance” functions? Can such an atomic function really exist? Or do we actually end up with a mountainous pile of functions knitted together like a bowl of spaghetti?
As our focus here is on continual digital transformation, we need not get stuck on the details of a particular example. My goal here is to consider the serverless future axiomatically in order to understand how this will play out for those paying attention: namely, your unseen competitors.
In practice, Southwest Airlines will not deploy Lambda functions running on Amazon Web Services. The power of serverless is really in the hands of the creative thinkers, like algorithmists, data scientists and computer geeks who are now able to innovative at remarkable speeds by focusing on value functions and, as it were, thinking in code.
To see this in action, just take a trip over to Algorithmia where you won’t find servers or even functions. You will find algorithms. As the website boldly claims: “Add facial recognition to your app with only 5 lines of code.”
Maybe this doesn’t make much sense to you in terms of its scale, so let me give you a real example from my own history of software innovation.
Back in 2009, I launched Thumb Jot, the first note-taking application for iPhone and the first to get an Apple Staff pick in the app directory (there was no app store back then). At the time, it was recommended by CBS as one of the best apps for iPhone, second only to Facebook.
It did all the stuff you might expect a note-taking app to do.
But my real goal was far more ambitious than organizing notes. I was trying to build a machine that could read my notes and, via a web-extended “brain”, identify themes and meanings in order to “talk” to me like a kind of personal creativity guru. Otherwise, digital note-taking apps are really just faster versions of pen and paper.
However, I found that the effort required just to do natural language processing, never mind more complex tasks like topic extraction (and beyond) was way out of reach for my bootstrapped start-up, or even a well funded one (if Evernote was/is anything to go by).
Roll on 7 years and I recently spent a Sunday afternoon building a machine that could, to some reasonable degree, figure out what my notes were about. I did this without any IT. I sent raw note data to IBM Watson, via their function-calling interface (called an API) and it returned meanings.
Connecting this to a bot that could talk to me is easy, given the vast numbers of bot-building services that I could deploy as yet another function.
From Clue-Less to IT-Less
What happened in those 7 years between my first attempt at building a smart note-taking app and my recent Sunday stroll through IBM’s Watson functions?
Two key trends emerged, one of which is obvious and the other of which is not so widely grasped by traditional organizations still struggling with even rudimentary digital transformation (like “going social”).
The first trend is the dramatic shift to cloud computing in all of its forms, the most recent of which, like server-less, can be thought of as dramatically removing the cost, and in some cases the need, of “oiling pans.”
The second trend is a massive acceleration in the velocity of software engineers thanks to the open and accumulative nature of software innovation that gives rise to vastly reusable intellectual effort.
Once a few engineers have figured out topic extraction, say, they can bind that know-how to a software service (like IBM Watson) that the next engineer merely deploys, mostly without any requirement to understand its inner workings.
This is dramatically different to two decades ago when, as a mobile chip designer, most of my time was spent reading science papers in order to understand fundamentals that I could build directly into my chip designs. There were no reusable parts.
This intellectual snowball effect is also aided by a dramatic shift in education and training whereby it is possible for anyone with an internet connection to educate themselves in a range of technical topics, including via nano degrees.
The sheer accessibility of software innovation at vast intellectual and deployment scale has been almost entirely missed by many traditional orgs who remain clue-less about the transformative nature of the new technological reality.
Many C-suite executives still cling to an out-dated operating model that deems “IT” as a necessary evil to be outsourced rather than a strategic necessity to be reclaimed and laser-focussed on key value processes in the organization. Indeed, entirely new value processes are imaginable that are able to enable a continual digital transformation model.
Indeed, there is no IT to be in-sourced. We are living in an IT-less era where you really can do more with less - a whole lot more!
Of course, going serverless, or IT-less, isn't like sprinkling magic dust over the organization. As with all paradigms, it requires careful thought - such as design thinking - to figure out how to embrace its potential to enable continual digital transformation.
And, as we shall see in part 2, there is a lot more to the "Less is More" future than IT-less.