About James Towers

James Towers, B.Eng (Hons), CEng, MIET, MINCOSE

James holds a Bachelor’s degree in Electrical and Electronic Engineering from Nottingham Trent University which he gained in 1996. James has had a varied career in software and systems modelling and has presented papers and tutorials at conferences and seminars, as well as writing and delivering training courses on the subject. He has provided consultancy, training and mentoring to various organisations working in automotive, consumer electronics, defence, finance, information technology, power electronics, telecommunications, rail, retail and supply chain. He is a Chartered Engineer, an OMG® Certified UML professional and member of the IET and INCOSE UK, where he is co-chair of the UK Model-Based Systems Engineering (MBSE) Working Group. He is also a visiting lecturer in MBSE at the University of Warwick.

Q1. James, your career spans Business Analysis and Model-Based Systems Engineering. What is the difference in approach between these disciplines?

I’ll first explain the difference between Business Analysis and Systems Engineering. I will come back to the Model-Based aspect later.

The International Institute of Business Analysis (IIBA) defines Business Analysis as:

“the practice of enabling change in an organisational context, by defining needs and recommending solutions that deliver value to stakeholders”.

It’s often associated with service organisations, ones which provide ‘virtual’ products or projects involving IT development, since most change involves IT, but it’s not limited to those contexts.

The important point, I think, is that Business Analysis is focused on the organisational context.

Systems Engineering (SE) is defined by the International Council on Systems Engineering (INCOSE) as:

“an interdisciplinary approach and means to enable the realisation of successful sys­tems”.

Originally practiced within Aerospace and Defence, it’s now used in a wide range of sectors and is essentially a risk-mitigation approach for large and / or complex projects and programmes.

It’s worth noting that “Systems” is used in quite a wide sense. Take the example of car manufacture:- Systems Engineering would consider both the enterprise that makes them, and the cars themselves, as “Systems”.

Not surprisingly SE is more common in ’traditional’ engineering sectors where it forms part of the overall engineering activity to produce a physical product. Both disciplines are connected to the general philosophy of “Systems Thinking”.

Once you put the history to one side, both disciplines are actually based on the same or very similar principles, such as:

• Understanding the problem before you define a solution
• Discovering the real needs
• Managing the changes and risks, and
• Ensuring the end result provides sufficient benefit for its cost

The differences are mainly due to the kind of systems being changed or developed and the differences between what could be described as the culture of ‘clerical’ vs. ‘engineering’ focussed organisations.

The ‘Model-Based’ aspect is really just a “way of doing” Systems Engineering. Historically, SE was performed by writing and reviewing lots of documents in tools such as Word, Excel, PDF and Powerpoint etc.

We used these documents to describe and define the problem, design possible solutions, and formulate tests (or more generally verification and validation) strategies. As system complexity has increased, so has this corresponding set of documents, and so it became necessary to manage the information in a different way.

Model-Based Systems Engineering (MBSE) uses a single source of truth (the model) to store all this information and the relationships between them. The information is far more granular than a simple document store, and documents (or views as they are known) are generated from the model, thus increasing their accuracy and consistency.

One of the major advantages is the ability to query the model in complex ways not easily done with discreet documents.

As an example, let’s say my project includes the concept of a boat. I can query the repository to tell me every occurrence of that concept throughout the whole model. This is the equivalent of searching every page or tab of every word document, excel sheet, pdf or powerpoint.

Even more powerfully, if I decide to change the concept from boat to ship, once I change the definition, it is changed everywhere it is used in the model and in all subsequently generated documents.

Models are typically constructed using graphical modelling languages which have additional advantages of precision, expressiveness and comprehension over natural languages (words and sentences).

Q2. You specialise in UML, SysML & BPMN modelling languages. How do you decide which to use and when?

My main focus at the moment is Model-Based Systems Engineering using SysML.

SysML (Systems Modeling Language) is a domain specific version of the Unified Modeling Language (UML) for Systems Engineering.

While UML was originally defined for modelling software, SysML has been developed to address the needs of Systems Engineers wishing to model a wider range of systems.

Business Process, Model & Notation (BPMN) on the other hand is aimed specifically at modelling processes. The choice of which to use is always dependent on several factors. There is some overlap, so for basic procedural models, either UML or SysML can be used rather than BPMN, although BPMN only really covers procedures.

For anything else, and organisational structure is an obvious example, you need to also use one of the others.

You also need to consider the complexity of your model; one which uses only a single language will probably be easier to maintain than one that uses two. Similarly the languages have to be understood by the people who are going to review the outputs. You also need capable tools.

While you can sketch diagrams on a whiteboard, sophisticated models require sophisticated tools, and again, one tool is going be less complex and cheaper to own than two.

Q3. From working with customers across the railroad, medical and aerospace sectors, which issues have proven to be the most difficult to model and why?

The hardest thing to model is always something you don’t understand.

This is actually a benefit and not an issue since often people don’t know or acknowledge what they don’t understand. As a favourite example, someone will often say in a workshop that “we don’t need to model that as we understand it”. My advice is that if that’s true then modelling it will be a trivial exercise.

Inevitably though, even when one of the participants believes they do understand it, there is seldom agreement or other participants learn something new. I can’t recall an occasion where it wasn’t a useful thing to do in some way.

Q4. Which new technologies or advances excite you the most in MBSE?

There’s currently a whole new version of the SysML in development. There are lots of changes but the most exciting one is a standard API so that anyone can write tools to update and query the model.

It is hoped that a whole ecosystem will develop around this which will make MBSE more accessible. Imagine if every time you opened Excel and started editing a list of requirements, you were actually proposing an update to the requirements database? Everyone who had an interest could then be automatically informed and allowed to comment on your proposal before they were agreed and included.

If that happens, you’ve started modelling (and working within a controlled lifecycle) and you didn’t need to learn any new tools or languages.

Q5. What do you think engineers should do to convince business stakeholders to adopt more advanced modelling tools and techniques?

There’s good evidence that model-based techniques have advantages over document-based ones, however people aren’t necessarily swayed by the evidence if the benefits or disadvantages aren’t immediate. Just look at smoking and obesity.

Alternatively, organisations are using MBSE to deliver success. The challenge is that document-based approaches aren’t infinitely scalable, so it’s hard to know where the tipping point is.

Since SE is a risk-mitigation strategy you need to have some appreciation of the risks to consider it worthwhile. Sadly it often takes a large failure for an organisation to realise they need to change.