Systems Engineering and SysML

I’ve always been a bit depressed about Systems Analysis in practice, since rather enjoying it in my computer science courses alongside lectures on Systems Theory, because the only system Systems Analysts seem to look at is the one being automated. But how can you tell whether an automated system works unless you understand its scope and the manual processes which use its outputs? And how can you decide whether it is successful or not without understanding the business processes trying to use it?

So I was most interested in what Andreas Korff, a Principal Consultant with Artisan, had to say about Systems Engineering when we talked recently—where Systems Engineering is defined by the International Council on Systems Engineering (SysML. This is a well-formed extension of UML2: it introduces new models—around Requirements, for example—and it uses “Parameters” to achieve what UML 2’s OCL (Object Constraint Language) achieves but in a more pragmatic and less software-oriented way. However, it also reuses (and sometimes extends) existing UML2 models such as Activity Diagrams, Use Cases, State Diagrams etc. And some UML2 isn’t relevant to SysML. If written properly around the MOF metamodel, UML2 tools shouldn’t find it too hard to adapt to SysML (but don’t count on this, although Artisan’s Studio tool is one example of how this can be done).

OK, so why should SysML be relevant to people just developing business software? Well, sometimes (depending on the environment they are working in) it won’t be—or won’t appear to be. But if you are developing holistic business services and your SLAs mention non-functional requirements such as security, business continuity and integration with manual business processes, then SysML modelling (in the context of a higher Architecture Framework and business ruleset and linked to lower level UML2 modelling and eventual code generation) may be the best way to manage delivery of a partially automated, holistic, business system.

As very few business systems are, in fact, wholly automated and implemented entirely in software (even if programmers think of a customer database as a whole system, the business probably sees it as merely a subsystem of a human-oriented customer relationship and sales management system), an EA approach and SysML modelling may help to ensure that the business users of a business system and the developers of the IT systems within it are all “reading off the same hymn sheet”.