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 (INCOSE) as: "an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem...[it] integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs".

In essence, Andreas talked about understanding the whole business problem before worrying about solutions; and about delivering effective business systems (including, but not limited to, software) from geographically dispersed teams and several generations of programmers (that is, from very large and long-running work efforts). An automotive company tells him that the innovation and product differentiation in cars these days largely comes from software, but, he says, this software can't be developed outside of the context of the physical car using it, partly because the behaviour of the software in a car may well be safety critical. Software is a simulation of the real world but the behaviour of a car is very much of the real world, constrained by the laws of physics and the laws of the country it is running in.

To achieve effective Systems Engineering, Andreas models the systems he is developing or changing using a language called 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".