Wednesday, May 26, 2010

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


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.

Wednesday, May 05, 2010

Textual Weather

I've been annoyed for years at the increasing trend towards graphics-only weather forecasts. With 24 hours in a day, how can a single picture with two numbers be particularly helpful? Anyway, I finally realized how to get a nice text forecast in the Mac Dashboard - I know, I'm a little slow.

In Safari, navigate to

Enter your zip code in the left side.

Now, scroll down and look at the bottom right, and click on "Text Only Forecast".

No go to File->Open in Dashboard...

Highlight the middle text section, and click "Add..."

That's it, that's my not-so-new tip of the day. Now, if I could only get it in a fixed-width font:)

Tuesday, May 04, 2010

Article:Using DNS for REST Web Service Discovery

I'm not sure if it's a "Good Thing To Do" or not, but it is interesting. Personally, I haven't seen the "service discovery" problem first-hand - I've long thought it a problem manufactured by vendors to sell their ESB-ish wares... I'll definitely be watching to see how the comments on this one play out:)

Article:Using DNS for REST Web Service Discovery: "Service Discovery is an essential aspect of service orientated architecture because it avoids early binding of clients to particular service instances. In this article, Jan Algermissen explains the need for discovery of RESTful services, and explains how the existing Domain Name Service (DNS) standard can be used as a widely-deployed and scalable solution. By Jan Algermissen"