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

Entries that have been tagged with 'Concept'.-

Every Viewpoint Has to Be Distinct - Say “Goodbye” to the TRAK CVp-02 Concept Viewpoint

by Nic Plum on Sunday 08 April, 2012 - 12:42 GMT

Posted in Architecture FrameworkTRAK

Tags: concepttrakviewpoint

TRAK Logo

Every viewpoint in TRAK is a specification for an architecture description view. In accordance with ISO/IEC 42010 each address one or more typical concerns using a combination of tuples (stereotype - relationship - stereotype combination taken from the TRAK metamodel). The tuples have therefore to contain the right types and relationships to address the concern and the concerns (and therefore the tuple sets) must be distinct from those addressed by other viewpoints. This keeps clear water between viewpoints and it means that the number of viewpoints needed is kept to a minimum because they aren’t driven by domain or application of viewpoints.

What then of the TRAK CVp-02 Concept Viewpoint? This is currently defined as answering concerns has the concept purpose been identified? and How is it seen as being used? and the tuples as:

Expected to be largely textual and scenario based but with use of other concept perspective architecture views to illustrate, expand, define.The set of tuples will be those from the mandatory sets of the concept perspective views used against CVp-01, CVp-03, CVp-04, CVp-05 and CVp-06.The selection of concept views used to illustrate the scenarios is left to the architect.

from TRAK. Enterprise Architecture Framework Viewpoints. 2nd October 2011

This isn’t good enough. None of this needs anything which isn’t already provided by one or more of the other viewpoints in the TRAK Concept Perspective. The purpose of a concept is embodied through its relationships with the solution or potential solutions that realise it and its relationship with the enterprise and the enterprise goals. The content of a concept is already covered by existing viewpoints and there is nothing that makes this viewpoint distinct from any others. Historically it was an analogue of the MODAF OV-1 which included a high level graphic and a textual version used to present ideas to senior management in an easy to digest form:

The OV-1a provides a graphical executive summary of the architectural endeavour, which describes the interactions between the subject architecture and its environment, and between the architecture and external systems. A textual description accompanying the graphic is essential, with labels on the graphic and a detailed description in the OV-1b. Graphics alone are not sufficient for capturing the necessary architecture data.
The purpose of OV-1a is to provide a quick, high-level description of the business objective that the architecture is addressing, and how that objective might be achieved. An OV-1a can be used to orient and focus detailed discussions. Its main utility is to communicate the purpose of the architecture to non-technical, high-level decision makers.

from The MODAF Operational Viewpoint. 26th April 2010.

In TRAK any view can be presented using graphical elements as long as the type of object is shown and with simple text labels on relationships it is easy to produce something that most people can simply read in a natural way so the presentation is never a justification for a separate viewpoint.

On the face of it there is no good reason for keeping this viewpoint and the best thing is to remove it. The recommendation has been made as a change request (#3475115) and unless anyone makes a good reason to keep it the sentence will soon be carried out ....

 

Comments

Comment on this article

Related Articles

    Sharing tags:

    External Links

    ‘Logical’, ‘Abstract’ or ‘Concept’ Instead of ‘Operational’?

    by Nic Plum on Monday 19 April, 2010 - 15:46 GMT

    Posted in Architecture FrameworkMODAFTRAK

    Tags: conceptdefinitionlanguageontologyoperationalperspectivetrak

    Abstract - from the New Oxford American DictionaryThe language used in a framework definition is important to its “user interface”. Get it wrong and you build in problems for the long term. It is, however, difficult to get the ‘right’ name - one that is readily understood and where everyone has the same understanding.

    In TRAK we have an ‘Operational Perspective’ - that provides the elements and viewpoints with which to describe the problem in terms of need, exchanges and behaviour in a way which is free from implementation or any particular solution or technology. The trouble is that the word ‘operational’ is all too readily associated with the day to day running or operation of the system. This has caused confusion in the rail domain. Of course any confusion can lead to the use of the wrong architectural views or for an unnecessary restriction in scope - all of which can lead to inconsistency and which make it harder to exchange or collaborate on architecture models.

    Back to the problem in hand. If we don’t use ‘Operational’ what could we use instead? ‘Logical’ is a possibility. It is used in other frameworks, such as Zachman, where it is a perspective that represents the logical information systems model which is free from the technology (another perspective). It looks as though MODAF would like to use ‘logical’ since the pre-amble to the MoD’s ‘The MODAF Operational (OV) Viewpoint’ states ‘the OV Views illustrate the Logical Architecture of the enterprise; ie whilst they show what is required to conduct an (operational or business) activity, they do not consider how a solution may manifest itself when implemented.’  The trouble is, would the average user equate ‘logical’ with implementation-free or would they associate mathematics, rules or some alternative “Spockian” image with the term?

    ‘Abstract’ is another candidate. Looking in the New Oxford American Dictionary, produced by the Oxford University Press (OUP),  that comes with the Apple Dictionary application we have:

    ab•stract
    adjective |ˈabstrakt|existing in thought or as an idea but not having a physical or concrete existence : abstract concepts such as love or beauty.

    • dealing with ideas rather than events : the novel was too abstract and esoteric to sustain much attention.
    • not based on a particular instance; theoretical : we have been discussing the problem in a very abstract manner.
    • (of a word, esp. a noun) denoting an idea, quality, or state rather than a concrete object : abstract words like truth or equality.
    • of or relating to abstract art : abstract pictures that look like commercial color charts.


    This looks to be promising. It is quite clearly nothing to do with a particular solution or realisation. Is ‘Abstract Perspective’ only a term that an air-head would use? It certainly seems to be better than keeping the current ‘operational’.

    Or would it be better just to use ‘Concept’....?

    Not easy. The request to change the name has been made on SourceForge and it will be interesting to see what comments or reaction develops.

    Whatever the outcome there will have to be some changes on the site wiki…. :-(

     

    Comments

    Comment on this article

    Related Articles

      {REL[139][related1_blog]dRNRMGuUREL}

      Sharing tags:

      External Links

      How ISO/IEC 42010 Controls Architectural Description

      by Maestoso on Sunday 31 January, 2010 - 10:56 GMT

      Posted in Architecture FrameworkStandards

      Tags: architecture descriptionconceptconsistencyexchangeieee1471isoiso42010modelrulestandard

      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.

      image

      ISO/IEC 42010:2007 Conceptual Framework for Architecture Description

      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). excaim

      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).

      Comments

      Comment on this article

      Related Articles

        {REL[6165][related1_blog]dRNRMGuUREL}

        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.