Internet of Everything

Internet of Things Journal

Subscribe to Internet of Things Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Internet of Things Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


IoT Authors: Zakia Bouachraoui, Yeshim Deniz, Liz McMillan, Elizabeth White, Pat Romanski

Related Topics: Virtualization Magazine, DevOps Journal, Internet of Things Journal

Blog Post

Your Car and the Future of Software Delivery | @ThingsExpo #IoT #M2M #ML #DevOps

The volume of code running in cars is representative of the central & growing role software plays in the automotive industry

If you're looking to predict how things should work in the future, start by looking in the right places in the present. Innovations in technology, management and collaboration that will change the way we work are already up and running in visionary organizations. Ever since reading Robert Charette's IEEE article titled This Car Runs on Code, I've been fascinated by the fact that the 100 million lines of code in cars represents one of the most complex software artifacts that we interact with day-to-day. That falls just above the number of lines of code you will find in Mac OS X, and in the same order of magnitude of complexity as the DNA of a mouse - as artfully illustrated by David McCandless on the Information Is Beautiful blog.

The volume of code running in cars is representative of the central and growing role that software plays in the automotive industry. The 2009 IEEE article highlighted a new "BMW Assist" system, that uses data from the car's air-bag, engine and other control units, along with cellular communication and GPS, to inform emergency response teams of location and injury severity. Recently, I saw a post by a mother praising the BMW Assist system (along with other technological innovations in the i8) for saving her son's life.

Likewise, Volvo has taken the potential that software and sensors provide to promise "death-proof cars" by 2020. These trends, along with autonomous driving, are creating the need for a whole new scale of software-centric innovation and are expanding the software in tomorrow's cars beyond 200 million lines of code. Software is becoming the most expensive part of the car. And this trend goes beyond cars to increasingly smarter devices across the board.

Large-scale software delivery is one of the most challenging and most important endeavors an organization can undertake. We've seen the most trivial software delivery mistakes cause business calamities. Things get even more interesting when hardware and software are mixed. For example, a software update in the Nest thermostat resulted in people unable to heat their homes during one of the coldest weekends of 2015. The bottom line is that organizations that master large-scale software delivery will thrive, while those that get trapped in its pitfalls will fall further and further behind.

Visibility into the software supply chain, automated reporting across individual boundaries and real-time flow across the software delivery value stream are critical to delivering the benefits of lean manufacturing to software. The "Industry 4.0" initiative is starting to force a connection between lean manufacturing and lean software delivery. It's at this intersection of a mature lean discipline and a new one that we're learning some of the key lessons for the future of software delivery. I've summarized a few below.

Connect the Software Supply Chain
The world around us is transforming into a set of Internet of Things (IoT) devices with microprocessors and sensors, including the world within the car. Automobile parts come from dozens of suppliers, and all of those microprocessors are running more and more code. This has transformed a hardware and part-centric supply chain, which the world learned to manage via lean manufacturing principles originating from the Toyota Production System (TPS), to a software supply chain.

Managing a software supply chain requires managing the lifecycles of numerous applications across company boundaries. To make this management possible, you need tool support. Although sometimes it's feasible to make everyone use the same supply chain management system (demonstrated by the success of the Android ecosystem, which forced members of the ecosystem to use Git), it is not possible to make suppliers use the same requirement, defect and issue tracking tools, because they tend to be development platform and company-size specific.

As a result, a new layer of integration infrastructure is required to connect the planning and tracking layer of the ecosystem. Without it, the speed of delivery is limited by the inefficiency of sending spreadsheets of requirements and defects around via email. When an integration hub is put in place to connect suppliers, a lean software supply chain becomes possible. For instance, as soon as a defect is found in a test drive or simulation, that defect can be routed in real-time to the right software supplier. As soon as the supplier commits a fix, and updates the workflow status of the defect in its issue tracker, the simulation or test drive can be rescheduled.

When you consider the bottleneck that managing tens of thousands of requirements across millions of lines of code via email and spreadsheets creates, there's a clear 10x efficiency and speed gain to be had.

Gain Visibility Across the Software Supply Chain
Connecting the software value stream across suppliers enables efficiency because artifacts like requirements and defects are moving in real-time, instead of being batched up and becoming bottlenecks. Equally as important as gaining efficiency is a gain in visibility - to show how software development is proceeding across the software supply chain. Without visibility, it is impossible to identify bottlenecks and apply the same continuous improvement that transformed manufacturing to the world of software.

When your software suppliers are not connected to your organization's lifecycle, you are relying on slow, manual, error- and opinion-prone methods of reporting. When that connectivity is automated, it becomes easy to see that a particular software component is causing a disproportionate number of defects or performance problems, and to quickly adapt. This is as important for traditional supplier relationships as it is for open source dependencies.

For example, if an open sources component that you depend on raises a security issue in the issue tracker, and that security defect does not appear immediately for your organization within its own lifecycle tools, you are now much more likely to release a component with that vulnerability. Forward-thinking automotive manufacturers are teaching us that visibility and continuous improvement are needed not just across an organization's developers and IT staff, but across the entire software supply chain.

Automate Requirements Traceability
Requirements traceability is a critical and often a regulatory requirement for devices that we fly or drive around in. But, it is notoriously difficult and expensive to gain this traceability, resulting in the "traceability gap." This causes additional non-value add work and re-work to connect requirements to defects to tests to builds, and so on, as things change. With the pace of software delivery today, change is the only constant.

The problem is not the change itself, but the disconnected nature of the change. For example, when developers change a line of code, they generally know the requirement they are working on and the release the change will go into. But they tend not to update three or more systems voluntarily when making that change. By creating an integration layer that connects the creation or update of any artifact to the downstream and upstream artifacts, such as requirements and builds, it is possible to completely automate requirements traceability.

I know this first hand as it's exactly what we've done at Tasktop. Not only does that mean that audits of our R&D require almost no effort, but our delivery is actually much more productive because developers can instantly access the code relevant to a changed requirement, for example, from one of our 10 OEM partners. What's even more exciting is that we are now starting to apply that same traceability and linking automation to large-scale automotive and manufacturing delivery, where the gains will be even larger.

Apply DevOps Principles to Systems Engineering
The lessons discussed here have been about applying scaled Agile and lean principles to software delivery. The aspect not discussed yet is connecting the build, test and deployment parts of the software lifecycle to reduce not just the development part, but also the overall cycle time. One challenge with manufacturing is how different the development environment is from the environment in which the deployed product is tested and used. If you're developing a web application, your operational and test environment are almost identical. A combination of VMs or, better yet, Docker containers, along with some service virtualization and test data automation, mean that you will have an automated layer for finding defects and then deploying to production.

Contrast that with a car, where the production environment could be flying down the road at 100 miles per hour, disconnected from any network. But the principles of DevOps still apply, in that the more you can automate the connectivity and process of testing and deployment, the more successful you will be. The grand challenge becomes creating a virtual environment where the principles of DevOps can apply to manufacturing. This has to go well beyond the test automation that we do for IT projects, which is why simulation is such an important trend in manufacturing. Once the production environment is simulated, it is possible to gain the velocity and cycle time gains of DevOps for embedded systems and devices. When a build fails at Tasktop because an Agile vendor just changed the semantics of an API call in its latest point release, a defect is instantly created on the backlog of the team that supports that connector.

By virtue of having created our Integration Factory, a simulation environment for Agile/SDLC/DevOps data and tools, we now measure a three-day Mean Time to Resolution (MTTR) for a defect discovered in a customer's on-premises environment to an updated build being in the customer's hands. The potential that this kind of simulation and connected lifecycle integration has for transforming complex manufacturing is tremendous.

The automotive industry is once again back at the forefront of technological innovation, and poised to have a very positive impact on everything from our safety to the shape of our cities in the coming decades. Effective large-scale software delivery is the discipline that will determine the success and the timing of these changes.

More Stories By Mik Kersten

Dr. Kersten is the CEO of Tasktop Technologies, creator and leader of the Eclipse Mylyn open source project, and inventor of the task-focused interface. His goal is to create the collaborative infrastructure to connect knowledge workers in the new world of software delivery. At Tasktop, Mik drives Tasktop’s strategic direction, key partnerships, and culture of customer-focused innovation. Prior to Tasktop, Mik launched a series of open source tools that changed the way software developers collaborate. As a research scientist at Xerox PARC, he created the first aspect-oriented development tools for AspectJ. He then created the task-focused interface during his PhD thesis and validated it with the release of Mylyn, now downloaded 2 million times per month. Building on the success of Mylyn, he created the Tasktop Dev and Sync product lines.

Mik's ideas on Application Lifecycle Management (ALM) and focus on individual knowledge worker needs make him a popular keynote speaker; he has been recognized with awards such as the JavaOne Rock Star and the IBM developerWorks Java top 10 writers of the decade. Mik's entrepreneurial contributions have been acknowledged by the 2012 Business in Vancouver 40 under 40, and as a World Technology Awards finalist in the IT Software category. Building on his contributions as one of the most prolific committers to Eclipse, he serves on the Eclipse Foundation's Board of Directors and web service standards bodies.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.