May 29th, 2014

Toward a Lean API Strategy

Books on Lean Business Strategy“Lean”, “API” and “IoT” are probably the most hyped terms in our industry right now. Normally, I tend to blog about the latter two but – for a change – I would like to balance that out by talking about the former: the concept of Lean and how it relates APIs.

You have probably heard about or even read The Lean Startup by Eric Ries. And you may have noticed that this book sparked a whole cottage industry of Lean publications, like Lean Analytics, Lean UX and the widely-misunderstood concept of “minimal viable product”.

But few of you may have ventured back to explore the texts that laid the foundation for the Lean startup. The Four Steps to the Epiphany by Steve Blank, for example. Blank outlines a business process called “customer development”, which helps startups find “problem solution” and “product market” fit. Even fewer will have ventured right back to the very origins of the Lean concept: the Toyota Lean Production System with its emphasis on pull over push and ever-decreasing batch size towards one-piece-flow manufacturing. And we have not even touched upon the “theory of disruptive innovation” that Clayton Christensen outlines in The Innovator’s Dilemma or Rita McGrath’s concept of “discovery-driven planning” outlined in Discovery Driven Growth.

But the purpose of this post is not to provide a comprehensive reading list for those of you hoping to learn more about Lean and discovery-driven business strategies. My real goal is to explore if and how these concepts can be applied to API design best practices. However, if you are curious and want to know more about the books mentioned, I suggest you head over to a blog post I wrote for launchd.io. And for your next long-haul flight, you might want to consider starting with The Goal, which will provide you with some truly novel-like business reading.

Before I explore how Lean and API design come together, let me first make a confession – I got an MBA a couple of years back. I know that this is not going to win me any brownie points and I still prefer code to spreadsheets – no contest! But it goes some way to explaining why I think business and API are joined at the hip. The business value of an API does not come from the interface’s intrinsic technical features but from its ability to provide access to a business asset or service. APIs provide a technical means to do (more) business.

From this follows the assumption that API design and implementation need to focus on the intended business outcome. Which means that you must have a clear view of your business goals before you can start to implement your strategy. Unfortunately – in my experience – most of us on the technical side are not equipped to talk to the business side of the house (and they are seldom well prepared to talk with us). This is why I went back and got an MBA – so that I could learn to speak with “them” and build better products.

Starting with Toyota’s lean product development process, I began to see approaches and tools that could help bridge the semantic gap between the technical and business sides. I plan to share some of these with you in subsequent posts. I will start by discussing Alexander Osterwalder’s Business Model Canvas. To get a little background on what I’ll be talking about in my next post, I suggest that you read this post on ProgrammableWeb, where Mark Boyd uses the Business Model Canvas to analyze Walgreens’ QuickPrints API. Also, you might want to take a look at my Lean API Strategy presentation from the recent APIdays in Berlin.

May 27th, 2014

Hybrid App Growth in the Enterprise: Lessons Learned at Gartner AADI

Gartner AADI 2014Last week, I was lucky enough to attend the latest Gartner Application Architecture, Development & Integration Summit in London. One of the key themes that emerged from this show was the need to create agile architectures for mobile apps that leverage enterprises’ backed systems. Architectural agility has long been a central concern for enterprise IT but it has taken on a new urgency with the mobile revolution. As all sorts of enterprises scramble to launch effective mobile app strategies, the issue of how to build agile architectures for the mobile domain is ever more pressing.

One of the key questions for architects charged with enabling enterprise app strategies is whether enterprises should be developing fully native mobile apps, building apps on Web standards like HTML5 or taking a hybrid approach. Based on the sessions I attended and my conversations with architects who are attempting to answer this question in the field, it is clear that each approach has its own advantages and pitfalls. The Web-centric approach enables enterprises to be quick-to-market – a significance advantage in the current climate. But HTML5 simply cannot deliver the kind of rich and seamless functionality offered by native apps.

Logically then, the hybrid approach would seem like the way to go. But even this has its disadvantages. For example, platform vendors like Apple and Google might impose more restrictive terms and conditions on hybrids. Furthermore, hybrid apps retain many of the disadvantages of a Web-centric approach. Hybrids can never deliver the full native experience users prefer and they create significant testing and security challenges. And it’s quite possible that, at some point in the future, mobile development tools could improve to the point where hybrids are no quicker or cheaper to deploy than native apps.

Nevertheless, hybrid apps have significant advantages. First and foremost, the hybrid approach turns the whole “Web-versus-native” binary into a continuum, allowing sophisticated trade-offs to be made between cost/time-to-market and functionality. Furthermore: tools to create hybrid apps are well understood and widely available; unlike pure HTML5 apps, hybrids allow a presence in the app store for marketing purposes; hybrids allow some content and features to be updated without resubmitting the app to the store.

In light of all this, it seems clear to me that the hybrid approach will have a role to play in the ongoing development of enterprise mobility. Indeed, if I remember correctly, one study I heard mentioned said that, by 2016, over half of all mobile apps deployed will be hybrids – whereas less than a quarter were just a year ago. Still, hybrid apps won’t work for every use case and my advice to architects would be to make sure your architectural approach matches the needs and resources of your organization. And whatever approach you take, make sure that it is built on a technology platform that will allow the apps to run smoothly at scale, without impacting the security or performance of backend systems.

May 23rd, 2014

Mapping the API Landscape

Mapping the API LandscapeThis week, I had the opportunity to deliver a “lightning talk” at the APIStrat Tech Un-Workshop at Gluecon 2014. The event was focused on two key topics: IoT and service description/discovery. I was in the service track and delivered a talk called Mapping the API Landscape. I won’t cover the entire talk here (BTW, the text has lots of links to information I could not discuss on stage this week) but did want to hit some key points.

What Google’s Self-Driving Car Tells Us
The Google car has been in the news again and a key point that was discussed at some length in these articles was the fact that the car depends on a very detailed map of the roadways. Right now, the car can only drive in the Mountain View, CA area since that is the only landscape mapped well enough for the car to navigate.

So, the Google car does not “discover” anything while driving. It actually recognizes intersections, traffic lights, etc. through a special representation of the landscape that contains all the right annotations. This reliance on a known map allows the car to navigate successfully between two points within that landscape – which is no simple feat, of course. Reacting to surroundings “at speed” takes serious computing power and that’s one of the reasons the Google implementation is so amazing.

Norman’s Action Lifecycle
The process of navigating from A to B is a goal-driven process that we see very often in nature. Ants, micro-organisms etc. all do this. Human-computer interaction expert Donald Norman calls this process the “action lifecycle” or “seven stages of action”.

This is how we learned to write GUI interfaces, too. Wait for a keystroke or button-click, process that action, affect the UI, then allow the user to evaluate the changes and decide if another action is needed. We also build Web servers this way. Wait for a request, process it, modify the backend (if needed) and reflect results back to the requestor. Game programming works like this, as well. But it’s rare to see the Web and mobile client applications that leverage enterprise APIs written in this way. They continue to look like single-minded bots that just go from A to B and ignore landmarks, incapable of actually reacting to surroundings.

Client Apps & Web Maps
Why are most client apps one-off implementations that are likely to break over time? It’s because client developers don’t have decent “maps” of the online landscape. And good maps are not just “photos” of the surroundings but heavily-annotated representations with recognizable symbols and landmarks. Most servers today just belch out JSON or XML with almost no recognizable symbols or signage (e.g. hypermedia controls).

So, what we need to do is create maps for devs to use so that they can build their own client applications against our APIs and solve their own problems. Client apps should be free to follow whatever route they wish within the maps – they shouldn’t be limited to following the path that server developers decide upon.

Let’s Make Maps!
Things like service description formats and discovery protocols are all ways to start creating more maps for client devs to rely upon. Using hypermedia in responses provides the symbols and signs client apps can use at runtime (like the Google car) in order to navigate in real time.

There are several description formats (see my paper Hold Your Nose vs. Follow Your Nose for more on this). In the book RESTful Web APIs, Leonard Richardson and I list close to 20 options for expressing hypermedia in Web responses. And more have come online since the book was published last year.

We have all the tools we need. We just need to use those tools to make more maps!

May 21st, 2014

The Increasing Impact of APIs on the Digital Marketplace

Written by
 

The Increasing Impact of APIs on the Digital MarketplaceFor years, organizations connected distributed applications using increasingly complex protocols. But as the principles of the World Wide Web rapidly penetrated the business world, IT organizations began to realize that many of the concepts, infrastructures and protocols that enable the infinite scalability of the Web could be applied to enterprise application development. Enter the application programming interface (API).

Business needs are driving enterprises to open their data and applications more to partners, developers, mobile apps and cloud services. APIs provide a standardized way to open up information assets across the Web, mobile devices and the cloud. However, to make API information sharing safe, reliable and cost-effective, enterprises must deal with critical security, performance management and data adaptation challenges.

The API can be used as a lingua franca of modern computing, allowing the enterprise to selectively open up applications in order to create value. It is not a coincidence that the API movement has grown in importance as a new generation of coders has come of age – a generation that values simplicity and getting the job done.

The complexities valued by the previous generation of developers are giving way to developers more focused on lowering the barriers to entry and on improving the accessibility of information while ensuring the security of critical enterprise resources. APIs allow developers to greatly simplify integration.

APIs open up new opportunities for executives to evaluate business information resources in order to build value for the enterprise by creating services that others can consume. For example, the New York City Subway System opened up APIs so that developers could build apps exposing train status information. The Metro Transit Authority (MTA) recognized that its core business was transportation, not app development, so it didn’t try to build smartphone apps but instead exposed its core information systems through APIs that allow developers to create apps which provide consumers with updated transit information.

The MTA is leveraging information in existing systems in order to allow developers to build apps that create more informed consumers, who are presumably becoming more reliant on public transportation. This strategy is allowing the New York MTA to provide better transportation through APIs and cities like Washington DC are similarly opening up their APIs to make transportation easier for their citizens. By understanding consumer needs for better and timelier transportation information and filling those needs by opening up APIs to the development community, transportation providers are building more loyal customers.

Understanding the opportunities to capitalize on APIs is crucial and many companies are turning to their marketing departments for direction on API strategies. To their credit, marketing professionals are often forward-looking and trend-driven and many have been monitoring API advances and seeing the business opportunities potentially enabled by API adoption. They are well positioned to evaluate available data within business applications in order to determine what information the organization should make available in a safe and secure manner to create value for the enterprise.

Once the APIs are developed, the ability to promote available APIs among the development community is essential for gaining acceptance and adoption. Organizations need the ability to market their APIs to create interest within the development community. To obtain maximum value from APIs, enterprises need ways to attract, onboard and manage developers.

The CA Layer 7 API Management Suite provides enterprises with a comprehensive set of solutions that externalize APIs in a secure, reliable and manageable way. It includes the CA Layer 7 API Portal, which allows the enterprise to deploy the infrastructure to monetize APIs, advertise them and create communities around them. This allows organizations to capitalize on the increasing impact APIs are having on the digital marketplace and to build and manage secure APIs that create increased value for the enterprise.

May 9th, 2014

Trade Shows, Connected Cars & Secure APIs

API Events May-June 2014May and June are shaping up to be busy months here at Layer 7! We will be sponsoring and exhibiting at a number of leading industry events and our API Management experts will be speaking at several of these shows.

Notably, throughout the month of June, our speakers will be focusing on the “connected car” – a prominent Internet of Things use case. Below, I’ve provided a list of some upcoming shows that will have a Layer 7 presence. If you’re attending any of these events, take the opportunity to learn how secure APIs will be vital to enabling automotive connectivity. And be sure to stop by the Layer 7 booth to say “hi”!

For full details of our upcoming events, visit the Layer 7 Web site. And if you’d like to schedule a meeting with one of our experts at any of these shows, please reach out to us by emailing events@layer7.com.

Layer 7 events in May/June 2014: