Listing all articles in The Residual World under the category 'Architecture Framework' :

MODAF is Dead - Long Live ‘NAF’?

by Nic Plum on Monday 02 March, 2015 - 23:00 GMT

Posted in Architecture FrameworkMODAFNAFStandards

Tags: architecture frameworkmodafnafnato

Integrated EA presents an interesting and useful opportunity to learn, listen and talk about enterprise architecture, mostly but not always from a defence and aerospace application and not just from the UK but other parts of Europe and the world that have experience in the application of MODAF, DODAF, NAF and similar architecture frameworks. The event was created by Ian Bailey of Model Futures who was one of the ‘elves’ behind the creation of MODAF and who has maintained parts of the documentation and the MODAF metamodel (M3) since. This year’s Integrated takes place this week on 3/4th March 2015 at One Great George Street, London.

Ian has posted on the Integrated EA blog about the imminent demise of MODAF as a distinct architecture framework since it is about to join forces with the Nato Architecture Framework (NAF). Ignoring the name, NAF hasn’t had a good record over the years in terms of its documentation and because the metamodels for NAF and MODAF were significantly the same it was often the case that architects would use MODAF documents to produce NAF views (or ‘models’ as NAF calls them - the terminology differs between frameworks and the ISO/IEC/IEEE 42010 standard).

The post makes for interesting reading. In his post Ian mentions TRAK:-

MODAF spawned TRAK, which was free of the legacy user base MODAF had, and so was able to do a lot of things we’d been trying to do in MODAF for a long time

I’m still jealous of the freedom Nic had when he developed TRAK, and I still like the idea of an open-source framework.

.

so we must clearly be doing something right which is nice to know as Ian knows his stuff! Presumably this must also apply to NAF - unless they’ve ditched their roots or elected not to make some aspects backwards-compatible.

On this very site in 2011 I suggested that it would be a good idea to merge MODAF and NAF since they were converging, it didn’t seem sensible to have two similar but different sets of documentation etc. and the overhead in terms of maintenance and development cost must be significant. In the interim period we’ve had the economic downturn / crash and the financial imperative for efficiency / cost saving must be even greater. What never occurred to me was that MODAF would disappear or be absorbed into NAF. It therefore seems very unfair that the reward for MODAF being more consistent, having better documentation and being ahead is to lose its own identity. I suppose there is still much collaborative effort but all of the user-facing terminology seems to be very much that of NAF.

A quick look at the new set of NAF::’Models’ ( aka MODAF::’Viewpoints’) shows that there has been some attempt to simplify the naming of the models/viewpoints (something TRAK has had from its inception). It’s also nice to see some principle of organisation for the models/viewpoints in the grid view. This is very reminiscent of Zachman. They have also attempted some rationalisation to improve consistency. What seems to have disappeared is the MODAF Acquisition Viewpoint and it looks as though the MODAF AcV-2 Programme Timelines View is now part of the NAF:Logical Specifications. [ How any high level architecture description can be considered to be a ‘specification’ is beyond me since it doesn’t support the basic ideas behind attributes of requirements let alone completeness of specification. This seems to be the Holy Grail of folks with a software background but inconsistent with readability / understandability / basic user interface principles e.g. if it’s complete enough as a coded specification it’s also likely to be highly technical, use formal notation that is capable of supporting machine-validation and completeness-checking and increasingly impenetrable to the user. This also ignores the “..ilities” and non-functional aspects of a specification because most notations seem to be designed to describe structure, messaging or behaviour.] The MODAF AcV-1 which described the structure of projects seems to have disappeared. It ought to fit under the NAF Structural heading but this is occupied by the NAF Logical Scenario which is an entirely different view so there are clearly going to be some significant problems to overcome in eliminating MODAF viewpoints and merging MODAF views with the NAF cousins.

If only the new NAF would take on board some reasonable amount of compliance with the international standard in terms of terminology we’d start to see some real progress based on standardisation. There are encouraging signs that someone behind NAF is taking some notice of the standard e.g. ‘A3 Architecture Correspondence. ISO 42010’ which I assume has something to do with correspondence rules but without any detail it’s impossible to see whether this complies. “It’s progress Jim, ..”.

MODAF might be nearly dead but it’s very hard to shout “long live NAF” - yes, Ian, something must really be done with that acronym otherwise we’ll have have “NAF models ..”, “NAF specifications” … and you can only have so much NAF-ness!  wink

Comments

Comment on this article

Definitions - What Exactly is a Risk Part 2?

by Nic Plum on Monday 05 August, 2013 - 21:46 GMT

Posted in Architecture FrameworkTRAK

Tags: definitionhazardontologyriskstandardthreat

In part 1 we established that a lot of the current definitions of risk don’t actually define what a risk is - they simply define a formula for calculating it or prioritising it which doesn’t help us get at what a risk is and therefore whether it is a distinct entity.

The OED has a definition:

(Exposure to) the possibility of loss, injury, or other adverse or unwelcome circumstance; a chance or situation involving such a possibility

Dissecting this with the old semantic scalpel we have parts:

  • possibility or chance
  • adverse circumstance
  • a situation

Possibility or Chance

A risk always has a probability of occurring. This therefore means that the metamodel entity has ‘probability of occurrence’ as an attribute. It also means that there are qualifying values in order for it to be a risk - the probability of occurrence cannot be zero since there is then no possibility and it cannot be 100% either because it is then a certainty not a risk.

Adverse Circumstance

A risk is associated with a harmful outcome (the positive flip side is an opportunity). We can represent this using a relationship between risk (if the vehicle for risk is an event) and hazard (threat).

A Situation

This starts to sound like an event through which the unlucky recipient is exposed to the risk. Is this a risk or is it really a description of a risky-event? 

Much the same thing happens to hazard where at least one definitions defines a hazardous event not a hazard. In IEC 61508:2010 part 4 Hazard is defined as:

potential source of harm [Guide 51 ISO/IEC:1990]

but then add

NOTE – The term includes danger to persons arising within a short time scale (for example, fire and explosion) and also those that have a long-term effect on a person’s health (for example, release of a toxic substance).

which isn’t correct because the release of a toxic substance is not a hazard but a hazardous event. The toxic substance represents the hazard. This is important because we’d represent hazard and hazardous event differently with a relationship between a Hazard and Event and the combination becomes the ‘hazardous event’.

Is something similar happening with risk in common parlance or definitions?

If a Risk is a distinct entity we have:

  • Hazard (syn. Threat) poses Risk
  • Risk is a Event (where 100 > probability of occurrence > 0)

and we can have

  • Hazard (syn. Threat) to Resource (i.e System, Physical, Software, Organisation, Job or Role) 

to introduce the required ‘harm’ or ‘adverse circumstance’.

The limits on probability of occurrence have to be applied because if it is 100% it isn’t a possibility it’s a certainty and therefore no longer a risk.  Similarly it cannot be zero because it can never happen and is therefore not a risk.

We could of course just represent a Risk using Event where the value of an attribute ‘probability of occurrence’ takes a value between these limits when representing a risk and is otherwise null or 100% if representing a ‘straight’ Event.

Of course even if it is a type of event there are advantages in making it a distinct entity since as an element in a tool it makes it easy to find, to navigate to or from and to distinguish it from a straight event. This utility might justify it being distinct.

So, is a risk a type of event?

Comments

Comment on this article

Just When You Thought It Was Safe - EntiTy Returns

by Nic Plum on Wednesday 13 March, 2013 - 21:33 GMT

Posted in Architecture FrameworkTRAK

Tags: safetysecuritysourceforgetrakworking group

TRAK logo

Sorry for the awful pun…

A small band of happy volunteers have been musing over possible extensions to TRAK to provide viewpoints that address typical safety and security concerns. As part of the ongoing activity a candidate set of concepts / entities for the TRAK metamodel have been described in a short document together with some of the backgrounds from which they arise. This has been published and comment / discussion is being encouraged on the forum on the TRAK Viewpoints project on Sourceforge. If you have any views on the candidate entities please post them there.

There will be other follow-on documents soon:

  • a definition of the candidate relationships that knit these entities together and to the residual TRAK metamodel
  • a definition of the candidate viewpoints (ISO/IEC/IEEE 42010 terminology) against which views are prepared that use the candidate and existing parts of the metamodel

There will then follow a testing phase to ensure that what is proposed is usable, easily understood, pragmatic and of utility (fit for purpose - but no more than necessary as we don’t want perfection at the expense of usability) for jobbing engineers and those who need to be able to read and understand the products and who aren’t in any technical priesthood. If anyone wishes to help in this testing phase can they please make contact either via this site or the Sourceforge discussion forum for the Safety and Security Working Group.

Comments

Comment on this article

All articles/posts © of the respective authors

Site design and architecture © 2010 - 2011 Eclectica Systems Ltd.