APIs are like LEGO building blocks, it is often said. Many API talks start off by explaining that APIs are like these bricks. They can be combined in innovative and creative ways beyond their originally intended purpose. What are APIs like for LEGO though? For those that are planning on attending our Platform Summit in October, you will hear the Danish worldwide phenomenon tell their API story first-hand. However, we wanted to share some of their experiences with our entire community. After catching up with Dennis Bjørn Petersen, Platform Architect at LEGO, we’re excited to give you the scoop on their API strategy and implementation.

The following insights from LEGO will help you execute a better API strategy that is able to meet the requirements of your customers, partners, and authorities.

LEGO’s API Strategy

LEGO’s API journey is somewhat unique in that they started with a partner API and progressed to a private API from there. This flow usually goes the other way, increasing in openness not decreasing. For LEGO though, the initial point in this progression came out of discussions the toy maker had with their video-game partners, Warner Brothers and Funcom. These third-parties were creating LEGO-themed video games that would be compatible with a wide range of mobile devices and for the web. “When someone has to log in to any LEGO system, they should only log in to one system, and that is our authorization. So, that’s why we started collaborating,” Dennis explains.

“In that way, we ensure we know what sort of information we are collecting from users… We are often working with children under 13 and being clear about what information is collected is crucial for us,” the platform architect continues. Around the world, many countries have strict regulations about what data can be collected from children using the internet, and compliance with these is a duty that LEGO takes very seriously. It is not a responsibility that LEGO would consider passing on to a business partner. Dennis says this is not a reflection on any of their business relationships, but that “it is in our mutual interest that this is covered by us.”

As work on the API design progressed, the company was also looking to upgrade its identification and authentication processes used internally. Dennis’ team quickly saw the benefits of using this new API that they were creating for internal authentication processes as well. In this way, the Partner API came first and led to it also being used as a private or internal API by the company. “We decided we may as well create an API for both external and internal developers. It is used in games, on our message board, in our rewards program. It’s used everywhere you need to log in with a Lego ID,” Dennis told us. This system thinking undoubtedly led to a much higher return on the investment that LEGO made to integrate with these two partners.

Tools & Processes

Though LEGO is a global market leader with large amounts of resources at its disposal, they have adopted a lean approach to managing their API. They have assembled a series of lightweight tools, processes, and techniques to help them meet the business objectives of their API. Dennis shares some of the simple strategies they use in their partnership and internal work.

Documentation

As we have blogged about before, API consumers need information if they are to use your service to solve their problem. This includes API documentation. LEGO knew this, and prioritized the creation of such resources that would aid API consumers in the use of the service. As Dennis told us, they built a test site with examples and snippets of JavaScript code that consumers could add to their applications to quickly and easily begin using the API. Providing API documentation is a best practice that Ben Nunney, European Marketing Manager at Twilio, shared last fall at our business-focused event.

API Metrics

If you don’t count it, don’t do it, the adage goes. Tracking key indicators of your API’s usage and performance is really important. The level of sophistication of your tracking system should increase with your API consumption. Otherwise, you may implement a large analytics system for an API that does not end up being adopted. Take a lean, just-in-time approach instead. This is what LEGO did. Dennis told us that a manual process was sufficient from the beginning. This is similar to the techniques that Västtrafik has shared with the Nordic APIs community in the past. This DIY approach is a good place to start as you dog food your API, but should be replaced by purpose-built tools over time. This advice is aligned with LEGO’s API rollout. As Dennis says, “We can see that usage [of our API] is increasing, so we are looking into an API management tool to take the load off our backs.”

Error Logging

Like Storebrand, a large Norwegian life insurance company which I’ve previously blogged about, LEGO has built an error logging system to help them discover, diagnose, and fix errors in their API. Finding help when something goes wrong is pretty easy within LEGO and amongst the smaller partner ecosystem that is currently using it. As consumption grows though, the importance of this system will grow. “We do like to keep an eye on how our API is being used and if it is being used correctly,” says Dennis. Following these practitioners examples is a good idea as you roll out your API to internal and partner consumers. Starting with a Minimal Viable Product (MVP), which may include rudimentary error logging, is another best practice that Ben of Twilio encourages. As with metrics though, the sophistication of this system will likely grow with increased consumption. At that point, a DIY approach may have to give way to more comprehensive, commercial log monitoring products.

Mentorship & Pair Programming

Pair programming is a technique encouraged by agile software development experts worldwide. LEGO follows this advice even when the developers being paired together are not from the same organization. Dennis says that, “[w]hen working with external games developers, we normally do a code review, and we send one of our developers to sit with our external partners and work on the first integrations.” Sending a developer to another city just to perform the integration might seem suboptimal. Overall, however, it is the best way in some cases. As Dennis continues, “It’s not that our API is complicated…it is just easier and faster to sit with them.” This technique is one that Travis Spencer, CEO of Twobo Technologies and co-founder of Nordic APIs has seen in previous partner API implementations. He explains:

I once did a job with a large TV studio in Hollywood. We were working 1,000 miles away in Portland to develop the data access APIs for a complicated Content Management System. Every month or so, we flew down to Hollywood to work with the customer and their partners to integrate new drops. This work wasn’t complicated when sitting in the same room, but it would have been hard over the phone or via email. Working shoulder to shoulder saved tons of time, and was cheaper in the long run.

As you implement your internal and partner APIs, consider if pair programming can reduce the Time to Value (TtV). As your API scales to the general public, however, you will need to consider other means to facilitate sharing within your developer community. At large scales, electronic, on-line methods will be required. Learn from the techniques you use when providing your API to internal and partner stakeholders and iterate over them as usage grows.

Building One Brick at a Time

Like any of LEGO’s construction sets, the company is assembling the API one “brick” at a time. What started with the LEGO ID API that is now being used across the company, others may follow as well. Dennis says that they “met with Disney a couple of years ago and they have some great ideas about what you can do with an API.” This type of market-driven development is probably the best approach for larger enterprises. In so doing, the platform opportunities to create value using APIs will be apparent to all parts of the business (e.g., sales, marketing, finance, top management, etc.). This people-oriented approach is one of the two things that will transform your business into a platform for growth.

For more on how LEGO is progressing in this transformation, be sure to subscribe to our newsletter where we will share more insights from this market leader in the coming months. Also, plan to attend the Nordic APIs Platform Summit on October 20-22 where Dennis and his colleague, Lars Axberg, Senior Developer, will share first-hand. Till then, comment here or on Facebook with your thoughts on tools, processes, and best practices you would recommend to other API practitioners in the community.