Difference between revisions of "Unification"
(→Forms of Unification: rm confusing dichotoy stuff, add political example) |
Infomaniac (talk | contribs) m |
||
| Line 1: | Line 1: | ||
| − | <noinclude>{{glossary}}</noinclude>{{value|Unification}}. It is the foundation [[direction]] of all [[Platform]]s ([[trust group]]s that operate to a [[system]] that is [[alignment|aligned]] with the [[OrganicDesign charter]]). It is the fundamental "default project" that essentially sums up the process of alignment itself, and could be thought of as "alignment with alignment". | + | <noinclude>{{glossary}}</noinclude>{{value|Unification}}. It is the foundation [[direction]] of all [[Platform]]s ([[trust group]]s that operate according to a [[system]] that is [[alignment|aligned]] with the [[OrganicDesign charter]]). It is the fundamental "default project" that essentially sums up the process of alignment itself, and could be thought of as "alignment with alignment". |
<noinclude> | <noinclude> | ||
| − | The unifications play an important role in the structure of the solution necessary to solve the larger problems of organisation. | + | The unifications play an important role in the structure of the solution that is necessary to solve the larger problems of organisation. The actual form of the core doesn't matter so much as long as it is able to achieve these key areas of unification, as the majority of the problems that the project is concerned with are a result of their fragmentation. The theme of unification features so greatly within the spectrum of solutions because of the problem of fragmentation that is prevalent on our heavily centralised civilisation. |
== The bottom line == | == The bottom line == | ||
Revision as of 19:19, 21 September 2011
|
Unification is one of the values of OrganicDesign (the Platform specification includes a process of alignment with it). It is the foundation direction of all Platforms (trust groups that operate according to a system that is aligned with the OrganicDesign charter). It is the fundamental "default project" that essentially sums up the process of alignment itself, and could be thought of as "alignment with alignment".
The unifications play an important role in the structure of the solution that is necessary to solve the larger problems of organisation. The actual form of the core doesn't matter so much as long as it is able to achieve these key areas of unification, as the majority of the problems that the project is concerned with are a result of their fragmentation. The theme of unification features so greatly within the spectrum of solutions because of the problem of fragmentation that is prevalent on our heavily centralised civilisation.
Contents
The bottom line
Organisations (and organisms) evolve in response to changes in their environment, such as changes in supply or demand of resources and materials and changes in knowledge, but an important factor determining the nature of change that takes place in an organisation depends on how it assesses the benefit of options available to it in terms of changes to its behaviours that it could choose to accept or reject.
This "measuring stick" that determines what's beneficial and what isn't, and how beneficial or damaging something is, often gets referred to as the bottom line, and is the ultimate determinant of which concepts survive. The most common bottom line we see in our civilisation today is the economic bottom line, which means that most decision-making processes are benefiting the planet only indirectly, if at all. The Organic Design system is instead based on the bottom line of harmony.
Specific OrganicDesign unification efforts
Organisation & Organism: One of the most fundamental and all-encompassing aspects of unification in this project is the push for the architecture of our system to look to nature and the biological system as an example and to mimic its solutions in our own systems. Bruce Lipton's book Spontaneous Evolution sums up our perspective on this aspect admirably and we consider it a must-read book for understanding this aspect.
East & West: Using western technology and systems-thinking to implement the eastern "physics" model of conceptual-space as described in Taoism, Advaita Vedanta and others.
Work & Life: Using the principles of Self Organisation, the personal goals and progress can make use of the same productivity methods and tools as business and project oriented organisations.
User & Developer: The application undergoes change from use and changing the way any aspect works is achieved from within the same content environment as the users of the application are operating in. This can also be seen as a unification of runtime into a single persistent space of objects. And also can be seen as a unification of application & content, by defining the application using the same generic components as all organisations, the application-development role merges with the content-management role. The collaborative network content ranges from passive information to active applicational content.
Software & Organisation: By defining the application in terms of generic organisation we unify the IT world with the Human world, reducing dependency on specialisation.
Client & Server: Operating as a peer-to-peer network means having no distinction between a client computer and a server; all nodes in the network are running the same software which performs as either role dynamically in response to the changing network topology.
RAM/Disk/Network: The same tree (of instances) is unified across all mediums, unifiying the runtime object environment with the filesystem structure and further to the network and Internet. This has the advantage of allowing peers to operate primarily from ram-based caches. Few applications support inherent memory-based operation due to complication of implementation within the fragmented environment (some vendors do like Panorama and OLAP). A similar solution is memcached which acts as a large shared hash table for caching database and function results in RAM, but this is still far less efficient than the nodal method because it requires serialise/deserialise operations on the data to preserve it across the fragmented run-time sessions.
Class & Instance: a.k.a Instance-based or prototype-based - instances are based on other instances, so class and instance become dynamic, relative relationships. This is also the unification of the is and has relations into only has.
Software architectural unifications
Inputs: All text input and output, and practically all widgets are based on the generic WYSIWYG-textarea which depending on its attributes can appear as textboxes, editboxes, listboxes, buttons, links and icons.
Lists: Another generic "widget" is the List which depending on its context can appear as inbox, spreadsheet, recentchanges, history, search/query and schedule.
Forms of Unification
After being involved with a number of unification-oriented projects and coming across many more conceptually in many domains from quantum physics to biology to spirituality we've noticed that there are two main forms of unification which take place.
The first and simplest kind is where there is a lack of communication between entities that results in the same thing being implemented a number of different ways. For example, a number of conflicting DVD standards, or people reinventing the wheel. This kind of fragmentation is easy to spot, but is often hard to resolve as it's usually being held in place by vested interests in one way or the other. In the open source world there is no such obstacle and so unification is achieved by merging the diverse projects, or agreeing on a common standard.
The second kind is where there is an unnecessary hierarchy in place that could be unified using bottom-up organisation, for example the centralised web-server system being replaced by peer-to-peer, large power stations being replaced by local solar panel and wind solutions, or a single person or minority group making decisions for the many.
