Continuous Engineering in the Decade of the Internet of Things (Part 1)

You run a high security business service that deals with a lot of secret paperwork.  Finally the ‘Office file tracking system’, with all its movement sensors and radio frequency chips connected to the Internet of Things (IoT), is on.  You can track the physical movement of classified files from the comfort of your home, or during a baseball match.  Your system is as good as your competitor’s, except for a special security feature.  The new feature requires a couple of extra bytes of data to pass through your movement sensors.  You don’t know how difficult it is to make the change, or its repercussions on your otherwise working system.

You could employ traditional methods of software engineering to analyze the requirement, and develop, test, and deploy the changed code.  Or you could adopt continuous engineering.

Most of us, having just managed to get our heads around ‘continuous delivery’, would grimace.  What with ‘continuous testing’, ‘continuous integration’, ‘continuous deployment’, and even ‘continuous release’, do we have room for a new ‘continuous’ concept?  And is it really ‘new’?

What is continuous engineering?  How different is it from continuous delivery, if at all?

Continuous Delivery

Continuous Delivery is about delivering software ‘frequently’.  That’s why it is ‘continuous’.  It primarily focuses on speeding up the deployment pipeline — that is, the transition from source code to customer-executable code.  Central to it is the concept of continuous integration: the practice of maintaining a common build across all teams that is updated every day as new code gets checked in.

What about the steps prior to build and even prior to coding?  Aren't those important?  They are.  And much has been said about them, too.  It’s just that Continuous Delivery processes prefer to focus on the stage after coding.

Continuous Engineering

Enter continuous engineering.  What happens when requirements come in at a canter, or change frequently?  How do we ensure that the gains of a mature continuous delivery process are not muted by a confused requirements and design process?  This question is especially relevant in the IoT era, when devices work in real-life business, social, legal, and climatic ‘environments’.  To call such environments dynamic and unpredictable would be an understatement.

Continuous engineering practices and tools address this problem.  Instead of beginning at the source code they begin at the point when customer needs are expressed, sometimes even before they are translated to formal requirements.  Hence, the term ‘engineering’.

As you would expect, being ‘continuous’ in an engineering context is about translating requirements to working product features as frequently as possible.  Without compromising on quality, of course.

It is not inaccurate to say that continuous engineering is about moving from concept to creation smoothly and efficiently.  Which leads us to conclude that continuous delivery tools and practices are a subset of continuous engineering tools and practices.  Both continuous delivery and continuous engineering have the same goals.  It is just that continuous engineering begins earlier in the software (or system) delivery lifecycle than Continuous Delivery.

Continuous Engineering and OSLC

What kinds of tools are required to enable continuous engineering?  Since continuous engineering is the superset of ‘everything’, it must be able to penetrate the rocky boundaries between analysis, coding, testing, and deployment.  Fortunately, the ‘Open Services for Lifecycle Collaboration’ (OSLC) specification supports interoperability between software lifecycle tools.  Tools that adhere to OSLC know how to share their data with each other.

Automation

First things first.  The tools that support continuous engineering must focus on speed and agility.  Automation is key; as it is in Continuous Delivery.  Which is why the emphasis on automated modeling, testing, builds, and deployment persists in continuous engineering as well.

Much has been talked and written about automation.  So we’ll skip it for other less-discussed topics.  That’s not to say that automation is unimportant, just that there are other equally important ingredients in the continuous engineering recipe.

Global Traceability

Continuous engineering is about changing applications continuously.  A complex product may have hundreds or thousands of artifacts from various lifecycle stages — stakeholder requirements, system requirements, software requirements, interaction diagrams, abstract models, prototypes, pseudo functions, source code, test cases, test scripts, environment settings, and many others.  Since an incremental change is not likely to affect all the artifacts it is important to identify the downstream artifacts that are likely to be impacted by a change in a requirement.

Global traceability requires tools that can help you connect to your entire portfolio of artifacts across lifecycle stages.  So, you can link test cases with software requirements and navigate from one to the other seamlessly, even when the two kinds of artifacts are created by different tools.  Such interoperability between tools can be achieved easily when the tools support OSLC.

Global Configuration Management

The next ingredient in the continuous engineering recipe is configuration management.  Versioning and configuration management have been around a long time.  However, as in traceability, the ability to work across a lifecycle is what continuous engineering needs.  Given that analysts, designers, developers, testers, and operations have traditionally worked in silos, a universal view of all artifacts across the lifecycle has not been a frequently expressed demand.  Not until continuous engineering.

With continuous engineering you can have multiple product release streams running in parallel.  Each product stream will have its own artifacts from different lifecycle stages — requirements, design use cases, test cases, and code — slightly different from those in other streams.  The set of such artifacts comprising a product stream is often called a ‘global configuration’.  In many ways, a global configuration is like an abstract layer that links together artifacts living in their own lifecycle stage and managed independently by stage-specific tools.

Global configurations are invaluable to continuous engineering because they support traceability and centralized management of products.

To be continued....

In the second part of this article we see why organizations looking to build continuous engineering capabilities must focus on skills like product line engineering, model-based engineering, and engineering analytics.