Peers
In peer-oriented systems, a node is a considered a 'peer' when it is both a consumer AND a producer. In a network, it is advantageous to have nodes not only consume value from the network, but also produce value back to the network. The more producers on a network, the more valuable the network is for consumers.
Non-Recombinant Systems
Traditional applications were often designed whereby the ultimate consumer was hard-coded at design time, and that consumer would be a human - and the vehicle would be some kind of graphical rendering. This is most likely a tradition held over from mainframe and client/server days. Today, many systems continue to fall victim to the same design center. Architects continue to assume that the data or functions would never be needed by anyone but a human and that whatever tool they built would be the final tool for consumption. In essence, the designers failed to anticipate future consumption scenarios that may have been out of scope of the 'Use Cases' that they built their system for.
Recombinant Systems
When an application is designed so that its functions or data can be discovered and used, we say that the application is 'highly recombinant'. This means that the services that are offered can:
1. Easily be found (often on the screen that used them) and
2. Easily be called (the barrier to usage is low).
Applications that are highly recombinant offer the potential for reuse, or sharing. These applications do not assume to know the future uses of the functions or data. The fundamental notion is that the true uses of the functions/data will not be known until after the system is put into production.
Exposing Functions and DataAs we move into a service oriented world, we have the potential of serving up two interfaces: one for human consumption (the screen) and one for machine consumption (the service).
The key is to make sure that the people who use the systems can easily gain access to the services. As an example, it is common for Blogs to identify their feeds via the classic RSS image:
. Just as easily, we can tag our more structured SOAP services with the WSDL image: 
. Publishing and advertising consumption scenarios must become second nature for organizations that wish to leverage the advantage of recombinant applications. 
YOU WILL EAT CARROTS!
Architect - "You will eat carrots!"
User - "But I want coleslaw..."
Architect - "You will eat cabbage!"
User - "But I want coleslaw..."
Enterprises and SaaS vendors must not only acknowledge that we are moving into an era of recombinant platforms but they must also take the necessary steps to enable the mashups, remixes, composite applications or whatever you want to call them. The future of software is about the creation and utilization of building blocks. It is about letting our users play with their Lego's. It is about allowing them to make coleslaw from their carrots and cabbage. It is about productivity and creativity. We do it for a few reasons: it lowers new software development costs, significantly reduces maintenance expenses, while simultaneously gives the users what they wanted.
You can have your carrots and coleslaw too.
