INCOSE ASEC 2010 - Human Factors: On the Right TRAK?

INCOSE logo

This was a joint presentation given at the INCOSE UK Chapter’s Annual Systems Engineering Conference at Heythrop Park in November 2010. INCOSE is the professional body that represents systems engineers (and thinkers). The conference is an excellent way to meet similarly-minded folks and this year the topics ranged from UK transport planning to understanding inflammation and disease.

We presented jointly with Liv Systems, a consultancy specialising in human factors and user-centred design. The title of the presentation was Human Factors - On the Right TRAK?. As we initially stated:

This presentation is about applying a user-centred design (UCD) approach to unusual things: the design of a UK rail industry architectural framework called TRAK and its use for Human Factors work in a challenging Systems Engineering environment.

This architectural framework, if it is to be usable, has to address a number of challenges. The framework needs to unite or integrate the different stakeholder viewpoints on the same underlying system or problem. The framework also needs to be usable by these different stakeholders.

In applying UCD, the emphasis has been placed on consistency, simplicity and ease of use, and as a system it is essential that not only does it embed HF principles in its design but also that it should support the practical needs of Systems Engineering disciplines. For this reason, we will also describe how TRAK supports the needs of practitioners with reference to studies conducted within the Rail Industry.

Some might be surprised to think that an architecture framework has any form of user interface at all. If you think of all the parts that need to come together to make architecture description work you need:

  • the definition of the framework
  • a place to store this
  • the developers that work on it
  • some sort of knowledge base
  • tool vendors that produce
  • modelling tools
  • the users or architects that produce the descriptions
  • lay browsers or readers of the description
  • glueware to support production and consistency
  • places to store the descriptions

Given that an architecture framework such as TRAK provides a language for describing the relationships between parts of the real world and a means of communicating it has to be usable, pragmatic, simple and relevant. These are very human qualities and if we draw a (system) boundary around all the parts of “the TRAK Enterprise” then there are clearly significant interactions with and influences of working with people. It is essential therefore to consider these in the design of the framework.

Illustration of dynamics between framework, tools and architecture description produced

Illustration of Dynamics between Framework, Tools and Architecture Description Produced

There are also dynamic influences, not the least of which involve the impact of the size of the framework and how well it applies rules on both the modelling tools and the users of the tools as well as consistency of the description and ability to share or re-use it.

If architecture description is to be successful within a company it needs to be being added to by many parts of the company, not just those with “architect” in their job title. Placing it in the hands of a priesthood never works. Letting a wide base describe their part of the company world ensures the information is correct and up to date and allows the cross-fertilisation and communication between the different disciplines. Since architecture (and system-thinking) is mostly about recognising the relationships you also need the right sorts of people working on the “wikitecture”. Get the wrong people and you end up with mostly vertical taxonomies that offer little insight. Get the right people and you end up with a rich set of cross-couplings that show dependency, justification, response and resulting behaviour and exchanges. People are therefore very much key to effective architecture description and collaboratively building the wikitecture.

External References

Categories: • ServicesEnterprise Architecture / Architectural ModellingSystems ThinkingTechnical Eclectica

Article 1 of 1 articles