QRA Corp

The State of Systems Engineering: A Q&A with Jordan Kyriakidis, PhD

Join Host Joshua Sutherland with Guest Jordan Kyriakidis, PhD as they discuss the current state of systems engineering from his perspective as a Quantum Physicist and CEO of QRA Corp.

Table of Contents

Joshua –  Today’s guest is Jordan, who is the founder and CEO of QRA Corp; a company based in Nova Scotia, Canada (Halifax), and we’re gonna talk about what that company does, what it offers to the systems engineering industry and also to the individual customers and learn quite a little about Jordan’s background, that led him to create this company. So welcome, Jordan. 


Jordan –  Thank you, Josh. It’s a pleasure to be here.

Could you give us a bit of an overview of your company, QRA?

Jordan –  Sure. We are a technology software company and we sell primarily to enterprise and engineering organizations. Currently, we solve 3 problems for our customers and they’re all centered around engineering requirements. One problem that we help solve is that a lot of our customers undergo difficult requirement reviews; very costly, very timely, and the outcomes aren’t as good as they want them to be. The second problem is that some of our customers lack an understanding of  requirements best practices. They know that the requirements need to be approved but they don’t have a good understanding of what the best practices are and how to verify that you are adhering to those best practices. And, the third problem is just a general improvement of requirements quality; especially if requirements are going to go on. Typically they’re in the initial phase of a product development or systems development, and they know that poor requirements quality will have a compounding danger later on inthe life cycle of the development process. So they really want to improve quality. Almost all requirements today are written in natural language. In fact, most of the world’s information is written in text. So natural language processing (NLP) and natural language understanding are the appropriate technologies to use here; so what we actually do with our software tools provides a quality score for each requirement that you have and also for the collection of requirements as well. We would look for term consistency. So if you called something “a rover,” “a module,” or “a vehicle;” different terms for the same thing in your document, we’ll flag those and say maybe you should consolidate the terms. It checks for unit consistency; We can look for requirements that are very similar, which often means they contradict each other. So those are the types of solutions we provide to our customers.

What is the process that customers go through when buying your product [QVscribe]?

Jordan – So it is a product that they would buy and install on their premises. And if they have requirements written we have several integrations.  Many large projects start off in either word or excel, so we provided integration to that so that you don’t have to move your requirements and you can analyze where you are. Also, many of our customers use specialized requirement management tools, like DOORS, which is a product by IBM; there’s Polarion, a product by Siemens; there is Jama Connect, by Jama. If you use those, our [Requirements Analysis tool] QVscribe, integrates directly with these tools and you don’t have to move your requirements anywhere.  So you can analyze requirements that exist, but also if you are authoring requirements, our product is right there beside you, advising on the quality of the requirement. A lot of our customers have the reason they want to improve requirements quality, for example, they may have a lot of engineers that are very young and still don’t have the experience or English is not their first language. So typically they would be paired with a senior engineer and there was a lot of back and forth on improving the quality; they may not be atomic, or they may have excessive continuances. The senior engineer would advise them and tell him to break it up. The issue they have is they’ll go into a review meeting and they end up talking about the syntax of the requirements, as opposed to whether the requirement is correct. So using our tool allows them to have the discussion at a higher level.

Download the Free Guide & Checklist

Due to popular request – booklet & printable checklist now available!

Are you finding that the demand for this type of product is on the rise?

Jordan – Absolutely. The demand is increasing a tremendous amount. The first product we built was a designed tool to make sure that the designs were correct. What ended up happening was most of our customers ended up comparing their design implementation with the requirements. What we found out is most of the requirements are very poorly written. I’m a physicist by background, so by nature I like to get down to first principles; in this case, it is finding the error as early as possible. We realized fairly early on that actually you can make mistakes even before you get to the design process when you’re first capturing your intent rather than writing down the requirements, so we should focus there. That’s where we saw great success; both commercially as a company, but also the value would provide and the solution provides your customers.

How did the company come to exist?

Jordan – So I am a bit of an accidental entrepreneur. The plan wasn’t to do what we’re doing; I just followed my nose and followed the interesting problems.I am an academic by training and an academic running a company? I would say there are pros and cons associated with that. My background is in Theoretical Physics; Quantum Theory, in particular. I was on the path to being the venerable theorist with the leather elbow patches and the whole bit, but then I ended up getting an R&D contract on quantum computing with an aerospace company. That contract was very successful and the value of the contract ended up increasing. The team expanded to service the contract, but it became progressively more applied. We went from doing the fundamental science to understanding the engineering problem that we’re trying to solve. From there, they altered the business problem that we’re trying to solve, and it became even more applied. As we learned more about the problem, the way we solved it kind of veered. The technology we used and the ways we solved the problem changed as we went along. A lot of the principles that we have in theoretical physics that were developed over the last half-century can be applied now to these synthetic systems because they’re so complicated – so many interacting pieces. We started making progress with that. It got to a point where I had to stop developing algorithms and start developing a product in order to get the engineers to actually use the algorithm to validate them. So it kind of started backwards I would say than what was typical. After we did that, we started learning about how to run a company.

How do you see the current state of systems engineering?

Jordan – I am not a systems engineer by training, so I have a view from the outside. I have a technical background, so I can understand it. So to my mind, the current state of systems engineering is that the fundamentals are quite strong. Systems engineering as a distinct discipline is gaining in importance all the time and will continue to do so for decades into the future. At the same time, there is a great deal of change and evolution, even disruption coming because of 3 items in particular. One is technology. New tools are available now that could automate parts of the work, especially design. CAD (computer-aided design), for example, is a huge change in the way the discipline works now. Another one is market demands. Products themselves are becoming far more complex and so too are the methods and techniques of design and manufacturing. Software is becoming far more important. The third one is people. The experienced engineers are retiring and the young ones are moving in. There is a generational shift happening. Because of all of these things, I would say there’s a mix of anxiety and confidence. Anxiety because there is a change coming and it’s not quite clear what the other side will look like, and confidence because systems engineering is gaining an obvious and recognized importance.

As an expert in quantum, where are you seeing that impacting how we can do systems engineering?

Jordan  – I think the timeframe of when quantum computing will affect systems engineering is unclear, but the technology clearly has the potential to be a game-changer. It is also unclear how this technology will be used. One of the analogies I like to use here is the laser. The laser is just light, but we don’t use lasers for illumination. We use it for so many other different applications. I think quantum computing is going to be a lot like that. It’s processing in some AI systems, especially the training of models could be using quantum computing. Cryptography and security are obviously going to be a big deal. It is going to be somewhere in there where these systems are going to play.

Would Natural Language Processing and AI be the most interesting new technologies that you would be actively engaging for your products?

Jordan – Today we use a lot of AI, Natural Language Processing, and Natural Language Understanding, only because that is where the requirements live. They live in text: if you want to analyze them, you need to use Natural Language Understanding. You can then go beyond that; you can think about what happens afterward. If you have some requirements and have a model, you can use AI to tell you what parts of the model are suspect that you may want to look at. Right now it’s primarily Natural Language Processing because that’s where we are, but the technology is increasing so fast. 

 

Joshua –  I guess you can piggyback on the advances from what’s going on with companies, like Microsoft and Google, who seem to be really pushing the envelope in those algorithms. 

 

Jordan – Yes,  to a certain extent. To a larger extent, we can. We don’t need to reinvent the wheels. The difference is, if you look at engineering requirements or technical specifications more generally, they tend to have a very particular kind of language, where most of the general models produced by the big companies are trained on newspapers, or Wikipedia; the just general pros. It’s a good base, but we need to do some training on top of that to steer it towards the technical language

Do you find that a lot of companies and organizations have their own language that they have sort of codified or taught to their employees?

Jordan – They do, yes. Some of them have it so there is a difference between the word “must” and the word “shall.” They mean different things and then codify them.Most companies today verify that manually, meaning they have a senior engineer, who is one of the most expensive resources, their job is to read the requirements with a highlighter in hand and circle all the errors until their eyes bleed. A lot of this stuff can be automated.

Are you working with customers in a wide range of industries?

Jordan – Yes. Our 2 biggest industries are oil and energy companies and medical device companies. Aerospace and defense, automotive, and semiconductor companies are up there as well. Those industries that really value systems engineering. They have products that need to adhere to some regulatory standards and there is a criticality associated with them. It’s important for them to be correct, and it’s expensive to develop and expensive to change once you find errors down the line. As opposed to a typical software startup that if they find an error, they can just fix it and no one dies if it goes wrong.

Do you find within the domains you do work that there are differences in this culture or the types of solutions that they prefer?

Jordan – So much actually. It’s not that we have to specialize in one industry or the other. In the end, they are all systems engineers and there is a core set of principles that they have to adhere to to make these complicated systems that work. It is a combination of software and hardware, and there are a lot of interacting components. So because those things are the same, the technical issues are the same and the solutions are the same. Where there are differences is more on the business side. A company in the medical device industry’s main driver may be time to market. So they want to make sure that the requirements are correct, because it’s a race to get something to market because their competitors are on their heels, and generally they’ll have a product they release and then start working on the next one. Whereas say an aerospace company, their main driver is correctness; things have to be correct and they’ll take the time to make sure they are correct; they cannot tolerate any errors. It’s more the business drivers and the structure of the company, not so much the technical core issues.

Where do you see the next 10 years for systems engineering as an industry?

Jordan – Again, this is largely speculation, and we have to look at what we can answer. One question is what is the state of requirements writing and how is that going to change over the next decade. Then there is a broader issue of what systems engineering is going to look like in general. We talked earlier about the state of systems engineering today and a lot of the challenges facing requirements in systems engineering in the near future really are outcomes of those. One thing that is different now is that most companies have either moved, or are planning to move from the traditional waterfall manufacturing technique to a more agile and flexible approach. So requirements are still vitally important because you do need to capture your intent of what you want to build. Whereas, maybe in the past, requirements were more of a very distinct phase and, when you’re done, you move on to implementation. What we’re seeing now, and what we continue to see, is requirements will parallel and mature over time; so there would be several passes. That means that it’s more important that as this information matures, you can maintain coherency and coupling between all these different artifacts. Today this is done largely manually and the burden is becoming just too great for individuals to do that. It’s not really a question of the caliber of engineering; it’s more a question of complexity and of putting all that information into one head. I would say that’s one big thing that both tools and processes are moving towards. It is going to take about a decade before that process is complete. The other one is the technology itself. Requirements are becoming more important now because for a long time, most new products were incremental improvements over the previous versions.The engineers that we’re building the products were pretty smart; if they saw the requirements were bad, the engineer could say, “I don’t know what kid wrote these but I know what I’m doing because I built these products before and I know how to build it correctly.” They were largely correct. What’s happening today because there is a new technology, sometimes disruptive technology, they’re being introduced deeper into the products – mainly sophisticated software, such as sensors.  Engineers have less experience with these new non-incremental kinds of systems, and because they don’t have the experience, they rely more on the specs and on the requirements. So even though the requirements were never really all that great, their importance is becoming greater as time goes on because people are relying on them more and that trend is going to continue in the future. Things like the quality, the completeness, and the correctness of requirements are gaining a new importance now because they are relied upon now more than ever.

What do you think some of the problems or challenges the systems engineering industry will face in the next 10 years?

Jordan  – There are multiple issues coming in, such as human resources and personnel problems, as well as a technological problem. I think over the next 10 years or so, there’s going to be  a lot of changes in systems engineering itself. I think I see 3 main changes in technologies that really are just starting now that are going to continue to spread. One is the whole idea of adaptive algorithms; the algorithm itself changes the more you operate the piece of equipment. Another one is generative design. The third one is additive manufacturing. So these 3 manufactured technologies are going to just become more automated and I think the whole idea of manufacturing will become automated.  The value of the human systems engineer is going to be even more so on the earlier stage of systems development, not so much on the actual manufacturing itself. Nvidia has recently become the largest semiconductor manufacturer in the world, and over time, they were able to grow at 3 times Moore’s Law. The reason they were able to grow so fast and leapfrog over the competition is because of the weight they put on simulations, emulations, and design upfront. When they were getting wafers back with far fewer errors than the competitors did. It still took 18 months, which is a general Moore’s Law that remarkably lasted for so long. That time scale is pretty much set; just set by the design, the manufacturing, the testing – it’s just 18 months. But because they were so sure that the error rates were going to be so low, they had 3 teams staggered 6 months from each other that when team one finished a third of their 18-month cycle, the second team would start, so they could release a new chip every 6 months by having 3 teams on 18-month cycles. They were only able to do that because they were so certain of their design. Now I think that level of design rigor is going to happen in many industries around the world with many different verticals

How have you found the transition from professor into the CEO role, where presumably you have quite different responsibilities?

Jordan – I do and I don’t know how much of my experience is due to my training or due to my personality. Some kind of weird mixture of two, but there are actually some things that I find quite similar between doing fundamental research in quantum theory and running a company, as strange as it may seem. The reason the things that are similar is that you’re never sure if what you’re doing is the right thing and you’re always kind of worried that you missed something or you screwed up something that can come in and bite you. So you’re always testing and always thinking how can I make sure that this is correct. That’s kind of similar, I would say for running a company and doing physics research. They’re both complex systems and oftentimes neither the inputs nor the outputs are well defined. The system itself is not well defined and part of it is because you just don’t know enough to define the system. Another part of it is that the system itself may not be defined because there’s kind of a part of creation there. You have to define the system that you’re going to then diagnose. So those parts are actually quite similar. The difference is – and there are significant differences- that when an academic career, especially in physics, really the main thing is to get it right. There is a system, which is nature and your goal is to try and get it right. Whereas when you’re running a company, that’s not possible. Even if it is possible, there is always going to be a bad idea. There is this idea that I’ve learned over the years of running a company that sometimes you always kind of want to make the right decision, but sometimes you have to make your decision right. A lot of it is much more subjective. There is no final arbiter. It’s always a trade-off. You have to make a decision. You have to move forward, even if you don’t know what the answer is, then you pick one and just move forward and try to make it work. That’s some of the differences: the speed of decision-making as opposed to in academia. 


Joshua – That’s great.  Well, fascinating, Jordan. Do you have anything else you’d like to add to tell the listeners? 


Jordan  – No, I think we’ve covered a lot of ground. I appreciate it. It was fun talking about this stuff. Thank you. Very, very enjoyable.


Joshua – Thank you, Jordan. It’s been excellent. Look forward to seeing you soon; hopefully in the real world. 

Share this Story

Share on twitter
Twitter
Share on linkedin
LinkedIn

Related Resources