Design and APIs

In general on August 1, 2007 at 8:10 pm

One of the skills a good engineer is expected to exhibit is design. This may come as a surprize to some but a good engineering solution will exhibit many principles of desisgn expertise that come from experience and the application of the art in which the enginner practices. This is as true for building audio filters for electronic circuits and bridges as it is for Application Programmer Interfaces.

So what is good design? Good design is what makes things invisible. Things that are well designed become more elegant, usable and useful that items that are not. This has a direct commercial impact on businesses – in manufacturing design is obviously a factor that affects the desirability of one product over another. But the commercial imperative of design is much deeper that aesthetics. Design affects adoption, design affects maintenance, design affects visibility.

An API can be one of a company’s greatest assets. The decision to code to your interface establishes a greater mindshare in the people you work with than merely being another name in a list of suppliers. Done well an API helps integrate your services into someone else’s business processes. However, bad design should not get off the developers to do list. Exposing your understanding of your value proposition to customers is a daunting step and one that can fail much more easily than many realise.

Of course the best APIs are released once they are already proven within their organization. Since APIs cannot radically change, there needs to be a high level of confidence that the decisions taken will stand up to use over a lengthy period of time. Design should make things easy whilst being useful. Rather than reiterate whats already known, I refer you, dear reader to an existing exposition of the value of APIs.

The important things about public APIs is that they will not necessarily be used by programmers! Programmers are people who spend all their time writing code. Is one of those people really interested in your business processes? Isn’t it much more likely that the real audience for your API is the technically-leaning component of your customer base? So write with those people in mind – and they can explain what needs to be done to their programmers. Remember programmers write sort algorithms – not business requirements.

Of course, once an API is released in the wild, there is an implied contract to keep servicing it. Unless there are exceptional circumstances (like an acquisition involving a different business strategy, and even then there is a loss of goodwill) users are not going to be happy if their interface is whipped from under their feet. Caveat emptor – or make sure you know what your backup plan is and ensure you are loosely-coupled to your services of choice.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: