Roberto Medrano

Editor’s note: this is the second in a series of blogs that provides insight into our new eBook, Building Successful APIs. As the leader in enterprise API solutions, we want our customers, partners and other stakeholders to be informed and knowledgeable about the options available to them.

Whether it’s a garden, an airplane, or a piece of software, you can’t create something without a plan and have it develop into something useful and usable. If you’ve been in the sofware field for any amount of time, then you can probably spot the difference between well-planned and poorly-planned software from a mile away. It’s surprising how often, when in the role of an end-user, we find ourselves cursing an application and wondering what on earth were the developers thinking? Well, the fact is they probably weren’t dedicating a lot of thinking power to their task. The result is grumpy users who equate an enterprise’s poor development quality with their brand. If they can’t even design a simple transactional application, we think, we’ll just take our business elsewhere.

Software has become much easier to manipulate into workable applications over the past decade. We see people with very little programming training being able to create wonderfully rich and interesting apps upon which, sometimes, and entire company is built. In our world, we see it especially happening with API development. Development, implementation, security – some really cool things are happening with APIs not necessarily because of programming skills, but because developers have taken the time to think through what they want to build. Irrespective how easy or difficult the tools are, to create a great application or API, you need to spend time planning and thinking with the end in mind.

Let’s consider the first two aspects of what is required:

Business Purpose of the API

What comes first, the reason or the solution? Well, in software, you don’t get started unless there’s a reason to sit down and put fingers to keyboard. And what drives the reason for an API should come from a specific, defined and agreed-upon purpose. Perhaps your organization wants to use it to drive traffic to your site. Maybe there’s a self-service element that is missing in your enterprise and you think an extension can help. Mobilty brings a host of other business imperatives for which an API could be an appropriate solution. An API may be created for any number of reasons, but the form and function of the API should be driven by the requirements of the business.

Because human capital and financial resources will be dedicated to API development, and because it’s important to really get correct what it will address, the organization’s executives should agree about the purposes of the project and define high-level, attainable goals. This defines the initial requirements, and then cascades to those who will have direct responsibility for the various ways the API impacts the business. Essentially, this will help to ensure that your API strategy is aligned to your business goals.

The importance of aligning your API delivery to your Enterprise Strategy

The importance of aligning your API delivery to your Enterprise Strategy

The importance of aligning your API delivery to your Enterprise Strategy is best accomplished when all integral parties are able to decide upon and agree to a common set of actions:

IT Goals vs. Business Goals

APIs are almost, by definition, driven by business goals, and because of that, they are a rare, and unique creature among those in development and IT. We’re still in the Middle Ages in terms of how business and technical folks interact – at best, there’s misunderstanding. At worst, there’s distrust.

We can see the issue – businesspeople can often be blinded by their own PowerPoints and be impressively ignorant of how a business goal gets translated into a technical set of requirements. “Just make it work” is often heard from the guys with cufflinks. On the other side, it’s not uncommon for developers to poke holes, in a technically respectful way (?), but doing so while totally forgetting that the goal is to deliver a solution, often one that involves a ringing cash register.

How do meet each other half-way? It can be delicate, but the best APIs come out of organizations that are respectful of one another’s needs. But it’s crucial to recognize that there is an abundance of skilled developers who make it their business to create new solutions by integrating software from many different businesses and sources. When you share your APIs with these developers, and they share their apps with your customers, everyone wins.

When developers see their reach increase, we start to see a viral effect take place, and in many ways, this is currency for them (and hopefully generates real currency to the bottom line). By their very nature, APIs are meant to be shared – this sharing gets the developer’s art in front of new audiences and done in (hopefully) an exponential way). This helps the marketplace for your users’ services and products and serves the needs of your own organization’s goals.

Planning is clearly a crucial aspect of API development. We will go into more detail about it in the next blog in this series, and you can get a more comprehensive view of it in our eBook, Building Successful APIs, available for free on our Web site.

Share Button

Comments are closed.