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.
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 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.
|
