SPK and Associates co-founder Chris McHale speaks with Peter Thorne, director at Cambashi, a Cambridge, England-based independent industry analyst firm. With his over 30 years of experience as a software engineer user, vendor, and now analyst, Peter’s in a great position to watch the market identify trends and upcoming issues. Here is Chris and Peter’s podcast discussing the latest trends in Product Lifecycle Engineering Tools followed by a transcript.
Transcript:
Chris: Hi, this is Chris McHale, co-founder and COO of SPK and Associates. And we are so pleased to be here with Peter Thorne, who’s a director at Cambashi, which is an independent industry analyst firm, which is based in Cambridge, UK.
So Peter has applied information technology to engineering and manufacturing enterprises for more than 30 years, holding development, marketing, and management positions with both user and vendor organizations. And Peter, could you just take a moment to tell us a little bit more about yourself and your experience leveraging technology in product development?
Peter: Chris, thanks. Yes, indeed. I think you’ve said it, really. I’ve spent my entire career of working with software for engineering. And I’ve sat in all the seats, I think, the user, the vendor, and, now, the analyst seat. So that’s given me a range of points of view.
And now, here at Cambashi, it’s a great position to be in to be able to watch the market, watch what’s going on, and then be able to hopefully assemble that into some framework and a view of the trends and the issues in the market.
Chris: Okay, that’s wonderful. And we’re hoping to be able to glean some wonderful pearls of wisdom from you today, because I know that you’re day in and day out looking at this market and this industry and trying to look for interesting things that are going on. And today, what we were thinking of discussing were intriguing trends in the product life cycle engineering tools, which is somewhat broad. But I know this is something that you’ve done some recent research on. And it’s certainly not new news that products are becoming increasingly complex and smart, and they involve all three disciplines of engineering these days, mechanical, electronic, and software.
And I’m wondering just to start off, to set the stage, can you describe some of the trends that you’ve been seeing and the popularity of various engineering or product life cycle tools, what you’re seeing emerging, especially over the last few years?
Peter: Certainly, yes. I think the place to start is really one strand of Cambashi’s research, which is market sizing data. So we maintain market figures for software tools used by engineers. Now, if we take a slice of mainly mechanical design, I think that’s the place to start, the familiar CAD, CAM, CAE, PLM. If we put that part all together, then last year had relatively modest growth. It was 4.9% worldwide. And if you look inside that slice of the market, there were no real surprises in the sectors showing the growth. High tech, automotive, aerospace and defense, machinery, all of those were above-average growth. Whereas, process industries, utilities, services, and public sector were all a bit lower than average growth.
So 4.9%, overall, not too bad, given the space of the current world economy. And actually, our forecast show a bit of growth, accelerate count to 5.8% in 2017, so generally an okay slice of the business. But, okay, that’s all it is.
We move on to another slice. And this is where I think the interest really is, systems engineering and embedded software development tools, so the stuff used by engineers to help to develop embedded system, especially the software part of that. And it’s a different picture.
To measure this bit of the market, it’s not an easy bit to measure, but what we do is pull together data from about 400 software tools offers and pull it apart again into about 600 product groups. Then we’ve got our classification scheme of about 20 engineering tasks. And we allocate these product groups into those tasks and then aggregate those tasks into the five major workflows that we define.
But before looking at that level of workflows, I think the first point is, overall, that this bit of market, systems engineering and embedded software development tools, this is growing at 11%. And we’re forecasting 12.5% next year. So the MCAD[SP] bit of the market was okay. But this bit, embedded systems tools, is growing two and a half times faster.
Chris: That’s an impressive growth rate.
Peter: Well, it certainly is, yes. For anyone who’s lived through a couple of economic cycles, it’s one that comes with the memories of the challenge of writing business plans to hire people and open new territories and plan the wow factor for the next version, all of that sort of thing. So yeah, it’s a strong growing environment, these systems engineering tools or tools for embedded software development.
But the next thing that jumps out from our numbers is the way that the growth is distributed. So I mentioned the 20 engineering tasks and the five workflows. The five pretty much just follow the time sequence of traditional product development, requirements, systems architecture, implementation. The fourth one is verification and test. And finally, we have maintenance.
And if we look at the distribution of growth, I can summarize that by quoting from a research interview that I personally did. I was talking to an engineering manager responsible for selection and implementation of tools for embedded system development. And this person said, “The value is upfront, but the volume is downstream.”
If you draw the chart of those five workflows, it’s exactly what you see. It’s a classic bell curve from requirements and system architecture to high point and implementation then dropping down again for testing and maintenance, and probably no real surprise.
But the point is in the growth, requirements and system architecture have been growing at faster rates than the average over the last four years, every one of the last four years. The average was already quite high, 9 or 10% in the past up to 11 and 12% now and next year.
So it seems that decision makers are indeed putting more into the tools for those upfront parts of the development process.
Chris: So it might be self evident, but why do you think that is, and why recently?
Peter: Yeah, good question. Each buying decision is different. But I think that a lot of engineering managers would agree with that quote “The value upfront, but the volume is downstream.” But when you think about the smart product makers, and that means just about everybody with an electronic component, I think that right across the board there, there’s a maturing in this market. And what’s happening is that the emphasis used to be on just making it work. That was especially true for the software. And that pushes the implementation and, I’m afraid, the downstream verification and test. But that’s under control these days. And it’s not quite so critical. It’s something else. And I would say it’s the growth of . . . And you mentioned this earlier, Chris. It’s the growth of complexity across just everything, electronic sensors, actuators, communications.
And it’s not just the product complexity. The engineering teams are also dealing with the complexity of partnerships, their partnerships with suppliers and their own distribution chain. All these things mean that there’s more emphasis on the requirements and systems architecture. You’ve just got to be in control of those things to be able to be part of what really is a complex supply network and, indeed, a fast changing supply network.
And in fact, there’s another factor, which is more hands-on, I suppose, which is model-based development. I think the market impact of that is smaller than the effect of complexity. But it is significant for each individual making a decision about tools. But the point is modeling tools are increasingly able to generate code automatically. You draw the system diagrams. The tools generate the code. And these tools effectively bypass a number of the implementation tools. So you get the work being done in the system architecture stage. The automatic code generation means you bypass that coding. And more and more engineering teams are recognizing this as a viable way of working. So more of their money is spent on these modeling tools.
Chris: Yeah, it seems as if because of this growing complexity in the products . . . Everybody has known from time immemorial that, yes, you should spend time on requirements. You should spend time on the upfront planning. There’s all those statistics about issues or bugs found downstream in the product life cycle, cost, whatever it is, 5x more, whatever that metric is.
But now, I think it’s getting to the point where it’s almost impossible to effectively develop a product with these three complex disciplines of engineering and including an extensive supplier network. You almost cannot do it unless you spend that upfront time and requirements in the systems architecture. I’m not sure it’s even possible anymore.
Peter: I think that’s right. And I think it was someone in the U.S. who used that phrase, which possibly is a bit of a cliche now, but it’s “Solve the right problem first. And then worry about solving it right.”
Chris: When you say that, actually, I’m also thinking that I think there’s increased competition in the development of products as well. There seem to be, because of perhaps the global economy, there are more companies developing products. There’s almost more competition. And so that idea of making sure that you’re really addressing defined user needs and requirements that address those specific needs becomes incredibly important. Otherwise, you do end up developing something that either nobody really wants or somebody else has been able to do before you.
Peter: Yes, that’s right. And I think there’s another angle on that, which is on the systems engineering side, which is simply the scope that teams are trying to consider. So by the time you get to a connected product with applications in the cloud supporting that, by the time you add in the design for manufacture, the design for maintenance, or maybe even the design for recycling thinking. That’s systems engineering stuff at a large scale. And people are trying to optimize across this huge range. It’s not just make a product that works. It’s make that product, and it’s got to be able to be right, for the maintenance guys to be right, for the recycling effort has got to be right, for integration with other systems, all of that broad scope.
And it seems that companies believe that the way to competitive advantage can be to broaden the scope of optimization so that they really can offer . . . Well, sometimes it’s better life cycle costs. Sometimes, it’s to support their own change of a business model as they want to move towards some sort of pay as you go pricing for their product.
So a lot of things going on, but it does mean that you get these engineering teams who need to drill down and focus on the specifics. And at the same time, we’re trying to handle this very broad scope of the domain that they’re trying to optimize within.
Chris: Do you also think regarding the requirements and the grilling[SP] need and importance of the requirements management tool? Do you think that’s also related to the growth and the importance of software in these various products, because one often thinks that the more complex requirement management has tended to come along with the software products rather than the hardware products? Do you think there’s a relationship there?
Peter: Yes. And I think there are a couple of parts to it. One is to do with the actual complexity and, indeed, the fact that software is down, software can indeed add to the complexity. The other thing is the way in which software engineers are bringing some new thinking towards the integrated product teams that are often the core unit that are developing these products.
I suppose I found some organizations where they recognize it as disruptive, but they’re determined to get through this disruption. And in these cases, it’s ones where it’s senior hardware people who are leading the teams, and they’re trying to find a way to use the software people in the team to move them forward. And the theme they like is agile development, which is pretty much chapter and verse for software development these days.
But hardware people, although they recognize it’s not the same, they’re beginning to think that, actually, the simulation tools are improving enough so that they can do this agile development. They can just take an initial specification, rig out some sort of model, push it through the simulation model, have a look, and loop back and do it all again, which you know, okay, I’m abusing the definition of agile. But that’s a part of it.
So this disruptive change, and it ends up . . . You see it in things like the user requirements tools and the other tools such as simulation. It’s because software is different, which gives people some difficulties. But I think there are people in there who are seeing software and the software development process as being something from which they can take some good points. It’s not all good, but they can take some good points from that.
Chris: Right, it’s almost a slightly different philosophy, but also a different way of working, a different mindset. And often, the software engineers do have quite a bit of a different mindset than the traditional hardware engineers. And I think some of these organizations, which have been traditionally hardware, with the hardware engineers leading the way, if you will, and then software was introduced in somewhere along the product cycle or the maturity of that company. And then the software guys sometimes sat over in the corner for a while and weren’t really as integrated. And I think the companies where they’re really allowing that kind of agile methodology, agile philosophy, or this agile way of thinking and working to lead the way and infiltrate the hardware engineering organization, they’re the ones that I think are benefiting the most.
And you see, like you said, you see the agile word, if you will, popping up in all sorts of places, agile manufacturing and agile this and agile that. But you’re absolutely right. I think it’s having a really wonderful influence on the hardware side and promoting a much more flexible and user- or customer-oriented way of engineering and developing product.
Peter: Yeah, I would agree with that. But the truth is software and software engineers are indeed different. They’re used to a rate of change a hundred thousand times faster than most traditional hardware change processes are designed for. So it’s going to be, if not a clash, there’s gotta be an appreciation of the coming together of the technologies that, if not, there are going to be issues to solve.
Chris: That’s right. And perhaps even in the introduction, I was thinking too as you were talking, you were talking about developing with better simulation and so on tools. But also with the development of 3D printing . . . And we certainly . . . I think we’re in our very nascent stages of that. And it’s probably over-hyped to some degree. But still, the ability to get a prototype out there that you can look at very quickly does help promote that agile methodology or thinking even on the hardware side.
Peter: Yeah, very much so. And there are some true engineering benefits from that, actually having something in your hand to look at and so on. And alongside that, there’s obviously the fantastic benefit in maintaining support for a project and maintaining engagement from a management team or from the top management through the marketing group, through everybody involved. And if you can get a physical prototype in their hands and stand them in front of the screen, which shows the simulated, the model being simulated, then suddenly you get input. You get enthusiasm. You get all sorts of possibilities. But yes, that means you’ve got to have somebody in there who’s willing to work in a new and different way.
Chris: That’s right. One other question and perhaps last one that we have time for, Peter, in this development or trends of these various tools that you’re looking at, there have traditionally been two camps of overall product life cycle tools, development tools, or management tools, rather, one typically called PLM and the other ALM or application life cycle management. It used to be called SDLC, software development life cycle. These have grown up side by side, and I would say they were both viewed as . . . PLM at least is used enterprise tool, ALM, more or less these days, I think, more and more. And yet they seem to coexist side by side and yet not really come together or be integrated in any formal way, if you will. Do you still see that being the case? Do you see any changes coming there? What is your view of these two worlds? And what needs to happen with them also?
Peter: Yes, that’s a very good question and a very important point. And it’s an issue actually for so many people making decisions and plans for tools. I suppose the starting point is indeed that software is different. Software engineer is different. But software is different because when you go down to the detail, and of course, you can’t force software structures. And by that I mean the source code trees or the include files, the build scripts, the run time library versions. It just doesn’t fit into a traditional bill of materials structure.
Chris: Right.
Peter: And when you examine that, you think, “Oh no, it doesn’t.” Really, it fits across the whole . . . If you look in mechanical manufacturing, discrete manufacturing, it effectively covers all of the processes from the design through to the manufacturing planning through to the actual manufacture.
A normal software environment with the include files, the build scripts, the run time libraries, it’s all of those things together. So it’s not surprising that it doesn’t fit just a single bill of materials structure.
So users recognize this. And they say, “But at some point, there has to be a solution.” And from what I’m seeing, they are expecting the PLM providers to find a way to solve this.
Now, in the meantime, they seem to be entirely happy that actually there’s nothing wrong with a data management solution, which doesn’t have to be completely prescriptive about the tools that individual engineers use.
Chris: Right.
Peter: And the reason is, as I understand it anyway, it’s that they know . . . If you think of yourself building one of these smart machines, it’s going to be out in the field for maybe 10 years, maybe 20 years. If you think of something like a railway, a locomotive, or indeed a coach, a carriage for a railway, that’s going to be there for 40 years. Now, when you build one of those machines, you know your buyers only invest if they believe that you’re going to be able to fix faults during the service lifetime.
Chris: Right.
Peter: And for you to give the confidence to a customer . . . So I’m speaking now as the manufacturer of one of these things. For you to be able to speak to your customer and convince them that, yes, in ten years time you’ll be able to fix faults or provide an upgrade of some sort, you’ve got to know in your heart of hearts that you understand all the dependencies. And that means the bill of materials dependencies, which are pretty well covered these days, and whatever extensions the software needs.
And I think that’s going to be the driver of how these things are brought together. The pressure is going to come from those manufacturers who are saying, “Look, I’ve got to be able to prove . . . Well, actually, I’ve got to be able to believe that I know all of these dependencies.”
So it means the example of a CPU being no longer available after five years. You’ve got to move to a new CPU. What does that mean for the electronics in some smart device. Is it going to be the same software? Well, actually, no it’s not, because all of the support libraries and maybe even the communication stacks are different. It’s going to be a different memory image, okay? That’s the point at which PLM and ALM have got to come together so that you can absolutely do the equivalent of where-used enquiry that roots you through from that change of processor right through to the software that might be involved because you’re going to change that processor.
So there’s going to be pressure. I’m sure you can absolutely convince the users look first to their PLM providers because their first in, as you quite rightly pointed out, as they enterprise system, the system that looks after this product information. But the smart product manufacturers absolutely know this ALM stuff has got to get in there somehow.
Chris: And perhaps it goes back to the requirements and the system architecture tools and the requirements management, often I think these days being viewed as it should, if it doesn’t already reside in PLM, and its driving requirements, not just for the hardware, clearly, but for the software as well. But then perhaps those ALM tools are managing the day-to-day turn of the software and the development of the software and, ultimately, delivering back whatever that deliverable is back into the PLM that meets those requirements. And also alongside that, the change control would definitely have to be in the PLM as well if there’s going to be one-stop shopping for all of these, for the entire system or the entire product.
Peter: Yeah, that makes sense. And that may be a completely, a really robust, way of solving the problem is to track everything back to the originating requirement. So if you can do that and you can get software that links the requirements, you can get the electrics and the electronics to the same requirement and the mechanical parts, if you could use that as the hub, and you can then imagine either an engineer eyeballing the setup and tracking through the database, or you can imagine an automated system following those links to do what has to be done, which is understand the dependencies, or at least not understand the dependencies, but find the dependencies.
Chris: Right. That’s wonderful, Peter. I think we’re probably out of time today. But this has been a wonderful conversation and fascinating. And I really appreciate your time. And we look forward to the next podcast that we can do together.
Peter: That would be great. Yes, thank you. Great questions, great comments, great conversation. Thanks, Chris.
Chris: Thanks so much, Peter.
