QuickBYTES Q&A: Bruce Douglass, Chief Evangelist, IBM Internet of Things

By | 5 minute read | October 24, 2018

I’m Bruce Douglass, Ph.D and Chief Evangelist for IBM Internet of Things. My role is to travel the globe spreading joy in technology, specifically in the systems and embedded software spaces. I help customers use modeling to improve their time to market, quality, products and increase customer satisfaction because they’re doing a better job in less time with fewer defects. Below, I share some thoughts about systems engineering.

What is your favorite thing about engineering or systems engineering specifically?

I find it fascinating to learn what people do in various engineering spaces, like Medical, Aerospace and Automotive – so I’ve spent some time consulting across a variety of engineering disciplines. One day I would be working on a CAT scanner for a medical device company, and the next, working to develop an aircraft carrier. Or I might be working on a nuclear power plant. So the problems that I see vary in specifics, but in the abstract sense are faced by everybody. I really enjoy helping people come to grips with the complexities of their problems.

Would you describe yourself as a practitioner or a theorist? How do you bend the universe as an engineer?

Practitioners see me as a kind of theorist, and theorists see me as a practitioner! In my mind, theory is useful only in how it helps get stuff done. Having said that, as a practitioner, I also want to know how things should come together to guide my practice. So I believe in really understanding what you’re doing – it’s using mathematics to help understand the nature of the problem. You can’t tackle the problem if you don’t have a concept of what a solution should look like in the first place. In the practical sense, we use formal methods to guide us to the application of engineering – to create new things.

Do you think those are wrong ways of looking at engineering?Or is it that people are not focused on the right outcomes?

I think that many people misunderstand Agile – and take it to mean that you don’t need to be disciplined or thoughtful in your approach. That you can just hack away until you’re done. Maybe it’s a reaction against people overly concerned with all kinds of details that are neither important nor relevant. The right approach is somewhere in the middle. You need to focus on the things that matter – the actual processes that make a difference and the practices that make you efficient and effective – but also be flexible about those details that aren’t so crucial.

Modeling can be applied to the whole life cycle of a system. What do you think is key to building confidence and requirements in systems architecture?

There are I think two fundamental keys. The first and most important is that you have to make sense. You have to make engineering statements and decisions falsifiable. “Falsifiable” is a philosophical term that means that it’s possible to test a statement or hypothesis against the evidence. Big picture thinking is all very well, but if it’s not precise enough to be testable you can’t really say anything about the validity of the systems. The second thing is to do this in a timely way: demonstrating your architecture is right early in the process – not late when the plane is taking off from the tarmac. That’s where Agile methods come in. You look at the requirements and architecture early in the process to ascertain their correctness – not defer verification to the end.

What are the challenges around dealing with compliance and functional safety?

It’s important to think formally about safety and functional requirements and architectures. There are a variety of tools you can use to keep your system safe. For example – I wrote a dependability profile for Rhapsody, that allows you to model safety, security and reliability, and reason about those things in a formal way. Then you use that to trace into requirements, and further into design element trees and into testing elements. In this way you create the entire story around how you demonstrated that these work products met the safety and compliance requirements.

An interesting side note here is around how to show safety compliance for autonomous systems. All the safety standards require is that you have traceability between lines of codes and functionality. For example, “here’s a function – demonstrate how that works.” That works well with software, but autonomous systems are something different. The notion that you can have traceability from a requirement to a line of code doesn’t apply here, because in autonomous systems the decision making isn’t in the code – it’s in the data that’s captured in the weights of the trained system. So how can you demonstrate compliance when you don’t have traditional means of traceability at your disposal? I think that’s a really interesting topic I can dive more into at this summit.

What do you believe is good Agile and how does it apply to modern systems engineering today?

I think that Agile is less about doing different things than it is about doing things in an different order that optimizes quality. Further, Agile pushes the notion of frequent re-planning as more information – such as the velocity of the developers and the stability of the requirements – becomes more known. A traditional project might have a five-year program – so traditionally, you plan that on June 17 2022, at 4:03pm, this or that is going to be done. At that planning stage, you’re really just making this level of detail up – there’s no way you can have the depth and level of stability of information required to make that statement with any kind of assurance. With Agile, you acknowledge the things you know, and those that you don’t. You bear in mind the level of risk and make some predictions about how long something is going to take based on resource requirements, within certain error boundaries. The outcome of agile planning is a range instead of a number, and we seek to reduce the extent of that range as we gain actual information as the project progresses.

For engineering, testing as early as possible means you’re avoiding defects rather than fixing them ex post facto. You build a system in small increments that can be demonstrated to stakeholders early – to ensure it meets their needs. Changing the order and the early demonstration of completeness is the key benefit of Agile. Ultimately, we want to get early measures of confidence. We can correct ourselves in real time, as we run the project, rather than wasting completed work by fixing mistakes we made early on.

Want to hear more from IBM’s engineering experts? Read the Top 10 Takeaways from this year’s Agile Engineering Summit. And if you want to meet our experts in person, be sure to register for our next engineering conference in April, the IBM IoT Exchange in Orlando. Don’t wait to register – tickets will go fast!