Open Parenthesis

In the spirit of (and heavily inspired by) the original Cluetrain Manifesto and the recent 10th anniversary edition, I offer the following definition and 10 principles of what we at Optaros have been calling the Assembled Web.

The Assembled Web is not experienced as a set of discrete web applications and sites, neatly separated from each other and organized into categories: it’s an indiscriminate field of content, functionality, and people interacting in multiple contexts and in unpredictable ways: like life.

New web applications are assembled from other projects/applications/frameworks/services, sometimes on the server, sometimes in the browser, sometimes in the cloud. People’s accounts, identities, and networks come with them across sites, applications, and contexts.

How should enterprises not only come to grips with this bewildering confusion but thrive in it?

By embracing the assembled web and participating fully in it.

Assembled Web First Principles:

1. You should always be thinking multi-site, multi-interface, multi-project. If you think you will (always) only have one interface to any given set of content of functionality, you’re mistaken, and you will paint yourself into a corner.
2. Success on the web is no longer (if it ever really was) about driving traffic to your site, or keeping eyeballs there once they arrive. It’s about engaging audiences everywhere they already are. It’s about improving the size, quality, and velocity of your “digital footprint.” Ubiquity is the target, not exclusivity. The danger is not that people will say bad things about you but that you will be ignored.
3. Your brand is not what you say it is, but what your prospects, customers, partners, and employees say it is. In short, your brand is what the Internet says it is. You influence this not through marketing but through creating appropriate experiences and getting users exposed to those positive experiences. (Micro-interactions are ultimately assembled into and become brands).
4. Design is critical, and design is not about pretty shiny objects. It’s about usable interfaces, in the sense of traditional HCI (Human Computer Interface) design, visual design, and technical design. Creating usable experiences for users and usable projects for developers are both essential, and to ignore either is to invite failure.
5. The internet itself, like the *nix operating systems on which it (almost entirely) runs, is a set of small pieces loosely joined. Every project you do must be composed of smaller discrete components communicating with each other. The corollary is that every project you do must also be composeable or consumable by other projects – including projects you know nothing about. This is true across multiple projects (within your organization and outside it) as well as over time within a given project.
6. The difference between “behind the firewall” and “out in the cloud” is trending toward zero. Same for the difference between employees and contractors, customers and prospects, competitors and partners. If you’re still thinking in terms of intranet, internet, and extranet, remember that the difference between them is (from a technology point of view) entirely arbitrary. What differentiates them is business processes and decisions.
7. There is no defensible reason to invent a proprietary standard wherever an open standard exists. In fact, even where no open standard exists, great efforts should be extended to create one, rather than implement a proprietary version.
8. Working in isolation from the rest of the internet is inherently limiting and dangerous. This is true whether you’re a one-developer shop or a 5000 developer IT department in a Fortune 100 company. Collaborative engineering with appropriate participants (which almost always means open source licensing arrangements) is required. Why continue to work alone now that the Internet exists?
9. Consumer Technology is beating Enterprise IT, and soundly. If your “in-house” IT can’t compete with a consumer-grade provider available “on the web” you need to catch up and compete or concede the function.
10. Small incremental releases are essential. It isn’t just a question of not putting too many eggs in one basket – it’s also about lowering the cost of failure and therefore raising the level of innovation. Don’t accept quarterly releases of functionality, or even monthly. Web applications should change hourly or at least daily. The web is live, not pre-recorded.