Difference between revisions of "Platform specification"
m (→Platform use for self organisation: add link, enter notes later) |
m |
||
(9 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | The [[platform specification]] document is a [[specification]] for [[OrganicDesign]] (which is a [[trust group]]) so that it's [[member]]s may engage in an ongoing process of [[alignment]] with its [[OrganicDesign vision|vision]] and core documents. The overall result of aligning with this specification is for the organisation or group to form into a [[platform]], and for all the platforms to form into a global [[platform network]] allowing our civilisation to [[self governance|self govern]] as a single organism achieving its [[shared vision]] in a sustainable manner which looks after the well-being of itself and all its members.<noinclude> | + | The [[platform specification]] document is a [[specification]] for [[OrganicDesign]] (which is a [[trust group]]) so that it's [[member]]s may engage in an ongoing process of [[alignment]] with its [[OrganicDesign vision|vision]] and core documents. The overall result of aligning with this specification is for the organisation or group to form into a [[platform]], and for all the platforms to form into a global [[platform network]] allowing our civilisation to [[self governance|self govern]] as a single organism achieving its [[shared vision]] in a sustainable manner which looks after the well-being of itself, its environment and all its members.<noinclude> |
{{section zero|OrganicDesign}} | {{section zero|OrganicDesign}} | ||
{{section zero|Platform}} | {{section zero|Platform}} | ||
Line 17: | Line 17: | ||
Getting more specific and viewing the software architecture from a perspective of milestones and tasks and effort involved, the [[platform roadmap]] then outlines a sequence and methodology for our ideas around implementation. This focuses on core technologies to create a functional platform in alignment with our design principles. There are a number of related projects which can then further expand on this foundation and provide further functionality or value-added services. Such projects can be negotiated between the peer group and interested parties on a case by case basis, including financial arrangements. | Getting more specific and viewing the software architecture from a perspective of milestones and tasks and effort involved, the [[platform roadmap]] then outlines a sequence and methodology for our ideas around implementation. This focuses on core technologies to create a functional platform in alignment with our design principles. There are a number of related projects which can then further expand on this foundation and provide further functionality or value-added services. Such projects can be negotiated between the peer group and interested parties on a case by case basis, including financial arrangements. | ||
− | == | + | === MVP === |
− | + | {{quote|A minimum viable product (MVP) helps entrepreneurs start the process of learning as quickly as possible. It is not necessarily the smallest product imaginable, though; it is simply the fastest way to start learning how to build a sustainable business with the minimum amount of effort. | |
− | + | Contrary to traditional product development, which usually involves a long, thoughtful incubation period and strives for product perfection, the goal of the MVP is to begin the process of learning, not end it. Unlike a prototype or concept test, an MVP is designed not just to answer product design or technical questions. Its goal is to test fundamental business hypotheses. | |
− | + | The lesson of the MVP is that any additional work beyond what was required to start learning is waste, no matter how important it might have seemed at the time.|http://techcrunch.com/2011/10/19/dropbox-minimal-viable-product/}} | |
− | + | == Technology independent description == | |
+ | As stated above, the specification must be complete and technology independent so that any variety of technological environments can have documents written to support the common specification. | ||
− | + | For example our [[software architecture]] document describes implementing the Platform specification in the context of our own Linux web-desktop operating system [[package]]d with all the software applications and documented [[procedure]]s necessary to fully support users to operate together as a Platform. Using a technology independent approach to the specification makes it possible to replace any part of the package with alternative solutions and update the configuration and procedures to allow this replacement to be a new option for people to select from. Such options may include variations of operating system its running within, different project management applications and different selections of documentation aimed at specific industries. | |
− | |||
− | + | This technology independent approach also means that a group of people could begin working as a platform without the use of computers and this specification would describe completely everything they need to do to work in [[alignment]] with all other platforms and for a [[platform network]] together that moves toward an aligned global vision as a single holistic organism. | |
− | + | A technology independent description can still refer to things like documents, forms, records, requests, reports, events and messages without needing to refer to any concept about IT, computer hardware, operating systems or software packages. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | The specification is divided into two sections, one for the [[Platform specification/architecture|architectural perspective]] which covers the functional aspects of a platform, and one describing the platform from the [[Platform specification/use cases|member's perspective]]. | |
− | |||
− | |||
− | |||
− | |||
− | ==== | + | == Current technologies == |
+ | === Singly === | ||
+ | *http://singly.com/ | ||
− | + | This sounds pretty similar to the Platform, for example the clean and unified interface sitting on top of multiple data sources. This is backed by some key open source people and they have got the right idea: | |
− | This | ||
− | |||
− | |||
− | + | {{quote|You make data. A lot of it. From Web browsing to link sharing to photos published online, from phone bills to medical records to online banking - almost all of us produce an incredible amount of electronic data that slips right through our fingers - often into the gaping maw of a corporate world without our best interests in mind. What if you could easily capture all that data yourself, though? What if you could use it like fuel for apps built for you to view, sort and take action based on all that data?|http://www.readwriteweb.com/archives/singly_platform_launch.php}} | |
− | |||
− | + | Now if only the "apps" were thought of as emergent organic groups based on preferences and usage patterns... | |
− | |||
− | == | + | == Subpages making up the specification == |
− | + | {{#dpl:titlematch=Platform specification/%|notnamespace=Talk}} | |
− | |||
− | |||
− | {{ | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== See also == | == See also == | ||
Line 109: | Line 53: | ||
*[[OrganicDesign]] | *[[OrganicDesign]] | ||
*[[Spontaneous Evolution]] | *[[Spontaneous Evolution]] | ||
− | [[Category:Documents]] | + | [[Category:Documents]][[Category:Platform]] |
</noinclude> | </noinclude> |
Latest revision as of 18:36, 16 April 2014
The platform specification document is a specification for OrganicDesign (which is a trust group) so that it's members may engage in an ongoing process of alignment with its vision and core documents. The overall result of aligning with this specification is for the organisation or group to form into a platform, and for all the platforms to form into a global platform network allowing our civilisation to self govern as a single organism achieving its shared vision in a sustainable manner which looks after the well-being of itself, its environment and all its members.
The platform specification serves as a high-level technology-independent organisational system description. It's intended that it be a complete description of what it means to be a platform, and as such is the general document that is used as a starting point for more specific documents such as the software architecture which covers use-cases, technology decisions for how software can be developed to be support a platform. All system related concepts such as procedures and best practices are also directed by this specification.
Each trust group may have its own more specific and refined specification, but this document is the specification that OrganicDesign aligns to and serves as a default to help other organisations and groups better align to the common global vision of the planet operating as a single organism as described admirably in Bruce Lipton's book Spontaneous Evolution. These common global ideals are discussed in more detail in the OrganicDesign charter, manifesto, values and OrganicDesign vision.
Contents
Methodology
In developing the platform specification we will be observing and documenting common organisational activities and processes at different scales of operation from personal, to group, to organisation and beyond. While we do this we will create a description of a system architecture and interface (including screen mock-ups) that can support those activities.
Using this specification, we will continue to develop a functional prototype system for running platforms, which we will use to work together as a team at Organic Design. Currently we are evaluating the Drupal content management system using the open atrium and storm modules to replicate what we are describing here.
In the software architecture article we are describing the qualities required by the ideal implementation of platform specification, including software language used and an overview of functional requirements. The software architecture article answers the question of how we intend to implement the specification when we have access to the resources to build a system from scratch.
Getting more specific and viewing the software architecture from a perspective of milestones and tasks and effort involved, the platform roadmap then outlines a sequence and methodology for our ideas around implementation. This focuses on core technologies to create a functional platform in alignment with our design principles. There are a number of related projects which can then further expand on this foundation and provide further functionality or value-added services. Such projects can be negotiated between the peer group and interested parties on a case by case basis, including financial arrangements.
MVP
A minimum viable product (MVP) helps entrepreneurs start the process of learning as quickly as possible. It is not necessarily the smallest product imaginable, though; it is simply the fastest way to start learning how to build a sustainable business with the minimum amount of effort.
Contrary to traditional product development, which usually involves a long, thoughtful incubation period and strives for product perfection, the goal of the MVP is to begin the process of learning, not end it. Unlike a prototype or concept test, an MVP is designed not just to answer product design or technical questions. Its goal is to test fundamental business hypotheses. The lesson of the MVP is that any additional work beyond what was required to start learning is waste, no matter how important it might have seemed at the time. | |
— http://techcrunch.com/2011/10/19/dropbox-minimal-viable-product/ |
Technology independent description
As stated above, the specification must be complete and technology independent so that any variety of technological environments can have documents written to support the common specification.
For example our software architecture document describes implementing the Platform specification in the context of our own Linux web-desktop operating system packaged with all the software applications and documented procedures necessary to fully support users to operate together as a Platform. Using a technology independent approach to the specification makes it possible to replace any part of the package with alternative solutions and update the configuration and procedures to allow this replacement to be a new option for people to select from. Such options may include variations of operating system its running within, different project management applications and different selections of documentation aimed at specific industries.
This technology independent approach also means that a group of people could begin working as a platform without the use of computers and this specification would describe completely everything they need to do to work in alignment with all other platforms and for a platform network together that moves toward an aligned global vision as a single holistic organism.
A technology independent description can still refer to things like documents, forms, records, requests, reports, events and messages without needing to refer to any concept about IT, computer hardware, operating systems or software packages.
The specification is divided into two sections, one for the architectural perspective which covers the functional aspects of a platform, and one describing the platform from the member's perspective.
Current technologies
Singly
This sounds pretty similar to the Platform, for example the clean and unified interface sitting on top of multiple data sources. This is backed by some key open source people and they have got the right idea:
You make data. A lot of it. From Web browsing to link sharing to photos published online, from phone bills to medical records to online banking - almost all of us produce an incredible amount of electronic data that slips right through our fingers - often into the gaping maw of a corporate world without our best interests in mind. What if you could easily capture all that data yourself, though? What if you could use it like fuel for apps built for you to view, sort and take action based on all that data? | |
— http://www.readwriteweb.com/archives/singly_platform_launch.php |
Now if only the "apps" were thought of as emergent organic groups based on preferences and usage patterns...