Setting-up an agile organization for innovation is not enough: one has to get his innovation accepted by the core business, and the market. To tackle this issue and preserve speed, ‘innovation by component’, based on modular and collaborative design, brings significant cues. How to achieve a successful component design (API) is what we address hereafter.
From rapid innovation to innovation by component
Addressing the challenge of accelerating innovation, we have crafted an organizational model based on:
- setting-up an agile and autonomous innovation entity;
- designing within a framework involving “creative tension”, an exciting environement mixing stimulating and stretched goals with a proven expertise in innovation discipline;
- aligning with innovation group strategy, across a shared portfolio and permanent connections, in order to facilitate adoption of the innovation output by the core business.
Furthermore, to streamline the delicate acception part, and solve the paradox of combining agility with core business alignement which might slow the process, we have refined Rapid Innovation model. Based on collaborative design approach and modular design, we have experimented a creative approach called Innovation by Component: “Designing with, rather than designing for” is the mantra of Innovation by Component.
Still, completing a creative component does not limit to deliver a functionally operative module; it requires a truely ‘design thinking’ approach consisting in imagining what future objects might be enhanced by your component and what they would need, how the future objects could be modular so as to include your component, and this move could embody an exciting vision for your company: nobody gets up to build a practical component, innovation requires a belief and a vision.
What is a creative component?
A component unfolds the idea of combining breakthrough innovation and bold exploration, with the leverage of letting others get ownership of your innovation in their activity, and build value on top of your platform. Concretely a component is a functional module, that can be embedded in multiple services through an API, and give birth to unexpected derived services: “one stone, multiple birds!”
A relevant example is the Social TV component developped at Orange, which is used within numerous applications, on a variety of content genres, far beyond the initial TV domain identified initially.
Component approach touches the world of Intelligent Things, Smart cities, Smart TV, Smarthomes, …, open and partner API, and Open data: communities of developpers build innovative applications making great use of data provided by devices and organizations, and therefore enhance the attractiveness of the formers. Innovation by Component is natively committed to innovation ecosystems and sparkling innovation.
Designing a successful component
Designing a successful component becomes then a major issue. Going through a handful of product attributes, let’s discover how excellency in code writing must be complemented by strategic innovation skills, and proceed on the route of ‘design thinking’. Designing an API as a truely accomplished innovation component is a cultural achievement.
- Meaning: creative component must have a clear meaning, “a reason why”, and be supported by a strong belief; these elements can result from identifying market trends through quantitative yardsticks, and detecting opportunities through qualitative user observation; in the case of Orange Social TV component, having noted the impressive growth of TV-related conversations on Twitter in the US, we developed in-depth focus group on content consumption to unfold emerging patterns. It forged our conviction, established our willingness to take risk , and shaped the focus of our API: there is great value in filtering the noise from the social networks and mastering the social buzz, to facilitate TV content discovery, and help viewers to join he conversation in real-time. Meaningful innovations meet with social imaginaries; they fit in the power of sameness described by
@brada: “you don’t read rental car manuals because all cars work basically the same way!”.
- Target: your service gets better when you can project who your customers will be, and listen to them once the service is alive: “Focus on user, not yourself; your developers can’t read your mind!” underline
@brada and @kcwalina; in our case, APIs are BtoBtoC: our direct customers are Orange Business units or external companies. From the start we have to imagine what would be the best methods and formats for them, data relevance and their representation, having in mind the end-user services that will be further initiated. To avoid numbers game, go for plurality: “good APIs offer their responses in a multitude of data formats, not least JSON and XML” explains Adam, master of TV hack day event. Acces differentiation depending on the type of customers (‘closed API’ access within the group, ‘partner API’ for privileged customers, ‘open API’ for everyone), and differentiated usage measurement must be anticipated. I.e, having primary designed our Social Culture component (remembering and sharing a cultural experience) for the use of Orange corporate communication & Orange NFC teams, we had in mind that customers would come from outside the group, museums, touristical spots, miscellaneous cultural entities: France is a country which is not lacking of cultural and touristical assets!
- Evolutivity: once a domain targeted, it may happen that unexpected demands arise, coming from other areas. Designed to detect TV related conversations, Social TV component was evolutive enough to travel across borders, and cover successively sports competition Paris Bercy, Roland-garros, Uefa Euro 2012, to detect social buzz linked to new films releases and VoD, and be embbeded in multiple screens: smart phones, tablets, computers, and smart TV. Start focusing your development endeavor and prepare to extend is a path to innovation success. In other words, “Do as little as possible now (but no less) to ensure room for extensibility in the future!” claims
- Scalability: no one is immune to succes: the more customers your innovation seduces, the more additional features will be required, the more workload will support your servers; your component will experience solid organic growth. Roland-Garros competition with 2 millions apps sollicitating our social TV component was a reassuring stress test for our architecture. In this domain, Google and Faceook are totally impressive, being able to add millions of users without any interruption of service.
- Interactive Innovation Ecosystem: your component was initially confined to a handful of services delivered by others: growing your innovation business requires a holistic approach. Crossing the chasm, by going beyond early adopters involves a more systematic marketing and customer relationship state-of-mind. Making an appropriate exposure of the API, streamlining process to subscribe, helping others to design, staging the API with a “killer demonstration-app”, developing use case and accurate documentation are required: “don’t force consumer to be archeologist of your innovation (@brada)”. “Make your API hard to misuse, explicit error message suggest parameters values” suggests
@piwik. It’s as well vital to keep your API a living innovation to monitore at a larger scale the users return loop, showing how your component is being used, leading to new features and to cross-fertilizatuion of usages among your customers. One specific request from our movie business unit led to new API methods which were further rapidly widespread across the others Orange business units. What kind of global system of component are you building is the next question raised by the innovation ecosystem approach.
This set of attributes is your “innovation storytelling”: it builds a common belief across all participants of your innovation ecosystem, and led everyone to participate and create value.
Nurturing interactions in the ecosystem drives fizzing creativity, making innovation a cyclic circulation of knowledge and a continuous process of improvement.
Good readings: how to design a good API by @piwik, the art of building a reusable class library, by Microsoft engineers Brad Abrams (
@brada) and Krzysztof Cwalina ( @kcwalina), Google engineer Joshua Bloch’s keynote
API platform: explore, consume, distribute and share APIs with others developers on Webshell