There are many pathways to API creation and design. Some businesses might start with private APIs and then make them public (but this is rare). Others may jump straight in and start creating an open (public) API (this is quite often the norm).

But one pathway to API creation is not as often explored, but it can feel more natural for established, non-pure play businesses. This pathway is to start with a partner API, and when the business feels confident enough, perhaps opening up it up as an open (or public) API. We spoke with Peter Jervgen, head of Strategy & Architecture at the Swedish offices of international energy company E.ON, and Marjukka Niinioja, Senior Consultant and Manager at Finnish startup PlanMill to gain some insight into how businesses are moving from partner APIs to public APIs. While both businesses have a significant online presence (with PlanMill even being a Software-as-a-Service product), they are also both firmly rooted in working in more traditional business sectors, where their partners and customers may not be all that API-conversant.

Marjukka will also be speaking at our Helsinki event where, she says, “I’m going to tell how we have done things with our current API and how we are in the process of renewing the API. I’m also going to discuss the organisational side of things: how to change sales, customer service and consultants to API sales, API customer service and API consultants. Then I’m throwing in some integration problems we have — or haven’t — solved with our API and why, things such as invoice and accounting integrations with financial systems. And, if we have time, I will share some thoughts on how to design a usable API (instead of concentrating where to put the input field or button in the UI).”

Starting with Partner APIs

In a previous discussion with Mark O’Neill, VP of Innovation at Axway, he pointed out that one strategic path that makes a lot of sense to businesses starting out with APIs is to commence with the low-hanging fruit that improve relationships with partners. This often includes making price catalog data available via API, or enabling access to processes like order and shipping information via API so partners can look up their order details themselves, all via your API. Mark’s point of view is that once these APIs are working well with partners, they are also ideal to then open up as more public-facing APIs.

Ronnie Mitra from Layer 7 had a similar comment. He urges businesses to ensure that the basic infrastructure is in place — and built with best practice principles in mind — for partner APIs (things like an API security gateway, a developer portal and API instance), so that if a business does decide to open them up more broadly, they are robust and secure enough to be accessible and usable by third-party developers.

“Naming our API as the PlanMill Open API was one of the signs of being an ‘accidental API developer’”, Marjukka told us (this is also the name of her presentation at Nordic APIs). “‘Open API’ wasn’t really a clear concept 5 years ago and the concept of public versus private is kind of problematic when our customer owns the data inside of their PlanMill system and decides who they want to play with, even if we say our API is open for anyone to create an integration.”

PlanMill is a business services Software-as-a-Service platform with components like a CRM, invoicing, and project management. So customers are storing a lot of their business data in the system.

“If you are our customer, you can use our API free or almost free-of-charge to connect to any of your own systems or to 3rd party systems. You can also give access to any of your customers and partners to access your system via the API. We do also let partners and companies we are interested in becoming our partners to use the API,” Marjukka explains.

For energy and utilities company E.ON, Peter Jervgen says they are just getting started with partner APIs, but have a ‘semi-open API’ in their sights. “At the moment, we are focusing on internal and partner APIs,” Peter told us. “However, E.ON acknowledge the user empowerment that comes with open APIs. E.ON wants customers and partners to be engaged in the future of Energy Solutions. But, the ramp-up towards open API’s will be done in a controlled way and according to the directives of the E.ON business strategy.”

Deciding which APIs to move from partner to public

In both of these case studies, the businesses have started with partner APIs and as they learn how to implement and manage the API with some external integrators, are moving towards opening them up more broadly as public APIs.

PlanMill is particularly interesting in this regard. One of the key reasons why businesses offer a public (open) API is to allow third-party developers build new apps and integration solutions that enable the API provider to enter new customer markets. By working with their network of business partners first, PlanMill has ended up with a suite of third-party apps that help them connect with new markets, and in some cases, share the revenue from entering those markets with their partners. The infrastructure is then tested and in place as PlanMill opens up API access to developers with whom they don’t already have an existing relationship.

“Letting partners and customers create integrations themselves with very little participation from us would have been totally impossible otherwise,” says Marjukka. “For example, integration with Atlassian’s Confluence wiki or Jira was done by mainly by our customer Ambientia and we are selling the Confluence integration together. Also, we were able to give Administer Oy the possibility to code purchase invoice integration with PlanMill, and our customer Futurice built a complete time report mobile app and UI (FutuHours) on top of our API. In terms of externalizing development and shortening the time to develop things, an API is a must. Real-time integrations just can not be done with a file import or export.”

E.ON is thinking along similar lines. Globally, in the final quarter of 2013, energy and utilities companies were the fastest growing sector creating mobile apps that routed data on energy consumption and usage from their APIs. “We think that ‘Home Energy Management’ and ‘Smart Cities’ are two examples where we can expect open APIs to soon emerge,” confirms Peter. “This is also in agreement with E.ON’s ambition to stay at the front in terms of investments to keep our globe and climate sustainable.”

Open APIs: Use your business workflows to create success

One characteristic that both PlanMill and E.ON stress in creating open APIs is to have clarity around business workflows and business logic. In many cases, it may be easier to resolve these questions when building an API with partners first, so that by the time it is going to a more public audience, you are confident it is robust.

“The first thought [in our business] when talking about APIs is that it’s something techy and only an integration layer,” Marjukka shared with us. “For many business users and managers, it has been really difficult to think of it from a business requirements perspective.”

“Lots of times, we get a request from a customer company related to our API where a developer (usually fresh out of school or making his thesis) has been given the task of ‘get our time reporting and XYZ things integrated between PlanMill and our X system’. They start to approach it as a programming task only and then they realize that they need to actually know a little bit of what is the process, where, when, how are things being created, edited and deleted, and, for example, which system is the master of the data? This brings us to the question of the whole business process.”

By using partner APIs first, a business can also get a feel for the support requirements that may be necessary to manage if releasing the API more publicly. “It has been — and still is — a huge learning experience internally how to support, consult and sell the API because it’s so different from our base products with user interfaces,” Marjukka said. “Plus the development: remembering that all the business logic checks done in the UI need to also be done in the backend, because you have to check data integrity.”

Peter agrees. “We try very early on to introduce Lifecycle Management for implemented APIs. We think that a lot of competence and experience can be obtained by adopting best practice already present at the current line organisation within E.ON IT. The unit is handling IT Services at the macro level according to the ITIL framework where service level agreements, release and change management are fundamental ingredients.”

Moving to open APIs

PlanMill are currently thinking through the ‘what ifs’ that have become more concrete now that they have started their API journey. “We are exploring possibilities to open up some of our localisation and other data more to the public, to customers who are not otherwise users of PlanMill, although we will be requiring registration and most likely some amount of fees, possibly according to usage.”

E.ON are moving their partner APIs to a semi-public type of access: “We think that we will start to introduce semi-open APIs to large customers and key accounts. These customer categories typically have a close partnership with E.ON so there can be a fruitful ‘give and take’ situation. All parties can benefit from an agile and refactoring style of development. E.ON is also participating in the EU initiative Finesce that is targeting the Future Internet for Smart Energy including machine-to-machine (M2M) communication and the Internet of Things.”

But like any business opening up their APIs, E.ON points to a discussion we hope to help resolve with our agendas for the upcoming Nordic APIs tour: “Our key considerations are related to security and intellectual property rights. Given that future E.ON Energy Solutions will include more of IT-related services and many of these services will be aggregates of 3rd party services E.ON needs to ensure that exposed APIs are robust, secure and not violating any business agreements.”

We look forward to continuing this conversation on the role of private, partner and public APIs, and to help businesses navigate a successful pathway as they increasingly open their data and capabilities via API. Join us in Stockholm, Copenhagen, Helsinki and Oslo at Nordic APIs next week.