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

Entries that have been tagged with 'Ontology'.-

‘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]yGFQSRDqREL}

    Sharing tags:

    External Links

    A System is a System, Right? Not if You’re Head-Modelling

    by Nic Plum on Saturday 27 February, 2010 - 16:24 GMT

    Posted in Architecture FrameworkMODAFTRAK

    Tags: artefactcapability configurationdefinitionhandbookhead-modelincosemeaningmodafontologyplatformstereotypesystemsystem of systemstrak

    Introduction

    Choosing stereotypes for an enterprise architecture framework isn’t easy. In defining something you embed the prevailing view at the time the framework was created. This may later haunt you. With every extra stereotype you add choice and then when you add the poor old architect or modeller into the mix you increase the possibility of inconsistency - the very thing the metamodel is designed to constrain and eliminate. This is illustrated very nicely in trying to place ’System’ at the centre of TRAK.

    Since we started with MODAF 1.2 this is where the story begins.

    MODAF 1.2

    In the MODAF System is defined as

    The usage of an artefact as a System in a Capability Configuration

    and part of the physical architecture.

    In MODAF a System is man-made and physical - no parts

    MODAF::System - A Physical Artefact

    Technically it is defined as an Artefact alongside Platform. This arose because when the MODAF was originally launched the consensus on what a system is wasn’t the currently accepted one with emergence et al and the MODAF quite reasonably took the then accepted view - hence it is a purely man-made thing. No notion of complexity whatsoever.

    From the The MODAF System Viewpoint(SV) (17th February 2009):
    ‘Artefacts - Physical objects made for a purpose (e.g. system, sub-system, platform, component or any physical item that occupies space and has attributes)’

    ‘Physical Architectures - Configurations of resources for a purpose (e.g. capability configurations)’

    ‘The physical resources contributing to a capability must either be an organisational resource or a physical asset. That is, a system cannot contribute alone; it must be hosted on a physical asset used by an organisational resource of both. Organisational aspects (e.g. who uses a system) can now be shown on SV-1.’

    In short as it is defined in MODAF 1.2:

    • system is something physical
    • it is man-made
    • it can’t contain anything else like Organisation, Post or Role, or Software
    • it is not the same thing as a Capability Configuration
    • systems cannot provide capability

    TRAK

    When creating TRAK we found we couldn’t use MODAF::System as it didn’t fit with either the London Underground view of a system or the INCOSE or ISO ones.

    The current INCOSE Systems Engineering Handbook defines a system as:
    ‘an integrated set of elements, subsystems, or assemblies that accomplish a defined objective. These elements include products (hardware, software, firmware), processes, people, information, techniques, facilities, services, and other support elements.’

    It was therefore impossible to use MODAF::System to represent what is currently accepted to be a system. So what could we use? As a system is a mixture of hard and soft resources it made sense to position at the centre of TRAK:

    In TRAK System is central to the metamodel

    TRAK::System - Central to the Metamodel

    Immediately therefore this allows us to describe systems

    • composed of a mixture of equipment, software and people - not just physical
    • composed of just software or of just human stuff - soft systems

    and we don’t need ‘Sub-system’ either or ’System of Systems’ since the terms just reflect a point of view in the hierarchy of systems and we already have the construct ‘System is configured with System’ to allow us to represent systems at any level. In fact if we introduced sub-system we would be forcing architects to make a choice and with choice comes difference of opinion and the potential for inconsistency - my Sub-system might be your System and so on.

    Now Add People

    The choice of metamodel elements is important, particularly when you add people (users of the metamodel) into the mix.

    Some of you will be looking at the TRAK metamodel fragment above and thinking ... Capability Configuration. Indeed in MODAF this is where Capability Configuration sits. So is Capability Configuration correct? As defined it cannot be - Capability Configuration is still part of the Physical Architecture.

    The bigger problem, however, is that you end up using one element but with the meaning of another. It’s easy to see how this might arise - being not allowed to add parts to MODAF::System the architect takes the stereotype that does allow him or her to add the stereotypes that they want - the Capability Configuration. It is possible that they don’t even see the problem in doing so. The trouble is that they describe something as a system but use Capability Configuration. Their ‘head-model’ doesn’t fit the meaning of the model elements used.

    It is actually worse because in providing MODAF::Platform and MODAF::System there is a choice to be made - when is something a platform and when is it a system? You can almost guarantee that different choices will be made and therefore it makes it more likely that architecture descriptions (models) can’t be ported between organisations. In fact the poor modeller has 3 stereotypes that can be used to mean ’system’ (in their head) - the MODAF::Capability Configuration, MODAF::System and MODAF::Platform. On the receiving end you can’t predict which will have been used.

    This is why in TRAK there is only 1 TRAK::System. It’s flexible, can be used for hard or soft systems and, importantly, ‘there shall only be one’ - no sub, super or whatever-system.

    You describe the context simply by the system boundary and hierarchy. Easy.

    After all a system is a system.

    Acknowledgements

    The MODAF is Crown Copyright/MOD
    The TRAK Metamodel is released under the GNU Free Documentation License.

    Comments

    Comment on this article

    Related Articles

        Sharing tags:

        External Links

        Is this Architecture? Where is the sentence?

        by Nic Plum on Sunday 07 February, 2010 - 15:42 GMT

        Posted in Architecture Modelling

        Tags: meaningnatural languagenounontologyrelationshipsentencesystem authoritytupleusabilityverb

        What is architecture when we are modelling? We might have architecture elements but is this enough? Consider the following thought experiment.

        Is this Architecture?

        On the first line we have 2 things. We don’t know what type they are. We can’t say anything about them and therefore this cannot be architecture.

        On the second line we know that they are both systems and there is some unidentified relationship between them. We know nothing about this relationship in terms of what it is or the direction. This still cannot be architecture.

        On the third line we know we have 2 systems and that System A is configured with System B. At last, this is architecture! But why? The fact is that we know how these 2 things relate to each other and this is at the core of architectural modelling. It is about describing relationships between things and placing things in their proper context. In many cases we are probably more concerned with the relationships between architecture elements than the detail of the elements themselves since we can then navigate along these paths or use them in queries to answer questions or discover things. This is one of the key differences in emphasis between an Enterprise Architect using, say, a UML tool, to a Software Designer. It probably also is at the base of a lot of frustration with tools.

        At a more general level this is architecture because it provides all the parts of a language to allow us to describe what the situation is - we have 2 nouns and a verb so that we have a proper sentence. Without the verb (the relationship) we do not have a sentence and therefore cannot communicate anything meaningful.

        This might sound trivial but it is important. It states that we need 3 things for it to be considered architecture - an object, a verb and the subject of the verb. In other words this looks like a tuple or a triple which is an important construct for an ontology. I suppose I sort of realised this but it was only in trying to define what is mandatory and what is optional for an architecture viewpoint (in ISO 42010 terms) that it became clear that just specifying metamodel elements wasn’t enough - the meaning is in the tuples.

        The other advantage of treating it like a natural language is that it makes it easy to communicate with folks who aren’t UML experts. Take for example the following 2 examples.

        Examples - Architecture Provides a Natural Language


        Reading from left to right we have;

        • Whizzo Dynamics (an organisation) plays the role of system authority which extends to Confabulator (a system)
        • System Authority (a role) requires competence in architecture modelling in order to conduct Design System (a function)

        and as architecture modelling ought to be about communication this is starting to be both useful and effective from a usability perspective.

        Comments

        Comment on this article

        Related Articles

            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.