|
|
| Line 24: |
Line 24: |
| | 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. | | 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 user's perspective. | + | 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|user's perspective]]. |
| | | | |
| − | === Platform use === | + | == Subpages == |
| − | In describing how platform is used, we are in essence describing a method for systematic organisation on a personal, group and societal level. The fundamental assumption we make is that individuals or groups are striving toward the achievement of goals and visions and are using a systematic approach to achieve them. We will attempt to describe clearly the activities and procedures individuals or groups engage in when working toward goals using a system, as well as what is needed to coordinate the activities of multiple groups forming societies or institutions.
| + | {{#dpl:titlematch=Platform specification/%}} |
| − | | |
| − | Even though we will describe these things in a technology-neutral way, these usage scenarios can form the basis of [http://www.bridging-the-gap.com/moving-from-an-epic-to-a-user-story-in-an-agile-product-backlog/ "epics" and "stories"] that are used in agile software development. This will aid our efforts to develop software that is compliant with the platform specification. software-specific considerations such as interface layouts and networking technology is described in our [[software architecture]] article.
| |
| − | | |
| − | ==== Platform use for self organisation ====
| |
| − | Our entry point to using a platform is naturally the perspective of the individual user and the activities people engage in to get work done, be it for private or business affairs. We refer to the systematic approach for pursuing these activities as "[[self organisation]]". Other terms commonly used for this process are personal organisation or self-management: {{quote|In [[W:business|business]], [[W:education|education]], and [[W:psychology|psychology]], self-management refers to methods, skills, and strategies by which individuals can effectively direct their own activities toward the achievement of [[W:Objective (goal)|objective]]s, and includes [[W:goal setting|goal setting]], [[W:decision making|decision making]], [[W:focusing|focusing]], [[W:planning|planning]], [[W:scheduling|scheduling]], task tracking, self-[[W:evaluation|evaluation]], self-intervention, [[W:personal development|self-development]], etc. Also known as ''executive processes'' (in the context of the ''processes of execution'').|Wikipedia, [[W:Self-management|Self-management]]}}In software terms, applications that support these activities go under the umbrella term "[[W:Personal information manager|PIM tool]]" - '''P'''ersonal '''I'''nformation '''M'''anagement tool.
| |
| − | | |
| − | ==== Personal organisation methodology ====
| |
| − | Two of the leading approaches for how to go about self organisation are ''principle-based'' and ''productivity-based''. The difference is which area of life they use as a starting point. Principle-based methods focus on defining personal high level goals,vision and principles (or habits). A popular example of this approach is Stephen Covey's "[[W:The Seven Habits of Highly Effective People|The Seven Habits of Highly Effective People]]". By maintaining a small number of specific habits, Covey maintains, people can achieve a balanced life and enjoy success. He does not cover in any great detail how to organise daily activities, projects or to-do lists.
| |
| − | | |
| − | Productivity-focused self organisation, in contrast, is about helping people organise the "stuff" in their lives: the projects they are involved with in private and professional life, tasks, appointments, in-boxes, filing systems, etc. Only after these things have been organised into a coherent, trusted system is the work on high level goals and values introduced. One of the leading thinkers in this area is David Allen, who pioneered the "[[W:Getting Things Done|Getting Things Done]]" system for self organisation.
| |
| − | | |
| − | There has been an increasing uptake of the productivity-based approach in the past decade, particularly GTD, possibly because it tackles a challenging aspect of modern life - information and work overwhelm. Among an increasing global population that earns its keep with [[W:Knowledge worker|knowledge work]], there is also growing demand for ways to increase productivity and free the mind of unnecessary clutter. In theory, having achieved productivity and a clear mind, one is then free to turn to defining high level goals, developing quality relationships and cultivating positive habits - all of those important, but not urgent activities that tend to fall by the wayside when life gets busy.
| |
| − | | |
| − | GTD specifically is also quite aligned with OrganicDesign thinking due to the fact that it is a systems-based approach (Allen often refers to the goal of GTD being the creation of a "trusted system") and also introduces the idea of "scale" to be able to encompass the most abstract and long term aspects of self organisation, such as goals, vision and values. On regular cycles, practitioners review the relationship between everyday activities and high level goals and ensure that there is clear sense of connection between the two. Therefore GTD as an approach conceptually incorporates the notions of both ''systems thinking'' and ''personal mastery'' advocated by Peter Senge as two of the disciplines required for creating learning organisations.
| |
| − | | |
| − | *Setup
| |
| − | *Direction and administration
| |
| − | *Communications
| |
| − | *Finance
| |
| − | | |
| − | ==== Group platform ====
| |
| − | Activities and processes for group activities
| |
| − | *Setup - group formation and membership
| |
| − | | |
| − | ===== Governance =====
| |
| − | *Group decision making
| |
| − | *TIPAESA
| |
| − | *Direction and administration
| |
| − | *Communications
| |
| − | *Finance
| |
| − | | |
| − | ===== Setup & deployment =====
| |
| − | *Organisation
| |
| − | *Member
| |
| − | | |
| − | ===== Roles & responsibilities =====
| |
| − | | |
| − | ===== Procedures & practices =====
| |
| − | | |
| − | ===== Documentation =====
| |
| − | | |
| − | ===== Scheduling =====
| |
| − | *Notifications
| |
| − | *Shared
| |
| − | *Resource booking
| |
| − | *System (roles, people, processors)
| |
| − | | |
| − | ===== Forms & records =====
| |
| − | *Reports
| |
| − | | |
| − | ===== Trading =====
| |
| − | *Payment methods
| |
| − | *products and services
| |
| − | *subscriptions
| |
| − | *invoices
| |
| − | | |
| − | ==== Platform Network ====
| |
| − | | |
| − | === Platform architecture ===
| |
| − | This is the architecture of the [[system]] that platform [[member]]s work within. The [[trust group]] is the concept which forms the foundation of what a platform actually is.
| |
| − | {{section zero|trust group}}
| |
| − | But more specifically, the group doesn't have just [[member]]s, but also is a collection of [[resource]]s such as documents, [[procedure]]s and tools all working together [[alignment|in accord]] with a [[system]] to become an [[organisation]], the details of which are defined in this specification.
| |
| − | | |
| − | ==== Portals & structure ====
| |
| − | Each of the items mentioned above have a [[portal]] for the members to organise and govern these resource together, usually with the aim of achieving a [[shared vision]]. The portal acts as an entry point for the members to collaborate together on knowledge and tools so that they can engage in [[group decision-making]] and [[self governance]] together. Since the groups can be further divided within into a hierarchy of trust-groups, it follows that all the groups forming this internal structure should work the same way and therefore also act as portals of organisation and governance.
| |
| − | | |
| − | ==== Alignment to values ====
| |
| − | We must ensure in our [[system]] design the [[alignment]] with our [[values]] so that all Platforms based on it always [[evolution|evolve]] toward a more and more aligned [[direction]] over time. Alignment is not just statements made that "we promise to care about this and that", alignment to something is a [[process]], it needs to actually exist as part of the system so that work is performed on a regular basis that ensures that the [[direction]] of the organisation really is maintaining alignment consistently throughout time with what it says it is. To really achieve this we must look carefully at the mechanism we're creating with our system description to see what its [[bottom line]]s really are; whether it will still be maintaining alignment to these values some time after it's been set free into the [[economic bottom line]] environment which is hostile to it. So we define here a structure which is primarily aimed at supporting this alignment, the top-level categorisation of our system is into [[department]]s.
| |
| − | | |
| − | ==== Platform departments ====
| |
| − | We're initially basing the departments on Thomas Robertson's "seven great mechanisms" described in his 1948 book [[Human Ecology]]. This is not to say that these departments need to be fixed to number seven, or that they should be the same names or same amount of them at different [[scale]]s of operation. These details can [[evolution|evolve]] through [[self governance]] just as [[all aspects changeable|all aspects can change]]. But the two key ideas here are:
| |
| − | *We start with departments that we know can cater for the needs of the global scale of operation
| |
| − | *We ensure that the principles of their operation remain consistent across all scales even if their names change or they [[split]] into more or [[merge]] into less of them in different scales of operation or specificity.
| |
| − | {{section zero|Direction department}}
| |
| − | {{section zero|Management department}}
| |
| − | {{section zero|Networking department}}
| |
| − | {{section zero|Administration department}}
| |
| − | {{section zero|Alignment department}}
| |
| − | {{section zero|Production department}}
| |
| − | {{section zero|Trading department}}
| |
| | | | |
| | == See also == | | == See also == |
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 and all its members.
Self governance: When a
trust group collaborate on their
shared vision and work together to actualise it in
alignment with their defined
values, they need to have methods and tools available for
making decisions together,
resolving conflicts and
managing resources in their
system.
Self governance is the ability for a
trust group to do these things without requiring any external parties, and in general, is how a group's system can undergo change in response to feedback from its
members and
stakeholders and from changes in the environment it operates within.
The
manifesto to which
Organic Design is
aligned follows the bottom-up principle that organisation at the global scale is achieved by organisation beginning with individuals and local regions, rather than being determined from larger centralised institutions downwards. From this global context, self-governance in alignment with the
values allows the best known options to be found and selected for all aspects of the social mechanism. This is achieved by making more effective, unhindered use of the totality of available knowledge and expertise.
[more]
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.
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.
The specification
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.
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 user's perspective.
Subpages
See also
