Summary

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

Be the first to comment on {resource_type} Just When You Thought It Was Safe - EntiTy Returns

Categories: Architecture Framework, TRAK

Tags: safety, security, sourceforge, trak, working group

Summary

Creating a definition sounds as thought it ought to be easy. It isn’t for many reasons - some of these are not so much technical as the process by which consensus is reached and the need to get consensus. For example the need to get consensus might mean that at times a weaker definition escapes because it was too difficult to get consensus with a tighter one.

Why do we care? Well there is a particular and a more general reason. The more general one is that the graphic blocks we use to represent the real world things have definitions and therefore the architect is supposed to select the most appropriate block to represent the real world thing based on the description. We can’t just choose anything otherwise we end up “head-modelling” where the verbal description we provide is not supported by the semantics of the model we’ve created (the model in our head is not the one on paper). If the description is wrong it might not be the right block to use (you wouldn’t represent ‘tank’ with a ‘tree’).

The particular reason is that we’ve a working group in TRAK looking to see if and how it is possible to extend TRAK to enable it to be used to address typical safety-related and security-related concerns. One of the starting points is therefore a review of general literature and particularly standards to identify the potential concepts or entities likely to be needed. In doing so we’ve found some potential problems with definitions.

A candidate entity is risk. What is a risk?

IEC 61508:2010

combination of the probability of occurrence of harm and the severity of that harm

MIL STD 882E

Mishap Risk. An expression of the impact and possibility of a mishap in terms of potential mishap severity and probability of occurrence.

NIST

The net mission/business impact considering (1) the likelihood that a particular threat source will exploit, or trigger, a particular information system vulnerability and (2) the resulting impact if this should occur.

There is a common thread. Many other standards also have very similar forms of definition. None of these, however, defines what a risk actually is The analogy is defining force as the product of mass and acceleration - it tells us nothing of what force is. None of the above are therefore definitions of risk they just indicate how we might derive a metric for it. One of the principles in defining something has to be that the definition is independent of other variables or an implementation. In the above if risk didn’t involve probability of occurrence it would mean that the concept of risk itself had changed which isn’t true.

My dictionary provides:

a possibility of harm or damage

IEC 61508:2010 defines a Hazard:

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

’ which is fine but then in the note that follows it states ‘….for example, release of a toxic substance…’ which looks to be a hazardous event not a hazard.

All of this means that it is harder and takes longer than it should do to analyse and form a view of a pragmatic compromise because you have to examine every word and be selective in what you choose to accept and what you choose to reject. You cannot blindly assume that any standard is correct since it is as much the product of gaining consensus as it is the technical content. You have to be a skeptical enquirer and constantly challenge. Too often folks put such committees on pedestals and don’t stop and think.

Comments

Be the first to comment on {resource_type} Definitions - What Exactly is a Risk?

Categories: Architecture Framework, TRAK, Standards

Tags: defence, definition, dod, iec, nist, safety, security, standard, trak, usa

Summary

This is something that has been bumbling around for some considerable time - safety and security. By that I whether there is something useful that an enterprise architecture view can be used for in the system safety and security disciplines.

On the face of it there is quite a bit of overlap. Both are ultimately concerned with risk inherent in a solution design which arises from threats (security) or hazards (safety). Both involve management with the aim to reduce the risk, threat or accident (safety) to an acceptable or tolerable target. I suspect also that security management also uses categories to classify acceptable severity or probability in much the same way that the various system safety management standards in defence do (MIL STD 882D, DEF STAN 00-56). Both also involve mitigation of risk by design - through structure, behaviour, or adherence to a normative process of some sort.

There are bound to be some differences, not the least of which is terminology. In the security area we seem to have constructs like:

• Threat poses Risk
• Threat exploits Vulnerability
• design aka TRAK:Resource (System, Software, Organisation, Job or Role) exposed to Risk (and subsequently that Risk is mitigated by the (improved) Resource or Function (of that Resource)

In the safety area we seem to have constructs like:

• Failure may present Hazard
• Hazard can cause Accident
• Accident poses Risk
• Resource exhibits Failure

and attributes such as probability, impact, severity.

Anyway it seems sensible to open up the debate so I’ve posted some thoughts in the forums within the TRAK Viewpoints project site on Sourceforge. Something is definitely needed and my hunch is that there is so much overlap that it would be possible to create a Viewpoint that addresses the risk within a solution design. This may of course end up being two viewpoints depending on the concerns and therefore concepts (metamodel stereotypes) and relationships involved. What is needed is more debate and input from those involved with system safety and system security - hence the post. As ever with TRAK the objective is economy so that we have something that is just or barely adequate to describe the concerns and concepts involved and no more.

Comments

Be the first to comment on {resource_type} Risk and Threats - The Common Ground Between Security and Safety?

Categories: Architecture Framework, TRAK

Tags: def stan, defence, forum, iso42010, mil std, ontology, risk, safety, security, solution, sourceforge, standard, threat, trak, view, viewpoint, vulnerability

Summary

Every viewpoint in TRAK is a specification for an architecture description view. In accordance with ISO/IEC 42010 each address one or more typical concerns using a combination of tuples (stereotype - relationship - stereotype combination taken from the TRAK metamodel). The tuples have therefore to contain the right types and relationships to address the concern and the concerns (and therefore the tuple sets) must be distinct from those addressed by other viewpoints. This keeps clear water between viewpoints and it means that the number of viewpoints needed is kept to a minimum because they aren’t driven by domain or application of viewpoints.

What then of the TRAK CVp-02 Concept Viewpoint? This is currently defined as answering concerns has the concept purpose been identified? and How is it seen as being used? and the tuples as:

Expected to be largely textual and scenario based but with use of other concept perspective architecture views to illustrate, expand, define.The set of tuples will be those from the mandatory sets of the concept perspective views used against CVp-01, CVp-03, CVp-04, CVp-05 and CVp-06.The selection of concept views used to illustrate the scenarios is left to the architect.

from TRAK. Enterprise Architecture Framework Viewpoints. 2nd October 2011

This isn’t good enough. None of this needs anything which isn’t already provided by one or more of the other viewpoints in the TRAK Concept Perspective. The purpose of a concept is embodied through its relationships with the solution or potential solutions that realise it and its relationship with the enterprise and the enterprise goals. The content of a concept is already covered by existing viewpoints and there is nothing that makes this viewpoint distinct from any others. Historically it was an analogue of the MODAF OV-1 which included a high level graphic and a textual version used to present ideas to senior management in an easy to digest form:

The OV-1a provides a graphical executive summary of the architectural endeavour, which describes the interactions between the subject architecture and its environment, and between the architecture and external systems. A textual description accompanying the graphic is essential, with labels on the graphic and a detailed description in the OV-1b. Graphics alone are not sufficient for capturing the necessary architecture data.
The purpose of OV-1a is to provide a quick, high-level description of the business objective that the architecture is addressing, and how that objective might be achieved. An OV-1a can be used to orient and focus detailed discussions. Its main utility is to communicate the purpose of the architecture to non-technical, high-level decision makers.

from The MODAF Operational Viewpoint. 26th April 2010.

In TRAK any view can be presented using graphical elements as long as the type of object is shown and with simple text labels on relationships it is easy to produce something that most people can simply read in a natural way so the presentation is never a justification for a separate viewpoint.

On the face of it there is no good reason for keeping this viewpoint and the best thing is to remove it. The recommendation has been made as a change request (#3475115) and unless anyone makes a good reason to keep it the sentence will soon be carried out ....

Comments

Be the first to comment on {resource_type} Every Viewpoint Has to Be Distinct - Say “Goodbye” to the TRAK CVp-02 Concept Viewpoint

Categories: Architecture Framework, TRAK

Tags: concept, trak, viewpoint

Summary

This is one of those slightly strange happenstance events - completely unplanned although not beyond the original intent.

At the 2010 INCOSE Annual Systems Engineering Conference Chris Lowe and I presented on ‘Human Factors - On the Right TRAK?’ which looked at the consideration of human factors in the design or TRAK itself and the use of TRAK for human factors work’. At the time INCOSE only really wanted the presentation and anything else was optional. In the end we decided to go over the top and produce an accompanying document in some detail. As much as anything this was to make sure the essence / thinking was preserved since looking at some thinly-worded slides might not convey what was done in person at the time.

Some months later the Singapore Institution of Engineers approached INCOSE to ask if they could reproduce the article. Naturally we said “yes” - the original is on Slideshare in any case. Many more months passed and nothing happened and then in September 2011 they asked for the source files but had some problems using them which meant their deadline was missed. Anyway it looks to have been published at long last.

Having had a look it looks as though they’ve missed Chris off the headline (but he is in the acknowledgement at the end). Had we have been asked we could have provided decent graphics since it looks as though something has got munged in the publication.

Comments

Be the first to comment on {resource_type} TRAK Article Published by The Institution of Engineers (Singapore)

Categories: Architecture Framework, TRAK

Tags: incose, institute, publication, singapore, trak

Summary

Just received news from Rich Hilliard via the IEEE 1471 Users List (to become the “ISO/IEC/IEEE 42010 Users List):

Today I was notified that IEEE P42010 was approved as a revised standard by the IEEE-SA Standards Board on 31 October 2011.

This standard replaces IEEE 1471:2000 and is identical to the ISO standard approved in July with 21 approvals and 0 disapprovals from member bodies.

The new standard, designated ISO/IEC/IEEE 42010:2011, Systems and software engineering—Architecture description, is available from IEEE and ISO.

The IEEE 1471 website will become the ISO/IEC/IEEE 42010 website.

The old website will redirect to the new URL which is:

• http://www.iso-architecture.org/42010/

Looking at the website I noticed

Per IEEE rules: An approved IEEE standard will remain active for   ten years. If the Sponsor does not complete a revision process   within ten years, the standard will be transferred to inactive   status.

Curious to know whether this means a standard has to be revised or whether the requirement is simply to review - it might still be a perfectly good standard even if it hasn’t been revised since the decision might be on review that it’s good enough.

Having to say ISO/IEC/IEEE every time is a bit of a mouthfull and therefore inevitably will be shortened in everyday use. Is there an acceptable shortform(s) e.g. ISO 42010, IEC 42010 and IEEE 42010? It’s unlikely in speech that the full qualification will be used.

Comments

4 comments

Comment on ISO/IEC/IEEE 42010:2011, Systems and software engineering—Architecture Description Released

Categories: News, Standards

Tags: ieee, iso, iso42010, news, standard

Summary

TRAK is a finalist in the 2011 IET Innovation Awards. As the IET say:

The IET Achievement Awards recognise the exceptional achievements of individuals working in the engineering and technology profession, from the well-known scientist to the fledgling engineer.

It was judged under the IET’s Asset Management category. It wasn’t easy to submit since it didn’t easily fit any of the categories against which judging was to be made. This is an all-too typical problem for systems engineering itself, for example under which subject category in a bookshop do you look for systems engineering books?

The IET’s judging criteria for the Asset Management category is:

The judges will look for originality and will place significant emphasis on the contribution made to whole life asset management, risk management and the impact on business performance.  Other factors include progress with implementation, integration into the business and the contribution to asset knowledge.

Last Friday (23rd September) the response came back:

I am delighted to inform you that your entry “TRAK - An Open Source Enterprise Architecture Framework”, reference 0383 has been selected as a finalist for the Asset Management category of the IET Innovation Awards 2011.

It was extremely competitive, with over 400 entries to the awards, but the judges felt that your innovation was amongst the best.

The finalists are listed on the IET Innovation Awards website.

Awards will be announced on 9th November at the Intercontinental Hotel in London.

The IET Innovation Awards 2011 will be hosted by Robert Llewellyn, actor, writer and presenter best known for playing the role of ‘Kryten’ in the hit science fiction sitcom Red Dwarf.

We’ve always thought of TRAK as innovative not just in the product and its definition but in the approach and how it is managed. It’s nice to know that people that are independent think this as well!

Comments

Be the first to comment on {resource_type} TRAK is a Finalist in the 2011 IET Innovation Awards

Categories: Architecture Framework, TRAK, News

Tags: award, iet, innovation, institute, london, news, trak

Summary

It’s very hard when everyone seems to be claiming conformance with ISO/IEC 42010 to establish whether the claims are true. All too often we get ‘partly compliant with ’ which means what exactly? As a standard trying to get standardisation in the field of architecture description and trying to eliminate the variability and anarchy it isn’t much use to be partly compliant (any more than claiming to be partly pregnant). You either do or don’t conform. The hard work put in by those that try to conform to the standard is undermined by those that claim conformance but don’t actually conform.

I’m pleased to be able to say that TRAK has agreed to take part in a pilot against an official ‘conformance assessment instrument’ prototype that is being developed against ISO/IEC 42010:2011 which is soon to be jointly published by both the IEEE and ISO. The conformance instrument applies to Architecture Frameworks, Architecture Description Languages and Architecture Descriptions.

As ever I’m sure the assessment and feedback will benefit both sides in refining and sharpening up the documentation. These are early days and no doubt some ideas still need to be worked through, hence the pilot using the prototype conformance instrument.

I’m quietly confident with respect to TRAK itself (time will tell!) but more importantly it will be useful to have an independent assessment of any claim to conformity whereas the current situation allows any Tom, Dick or Harry to claim conformity with impunity and where no sanctions can be applied. I look forwards to this situation being changed.

Comments

Be the first to comment on {resource_type} Conformance Assessment vs ISO/IEC 42010:2011

Categories: Architecture Framework, TRAK, News, Standards

Tags: compliance, conformance, ieee, iso, iso42010, standard, trak

Summary

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

Be the first to comment on {resource_type} A MODAF Architecture Description Only Applies to a ‘System of Systems’?

Categories: Architecture Framework, MODAF

Tags: 1.2.004, architecture description, definition, m3, sos, system of systems

Summary

ADLs and Architecture Frameworks

Any architecture description language, e.g. UML, BPMN, ArchiMate potentially can be used to represent the views in any architecture framework. Whether they can or not depends on whether they have the necessary concepts/entities to suit those in the architecture framework and architecture viewpoint that governs the view content. The reality is however that as ADLs have been developed for different and often more generic purposes they all have limitations when used for an architecture framework. They may, for example, lack concepts that are needed or they might have rules which mean that relationships that are needed cannot be established. In the terminology of ISO/IEC 42010 their concerns might not align with the concerns addressed by the architecture framework and one or more architecture viewpoints within that framework.

Of course such a central assessment not only applies to UML but for any other language used to represent TRAK architecture viewpoints. After all this is architecture description and this is what it’s all about, surely - identifying the relationships and communicating them? Trouble is I can’t see anyone else doing it (or if they are they keep it out of the public gaze). For the life of me I can’t understand why you wouldn’t want the users to to use a tool or use a particular ADL without knowing the implications and limitations of this implementation. It’s inevitable that there are trade-offs because the ADL wasn’t designed for the specific purpose.Even if a view cannot be represented there is usually a workaround. Even if there aren’t workarounds it will only matter if the concerns of the task sponsor require the viewpoint that cannot be implemented. Knowing what you can and can’t do with a tool and with an ADL in that tool and therefore the suitability of both for the task(s) is important. How many architecture frameworks do you know that make this information publicly available?

The Assessment of UML Suitability to Represent TRAK Architecture Viewpoints is Part of the Implementation of TRAK i.e. Solution

TRAK

This mapping between ADL and architecture framework and therefore the suitability of the ADL for use seems to be something that is traditionally a dark secret.  In the interests of keeping everything in the open so that the user can make an informed decision I’ve mapped UML (as implemented in the UML profile for TRAK project on Sourceforge) against TRAK. Specifically I’ve identified the mandatory and optional tuples for each TRAK Viewpoint and compared them against the combinations of UML stereotype that would be needed and identified whether UML allows these combinations and can therefore be used to represent each TRAK tuple.

Although the TRAK metamodel is tiny by comparison with others (only types of architecture description element can appear in TRAK architecture views) there are a lot of relationships between them and therefore a lot of tuples that provide the many paths or routes through the TRAK metamodel and therefore richness of description available to the user. I think I’m right in saying that a metamodel is really a directed graph (so don’t get misled by the relative prominence of the big block things - they’re not the most important parts).

What falls out of this is a list of:

 
• TRAK Viewpoints (and therefore views) that UML can fully realise - 19 or the 22 TRAK viewpoints
 
• TRAK Viewpoints (and therefore views) that UML can partially realise - 2 viewpoints: CVp-03 Concept Item Exchange and SVp-02 Solution Resource Interaction
 
• TRAK Viewpoints (and therefore views) that UML cannot realise at all. There is only 1 viewpoint - the SVp-03 Solution Resource Interaction to Function Mapping Viewpoint because UML doesn’t permit a UML::Activity to be connected to a UML::InformationFlow and therefore this either has to be done manually or using a SQL query if the AD is stored in a database.

Importantly I’ve tried to identify why UML can only realise some viewpoints partially or not at all and the consequences of this with any workarounds.   This sort of situation exists in other frameworks. The difference here is that I felt it made sense not only to be open but to do this once in a central location rather than everyone do it in their own space time and time again.

Of course it depends on whether the UML profile is sensible (it may not be) and whether my assessment is correct (I’m no UML expert). The spreadsheet on which it is based has been circultaing around theTRAK SG members for some months including Simon Perry from Atego (who understands a lot more about UML than I do).

It is distinctly possible that there are errors or it can be improved. There is a tracker on the Sourceforge trak project for all of the documents that implement TRAK where you can submit comments or errors spotted. The assessment itself is in the/Suitability of Architecture Description Languages/UML/ directory within the trak project.

It is part of a big exercise to make things clear and place in full public (i.e. for users as well as tool implementers) so that we have clear mappings between:

 
1. TRAK and ISO/IEC 42010
 
2. each individual ADL and TRAK
   

so that where there are limitations or trade-offs you can see where these occur i.e. they might be in the international standard, in TRAK, an ADL or the implementation of an ADL in a tool.

Implementing TRAK in Another ADL?

As part of this exercise I’ve created an Open Office spreadsheet template which can be used to support the assessment of the suitability of that ADL for representing TRAK architecture viewpoints and therefore views. It is the basis of my assessment of the UML profile for TRAK.

You should use this template so that there is consistency in the approach taken. It is updated in line with the TRAK Viewpoints and TRAK Metamodel definitions.Please consider making the assessment available centrally so that others can find it and so that they don’t have to repeat the exercise. We have the space on the trak project to host these. If anyone has an alternate UML profile of TRAK I’d be interested to see the differences in implementation and this again would need to be assessed. Obviously we really only want representation or mapping for any one particular ADL.

Comments

Be the first to comment on {resource_type} Assessment of the Suitability of an ADL (UML, ArchiMate et al) to Represent TRAK Viewpoints/Views

Categories: Architecture Framework, TRAK, Standards

Tags: adl, architecture description language, architecture framework, implementation, solution, spreadsheet, template, trak, uml

Summary

There is a constant need to reduce the scope for inconsistency in any architecture description. TRAK is no different. TRAK has been defined in a way that is free of implementation and using natural language wherever possible. One of the pitfalls of this is the possibility that names will be implemented inconsistently in tools. For example, the attribute ‘start date’ might be called ‘start date’, ‘start_date’, ‘startDate’, ‘Start Date’ and so on. The danger in this is that upon exchange the receiving tool might not recognise this if it is using, say, ‘startDate’.

I’ve therefore created a document titled ‘TRAK. Implementation. Architecture Description Elements’. To put it into context a couple of diagrams (produced using the OmniGraffle stencil for TRAK):

The TRAK. Implementation. Architecture Description Elements Document is Part of the set of Documents that Improves Consistency of Exchange of an Architecture Description

Article continues…

Comments

Be the first to comment on {resource_type} Improving Consistency for Tools - ‘TRAK. Implementation. Architecture Description Elements’ Document

Categories: Architecture Framework, TRAK, Tools

Tags: architecture description, consistency, document, exchange, implement, solution, standard, tool

Summary

This is a bit of a tale, and not an unusual one at that. It concerns the development of a stencil for the Omni Group’s OmniGraffle drawing application which is available for both Mac and iPad. I’m a long time user of OmniGraffle Pro (at least 8 years) as well the the Mac (still have my original Mac Iici working) and OmniGraffle is just an easy to use and intuitive means of producing good drawings. All of the stuff in the defining TRAK documentation is produced using it.

Anyway, thought it might be an idea to have a stencil of the stereotypes and relationships to be able to knock up a quick TRAK architecture view when I felt it merited it (rather than firing up a bigger modelling tool such as Sparx Enterprise Architect). It’s all about horses for courses.

The OmniGraffle Stencil for TRAK Implements the TRAK Definition

The Beginning - Fumblings

Not knowing anything about developing a stencil I simply created the blocks needed for the TRAK views and added a set of connectors for the relationships having labelled them. Then I discovered on loading the stencil that OmniGraffle presents the bare connectors separately from the labels for those connectors so there were many connectors in the stencil all seemingly the same. Started again. This time I just had 2 connectors and a text label for each relationship. This cut down the noise but I discovered that on the iPad version it wasn’t easy to use these as it didn’t seem to allow you to drag the label onto the connector and for the 2 to remain locked together as it would do on the desktop version. Started again. This next version had separate connectors, each with it’s own label but this time I grouped the label with the line and this indeed stopped the stencil from displaying them separately.

Sharing

Now I felt I was starting to get the hang of it. The obvious choice was to lodge this onto Sourceforge with all the other TRAK stuff so I created a new project (trakomnigraffle) and then discovered the front end of Sourceforge had changed so much I no longer knew where to go to do what in setting it up. This looks to be a consequence of security and an earlier attack on Sourceforge this year. Then I remembered GraffleTopia. This is a site that holds stencils and templates for OmniGraffle. Even better it’s moved on apace such that when looking for a stencil in OmniGraffle, including the iPad, it will display results from GraffleTopia for download/installation. Sounds good so I duly submitted the stencil. It appeared last Friday on the 12th August so very pleased. The ability to see how many downloads is nice. Sure enough I found it does appear within the desktop and iPad versions and you can download it from the iPad version. For whatever reason it throws an error in OmniGraffle Pro when you select it for downloading. I then had to spend time submitting a bug report.

I know that OmniGraffle supports user data in terms of a set of keys and data values. It seemed therefore sensible to implement the attributes for the various elements in the TRAK metamodel. This would allow more information to be captured and it looked likely to offer a path through which a XML export could be produced with these which would allow a sensible conversion or import via XMI into a UML modelling tool. I then updated the stencil so that each object has the right set of attributes. Great - making progress! I then update the Sourceforge site and go to the GraffleTopia site to upload the new version only to find that it doesn’t support the workflow involved with an update -

Update: Have now found the link to edit and resubmit new versions of the stencil so can only assume it was stupidity and/or blindness on my part. The good news is that GraffleTopia and Sourceforge are in sync!

More Ideas, More Problems

Having all these attributes as user data is good. Trouble is I then thought it’d be nice to be able to copy the attributes and perhaps the values from one object to another. No problems - this is a job for AppleScript (a venerable but very useful scripting technology that operates across the Mac platform and has done so for many many years) which could automate this. Luckily I have a decent debugger but even so it wasn’t going well owing partly to ignorance or forgetting things on my part not having used it for a while. I had to call on support from the ‘Support Ninjas’ at OmniGraffle and each time I’ve managed to move it forwards. I’ve now got to the stage where I can populate a set of shapes with a set of TRAK attributes. Even better it recognises if there is a key with data that exists and asks whether it should continue and wipe this data out for that key or just skip this item. You can see it’s getting ever more complicated which I suppose is the penalty for user-friendliness. Unfortunately it hit a problem when testing for a key name that doesn’t exist. After another response from the OmniGraffle Support Ninjas it seems there is a bug with the AppleScript object in OmniGraffle which causes it to return an undefined object and causes a runtime error. I have been directed to a workaround but it’s going to take a while to get my head around this.

Continues on site…

Comments

Be the first to comment on {resource_type} Things that You Think That Are Going to be Simple Never Are

Categories: Architecture Framework, TRAK, Tools

Tags: applescript, application, bug, develop, drawing, implement, ipad, mac, omnigraffle, opensource, sourceforge, stencil, support, tool, trak

Summary

TRAK benefits from a lot of effort put in by a group of people who do this because they believe in it and have the motivation to get stuck in. A lot of this is invisible behind the scenes work and it is all unpaid. I can’t deny that it is nice, however, when this effort is recognised. It was therefore a pleasant surprise when an email popped up with a screenshot of an INCOSE working group award.

To put this in some context, INCOSE state:

The Working Group Awards and Recognition Program rewards efforts and achievements by individual or multiple Working Groups in support of INCOSE’s mission. By focusing on the Working Groups, it specifically recognises team effort. It does not replace existing awards, such as Service Awards.

All Working Groups that have approved charters under Technical Operations are eligible to receive awards under the Working Group Awards and Recognition Program. Not all awards are awarded every year. The Awards recognise exemplary Working Group activities in specific areas:

and it is in the following context that TRAK received the award:

Achieving the Systems Engineering Vision award is presented to the Working Group that has made the most significant contribution toward achieving the Systems Engineering Vision 2020.

Kuldeep, Colin and I received the award on behalf of TRAK at a Railway Interest Group (RIG) meeting in London, collecting it from the president-elect of INCOSE, John Thomas on his recent trip to the UK.

TRAK has always been about more than just the definition of a general purpose enterprise architecture framework - it’s as much about how it’s released and managed and maintained throughout its life and the interface and dynamics presented to users in doing so. We try hard to do this using in the way that you’d specify and manage any system so it’s doubly-nice to get recognition from the professional body that represents systems engineering.

The keener eyed will spot some advice being given from the INCOSE UK Architecture Working Group via feature and bug requests at the Sourceforge sites through which TRAK is released. I should stress that we’re always keen to encourage input and interaction from anyone - you don’t have to be part of a company or large organisation.

Comments

Be the first to comment on {resource_type} TRAK Receives an INCOSE 2010 Working Group Award

Categories: Architecture Framework, TRAK, News

Tags: award, event, incose, london, systems engineering, team

Summary

The NATO Architecture Framework (NAF) has been around for many years now. It has been on a convergence path with MODAF from version 3 (released in November 2007) and the latest version, 3.1 appears to be even more closely aligned with MODAF than ever. I say ‘appears’ since there is only 1 part - Chapter 5 - that has been released and the remainder is subject to an official delay.

The documentation for NAF isn’t the best as it describes on Wikipedia with respect to version 3:

The documentation of the NAF Rev 3 views (Chapter 4) does not always align well with the NAF Meta Model (Chapter 5). This is particularly the case with some of the examples, which are based on DoDAF version 1.0. Some NAF users find it useful to first of all refer the official MODAF Documentation - [1]. This is a useful strategy, as the MOD documentation can be somewhat easier to follow, and NAF and MODAF share a common meta-model.

There is certainly a consistency problem. At version 3 the framework consists of 7 views each of which has a number of subviews. A NAF::View is a collection of NAF::Subviews that are related by the subject matter. This terminology actually came from DODAF 1.X.

Chapter 7, Architecture Definitions, Terminology and Ontology, 7.2.1 defines NAF::View:

A set of subviews grouped by purpose.

clearly a collection of subviews, and defines NAF::Subview as

A pattern from which to develop individual products by establishing the purposes and audience for a product and the techniques for its creation and analysis.

Note: this is called Viewpoint in IEEE-1471-2000; perspective is often used in the same sense.

Under 7.2.3 NAF Metamodel Terminology it then defines NAF::View as:

A specification of a way to present an aspect of the architecture. Views are defined with one or more purposes in mind - e.g. showing the logical topology of the enterprise, describing a process model, defining a data model, etc

...continued…

Comments

Be the first to comment on {resource_type} NATO AF v3.1 - Is It Now Time to Merge MODAF and the NATO AF?

Categories: Architecture Framework, MODAF, NAF, Standards

Tags: meaning, modaf, naf, nato, view, viewpoint

Summary

ISO/IEC 42010 advocates or, more likely, is predicated on the assumption that an architecture description of a complex system needs many architecture views. Each describes the real world architecture and addresses a different set or concerns or questions posed. The typical concerns each view addresses are defined within an architecture viewpoint which is a specification for each view type. Note that this use of ‘viewpoint’ is not that same as that used in MODAF and DODAF where viewpoint is a collection of architecture views, not a specification.

Pretty obviously these need to overlap so that the reader can move around the architecture description and also understand the context for any part. For example there’s no point in showing a function without showing the thing that performs the function and this in turn might realise or implement part of a concept. Overlapping views are therefore a good thing. This in turn requires overlap between the defining viewpoints (ISO terminology).

Whilst some overlap is always good, too much overlap in invariably bad. If there is too much overlap in the things that can be shown in different view types then it becomes difficult if not impossible for the reader to understand the purpose of each view type and differentiate between them. It also leads to inconsistency in the way that an architect approaches the task since if the same content can be shown on 2 view types one architect might choose one view type and another might choose the second. From the reader’s point this is confusing since there is no clear expectation in terms of finding particular objects and relationships. In essence it is a human factors problem since with too much overlap the affordance suffers as there is no longer a clear distinction between view type and the likely view content. From the point of ISO/IEC 42010 the risk is that there is no longer any clear distinction in terms of the concerns addressed by each view type.

This is best illustrated by practical example. The following is taken from MODAF 1.2.004 and looks at the MODAF::SV-1 Resource Interaction Specification View vs the MODAF::SV-2 set (SV-2a System Port Specification View, SV-2b System Port Connectivity Description View and SV-2c System Connectivity Clusters View).

Comments

2 comments

Comment on Keep Clear Separation Between the Concerns that Each Architecture View Addresses

Categories: Architecture Framework, DODAF, MODAF, NAF, Standards

Tags: dodaf, iso42010, modaf, naf, nato, purpose, solution, stakeholder concern, structure, viewpoint