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 = 'System Of Systems'

Entries that have been tagged with 'System Of Systems'.-

A MODAF Architecture Description Only Applies to a ‘System of Systems’?

by Nic Plum on Thursday 22 September, 2011 - 12:29 GMT

Posted in Architecture FrameworkMODAF

Tags: 1.2.004architecture descriptiondefinitionm3sossystem of systems

In the MODAF metamodel (M3) v 1.2.004 we have:

ArchitecturalDescription : public <<stereotype>> class

A specification of a system of systems at a technical level which also provides the business context for the system of systems.

This definition of an architecture description has been unchanged since at least v 1.1 (May 2007).

This defines an AD as a specification. This is too restrictive and doesn’t fit current usage within the MoD since MODAF ADs are more often used to discover and analyse the architecture that exists in order to assess the impact of decisions or proposed design changes.

The real problem is the ‘system of systems’ bit because it looks to be misusing the term. In restricting an AD to a ‘system of systems’ and not ‘system’:

     
  • Are they then saying it is only an AD when it describes a ‘system of systems’? Since a ‘system of systems’ is formed from systems that have an independent existance this definition means that you can’t have a MODAF AD of a submarine where the systems are tightly coupled and have no meaningful existence away from the submarine.
  •  
  • Are they saying MODAF cannot be used to describe a vanilla system? This states that a description of the architecture of a system (formed from essential parts that aren’t themselves systems) isn’t an AD.
  •  
  • Are they saying that ‘system of systems’ is a new type (in which case how do they know it can be described using MODAF)? This would be technically incorrect since a ‘system of systems’ is of the type ‘system’ with the emergence et al that this brings.

I don’t for one minute believe that any of this is the intent nor that this represents how MODAF ADs are intended to be used. It doesn’t therefore reflect the real use of an AD and needs to be changed to make it a valid definition.

The good thing is that the MODAF M3 recognises the distinction between the architecture (of the system) and the thing that describes it (the AD). Far too many others confuse the 2 concepts

Comments

Comment on this article

Related Articles

    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

        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.