Open the door and let me in…

I have been playing with the Roku Netflix streaming device, Apple TV as well as the XBMC and Boxee open source media centers running on Apple TV. This is the inspiration of this post: the what, why, when and how questions relating to defining your open architecture strategy.

Quick background: Using ATV USB Creator, it is possible to install XBMC and Boxee on Apple TV. However, as soon as a firmware upgrade occurs for Apple TV, I’m back to square one: wait for the open source community to catch up with the fixes to ATV USB Creator, followed by reinstall and reactivate. As much as it is a hack, these hacks/solutions do increase the value of Apple TV, enabling me to access other available Internet channels, outside of iTunes.

Open architecture or open implementation allows 3rd party developers to alter and add to pieces of the underlying software to fit their specific needs. The degree of openness changes from product to product and company to company. It could be as simple as open formats to enable data interchange (OpenDocument), or extensions in the form of features/functionality to enhance the platform (FireFox add-ons), or completely new applications/products using existing foundations (RIM BlackBerry email communication over cell networks). Though open architecture strategy is challenging, it has numerous benefits:

• Enables rich ecosystem of complementary products and services for the customers;
• Provides a method for cost avoidance or cost sharing, enabling the firm to focus on their key competency and differentiation, yet still increasing the value of the product through 3rd party developers;
• Enhances the interoperability of products and solutions;
• Establishes a customer-driven innovation process, increasing the communication and feedback with the customer and marketplace;
• Potentially leads to de-facto standardization of the interface;
• Increases the profit potential of the firm through premium pricing and increased sales volume;

In defining an open architecture strategy, three key areas need to be considered: technical, business and culture.

Technical Considerations

With all its benefits, an open architecture strategy will increase the complexity of your product’s design and use. Performance, security, vulnerability, quality, flexibility, privacy are all issues that need to be thought through and designed into the architecture. Strategies for what parts of the system to expose, how to expose them, what technologies to use for open implementation and how to maintain and manage architecture obsolescence and updates, support integration and interoperation while ensuring high-quality product all need to be incorporated into the development process. Today’s virtual machine technology can go a long way to help manage this complexity and improve stability. Providing a documented virtual machine to your 3rd party developers will allow them to use selected features of your system without jeopardizing the existing software through hacks and patches.

Business Considerations

Business reason should drive the technical decisions on what and how much to expose. Your open architecture strategy requires clear answers to the questions of “what problem are we solving” and “what is important“. As an example, Google recently indicated they are looking to open their Chrome architecture to 3rd party plug-ins in order to increase their market share. Here are a few examples of key business decisions that should be taken into consideration with your open architecture strategy:

• What is the business model around the open implementations?
• How is the licensing structured?
• What is the support model for 3rd party developers and the customers using these solutions?
• What is the most effective organizational structure for managing proprietary architecture and open implementation?
• How is the value proposition changed (for the better) through your open architecture strategy?
• What is the distribution model for 3rd party solutions; how are our customers informed?
• How do we ensure the broad diffusion and adoption of our open architecture?
• How do we differentiate while maintaining/improving our overall competitiveness AND what we DON’T open?

Cultural Considerations

Successful implementation of an open architecture strategy also depends on the culture of your organization. Working collaboratively, listening to 3rd party developers to share knowledge and know-how, demonstrating systems thinking in the design when it comes to revisions, and sponsoring reference implementations are key to building a vibrant 3rd party developer community.

Welcome them in…

Today more than ever, an open architecture strategy is a vital consideration for a product line. The Apple II’s success was in part due to its open architecture, enabling 3rd parties to develop plug-in cards and software applications, which Apple’s competitors at the time lacked. The same strategy could enable Apple TV to expands its iTunes universe, while maintaining the strong end-to-end connectivity.

Finally, as you evaluate your open architecture strategy, keep in mind the following factors that could support or inhibit your success:

• How big is your installed base of users and do you have a good relationship with them;
• Do your business model, licensing and intellectual property rights support the diffusion and adoption of your open architecture;
• Are you enabling yourself and others to innovate on your open architecture;
• Do you have the brand name and reputation the market demands;
• Can your product foster a strong community of complementary services and applications;
• Do you have the manufacturing and distribution capabilities to promote diffusion and adoption;
• Do your culture and resources support the needs of a 3rd party developer community;

Remember, building a product and selling it to your customers is one thing. Enabling (and encouraging) everyone else to make your product better is like adding free resources to your team, resulting in increased appeal to a broader (and more enthusiastic) customer base.

Technorati Tags: open architecture, open implementation