Continuous Engineering

Every so often I get to attend an online RoundTable with IBM’s Bret Greenstein and his systems leadership team, looking at where Systems Engineering is going, at least as far as IBM is concerned. A couple of years ago, IBM was reworking Agile for Systems Engineering—it’s interesting to see where this is going.

As I believe that automation frameworks built with systems-engineering principles are a key enabler for well-governed agile people-centric automation, I find these round tables really interesting. It’s not that I think a quick app to help business people cope with the latest trend needs to be engineered to last for centuries; just that you’ll be a lot less stressed using it, if the automated business framework it sits in, which might well last for years, is engineered appropriately. Systems engineering, in my opinion, isn’t about over-engineering stuff to work for ever, it’s about right-engineering stuff to last as long as necessary and no longer (with a bit of margin for error—and provision for re-use).

The most recent round table had a look at continuous delivery and DevOps and what they mean in a systems engineering context. Obviously, systems engineering is about a lot more than just software and the idea of continuous delivery of a Boeing 747 is a bit frightening. Obviously, too, terms like DevOps are just marketing terms sometimes and mean different things to different people.

However, I think IBM’s general definition of DevOps at scale is a good one—it’s about collaboration of all stakeholders around pipelined delivery of automated business outcomes, controlled by end-to-end feedback loops (production metrics identify issues for the business, which then result in new developments, in order to address them). It applies quite well to systems engineering, if one can think of software-controlled hardware flying a plane, say, as a ‘business outcome’. Mind you, I sometimes wish more businesses (especially in Financial Services) would design and validate core business control systems the way aircraft manufactures design their control systems.

So what about ‘continuous delivery’? Well, Bret and his team think about ‘continuous engineering’ that delivers an actual end product to production only when it has passed its validation and regulatory tests. Sometime, ‘continuous delivery’ is both feasible and useful; sometimes it isn’t. However, thinking in terms of delivery pipelines (even if you turn the tap on and off) and of collaboration between all of the stakeholders in delivery is always useful as an ideal.

Continuous engineering is about strategic reuse, about not re-inventing the wheel and about actively preventing re-work. It sounds a lot like product line engineering (see here) updated a bit in the context of Agile and DevOps. Usefully, IBM is collaborating with people like BigLever Software to help deliver exactly this.

What makes this all feasible now is the availability of OSLC to let the various tools talk to each other, RELM (Rational Engineering Lifecycle Manager) to provide a framework for managing the life-cycle—and, last but not least, the use of big data analytics to provide ‘Expert Advisers’. These are a modern take on artificial intelligence; made practical by innovations like Watson and content analytics working on ‘big data’ from ubiquitous connected instrumentation in systems-of-systems, to identify root causes and to help you build in good design, good governance and so on from the first.

Science fiction? Not really, Sky Matthews showed us a plausible scenario of how this would all work in practice. All the tools in his scenario are available today in various IBM tools and research labs, although integrating them seamlessly as a commercial offering is probably 3–5 years out.

If there is an issue with all this, I wonder if the organisational and people culture issues aren’t being treated as scientifically as the rest of the engineering. There will always be cultural issues when you move from silo’d delivery to a world where all stakeholders collaborate around a delivery pipeline. I’m quite convinced that Bret and his team are fully aware of such issues—but I would like to see some operations research on how this plays out against the vision in practice, investigations of the possible impacts on organisational structures, and investigation of the psychological issues experienced by those involved. As I said, I sure Bret etc are fully aware of such issues, but I wonder if something more formal might be useful too.