How to Govern an Architecture Framework - One Possible Approach

Adapted from original posted on trak-community.org 4th February 2010

---

The TRAK specification documents don't itself define how architecture description is done or managed. How, therefore, might TRAK itself be administered?

This is clearly a balancing trick. On the one side with London Underground having agreed to release the architecture framework as open source it seems sensible to keep it as open and accessible as possible and involve as many as is sensible. Ideas collection and work is a product of the size of the community so in this sense ‘large’ is good.

On the other side is the need to formally manage the release of the standard itself. In this capacity ’small’ is better.

In terms of efficiency of an organisation I suppose you could say that that any organisation whatsoever is a fixed overhead and somehow this has to be balanced with the amount of activity or work output. Ideally you want as small a fixed overhead as you can get away with. The other advantage of small is flexibility and speed of response and in this sense a large organisation can be a bit like a dinosaur in that the communication paths and decision-making structures become so cumbersome that the time take to respond is long - a bit like the length of a nerve from the corporate brain stem.

The "TRAK Enterprise" needs therefore to be more dynamic and to encourage incremental change. In order to encourage development of the standard and products TRAK will be released under an open source license . The importance of this is that it allows others to change TRAK providing that the changes are identified and incorporated into the license and that attribution is kept. It allows everyone who wants to to take part in some way that suits them best. It also ensures that development is led by the business needs of the users of the framework rather than the specifiers. [The controlled version of TRAK would still only be available from the one place. It is also important since as an open source license it signifies a model of collaboration and user participation that is unusual in the standards world.

The "TRAK Enterprise" needs to adopt a business or problem-led model. It needs to address and help solve everyday practical problems faced by users of TRAK, often systems engineers and system-thinkers. The expectation is that the metamodel will settle down first and most of the effort will be in developing the application of the TRAK architecture views. At all costs the "TRAK Enterprise" needs to avoid the “purity trap” where effort is spent on the theoretical underpinnings at the expense of use or usefulness. “Good enough” is fine!

So small seems good. How might this work? In order to encourage and involve the user community in the evolution of TRAK the organisation of the "TRAK Enterprise" could be based on the model adopted by the Internet Engineering Task Force (IETF). The IETF are responsible for the issue and maintenance of a significant number of technical standards on which the Internet and modern life is dependent, such as TCP, IP, POP and SMTP and have been operating for over 15 years so the organisation and process we see today are the result of significant experience in the standards-setting domain.

The following quotes from RFC4677 The Tao of IETF: A Novice’s Guide to the Internet Engineering Task Force. P. Hoffman. September 2006 – provide an indication of how the IETF works:-

There is no membership in the IETF. Anyone may register for and attend any meeting. The closest thing there is to being an IETF member is being on the IETF or Working Group mailing lists.

In many ways, the IETF runs on the beliefs of its members. One of the “founding beliefs” is embodied in an early quote about the IETF from David Clark: “We reject kings, presidents and voting. We believe in rough consensus and running code”. Another early quote that has become a commonly-held belief in the IETF comes from Jon Postel: “Be conservative in what you send and liberal in what you accept”.

The IETF is really about its members. Because of the unrestrictive membership policies, IETF members come from all over the world and from many different parts of the Internet industry.

The principles of organisation taken from the IETF that apply are:-

• No hierarchy. The Working Groups form themselves; they are not chosen or created from above.
• Application/problem-led: A Working Group forms in response to the need to solve a shared problem with either the TRAK standard or in the application of TRAK to architecture description. It forms to solve small, bounded and specific problem. It doesn’t have any formal or permanent members but has individuals who share the problem and who are motivated to solve it. The Working Group creates a charter to bound the scope of work and this has to get ratified by the TRAK Steering Group in order to ensure that the intended objectives and products fit with the overall direction and fit with the work of other working groups.
• No permanent working group structure. Since the working groups are task and product-focussed they only exist for the task duration. This keeps the hierarchy at a minimum and it also ensures that the application or problem remains the focus not the organisation of the "TRAK Enterprise".
• "TRAK Enterprise" artefacts are always in the open for comments by others. This is really important not only to collaboration but also in helping the understanding. Often it is as important to see the decision-making process and rationale as it is to see the result. The intent is that comment will be able to be made not only on the products but also that the decisions and the choices and compromises will be exposed for all to see.

The principles outlined above would provide a flexible and lean organisation and are deliberately as inclusive and collaborative as possible in order to benefit from the many different viewpoints and collective experience of those at the coal face of having to use and share architectural models. It would also embody a principle that the collective user knows best what he/she wants or is most useful.

The minimal TRAK organisation structure needed for governance is described separately on the governance page based on the Tao of the IETF and BCP25 .

References

• RFC4677 The Tao of IETF: A Novice’s Guide to the Internet Engineering Task Force. P. Hoffman. September 2006"
• BCP 25 IETF Working Group Guidelines and Procedures. S. Bradner. September 1998