Open innovation bridges the gap between business and academia. It encourages participation on both sides, through a distributed and decentralized approach.

by Henry Chesbrough, Haas School of Business, University of California at Berkeley May 13, 2016

Open innovation is “the use of purposive inflows and outflows of knowledge to accelerate internal innovation and expand the markets for external use of innovation.” It’s a model for industrial innovation that I originated in my 2003 book, Open Innovation. Since that time, the concept has been adopted by most large companies in the U.S. and Europe and cited in thousands of academic articles.

Open innovation assumes that companies can, and should, use external ideas as well as internal ideas, and pursue internal and external paths to market, as they look to advance their innovations. Open innovation processes combine internal and external ideas into platforms, architectures, and systems. Open innovation processes use business models to define the requirements for these architectures and systems. These business models access both external and internal ideas to create value while defining internal mechanisms to claim some portion of that value.

A traditional innovation process is closed because projects can only enter it in one way, at the beginning from the company’s internal base, and can only exit in one way, by going into the market. Under this closed model of innovation, research projects are launched from the science and technology base of the firm. They progress through the development process, and some projects are stopped while others are selected for further work. A few successful projects are chosen to go through to the market.

Contrast that with the open innovation model, in which projects may enter or exit at various points and in various ways. Here, projects can be launched from either internal or external technology sources, and new technology can join the process at various stages. As well, projects can make their way to market in many ways, through out-licensing or via a spinoff venture company, for instance, in addition to going through the company’s own marketing and sales channels.

A more recent development is the consideration of how innovation plays out in service businesses. Most of the top 40 economies in the Organization for Economic Cooperation and Development (OECD) get half or more of their gross domestic product (GDP) from that sector, and many companies are witnessing a shift to services as well.

More generally for services, innovation must negotiate a tension between standardization and customization. The former allows activities to be repeated many times with great efficiency, spreading the fixed costs of those activities over many transactions. The latter allows each customer to get what he or she wants for high personal satisfaction. The problem is that standardization denies customers much of what they prefer, while customization undermines the efficiencies available from standardization.

The resolution to this dichotomy is to construct service platforms, which invite others to build on top of your own platform offering. This allows economies to emerge from the standardization of the platform, and it creates customization through the addition of many others to the platform. A fundamental premise of open innovation is that “not all the smart people work for you.” That means that there’s more value in creating the architecture that connects technologies in useful ways to solve real problems than there is in creating yet another technological building block. System architecture, the system integration skill to combine pieces in useful ways, becomes even more valuable in a world where there are so many building blocks that can be brought together for any particular purpose.

Platform leadership is the business-model side of systems integration. A successful platform requires a business model that can inspire and motivate customers, developers, and others to join the platform. The model must be designed to allow those third parties to create business models that work for them, even while the business model works for the platform creator. In that way, their activities increase the value of the core business, and their investment makes the platform business more valuable.

Open innovation was first understood and implemented as a series of collaborations between two organizations to open up the internal innovation process. Today, though, we see many instances in which the concept is being used to orchestrate a significant number of players across multiple roles in the innovation process. Open innovation is going to expand well beyond collaboration between two firms, and designing and managing innovation communities is going to become increasingly important to the future of open innovation.

Furthermore, open innovation’s effectiveness is not restricted to a few select corporations. It is a process that makes more effective use of internal and external knowledge in every organization, whether old or young, large or small, public or private.

This article is adapted from a longer version. Read the full article here.

Each participant in the conversation had different personal preferences for how they write code, which makes sense. However, from each participant’s personal preference you could extract an identical principle: “I need to observe something before I can make a decision.” Kent often (though not always) liked writing tests first so that he could observe their behavior while coding. David often (though not always) wanted to write some initial code, observe that to decide on how to write more code, and so on. Even when they talked about their alternative methods (Kent talking about times he doesn’t use TDD, for example) they still always talked about having something to look at as an inherent part of the development process.

It’s possible to minimize this point and say it’s only relevant to debugging or testing. It’s true that it’s useful in those areas, but when you talk to many senior developers you find that this idea is actually a fundamental basis of their whole development workflow. They want to see something that will help them make decisions about their code. It’s not something that only happens when code is complete or when there’s an bug—it’s something that happens at every moment of the software lifecycle.

This is such a broad principle that you could say the cycle of all software development is:

If you want a term for this, you could call it the “Cycle of Observation” or “ODA.”

Example

What do I mean by all of this? Well, let’s take some examples to make it clearer. When doing TDD, the cycle looks like:

See a problem (observation).

Decide to solve the problem (decision).

Write a test (action).

Look at the test and see if the API looks good (observation).

If it doesn’t look good, decide how to fix it (decision), change the test (action), and repeat Observation → Decision → Action until you like what the API looks like.

Now that the API looks good, run the test and see that it fails (observation).

Decide how you’re going to make the test pass (decision).

Write some code (action).

Run the test and see that it passes or fails (observation).

If it fails, decide how to fix it (decision) and write some code (action) until the test passes (observation).

Decide what to work on next, based on principles of software design, knowledge of the problem, or the data you gained while writing the previous code (decision).

And so on.

Another valid way to go about this would be to write the code first. The difference from the above sequence is that Step 3 would be “write some code” rather than “write a test.” Then you observe the codeitself to make further decisions, or you write tests after the code and observe those.

There are many valid processes.

Development Processes and Productivity

What’s interesting is that, as far as I know, every valid development process follows this cycle as its primary guiding principle. Even large-scale processes like Agile that cover a whole team have this built into them. In fact, Agile is to some degree an attempt to have shorter Observation-Decision-Action cycles (every few weeks) for a team than previous broken models (Waterfall, aka “Big Design Up Front”) which took months or years to get through a single cycle.

So, shorter cycles seem to be better than longer cycles. In fact, it’s possible that most of the goal of developer productivity could be accomplished simply by shortening the ODA cycle down to the smallest reasonable time period for the developer, the team, or the organization.

Usually you can accomplish these shorter cycles just by focusing on the Observation step. Once you’ve done that, the other two parts of the cycle tend to speed up on their own. (If they don’t, there are other remedies, but that’s another post.)

There are three key factors to address in Observation:

The speed with which information can be delivered to developers. (For example, having fast tests.)

The completeness of information delivered to the developers. (For example, having enough test coverage.)

The accuracy of information delivered to developers. (For example, having reliable tests.)

This helps us understand the reasons behind the success of certain development tools in recent decades. Continuous Integration, production monitoring systems, profilers, debuggers, better error messages in compilers, IDEs that highlight bad code—almost everything that’s “worked” has done so because it made Observation faster, more accurate, or more complete.

There is one catch—you have to deliver the information in such a way that it can actually be received by people. If you dump a huge sea of information on people without making it easy for them to find the specific data they care about, the data becomes useless. If nobody ever receives a production alert, then it doesn’t matter. If a developer is never sure of the accuracy of information received, then they may start to ignore it. You must successfully communicate the information, not just generate it.

The First ODA

There is a “big ODA cycle” that represents the whole process of software development—seeing a problem, deciding on a solution, and delivering it as software. Within that big cycle there are many smaller ones (see the need for a feature, decide on how the feature should work, and then write the feature). There are even smaller cycles within that (observe the requirements for a single change, decide on an implementation, write some code), and so on.

The trickiest part is the first ODA cycle in any of these sequences, because you have to make an observation with no previous decision or action.

For the “big” cycle, it may seem like you start off with nothing to observe. There’s no code or computer output to see yet! But in reality, you start off with at least yourself to observe. You have your environment around you. You have other people to talk to, a world to explore. Your first observations are often not of code, but of something to solve in the real world that will help people somehow.

Then when you’re doing development, sometimes you’ll come to a point where you have to decide “what do I work on next?” This is where knowing the laws of software design can help, because you can apply them to the code you’ve written and the problem you observed, which lets you decide on the sequence to work in. You can think of these principles as a form of observation that comes second-hand—the experience of thousands of person-years compressed into laws and rules that can help you make decisions now. Second-hand observation is completely valid observation, as long as it’s accurate.

You can even view even the process of Observation as its own little ODA cycle: look at the world, decide to put your attention on something, put your attention on that thing, observe it, decide based on that to observe something else, etc.

There are likely infinite ways to use this principle; all of the above represents just a few examples.