The Residual World::Tag = 'Standard'
Entries that have been tagged with 'Standard'.-
by Nic Plum on Thursday 04 February, 2010 - 19:02 GMT
Having presented a short potted overview of some of the logical side of TRAK as an Enterprise, how might TRAK as a standard be administered?
It 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 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.
In this solution we have the TRAK Enterprise with 2 parts:-
- TRAK Steering Group
- Working Group.
TRAK Steering Group
The functions of the TRAK Steering Group are:-
- Control of the formal release of the TRAK standard. The Steering Group is the body that ratifies the incorporation of new material and formal release of TRAK.
- Definition of the overall direction for TRAK i.e. where it needs to go in order to be successful (useful).
- Co-ordination of the working groups. This might initially involve the seeding of some ideas or known problem or applications areas that need investigating but thereafter working groups are expected to be self-selecting in terms of their ‘problem area’. It is important, however, that the Steering Group ensure that the scope of each working group is consistent with the direction set (via their charters) and that each is aware of the impact and dependencies on other working groups to ensure that there are no conflicts.
The Steering Group would not involved in day to day control. In essence therefore the Steering Group collectively would have the role of Chief Architect of TRAK.
A mechanism would be needed to ensure that the direction is not set by any particular individual nor the progress of a working group blocked by any individual. This is most likely to be based on “rough consensus” in order to avoid the potential for a veto.
TRAK Working Group
The TRAK Working Groups represent the real power-house of the TRAK Enterprise since it is intended that pragmatism and demand are the drivers for development of the TRAK and TRAK-related products. The demand or “pull” or prioritisation needs to come from those who create and exchange architecture models not pushed from the centre.
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 architectural modelling. 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 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 products are always in the open for comment 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.
- Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (20% )
- Just When You Thought It Was Safe - EntiTy Returns (20% )
- Definitions - What Exactly is a Risk? (20% )
- What Would a TRAK View Look Like in a Graph Database? Part 1 (20% )
- Definitions - What Exactly is a Risk Part 2? (10% )
- 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.
by Maestoso on Sunday 31 January, 2010 - 10:56 GMT
ANSI/IEEE Std 1471 :: ISO/IEC 42010 - Recommended Practice for Architectural Description of Software-Intensive Systems
ISO/IEC42010:2007 states that ‘most architects must work within an architecture framework’ where this is defined as a predefined set of concerns, stakeholders, viewpoints and viewpoint correspondence rules; established to capture common practice for architecture descriptions within specific domains or user communities.
It controls architectural modelling at a high level by requiring architecture viewpoints that specify what concerns a particular view answers and what content a view must contain. It does not specify how the modelling is done or what presentation language must be used, for example UML, SysML, BPMN.
UPDATE. The re-issue of the standard as ISO/IEC/IEEE 42010:2011 changes the underlying conceptual metamodel in the standard. This is shown on ISO/IEC/IEEE 42010 website.
IEEE 1471 does not specify any particular one because it states that these are specific to the needs of a particular domain and there is not, as yet, any consensus on generic architecture frameworks.
In ISO 42010:2007 it specifies that an analysis be undertaken of the consistencies across the architectural views and any known inconsistencies be identified. Where does this consistency arise from, however, and what is the scope? It is perfectly possible for an architecture description comprising a set of models to be self-consistent. The problem is that another architect can choose to model using different object types and whilst again consistent the 2 architects will have produced 2 architecture descriptions that can’t easily be exchanged or re-used.
IEEE 1471 is evolving and not only has the name changed to better reflect the application of architecture modelling - ‘Systems and Software Engineering - Architecture Description’ [draft 7, 25th January 2010]. It also has more on architecture frameworks and states that
Correspondences and correspondence rules as specified in 5.7.2 and 5.7.3 may be used to express, record, enforce and analyze consistency between models, views and other AD elements.
IEEE 1471 is definitely heading in the right direction and provides useful principles and rules. Simply making a reference to IEEE 1471, however, is not sufficient in order to control architectural modelling to the level needed to be able to maximise the likelihood of success for the exchange of architecture descriptions (or models). Correspondence rules are necessary but there are potential problems with sets of text-based rules (this affects any requirement collection). A metamodel defines that only the allowed element types and relationships that can be used in a model or architecture description. In essence it provides the architect with a mandated language of nouns (element types) and verbs (relationships) to describe the system of interest. It is also visual and a very concise form of specification. There will always be the need for additional rules to specify consistency between views for the system of interest but having a metamodel is essential to a consistent set of building blocks from which to construct the views.
I’d argue strongly that having a declared metamodel is fundamental to defining an architecture framework and that without one you can’t hope to control consistency of modelling or meaning (semantics).
Even with a well-defined and controlled architecture framework there will be problems in exchanging architecture descriptions (and models) since modelling is a creative art providing many ways of modelling a particular thing and we have local or personal modelling styles. If we don’t share or have good access to a central set of definitions which includes elements and probably agreed boundaries (i.e. agreed understanding of the system breakdown structure) it is likely that elements will have different semantics.
IEEE 1471 is a good start and an architecture framework with a metamodel helps, but there is a lot more to put in place to be able to successfully exchange and collaboratively develop architecture descriptions (and models).
- Risk and Threats - The Common Ground Between Security and Safety? (20% )
- What Would a TRAK View Look Like in a Graph Database? Part 1 (20% )
- Definitions - What Exactly is a Risk? (10% )
- Definitions - What Exactly is a Risk Part 2? (10% )
- Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (10% )
by Nic Plum on Monday 02 November, 2009 - 18:46 GMT
TRAK - The Rail Architecture Framework - is an architecture framework (Editor - ‘no kidding’?) that was born within London Underground Ltd. based on MODAF and hence also DODAF.
Like other architectural frameworks it provides a fixed grammar (objects and relationships) for representing the real world in architectural models - everything from the enterprise down to the technical products and interfaces. It also forms an interoperability or exchange standard to allow models to be exchanged with others.
It has it’s beginnings in proprietary attempts to establish standards for system architecture. Prior to this there were single views of purely physical architecture. Architectural views of the physical, functional and geographic architectures of the underground were developed and the relationships between views established.
A metamodel with a richer langauge for describing rail architecture was needed. There wasn’t any obvious architecture framework available within the rail industry that could describe systems other than computer or IT systems and after deliberation it was decided to adapt the MODAF metamodel for use within the rail domain.
The driving needs have been:-
- pragmatism - good enough / fit for purpose is all that’s needed
- recognition of hard and soft ‘systems’
- supportable by tools
The objectives in developing TRAK are:-
- Standardising the content and presentation of rail architecture views. At present different companies, different projects present diagrams that mix ideas and presentation and which have no means of checking for consistency. Typically they are on paper, difficult to maintain and each diagram represents a fresh start in terms of the objects, descriptions and relationships shown.
- Providing a standard for the exchange of architectural models of rail systems. There is no means to allow incorporation of the architecture represented on a diagram within another project or companies architecture.
- Enabling portability of architectural models of rail architecture. Diagrams are paper or CAD files. One is portable but not easily integrated, the second is portable very restricted in those who can use it.
- Collaboration. If models can be exchanged and re-used and standards define the component parts of the model then it becomes possible to collaborate.
- Providing the means to show interactions and dependencies between enterprise, project, operational and solution component parts i.e. a more complete systems engineering (holistic) view.
The thing is .. having set out to create an architecture framework for the rail community we stripped out all defence-specific concepts, added things to better represent systems and organisations and have ended up with something that is generic. This shouldn’t have been a surprise - a system is a system and it doesn’t know whether it’s in rail or telecomms nor whether it is a hard or soft system.
- What Would a TRAK View Look Like in a Graph Database? Part 1 (22% )
- Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (22% )
- Just When You Thought It Was Safe - EntiTy Returns (11% )
- MODAF is Dead - Long Live ‘NAF’? (11% )
- Definitions - What Exactly is a Risk Part 2? (11% )