So I'm on my magical patio again consuming a cold beer and thinking about retail customers and the systems that serve them.
I've been asked too many times in my career to replace legacy systems with bright shinny new retail systems. Now, I'm a bit of a nostalgic guy. My first rule of technology is "embrace the legacy". Good thing because not only has that saved millions of dollars for the companies I've worked for, it's also made them millions of dollars.
You see, I've found that the fastest path to innovation is through understanding the past; the solutions to even the hardest problems are always obvious with hindsight. Irony at its best. You don't need to see into the future, you need to see into the past.
Freedom to Innovate
With that in mind, you can free yourself from the excuses of not innovating. You won't need millions of dollars in new systems, a hoard of new employees or a 18 month roadmap to change the way you do business in the new multichannel web. Want to reach mobile phones, app stores, set-top boxes, hoards of partners and affiliates? All you need is a way to tap into all the goodness of your enterprise systems and capabilities. All you need is an API, or as I call it, A Profit Interface.
That's the first step - abstract yourself from the legacy systems with an API - technically an Application Programming Interface (a technology blast from the past). Abstracting from the legacy is a bit like asking a girl to drive you to the prom but not making her your official date. You want to play the field and in this age of retailing that means smartphones, tablets, e-book readers, kiosks, game platforms, connected cars and internet everywhere. APIs let you get there.
Getting Everywhere, Fast
Imagine having a single connector, to say your legacy product catalog, that all those new screens could access quickly. And when the next sensational device arrives, you just snap it in - no coding necessary. How many more sales could you make if your customers had access to your products and services from anywhere? What if another retailer could access your product catalog and offer your complementary items to their customers? That's money, baby!
I know because the innovations I've seen and guided at companies opening APIs have made millions of dollars. I even got a couple of logo coffee cups for my efforts. One more beer, slides into my logo beer cozy. I forgot i got a cozy too.
I really wish I could pay for all this beer with my phone. I always forget my wallet in the car. Hmmmmm..... how to do that without millions of dollars in hardware upgrades? Maybe someone needs to contact the beer distributors about embracing their legacy systems...
Two weeks ago the Wall Street Journal ran the story ‘Sam's Club to Use Wi-Fi to Push TVs,’ highlighting internet-connected TVs which run popular social media or video applications. Last week WSJ highlighted how cable companies are getting their content on the iPad in response to excellent execution by Netflix and Hulu. This week, WSJ reports how businesses like law firm Sonnenschein Nath & Rosenthal, Bausch & Lomb, and Mercedes-Benz Financial are adopting the iPad as a business tool. APIs are all over the business press as early leaders emerge and competitive pressure to succeed in the multi-device web heats up.
Chris Anderson sees the trend. From his excellent feature article in this month’s Wired:
Over the past few years, one of the most important shifts in the digital world has been the move from the wide-open Web to semi-closed platforms that use the Internet for transport but not the browser for display. It’s driven primarily by the rise of the iPhone model of mobile computing, and it’s a world Google can’t crawl, one where HTML doesn’t rule. And it’s the world that consumers are increasingly choosing….
We’ve seen a shift like this before. In the late 90s, consumers adopted the web to search, shop, and socialize. Companies who recognized the shift capitalized (think Google, Amazon, or eBay), and those who couldn't innovate fast enough suffered.
How can consumers reach your service or interact with you on their device (phone/set top/tablet/car/other) of choice? Can your service or data be included or embedded in applications consumers love? What would be the impact if your main competitor’s service was available everywhere and embedded in popular applications and devices?
An open API strategy allows you to engage and capitalize in the multi-device world - and just like we saw in the 90s with websites, companies need to adapt to succeed.
APIs are like a garden hose. They can make things grow.
Well that's what I was thinking as I tried to save my roses from the blistering summer heat here in Dallas, Texas. It really started to make sense when I snapped off my trigger nozzle in favor of a sprinkler. I have the quick connect system so it's a piece of cake to swap out attachments. The 104 degree heat was getting to me, and I started to imagine the hose being connected to retail information and inventory - the API being the quick connect and the nozzles being the interface to consumers.
I'm sitting on the patio at this point, the sprinklers doing the work now, and I'm thinking I should grab a beer and really see where this analogy goes. I watch the sprinkler go back and forth, spraying a pattern of precious water across the lawn - and on my FENCE!
No, the source of life cannot be wasted on a board-on-board fence. I get up and carefully plan my assault on the sprinkler, careful not to get wet (note to self: cold water pelting your body when its 104 is not something you should avoid). The sprinkler has all kinds of adjustment mechanisms. I can adjust the spray pattern left or right, long or short. I can control the amount of water going through the valve and of course there's a timer.
Ahhhhh, this like API infrastructure, the control panel for APIs. Crystal clear. Just like the mechanisms of the garden hose nozzle let your control and target different areas of your lawn, API infrastructure lets you optimize your API for various sections of the market - from mobile developers to affiliate marketers. And just like a great sprinkler system, an API infrastructure lets you scale up to cover your whole "lawn." Finally, API infrastructure provides visibility, letting you see where your services are going and how they are being used.
At its core, an API infrastructure lets you harness and control the power of an API and grow your market, just like a garden hose lets you harness the power of water to grow your lawn.
So you know what I did? The next time I went to talk to a prospect I carried a garden hose, quick connect and sprinkler with me (at least they will remember me).
Analogy complete. No!
One more beer (my answer to Job's "One more thing").
API.... A Profit Interface. Another entry on that soon.
The world of APIs hit me in the fall of 2009.
At the time I was working for a large retailer in the entertainment business and putting together a mobile strategy to leverage our existing assets and systems. Ultimately, I was trying to make it easier for our customers to transact. Too many times customers would enter the retail locations and ask for a product only to be told it was rented out or out of stock. I knew for a fact that the product was somewhere in our supply chain, I only needed a way to get it to the customer.
Initially I thought that the ability to look up realtime inventory at the POS would be a good first step. At least we could locate the product in another store and then hold it for the customer. Better yet, we could make the inventory levels available on our website and iPhone app. Itʼs called "trip assurance" in the retail business; a very nice customer convenience. All this information is good, but how does the customer pull the trigger and transact, and actually get what they want?
The answer was right there in front of us. Transact in one channel and fulfill from another channel. The old endless aisle strategy. Use your e-commerce inventory to fulfill demand in the brick and mortar stores. The opportunities were endless - we also had kiosks and digital delivery.
The tenets of our cross-channel strategy were forged:
- Inventory
- Visibility
- Flexible Fulfillment and Payment
- Order Management
- Account Management
- Consistent Pricing and Promotion
- Item Management
We decided to leverage our e-commerce channel as the platform for the future. We built everything to be reusable. We built the foundation using an API.
Originally I was barely able to search my memory for the meaning of the acronym. An Application Programming Interface. An interface that can tap legacy and modern systems alike, an interface that offered a clean read/write function that could be reused from any and all screens.
We set out to build our API as a means to an end for our mobile strategy. But when we started to blur our vision, we saw something new: inventory, orders, payments, items, price, promotion, fulfillment. It was a point of sale. We discovered we could build our next generation POS by leveraging our new retail API strategy.
Mike Debnar is VP of Business Consulting at Sonoa. He comes to Sonoa from Blockbuster where he led the retail systems organization as Vice President, working closely with operations, merchandising and marketing to implement the company's multi-channel retail strategy.
OAuth 1.0 (the current spec version is 1.0a, which fixes a security problem with 1.0) solves an important problem in the world of APIs -- how one web application can give another application API access without requiring that the user give out their password. OAuth 1.0 solves this problem in a clever way through a secure handshake, via API calls, between the two applications. This has allowed APIs to go in places where they could never go before.
OAuth 1.0 works by ensuring that the API client and server share a token, which is like a username, and a token secret, which is like a password. The client must generate a "signature" on every API call by encrypting a bunch of unique information using the token secret. The server must generate the same signature, and only grant access if both signatures match.
The advantage of this approach is that there is no way to find out the token secret, because it is always encrypted when it's sent over the network, and only the client and server have the keys. It doesn't matter if the data is eavesdropped on a WiFi network in Starbucks or captured by a proxy like Apigee -- there's no way to see the secret, so there's no way to impersonate the client based on what's sent over the network. All of this is done without requiring SSL, since SSL can slow down the client and server alike, and make deployment of the API server more complex.
However, both client and server developers found the complexity of generating and validating signatures to be too much. There are many tricky things that a developer must get right, down to exactly what type of "URL Encoding" is used (it's not exactly the same as it's used in other places). If the client or server makes a single tiny mistake in the signature, it's invalid and it's hard to figure out what went wrong.
OAuth 2.0 promises to simplify this stuff in a number of ways:
1. SSL is required for all the communications required to generate the token. This is a huge decrease in complexity because those complex signatures are no longer required.
2. Signatures are not required for the actual API calls once the token has been generated -- SSL is also strongly recommended here.
3. Once the token was generated, OAuth 1.0 required that the client send two security tokens on every API call, and use both to generate the signature. OAuth 2.0 has only one security token, and no signature is required.
4. It is clearly specified which parts of the protocol are implemented by the "resource owner," which is the actual server that implements the API, and which parts may be implemented by a separate "authorization server." That will make it easier for products like Apigee to offer OAuth 2.0 support to existing APIs.
For these reasons, OAuth 2.0 has already been adopted by companies like Facebook, which uses the draft spec in its Graph API. Of course, it's a new spec, which means there are new requirements and use cases that make it more complex. For instance, OAuth 2.0 also clearly lays out how to use OAuth entirely inside a browser using JavaScript that has no way to securely store a token, and it explains at a high level how to use it on a mobile phone or even on a device that has no web browser at all.
Finally, although the developers of the world will not miss generating OAuth 1.0 signatures, they served a purpose, because they allowed a client to send its token and secret securely to a server without requiring SSL. For APIs and devices that do not want to support SSL for performance or complexity reasons, signatures are still a good choice. Right now, signatures have been removed from the OAuth 2.0 spec, but they'll be added to a separate extension spec at some point.
So should you use OAuth 2.0 today? Here are a few things to consider:
- Spec changes. OAuth 2.0 has not reached a stable IETF draft yet. If you implement it today, are you prepared to change your implementation every few weeks until the committee has agreed on a stable version? OAuth 1.0a, on the other hand, is already a well-defined standard that's not going to change any time soon.
- Implementations. There are a number of code libraries for both client and server that support 1.0a today. There aren't as many for 2.0, so you're going to have to build more stuff on your own.
- Complexity. There's no doubt that 2.0 is easier to implement both on the client and server side.
- Performance. If you are unwilling or unable to use SSL for all of your API traffic, then OAuth 2.0 is not a good choice until some sort of signature extension is added to the spec. OAuth 1.0a already supports signatures, which are complex but allow you to securely exchange tokens without requiring the use of SSL.
You can also check out my blog on "When to Use OAuth" for more, and we'll continue to explore this issue as it evolves.
