Building a system bigger than any one person can understand.

Inventing The Wheel

There is consensus that 'we should not re-invent the wheel' in anything that we produce. This needs stating more precisely. In approaching any problem we will consider the following approaches in the order presented:

1. Use an existing solution. If someone else has already solved the problem and it looks as though (after due consideration) the solution is open, stable and likely to endure then we should adopt it.
2. Subvert another solution. If someone else has a mechanism that looks like it might solve the problem we should approach them and ask if they would change it to support our needs. Many standards organisations are keen to embrace other areas of endevour and would be willing for us to participate in improving their standard.
3. Extend another solution. Existing solutions often have formal extension mechanisms. If we can solve our problem by extending an existing architecture (after due consideration) we should do it.
4. Copy another solution. If another organisation does something well but their governance does not meet our requirements or we feel we need more control over the technology then we should consider copying someone else's solution (Copyright and IPR permitting and giving due credit to the sources).
5. Create our own solution. As a last resort we should design something of our own.

-- RogerHyam - 24 Oct 2005

I believe that there are advantages to combining bits from various solutions, each of which is a partial solution. When strictly following the above-given reasoning, none of xml/html (sgml already existed), xml formatting objects (CSS already existed), etc. should ever have been created. And you could argue that none of XLink, XForms, etc. should exist, and that they rather should extend than attempt to replace existing mechanisms. -- Gregor Hagedorn, 12. April 2006

Project Constraints

A very simple project management methodology will be adopted to ensure a useable architectural vision is delivered within the time available. There are four variables:

1. Resources: These are the people available. For this project we have an loosely defined pool of people who can commit time. The important thing to remember is that human resources can not be turned on like a tap. Even if we could recruit more people to a project it would take them a finite time to get up to speed with the problems and technologies involved. This is mitigated to some degree if we adopt existing technologies and solutions. Once the project is in full swing it is difficult to add human resources and easy to lose them.
2. Timescale: Time appears to be finite. This project, like any other, is bounded by a specific TimeLine which is fixed.
3. Quality: Whether the product does what it says on the tin! This is a non-negotiable. The result has to do what is specified in the scoping process.
4. Scope: What it says on the tin. This is the specification for the system. What it will and won't do. (see MoSCoW below.) This is the only thing that can be varied throughout the project. Managing scope is therefore the most important thing to do. It may be necessary to abandon areas of interest in order to be sure of delivering Quality with the available resources in the timescale. This is particularly difficult when development is being driven by voluntary effort but should be borne in mind by all involved i.e. one solution to any problem is not to solve it but to put effort into something more important.

-- RogerHyam - 21 Oct 2005

MoSCoW = Must, Should, Could, Won't

As stated in ProjectConstraints one of the most important things to do is manage scope and this is done by prioritising different features of the system. It is important therefore to have a clear and easily understood prioritisation scale. Using InventingTheWheel principle number one this is the adoption of a well know methodology. Coley Consulting have a good description or you could Google on it. Any requirement falls into one of four categories.

• Must: Requirements in this category are non-negotiable. If the system does not do them it has failed.
• Should: It is intended that the system will do things in this category. They are not, however, sacrosanct and may be sacrificed if their inclusion would lead to the loss of quality of solutions in the Must category. Sacrifice isn't so bad as it only means moving to the Won't category.
• Could: As Should is to Must so Could is to Should. Features in this category will definitely be sacrificed for higher category items. These things are 'nice-to-haves' that probably wouldn't cost to much or add significant project risk.
• Won't: As important to identify as the Must requirements. These are things that will not be done this time round. They may be very important but they are not going to be implemented now. They are here so that Quality is not lost in what is actually delivered - see ProjectConstraints.

-- RogerHyam - 24 Oct 2005