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
 

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

 

External Links

Comments

Logged-in site members can receive notifications of comments made on this article.

Comment on this article

Related Articles

Linked directly:

Sharing tags:

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.