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

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]XI6MNsHSREL}

    Sharing tags:

    External Links

    Perspectives - Structure / Grouping of TRAK Viewpoints

    by Nic Plum on Sunday 06 December, 2009 - 09:52 GMT

    Posted in Architecture FrameworkTRAKStandards

    Tags: capabilityconceptieee1471iso42010managementoperationalperspectiveprocurementsolutiontrak

    —Edited to reflect changes in names of TRAK Enterprise and Concept Perspectives—

    Architectural frameworks normally provide ways of grouping views that have a common aspect and these collections are known as perspectives.

    TRAK provides the following perspectives:-

    They provide a way of simplifying and organising the architectural description.

    TRAK defines a set of architectural viewpoints and view contents. Elements shown on a view have to be part of the underlying metamodel and can only be connected using the allowed relationships. TRAK specifies what can be shown and how it is presented and organised. This is shown in the context of IEEE 1471 in Figure 4?1. It is the ‘architecture element conforms to metamodel’ relationship outside the IEEE 1471 space and the ‘framework defines architecture viewpoint’ and ‘framework defines perspective’ that provide conformity and consistency.

    IEEE 1471 Model - with links to TRAK Metamodel

    IEEE1471 Conceptual Model with TRAK Metamodel Elements Added

    Each TRAK viewpoint (and therefore view) is designed to address specific concerns or questions.

    Enterprise Perspective

    This perspective covers the enduring capabilities that are needed as part of the bigger enterprise. These are high level needs that everything else contributes to and form part of the long term strategic objectives that need to be managed. It provides a mechanism to link into the higher level goals such as ‘Keep London moving’.

    Concept Perspective

    The concept perspective covers the logical view of what is needed. It covers the logical connection of concept nodes, for example a service control centre, to other nodes with no recognition of how this might be realised either by organisation or technology. It provides a means of stating the operational exchange needs and information required.

    Procurement Perspective

    The procurement perspective provides a top level view of the solution to the problem outlined in the capability perspective and developed in the operational perspective in that it provides a way of showing how projects deliver solutions to provide capability. It provides a way of showing time dependency between projects and is an essential prerequisite for investigating capability gaps in the capability perspective. It also provides a mechanism for showing how organisations and projects relate to the systems being delivered.

    Solution Perspective

    The solution perspective provides views of the solution or potential solution, recognising that there may be many potential solutions which might meet the logical needs expressed in the operational perspective. Functional views provide a means of describing the behaviour in terms of functions, activity, sequence, state and interactions. Physical views describe how the system is organised, how information is routed and where parts are or must be.

    Management Perspective

    The management perspective covers views that are concerned with the management and production of the architecture products. It enables the scope of any architecture task to be defined and the provides ways of recording what was done and capturing the intended understanding so that the architecture can be provided to others or re-used.

    Comments

    Comment on this article

    Related Articles

      {REL[126][related1_blog]XI6MNsHSREL}

      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.