82,985
edits
End-to-end principle: Difference between revisions
no edit summary
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| Line 24: | Line 24: | ||
The classic example is of course the [[internet]] itself. At its most basic layer, it is a series of connected notes using the [[TCI/IP protocol]] and packet switching to which takes any type of data (text, video, audio etc) breaks it into tiny homogenous “packets” and sends them off across the network with an address, and the client at the receiving end reassembles them. There are all kinds of additional layers in it, be they walled gardens (Facebook etc) streaming services (Netflix), cloud servers and what not. Even as the fortunes of these services and gardens wax and wane (where are they now, AOL and MySpace) the un-owned internet grows ever stronger. | The classic example is of course the [[internet]] itself. At its most basic layer, it is a series of connected notes using the [[TCI/IP protocol]] and packet switching to which takes any type of data (text, video, audio etc) breaks it into tiny homogenous “packets” and sends them off across the network with an address, and the client at the receiving end reassembles them. There are all kinds of additional layers in it, be they walled gardens (Facebook etc) streaming services (Netflix), cloud servers and what not. Even as the fortunes of these services and gardens wax and wane (where are they now, AOL and MySpace) the un-owned internet grows ever stronger. | ||
==Design== | ==Design== | ||
===Systems theory=== | |||
{{quote|We don’t want to sell you Life Insurance . . we want you to know and have ''what life insurance will do''. A 1/4 million drills were sold last year: no one wants a [[drills and holes]]. What they want is the hole. | |||
:—The ''Manhattan Mutual Life Company'' advertisement, Manhattan Kansas, 1946}} | |||
A new tool is not an end-goal in itself but a means to improving an existing [[Systems theory|system]] to create a certain output. In figuring out how to improve that system bear in mind the stocks, flows and feedback loops already in that system: these are what you need to influence; your machine needs to influence them. So bear in mind: | |||
*Systems will have developed in a certain way for a reason. Most likely, lots of reasons. Not all the reasons will be good ones (in any [[Agency problem|agency]] scenario the hard to persuade an entrenched agent that she her role in the revised system should change — she has invested her capital in getting to where she is, and will not want to give up that capital, nor control over that position. If her role in the revised system will be deprecated — will change for the worse — it will be impossible to persuade her to adopt the new system. Why should she? | |||
But no participant in the system has a monopoly on it. If the system appears to necessitate such a behaviour change: to oblige someone to embark on a new journey that they don’t control, the better approach might be to leave that agent in situ, as it, but give other participants in the system an alternative route to achieving their goal. In the [[digital commons]] this is particularly easy to do. This way you have changed the dynamics of the ''remainder'' of the system in a way that obliges the agent in question to change her approach. | |||
Take the arrival of email. Had its success criteria involved shutting down the physical email system first, and replacing it with email — obliging people to buy the computer equipment and networks needed before a single switch-over day, it would never happen. | |||
===Do this=== | ===Do this=== | ||
This design principle has a number of advantages, especially in the digital commons where issues of physical property and the tragedy of real commons don’t apply: | This design principle has a number of advantages, especially in the digital commons where issues of physical property and the tragedy of real commons don’t apply: | ||