“Applications as Platforms – Supporting the Enterprise” on the Iasa Blog

Carrying the weight of the world

You have a limited number of resources that can work on any endeavor. Call it headcount. People who are excellent at creating user experiences, working with design, and polishing pixels are almost never excellent at building easy to use, scalable, and flexible APIs. And of course the reverse is even more true: plumbers can’t paint worth beans. If you choose to be both an app and a platform you will have half the great plumbers and half the great painters you’d have otherwise.

Charlie Kindel, in his post “Be Either an App or a Platform, Not Both”, points out the difficulties of trying to be both an application and a platform, much of which comes down to the difficulties of designing a platform, period.

My latest post on the Iasa Blog discusses why, even with the obstacles, you may need to be both.

Update 4/12/2013: Mirrored here.


2 thoughts on ““Applications as Platforms – Supporting the Enterprise” on the Iasa Blog

  1. I was going to leave a comment on the IASA blog but could not create an account so I will comment here. I worked on a product with a public API for over ten years where seemingly innocuous decisions haunted us.

    To be honest, I see the main issues with API design as organizational. API designs are always going to have mistakes so the focus should be on minimizing, handling and correcting those mistakes.

    For example, API development leads to an “us and them” mentality. Like any architectural decision, API creation involves predicting the future and, unless the prediction is perfect, consumers of the API are rarely happy with it. Consumers also tend to overstate the work required to circumvent API issues compared to the benefits an API provides, meaning it is very easy to point the finger at API development or maintenance teams for any issues consumers of the API encounter.

    Therefore, it is important to rotate team members into and out of each of the teams. It gives developers previously working on back-end components experience how the API is used and API consumers understanding of the challenges with maintaining older APIs. This may be a formal team change or as simple has having team members eat lunch together.

    It is also important to document exactly what the API does and does not do, ensuring the edge cases are captured in automated tests. This often easier said than done, since the edge cases are often not known in advance and the communication mechanisms between consumers and API designers either do not exist or development schedules do not allow timely changes.

    Another challenge with any API is the API transport and messaging technology itself. Ten years ago, DCOM or raw sockets were comment. WS-* then had its day and now the rage is REST and JSON over HTTP. It is fair to assume that the future will bring similar changes so, even if the API is perfect, facades or proxies/stubs may still be needed in the future.

    I agree with strict versioning of APIs as you say above – that way, you know when you are broken – as long as the rules are consistent across an API set. I also think that there is a case for multiple sets of APIs, particularly for different audiences. For example, there may be a low level web services API aimed at developers and a higher level power shell or command line API aimed at operators or admins.


    • Anthony,

      First, thanks for making the effort to comment…I’d imagine the IASA’s comment policy is set up that way so that they don’t have to moderate them, but the loss of feedback is definitely regrettable.

      I like your suggestion for dealing with the conflict between producers and consumers of an API. Obviously, it’s easier to implement when both are within the same organization, but even when designing for public use, it’s vital to get into consumer’s head. Designing an API is no trivial matter.

      Regarding the challenge of transport, take a look at https://genehughson.wordpress.com/2012/04/23/on-the-plane-or-in-the-plane/. Decoupling the logic from the transport is critical to preventing a multi-protocol environment turning into a DRY nightmare.


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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s