Difference between revisions of "Unification"
(better section zero) |
(forms of unification) |
||
| Line 1: | Line 1: | ||
<noinclude>{{glossary}}</noinclude>[[Unification]] 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 a [[core values|core value]] of [[OrganicDesign]] and is a fundamental "default project" that essentially sums up the process of alignment itself, and could be thought of as "alignment with alignment". | <noinclude>{{glossary}}</noinclude>[[Unification]] 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 a [[core values|core value]] of [[OrganicDesign]] and is a 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. It doesn't matter so much about the actual form of the core as long as its able to achieve these key areas of unification as the majority of the problems that the project is concerned with are a result of these things being fragmented. The theme of unification features so greatly within the spectrum of solution because the problem of fragmentation which is prevalent on our heavily centralised civilisation. | The unifications play an important role in the structure of the solution necessary to solve the larger problems of organisation. It doesn't matter so much about the actual form of the core as long as its able to achieve these key areas of unification as the majority of the problems that the project is concerned with are a result of these things being fragmented. The theme of unification features so greatly within the spectrum of solution because the problem of fragmentation which is prevalent on our heavily centralised civilisation. | ||
| Line 21: | Line 20: | ||
'''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''. | '''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 == | + | === 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. | '''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. | '''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 [[merge|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]], or large power stations being replaced by local solar panel and wind solutions. | ||
| + | |||
| + | More generally speaking the first kind is a fragmentation or disconnection between similar items in a domain, and the second kind is a conceptual difference in the operation of entities in a domain. | ||
== See also == | == See also == | ||
Revision as of 00:21, 3 July 2011
|
Unification is the foundation direction of all Platforms (trust groups that operate to a system that is aligned with the OrganicDesign charter). It is a core value of OrganicDesign and is a 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 necessary to solve the larger problems of organisation. It doesn't matter so much about the actual form of the core as long as its able to achieve these key areas of unification as the majority of the problems that the project is concerned with are a result of these things being fragmented. The theme of unification features so greatly within the spectrum of solution because the problem of fragmentation which is prevalent on our heavily centralised civilisation.
Contents
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 it's solutions in our own systems. Bruce Liptons 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, or large power stations being replaced by local solar panel and wind solutions.
More generally speaking the first kind is a fragmentation or disconnection between similar items in a domain, and the second kind is a conceptual difference in the operation of entities in a domain.
