Mary Logan: ‘Build to Evolve, Not to Last’

These provocative words echo in my ears a week after listening to keynoter Jan Bosch at the recent INCOSE International Symposium in Seattle. INCOSE is the professional society for systems engineers spanning multiple domains. Bosch is a highly respected systems engineer who leads the Software Center in Sweden, where industry, academia, and government collaborate to accelerate software research and innovation, supporting innovation for a number of global Nordic-based companies. Bosch pushed us outside of our comfort zones, far beyond traditional ways of thinking about product and systems design. I’m writing about his concepts, admitting my own uncertainties, inviting others to share their own, and nudging the AAMI community to get into this learning zone with me.

Bosch laid the groundwork for his message with five fairly obvious trends: 1) the nature of product innovation is shifting to software (e.g., 70% of all innovation in a Volvo truck is software); 2) the world is moving from products to services (e.g., the fastest growth for Ericsson, a Swedish provider of communication technology, is in the business unit that sells network management, where there is enormous drive for continuous improvement); 3) the nature of innovation is moving to continuous experimentation because of the speed at which the Internet of things allows us to figure out what customers want by watching their behavior; 4) the need for speed keeps speeding up, resulting in a push to shorten the product development cycle; and 5) R&D is becoming a system for experimentation, continuous learning, and fast cycles of evolution, hence the title of the keynote: “Build to evolve, not to last.”

Bosch drove home his main points: Customers will not pick you because of commoditized functionality, so you have to differentiate yourself with software and what it allows the customer to do. For that reason, he argued that design needs to evolve to focus less on hardware and more on software, so that you can modify quickly. If you have to build design into the hardware, build it in modules to maximize flexibility.

It’s easy to apply Bosch’s advice to examples such as the evolution of Amazon and virtual game developers, who can learn customer preferences instantly by how they behave in a controlled web-based environment. I also appreciate that my bank’s ATM network knows my personal cash preference. And if Google wants to mine my brain to learn how I think and buy by tracking my online searches, so be it.

I admit to being more cautious about what’s coming with future generations of safety-critical technology. Even though Bosch is way ahead of me in his enthusiasm for what’s possible, I know in my gut that he’s right. The Internet of things has opened up the floodgate for our immediate access to data that can support continuous improvement of just about anything. That said, are we humans truly capable of building safety-critical systems with a mindset of continuous experimentation and fast cycles of evolution? I struggle to imagine myself driving a car (or being driven by a car, or riding in an airplane) that has software updates every one to five days. While software updates apply largely to the entertainment system in the car today, I have no doubt that in 10 years we will see more software updates that touch on safety-critical features. It’s not too much of a stretch to see that these disruptive software-driven innovations are coming to aviation, aerospace, defense, and, yes, medical technology.

It will be awhile before the highest reliability industries such as defense, aerospace, and healthcare catch up with the pace described by Bosch. However, the majority of the systems engineers in the audience to which he was speaking were from these safety-critical industries. Among them will be the Jan Bosch disciples and next generation visionaries who pass him by. Are we ready to get out of our comfort zones and start thinking of how we will design, regulate, and implement healthcare technology with a mindset of “build to evolve, not to last”?

Mary Logan, JD, CAE, is the president of AAMI.

One thought on “Mary Logan: ‘Build to Evolve, Not to Last’

  1. The “Internet of things” requires that there be things that the Internet provides communication with and between. In our case, those things have traditionally been medical devices that we have helped design, select, regulate, maintain, and, most importantly, use. In most cases, it is those things, in the hands of humans, that provide patient care. Without things, the Internet is only a data machine. We have been much concerned of late with capturing data (from things), moving it around, processing it, storing it, sharing it, and sometimes presenting it for human review. Relatively rarely does the data from one thing directly cause some other thing to do something, although many have predicted that this will occur. Thus one meaning of “interoperability,” before EHRs sharing data co-opted the term, was various medical device things communicating with each other. Even when this occurs, it will be the medical devices that interact with the patient, not the Internet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s