Section 8.3. The Real Business Model

8.3. The Real Business Model

Customers view solutions as a network of related "bits" that have to come together in some definable fashion to solve their IT problems. This network can be defined with nodes representing various technology objects and the paths between nodes representing the relationships. This is a very informal network, but very real. For example, a solution for a new retail inventory management system will include nodes representing the existing application systems to which the new retail system must interface, computer resources on which it will run, the programming language environment in which it will be developed and maintained, the staff and their experience and skill sets that will develop and then maintain the new system, databases with which it will need to interact, . The other application systems to which the new retail inventory system will need to interface have their own historical networks. The platform resources may represent a different network view if multiple application systems share the fundamental computing platform. Companies define architectures for their IT functions to attempt to simplify the decisions that need to be made, and often publish these as internal procurement and development standards. History also counts in the networkfor example, some shops always buy "Unix" hardware or always program in C or Java, because that is how their resource history has developed.

Turning the discussion around to the vendor-centric product perspective, Geoff Moore defined a model^[8] in 1991 for technology adoption that suggests that once a market starts to develop, a company best leads by providing a customer the best "whole product solution." By this he means that the vendor offers its core value product proposition to the customer and then needs to wrap as much around that product as it can to present a "complete" product solution to the customer to meet the customer's broader needs, essentially mapping as much of the customer solution network as possible. Another way to think about this is that the vendor wants to provide as many complements as it can to its core product offering, covering as much of the customer's solution network as is feasible to present the best (most valuable) solution in the customer's eyes.

^[8] Geoffrey Moore, Crossing the Chasm (New York: Harper Collins, 1999).

The business of a vendor would then be to ensure that the complements were as inexpensive as possible, indeed commoditized if possible, so that the whole solution, from the customer's perspective, is as inexpensive as possiblebut the lion's share of the revenue would come to the vendor through its core offering. Several business tactics and tools are available to the vendor to try to drive these complement spaces:

• Traditional buy-versus-build strategies can be used to ensure that as much as of the customer's solution is provided through the vendor's own brand, regardless of whether the complement products are offered as add-ons or are bundled directly with the core revenue stream.

• Develop a rich ecosystem of add-ons by encouraging developer and partner networks to provide a richer whole solution to the customer. Publishing proprietary specifications for the complement space enables more partners to develop businesses in the complement spaces.

• Develop tool spaces that help add complements to the complement ecosystem.

• Provide certification programs around the core technology to ensure that there are lots of service professionals to help the customers complete and support their solution. Indeed, a company might have its own consulting services arm for parts of a solution, and provide certifications for other parts of a solution.

Taking this view, a company's assets and offerings also form a network of related products and services it matches against the customer's solutions network through the sales and marketing functions. Each node in the network has cost, risk, and revenue models associated with it, and as long as the overall revenue model is greater than the sum of the costs, the company will be profitable.

It is important to remember, however, that no company exists alone in the market to solve the customer's problems. Each vendor in a particular space must have different product networks to allow a differentiation in its sales pitch to the customer. Different vendor companies will also behave differently in their hiring and acquiring strategies to shore up their "whole product offerings."

In addition, it is important to note that one can now look at intellectual property (IP) tools (and by that I mean trademarks, patents, copyrights, and trade secrets) in context. Each of these four legal property types or tools (regardless of legal and geographical jurisdiction) provides a different set of legal protections at different costs. One is far more likely to spend heavily and strategically with IP protection tools in the spaces defining one's core product value proposition or in spaces in which one has the greatest investment, than farther out in the complement spaces of one's product offering network. Indeed, in the complement spaces, a vendor may aggressively publish (or sparingly strategically patent) to ensure that no other vendor can patent in the complement space and raise the prices on that complement.

If we now start to consider open source and open standards in this core-complement context, we see that they are simply additional tools in the tool chest to drive complement spaces. Let's look at each separately for a moment.