Architecture of Governance Structures

When working on complex problems it's easy to get bogged down by stuff that just doesn't matter. In software, we address this through architecture. We define, up front, properties we'd like to see in the end system. Then, we carefully begin adding constraints that will evoke those system properties. Over time, we learn that we can snapshot certain coordinated constraints and refer to them by a simple name - as an "architectural style."

For example, we might endeavor to have a system that evokes the properties of re-usability, simplicity, and evolvability and this might lead us to a design based on the Pipe-and-Filters Architectural Style which is a set of contraints (e.g. Uniform Interface) known to positively effect those properties. But you can learn more about that reading Roy's dissertation.

Like software architecture, within organizational governance it's easy to get bogged down by stuff that just doesn't matter. This typically leads to more bureaucracy. I'm interested in thinking about applying the same architectural techniques to defining an organizational governance structure.

For starters, we'd need to think about the properties that are important to the organization. For this experiment, I'll use an organization with wide familiarity - the Apache Software Foundation. So let's define some [subset of] organizational properties that are important to the ASF:

• Participatory (Pa) - the characteristic of affording the opportunity for broad participation.
• Stability (S) - the characteristic of the organization and it's product to be viable over a long period of time.
• Protectiveness (Pr) - the characteristic of being protective of volunteers and end-users from liability.
• Frictionless (F) - the characteristic of achieving goals while minimizing friction.
• Modifiability (M) - the ease with which a change can be made to the organization and/or its products.
• ...

This is enough to get the experiment going. Now, we can begin adding constraints and reason about their effect on the organizations governance goals.

1. Open mailing lists. Open mailing lists shall be used to facilitate communication and decisions. By channeling communications over asynchronous medium we maximize participation (Pa). We further maximize participation by being volunteer friendly - they can get to it when they get to it. It enhances stability (S) by being both openly archived and self-documenting. It moderately evokes modifiability (M) allowing anyone to participate in decisions and direction of the project.

2. CLA/CCLA/Grants. All contributors must agree to grant copyright/license to the ASF. This has a positive effect on long-term project stability (S) and modifiability (M). The great positive effective also negatively impacts wide participation (Pa).

3. Release Process. All projects must have formal releases following a process that ensures license compatibility, export controls, etc. This has a positive effect on protectiveness (Pr) by ensuring that software release to the public is done under the Corporate entity (ie. the Foundation).

4. Decision making. When coordination is required, projects use simple, pre-defined voting procedures. These are simple votes (+1, 0, -1) for pre-defined approval types (e.g. lazy consensus, consensus, etc.) for pre-defined actions (e.g. releases, major code shift, new committer, etc.). Having a transparent decision making process limits friction (F). It also has a positive impact on long-term stability (S), participation (Pa), and modifiability (M).

5...

Hopefully that's enough to convey the idea. Once the properties are fully enumerated and the constraints fleshed out, we might dub this coordinated constraints the "Apache Organizational Style." I'm sure the analogy and, therefore, the framework breaks down somewhere, but it seems a better fit than the typical adhoc adaptiveness that many organizations currently suffer. I think the key value that this brings is focus. Every proposed governance change would need to be reasoned about through the lens of desired organizational properties. It also forces the organization to think about what properties it really thinks are important.