Site

RW - Navigation

RW - Recent

Last 10 entries [comments]:

Forums

Last 10 posts [threads/views]:

Wiki

Last 10 pages updated:

There are 484 wiki pages in total.



RSS logoRSS Feed
 

The Residual World::Tag = 'Enterprise'

Entries that have been tagged with 'Enterprise'.-

How to Administer an Enterprise Architecture Standard - One Possible Solution

by Nic Plum on Thursday 04 February, 2010 - 19:02 GMT

Posted in Architecture FrameworkTRAKStandards

Tags: adminenterpriseietforganisationrfc4677rolestandardsteering grouptrakworking group

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.

A Possible Organisation to Administer TRAK

In this solution we have the TRAK Enterprise with 2 parts:-

  • TRAK Steering Group
  • Working Group.

TRAK Steering Group

The TRAK Steering Group Would Control Direction & Co-ordinate

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 Would be the Powerhouse for Development

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.

 

Comments

Comment on this article

Related Articles

    {REL[124][related1_blog]JKTUkNxAREL}

    Sharing tags:

    External Links

    Thoughts - “The TRAK Enterprise”

    by Nic Plum on Saturday 02 January, 2010 - 12:11 GMT

    Posted in Architecture FrameworkTRAK

    Tags: boundaryconceptcv01enterpriseperspectivetrak

    This article presents some musings on how TRAK as an enterprise might be represented and how it might work. Needless to say there is an architecture description underpinning this!

    • Capability Perspective - what are the likely goals?
    • Concept Perspective - logical needs, connectivity & exchanges
    • Solution Perspective - aspects of a possible solution

    Concept Perspective

    What Does the TRAK Enterprise Consist of - Conceptually?

    If TRAK is considered to be a standard then what would we need to maintain it, what would would we need to support the users (architects, tool vendors, browsers etc) and how does it fit together? Indeed where does it stop and something else start i.e. what is the boundary of the ‘TRAK Enterprise’ "system"?

    Fig. 1 - CV-01 The Needs of "The TRAK Enterprise"

    Figure 1, TRAK::CV-01 - The Needs of "The TRAK Enterprise", attempts to show a boundary - light blue background - within which the ‘TRAK Enterprise’ might exist and logically how it depends on things outside the boundary (and vice versa).

    The logical things inside the ‘TRAK Enterprise’ boundary listed below in Table 1.

    Table 1 - ‘TRAK Enterprise’ Logical Parts

    TRAK Enterprise

    Logical Part

    Description

    Community Self-Support

    The parts that enable the TRAK wikitecture/architectural community to help each other and enable interaction with framework definition, products etc.

    Framework Definition Store

    The definition of TRAK that is exposed and which can be interacted with. This includes the metamodel and specification of views.

    Support Tracker

    A means of systematically capturing bugs, support requests and feature requests in relation to TRAK i.e. metamodel, viewpoints, products/templates in a way that allows the response to be open, visible and linked to the original request or problem.

    TRAK Body of Knowledge

    The store, means of capturing use of TRAK advice / problem solving tailored templates application of TRAK products academic / public papers case studies links to external sources of information

    Wikitecture Glueware

    The wikitecture components that are necessary to enable models to integrate, be exchanged  and be understood

    Wikitecture Model Repository

    A public / shareable repository of TRAK models / fragments.

     

    The logical things outside the ‘TRAK Enterprise’ boundary are listed below in Table 2.

    Table 2 - Logical Things Outside ‘TRAK Enterprise’ with which there is a Need

    External to the TRAK Enterprise (=“Residual World”)

    Logical Part

    Description

    Professional Bodies

    Often technical, the professional discipline or functional expertise bodies whose members are affected by TRAK

    Architecture Browsers

    The organisations and people that browse, consume or need to be able to understand the models and other architectural products.

    Often from other domains, not technical and probably key drivers in the user-interface of TRAK and communication-effectiveness.-interface of TRAK and communication-effectiveness.

    TRAK Modelling Tools

    The tools that implement or use TRAK or produce TRAK-compliant architectural products.

    Framework Developers

    The community co-ordinating and involved in the development of TRAK metamodel and viewpoints

    Tool Vendors

    Companies that provide or develop modelling tools that are relevant to TRAK

    Of course this isn’t quite right yet as it should also include ‘Training Providers’. This is one of the points of modelling and trying to draw something visually - it slows you down and forces you to think. The metamodel provides the skeleton upon which you hang your ideas and it also provides a sort of filter to view the real world and tease of the types of thig it consists of.

    Anyway, more to follow as the thoughts unfold ....

    Comments

    Comment on this article

    Related Articles

      {REL[6144][related1_blog]JKTUkNxAREL}

      Sharing tags:

      External Links

      1.2.004 adl admin advice applescript application architecture architecture description architecture description language architecture framework artefact artisan studio award berlow blog boundary browser bug c3 capability capability configuration colaboration collaboration committee compare compliance concept concert conference configuration control conformance consistency content contrast css cv01 def stan defence definition demonstration denmark department for transport develop discovery dndaf document dod dodaf drawing enterprise enterprise architect ertms event evolve exchange exploit forum fun geneology gfdl gnu graph group handbook hazard head-model history humour ibm rhapsody iec ieee ieee1471 iet ietf implement implementation incose innovation institute integrated ea interoperability introduction ipad iso iso42010 isse keynote knowledge language linkedin lockheed martin london london underground m3 mac management mdg meaning meeting metamodel mil std modaf model modelling style naf nato natural language needline news nist no magic magicdraw noun omg omnigraffle ontology open source opensource operational organisation oxfordshire perspective plan platform playlist portability presentation procurement profile project public publication publish purpose rail relationship release repository research resource rfc4677 risk role rssb rule safety sea search security sentence service singapore site softeam modelio software solution song sos sourceforge sparx systems sparx systems enterprise architect specification spreadsheet stakeholder concern standard steering group stencil stereotype store strategy structure support sysml system system authority system of systems systems engineering team template test threat
       

      All articles/posts © of the respective authors

      Site design and architecture © 2010 - 2011 Eclectica Systems Ltd.