Embedded DevOps - Addressing Pressing Challenges in Digital Adoption

In an increasingly connected world, technology cannot be a standalone player. Gartner study predicts that by 2021, the number of wireless connected devices in the world will grow to 25 billion. Making them operable and intelligent will need active embedded DevOps.

While products and services are two separate domains, the new digital economies and consumer realms have made a congenial marriage between products and applications an imperative. So, products without embedded intelligence and cognitive technologies stand no chance in a market where agility, robustness and cost-effectiveness matter more than pure technology. The result is, almost all products today need embedded software utility or component in it. From the manufacturing standpoint, quality management of products that offer better and higher services, in a cost-efficient, agile manner, is the ultimate goal.

Business innovation and market success today is synonymous with the digital robustness of any software. It goes without saying that all the stages of a development lifecycle benefit from an agile DevOps process and adds to a lean go to market strategy.

While collaboration is a dear term, at a practical level, the differences in development and operations environment can cause failures. Besides, the market demands faster and more frequent releases and better go to market to meet these needs. When developed manually, scalability, repeatability and lack of speed create a hurdle for software launches. With delayed launches, the lack of feedback and quality metric can also lead to missed SLAs and unhappy market situations.

The challenges of agility

A necessary prerequisite for an organization planning to adopt DevOps, is the assurance of agile workflows. However, since the very nature of DevOps is about both hardware and software, agility could pose an additional challenge for the hardware portion in embedded products. One way out could be segregating the two development processes, that is to say, the hardware development pipeline needs to be distinct from firmware/system software pipelines. Concepts such as trunk development, service versioning, de-coupled architecture and micro-services can be explored to design the development better.

When it comes to testing for embedded projects, the investment would be right simulators/emulators and apportioning of feature testing rightly between them. Right container technologies and virtualization are also techniques one can explore to smoothen deployment/versioning challenges. Designing the right provisioning systems to spin up simulator instances to achieve scale in test farms are approaches to cut back on validation and testing. This, eventually become a critical aspect of DevOps in embedded projects. In the process of segregation as well, one of the vital decisions will be about the identification of modules and layers that needs to be moved into DevOps, and the phases that the process would be divided into.

The regulatory challenge

Since compliances for software development life cycle in regulated industries are very stringent, it needs to adhere to much higher levels of quality, testing, and engineering expertise as well. The most critical domains typically mandate V-model development. So a significant part of the strategy is about the treatment of agile workflows within the V-model for domains such as aerospace, rail, automotive and medical. There are emerging approaches such as SafeScrum that apply agile software development principles to safety standards like IEC 61508, but they are still under testing. Once applicable, this could address functional safety aspects in agile development for DevOps adoption. There are also other domain-specific standards like AAMI’s TIR45 that would support agile DevOps in the medical devices embedded software projects. Additionally, data security regulations like GDPR have made data-led compliances more stringent as well. Companies need to consider those while extracting the maximum benefit from embedded DevOps.

Existing IP and technology management

Many current embedded systems are built on a large quantity of existing IP. This, in most cases, is dependent on a legacy platform, and unfortunately this is a common hurdle in implementing new processes or systems. Additionally, systems encompass highly regulated industries and the risk for embedded systems increase while a DevOps culture is being developed. Managers, while the work is being done, need to ensure they maintain stringent industry-specific compliance and security standards. Another fallout of legacy systems and tight regulations is often the inability to have visibility of the end-to-end processes, especially to the management team. Like the famed HP Printer embedded division’s DevOps transformation proves, sometimes, an entire re-architecting of product lines (e.g. moving all product lines to a single code base) might be called for agile and DevOps adoption. Migrating features and bug-fixes across several product lines is a typical tech-debt that accrue for most product companies that slow down product development and innovation.

For embedded DevOps, the growing code size, diversity in team skill, and the competition for faster go to market will put huge stress on software design teams to deliver effective design methods and efficient development processes. In Product engineering space, the focus is more on quality, unlike enterprise domain where scale also becomes a more significant factor. Achieving scale of operations in terms of large scale agile development on embedded platforms is another more substantial challenge to lookout.

From an agile approach, the best path would be to start with a DevOps assessment and strategy planning, create a minimal framework and stack, build through managed and monitored services and continually work on optimizing the model. Defining the right metrics for each phase to measure DevOps migration, such as tracking the percentage of feature churn in requirements phase to branching mechanism and time to release in deployment phase matter, is key as well.

The agility and accuracy of DevOps is an advantage that can support in testing processes for embedded software too, as the engineers at QuEST Global discovered. While working on an embedded software project, the company faced critical challenges in poor code quality, service outages and loss of time and agility caused by redundant testing. Using DevOps, the embedded engineers at QuEST Global were able to complete the regression testing process efficiently in a time-bound manner. The regression testing time was reduced from 8 days to about 6 hours, with assured code quality. With the deployment time falling from 4 hours to about ten minutes, the company was successfully able to deliver a fail-proof system to the customers.

Looking forward

Firms will need to ensure support for agile process, a culture that encourages DevOps and the necessary tech muscle to make it work in an embedded environment. Agility and robustness of the system will boost productivity, while security risks, slow uptake and lack of coordination between skills will serve to derail any progress made.

As the market of DevOps grows, the number of tools used increases, and there will be an increased need for newer skills and faster, smarter deliveries. The next few years will see unprecedented changes, and companies need to constantly update themselves on being flexible, agile and continuously review DevOps deliveries to stay on top of the market.