Platform specification
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.
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.
Platform use
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.
Even though we will describe these things in a technology-neutral way, these usage scenarios can form the basis of "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:
 | In business, education, and psychology, self-management refers to methods, skills, and strategies by which individuals can effectively direct their own activities toward the achievement of objectives, and includes goal setting, decision making, focusing, planning, scheduling, task tracking, self-evaluation, self-intervention, self-development, etc. Also known as executive processes (in the context of the processes of execution). |
| — Wikipedia, Self-management |
In software terms, applications that support these activities go under the umbrella term "PIM tool" - Personal Information Management tool.
There are two main entry points to self organisation: Bottom-up and top-down. The difference is which area they focus on, whereby top-down methods focus on defining high level goals,visions and principles and use those as a starting point to allow people to organise themselves. A popular example of this approach is Stephen Covey's "The Seven Habits of Highly Effective People". Bottom-up self organisation in contrast focuses on 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 structure is the work on high level goals and values introduced. One of the leading thinkers in this area is David Allen, who pioneered the "Getting Things Done" system for personal organisation.
The platform will support both approaches, while incorporating all of the concepts generally used in personal organisation.
- 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 members work within. The trust group is the concept which forms the foundation of what a platform actually is.
But more specifically, the group doesn't have just members, but also is a collection of resources such as documents, procedures and tools all working together in accord with a system to become an organisation, the details of which are defined in this specification.
An important aspect of systems which is all too often forgotten is that it must be designed to account for the forces at play in its operating environment. In the same way that a physical machine must account in its design for forces such as gravity and momentum, so must an organisation or social mechanism account for the forces such as the conflicting goals of existing centralised systems, or peoples habits that are based on wide-spread false conceptions.
The most fundamental and dominant force is fragmentation which benefits the centralised, materialistic, self-oriented systems that emerge generally in our social mechanism in the form of the economic bottom line. So in our deployment of the common vision, we must ensure that our organisational infrastructure is properly designed to be deployed into a heavily fragmented and centralised environment which is in many cases overtly hostile to systems aligned towards unification.
The most common means that these opposed systems use to hinder alignment is through the use of legally binding contracts which in turn occur through the acceptance of benefits (i.e. there doesn't necessarily need to be a piece of paper with a signature involved for a legally binding contract to exist between parties). So independence is the key to being able to freely pursue the common vision.
In the context of OrganicDesign the group of people are a trust group and the fundamental kind of organisation they can choose to become is a Platform by implementing together the system defined by the Platform specification. [more]- Organisation → Departments & Roles → Projects → Tasks
All of these structural aspects of an organisation can, like the organisation itself, be addressed and involved in workflow in the same way as a trust group, or member of a trust group. In fact every concept (node) in the Ontology is a trust group that has members and a direction it's evolving towards.
This structure can change according to the needs of specific groups, for example, an individual member or project will most likely not require separate departments. And in some cases there can be more appropriate words for the structural categories, for example, in the context of Self organisation, the category that's normally called a "department" is called "area of focus". Groups can use splitting & merging processes to change the granularity or diversity of an operating system "in the field".
Organisations have members, resources, roles, departments, projects, tasks and activities amongst many other kinds of records and aspects of structure. They also have some key documents such as a charter, a manifesto, a best practices document and an alignment statement. [more]Each of the items mentioned above have a kind of portal for the members to organise and govern these resource together, usually with the aim of achieving a shared vision. 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.
We must ensure in our system design the alignment with our values so that all Platforms based on it always 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 lines 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 departments.
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 scales of operation. These details can evolve through self governance just as 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.
|
