June 19th, 2013

When Good API Design is a Waste of Time

The idea that good design is essential to building great products and services has become a truism in our industry.  Most of us intuitively understand the idea that expending effort on the design of our code, system architecture and APIs will payoff after implementation.  I’m certainly a big believer in the power of good design for the API space, but I wanted to explore a situation where a design focus might not be necessary.

Consider the case of a small business offering a cloud-based service product for a niche market.  If this business chose to invest in a well-designed, developer-centric API, at a minimum they could expect:

  • A reduced learning curve for developers consuming the interface
  • A reduction in troubleshooting time
  • Increased interest from their developer community

For most audiences, these are goals worth achieving.  Indeed, this is why we emphasize good design for APIs in the first place – the benefits fit remarkably well with the main reasons for embarking on an API strategy: reduced cost and increased adoption.

But, in my conversations with connectivity professionals from larger organizations, it is apparent that not all service vendors see the value in investing in this type of design effort.  Developers and architects are bursting with  tales of forced integration with service providers who have simply thrown an ugly or barely functioning interface on top of  core component.  It is in these scenarios that we hear about laughable attempts at implement whichever API styles and features are in fashion.  ’REST’ and ‘security’ become sales-worthy buzzwords that don’t live up to their promise when developers get their hands on the actual interface when real project work commences.

In the majority of these cases, technical teams have very little say during the procurement process of outsourced and cloud-based services.  In effect, these API providers don’t need to design for their developer audience because they aren’t critical to succeeding.  For many years a sound strategy for selling cloud-based products has been to sidestep technical teams and engage directly with the business.  It’s frustrating that technology teams are often still left with the responsibility for reducing integration costs regardless of the lack of sophistication in the APIs that they are tasked with connecting to.

Thankfully, the wealth of knowledge and connectivity products in the enterprise space allows these teams to reduce the impact of bad design on the overall project and organization.  Components such as API proxies can be used not only to build a facade for APIs that are being exposed, but also to provide abstraction for services that are being consumed.  In essence, the design burden can shift from the service provider, to the enterprise developer who wraps a poorly designed interface in a more consumable, developer-friendly API for the rest of the organization to use.

As a whole, the scenario makes sense.  Well designed products are based in part a designer’s empathy for their users.  Good design involves perceiving a product from a user’s view point along with an understanding of the impact that design decisions will have on the user base.  However, an organization that builds an API as an afterthought for developers, who are only viewed as a means to an end, will likely produce a poor API.

Ultimately, building a technology business based on developer apathy is a bad idea.  The industry shift towards API product based integration is empowering technology teams at all levels and services that continue to ignore the needs of their developers will eventually be ousted from the market.  In short, good design is only a waste of time when you don’t care about your users.  If  in fact you do care about the developers who will be using your API product, then you need to invest in designing your API with their point of view in mind.

March 8th, 2013

Nation Building in the Age of APIs

I’ve been working with a number of companies lately on their API strategies.  People seem to recognize that having an API is modern day necessity, but they’re not sure how to get started.  Since APIs are viewed as a technical innovations, responsibility for rolling them out is frequently handed to IT groups.

Clearly, there is business value to be attained by companies who utilize an API, and an accessible web API is a requirement for modern corporations.  For companies looking to launch an API, there is a temptation to focus on the technological aspects of implementation.  Good API design, architecture, and infrastructure are vital to the success of a company’s API, but there are other areas to address first.  I am currently reading the book “Why Nations Fail”, and recently read “Thinking Fast and Slow” by Daniel Kahneman.  Although the former is a geopolitical study whereas the latter focuses on the human mind, both share an identical observation that is the foundation of their arguments: a great amount of economic study is flawed because it fails to account for human behavior and tendencies.  I feel the same way about technology.

Every paradigm shift in technology has been driven by both innovation—the new technology itself—and application—how that technology can be used.  In other words, there is a machine side and a people side to every technology change.  The technologists responsible for implementing these changes often bias towards their comfort zone—the machine side—and overlook the people side.  This has led to frustration for companies who invest significantly in new technology only to miss the intended benefits of the change.  For APIs, the people side of the change is especially important.  In fact, the social nature of the API world means there are even more groups of people to consider.  Ultimately, the success of a company’s API will depend on the creation of a diverse community for that API—end users, partners, developers, and more—as well as the adoption of a business model that allows the API to contribute to the company’s bottom line.  Taking the community and the economics together, this means you will need to build a nation for your API.

Some of the biggest companies on the web have taken this approach with their APIs, and I recently explored some of their winning tactics in this VentureBeat article.  Please have a read and let me know your thoughts, and perhaps your own API lessons

April 12th, 2011

Space Exploration and the Trough of Disillusionment

Written by
Category Uncategorized
 

Hype cycles may be a largely a marketing construct, but it’s easy to forget that a lot of important engineering work gets done in the heady days of an emerging technology. I was reminded of this today when I noticed these two news items side-by-side on CNET this morning:

Rocket science just isn’t what it use to be. Must have been an amazing 20 years…


March 31st, 2011

The ESG pattern


Category Uncategorized
 
Are you still considering rolling out a major Enterprise Service Bus (ESB) stack — you know, the kind that involves a massive initial investment and takes 8+ months to deploy? This wasteful approach was a major factor in doomed corporate SOA initiatives that were common between 2003 and 2009. During this same period, clever architects ignored large vendor promises and realized that you simply cannot buy your way into an agile enterprise SOA. They instead focused on the tasks at hand, integrating existing IT assets, following SOA principles, using existing tools and adding lightweight strategic and specialized infrastructure to help them along the way. The winning enterprise SOA initiatives are the ones who made sure that the SOA was operational as it evolved. SOA Gateways gained popularity in recent years as a lightweight ESB that can span departmental boundaries. Like software ESBs, SOA Gateways can translate data formats, route content, service-enable data sources and switch between transport protocols. But SOA Gateways have a number of significant advantages over traditional software ESBs. For example, they scale easily and accommodate high volume traffic environments owing to their specialized acceleration of message validation, routing and translation. Also, SOA Gateways offer comprehensive security and identity federation features built in so they can be deployed at the service zone perimeter (think DMZ). Looking back, the pattern of using an SOA Gateway to integrate and service-enable existing IT assets has been a large success. Because of the appliance form factor and the configure, not code approach, the cost of integration and the time to react to new requirements both shrunk considerably. And with a focus increasingly shifting towards cloud computing, this ability to quickly accommodate new integration mechanisms has already paid off for those who invested in the lightweight, agile solution. This is especially the case for those who opted for the virtual appliance form factor. I like to refer to this pattern as the Enterprise Service Gateway (ESG). That is, the ability to execute integration, transformation and security using a specialized gateway appliance as opposed to coding using traditional software ESB frameworks.