The Residual World::Tag = 'Perspective'
Entries that have been tagged with 'Perspective'.-
‘Logical’, ‘Abstract’ or ‘Concept’ Instead of ‘Operational’?
by Nic Plum on Monday 19 April, 2010 - 15:46 GMT
Posted in Architecture Framework • MODAF • TRAK
Tags: concept • definition • language • ontology • operational • perspective • trak
The 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
Related Articles
- {REL[139][related1_blog]oGQCL8IWREL}
Sharing tags:
- Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (43% )
- Definitions - What Exactly is a Risk? (29% )
- Definitions - What Exactly is a Risk Part 2? (29% )
- Just When You Thought It Was Safe - EntiTy Returns (14% )
- What Would a TRAK View Look Like in a Graph Database? Part 1 (14% )
External Links
- MODAF. The MODAF Operational (OV) Viewpoint.26th April 2010.
- Sourceforge. TRAK Enterprise Architecture Viewpoints. Feature Request #2989344
Thoughts - “The TRAK Enterprise”
by Nic Plum on Saturday 02 January, 2010 - 12:11 GMT
Posted in Architecture Framework • TRAK
Tags: boundary • concept • cv01 • enterprise • perspective • trak
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.
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.
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
Related Articles
- {REL[6144][related1_blog]oGQCL8IWREL}
Sharing tags:
- Risk and Threats - The Common Ground Between Security and Safety? (17% )
- Definitions - What Exactly is a Risk? (17% )
- Just When You Thought It Was Safe - EntiTy Returns (17% )
- What Would a TRAK View Look Like in a Graph Database? Part 1 (17% )
- Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (17% )
External Links
Perspectives - Structure / Grouping of TRAK Viewpoints
by Nic Plum on Sunday 06 December, 2009 - 09:52 GMT
Posted in Architecture Framework • TRAK • Standards
Tags: capability • concept • ieee1471 • iso42010 • management • operational • perspective • procurement • solution • trak
—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:-
- Enterprise (was ‘Capability’) concerned with the overall enterprise and capabilities needed.
- Concept (was ‘Operational’) concerned with the logical ‘what’
- Procurement concerned with projects and delivery of solutions
- Solution concerned with the behavioural and physical aspects of the solution
- Management concerned with the management of architectural views
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.
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
Related Articles
- {REL[126][related1_blog]oGQCL8IWREL}
Sharing tags:
- Risk and Threats - The Common Ground Between Security and Safety? (30% )
- What Would a TRAK View Look Like in a Graph Database? Part 1 (20% )
- Definitions - What Exactly is a Risk? (10% )
- Just When You Thought It Was Safe - EntiTy Returns (10% )
- Solution Risk, Vulnerability, Threat and Mitigation - Does Risk Need to be Separate from Event? (10% )