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 = 'Standard'

Entries that have been tagged with 'Standard'.-

Conformance Assessment vs ISO/IEC 42010:2011

by Nic Plum on Thursday 22 September, 2011 - 12:59 GMT

Posted in Architecture FrameworkTRAKNewsStandards

Tags: complianceconformanceieeeisoiso42010standardtrak

Logo of The International Standards Organisation

It’s very hard when everyone seems to be claiming conformance with ISO/IEC 42010 to establish whether the claims are true. All too often we get ‘partly compliant with ’ which means what exactly? As a standard trying to get standardisation in the field of architecture description and trying to eliminate the variability and anarchy it isn’t much use to be partly compliant (any more than claiming to be partly pregnant). You either do or don’t conform. The hard work put in by those that try to conform to the standard is undermined by those that claim conformance but don’t actually conform.

I’m pleased to be able to say that TRAK has agreed to take part in a pilot against an official ‘conformance assessment instrument’ prototype that is being developed against ISO/IEC 42010:2011 which is soon to be jointly published by both the IEEE and ISO. The conformance instrument applies to Architecture Frameworks, Architecture Description Languages and Architecture Descriptions.

As ever I’m sure the assessment and feedback will benefit both sides in refining and sharpening up the documentation. These are early days and no doubt some ideas still need to be worked through, hence the pilot using the prototype conformance instrument.

I’m quietly confident with respect to TRAK itself (time will tell!) but more importantly it will be useful to have an independent assessment of any claim to conformity whereas the current situation allows any Tom, Dick or Harry to claim conformity with impunity and where no sanctions can be applied. I look forwards to this situation being changed.

Comments

Comment on this article

Related Articles

    Sharing tags:

    External Links

    Improving Consistency for Tools - ‘TRAK. Implementation. Architecture Description Elements’ Document

    by Nic Plum on Monday 05 September, 2011 - 15:03 GMT

    Posted in Architecture FrameworkTRAKTools

    Tags: architecture descriptionconsistencydocumentexchangeimplementsolutionstandardtool

    There is a constant need to reduce the scope for inconsistency in any architecture description. TRAK is no different. TRAK has been defined in a way that is free of implementation and using natural language wherever possible. One of the pitfalls of this is the possibility that names will be implemented inconsistently in tools. For example, the attribute ‘start date’ might be called ‘start date’, ‘start_date’, ‘startDate’, ‘Start Date’ and so on. The danger in this is that upon exchange the receiving tool might not recognise this if it is using, say, ‘startDate’.

    I’ve therefore created a document titled ‘TRAK. Implementation. Architecture Description Elements’. To put it into context a couple of diagrams (produced using the OmniGraffle stencil for TRAK):

    Context - the TRAK. Implementation. Architecture Description Elements documents is part of the set of documents that improves consistency of exchange of an AD

    The TRAK. Implementation. Architecture Description Elements Document is Part of the set of Documents that Improves Consistency of Exchange of an Architecture Description

    The TRAK. Implementation. Architecture Description Elements document responds to the logical TRAK Metamodel definition.

    The TRAK. Implementation. Architecture Description Elements Document Responds to the Logical Definition of the TRAK Metamodel

    The document is at http://sourceforge.net/projects/trak/files/Implement%20TRAK/

    The purpose of this document is therefore to standardise the naming of the architecture description elements used in any implementation of TRAK, whether graphical or text-based.

    In addition to naming this document also specifies the formats used for attributes such as text, language labels, geographic location and uniform resource identifier. It also identifies the allowed values where an enumerated list specified for an attribute.

    None of this guarantees successful exchange - in a UML modelling tool there will be an extra wrapping applied through XMI which might be at a different version in the sending and receiving tool and in addition even if an element has the same name it might mean something completely different in each. This document is therefore one part of a set of normative measures needed to maximise the chances of successful interoperability between a pair of tools.

    There are a couple of things still left to do, not the least of which is figure out how to specify privacy marking / security descriptor schemes. If anyone knows of any good standards-like sources for these please let me know.

    Any constructive comments via the Sourceforge Tracker set up for implementation of TRAK at https://sourceforge.net/tracker/?group_id=393432&atid=2376222

    Comments

    Comment on this article

    Related Articles

      {REL[6140][related1_blog]3NkPnJB9REL}

      Sharing tags:

      Forums

      External Links

      New Revision (“The ISO 42010 Mix”) of TRAK Released

      by Nic Plum on Friday 21 January, 2011 - 16:37 GMT

      Posted in Architecture FrameworkTRAKNewsStandards

      Tags: architecture descriptiondefinitionincoseiso42010standardtrakviewpoint

      TRAK Logo


      Just managed to shovel the last part of the documents that defines TRAK into cyberspace last night. The main purpose of the revision is to anticipate the likely requirements from ISO/IEC 42010 expected to be released under a slightly new name during 2011. There are quite a few changes to the ISO not the least of which is that it has requirements for architecture frameworks and makes reference to a framework metamodel. The opportunity has also been used to respond to constructive comments and requests made by the INCOSE UK Architecture Working Group.

      In the end this has proved a bigger change to the existing documents than anticipated. We now have a 3 document set that defines TRAK since it became clear that things that were global or common or which were best dealt with as “a whole” would be best separated into an overall TRAK Enterprise Architecture Framework document. This has meant things like the bye laws, colour rules and conformance/non-conformance with TRAK being moved into this document. It also provides the better place to provide advice on choosing an architecture description language to represent TRAK and to describe how TRAK relates to ISO/IEC 42010.

      This new 3 document structure has resulted in breaking out a new project on Sourceforge. The top-level reference for TRAK is now trak.sourceforge.net which is an improvement on the old bifurcated reference to both the viewpoints (trakviewpoints.sourceforge.net) and metamodel (trakmetamodel.sourceforge.net) projects / sites. Errors or feature requests for any of the documents can be made on the respective site.

      As a result of comments made by Rich Hilliard (always useful) it became clear that the old viewpoint definitions needed to be sharpened up. In particular I’ve added stakeholders derived from the standard , added more detail and examples to the presentation sections. Some of this existed in the old days before release as open source but never got incorporated into the new documents. In any case some of the thinking and the changes to the ISO have changed the content and it had to be started afresh. A suggestion was to add a ‘well-formedness’ section which attempts to define the minimum acceptable content for a view of each type. The latter was quite hard work and an empirical task as you think you’ve got it nailed, draw an example to immediately find that it breaks the rules. It’s not quite complete but a lot better for the effort and therefore worth releasing rather than waiting for perfection.

      No doubt there will be a few “after shocks” but nothing of the scale of this revision (I hope!).

      One of the ongoing questions is how to make it more concise, less wordy but accessible and understandable to the ‘normal’ Mk1 Human Being (the “non-softie”). In particular is there a way to define the minimum content visually without words - there are ways from the software world but are these likely to understandable to the non-softie or non-tecchie? Constructive suggestions on a postcard.

      Comments

      Comment on this article

      Related Articles

        {REL[6099][related1_blog]3NkPnJB9REL}

        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.