Overview
In 2015, SPK and Associates co-founder Chris McHale spoke 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.
Trends Overview:
1. Impressive Growth Rate
2. Faster Growth Rate in the Early Product Development Workflows
3. Growing Complexity in Products and Partnerships”
Video Transcript:
You’re listening to the SPK and Associates podcast.
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 is 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 um. Well I think you’ve said it really. I mean 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 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 into some framework and a view of the trends and the issues in in the market.
Chris: Okay that that’s wonderful and um we’re hoping to be able to glean some wonderful pearls of wisdom from you today because I know that your your day in and day out looking at this market in this industry and uh trying to look for you know 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 in the popularity of various engineering or product life cycle tools? What you’re seeing kind of 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 you know if you look inside that slice of the market there were no real surprises in the sectors showing uh 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 uh you know 4.9 overall not too bad given the state of the current world economy. And actually our forecasts show a bit of growth accelerate you know accelerate out to 5.8% in 2017. So you know generally an okay slice of the business But okay you know that’s that’s all it is. Move on to another slice and you you know this is where I think the 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 the software part of that. And it’s a different picture. To measure this bit of the market, I mean it’s not an easy bit to measure but what we do is pull together data from about 400 software tools authors and pull it apart again into about 600 product groups. Then we’ve got our classification scheme of about 20 engineering tasks and we put the allocate the these product groups into those tasks. And then aggregate those tasks into the five major workflows that we define. But you know before looking at that level the workflows, I think the first point is overall that this bit of the market systems engineering and embedded software development tools. This is growing at 11% and we’re forecasting 12.5% next year. So the MCAD bit of the market was okay um but this bits embedded systems tools is growing two and a half times faster.
Chris: That’s an impressive growth rate!
Peter: Well, it certainly is yes. I mean you know if it for anyone who’s lived through any a couple of economic cycles you know. It’s one that comes with the memories of the challenge of writing business plans to hire people, you know, and open new territories and plan the wow factor for the next version all that sort of thing. So yeah I mean the so it’s a strong growing environment these systems engineering tools. The tools for embedded um 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 5 workflows. The five it pretty much just follow the time sequence of traditional product development. You know it’s 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 it actually 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 up front but the volume is downstream and if you draw the chart of if you draw the chart of those five workflows it’s exactly what you see. It’s a classic kind of bell curve from requirements and system architecture to a high point in implementation then dropping down again for test 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. And that the average was already quite high, nine or ten percent in the past you know 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 but why do you think that is and why recently?
Peter: Yeah good question. Each buying decision is different but I think a lot of engineering managers would agree with that quote. You know. “The value up front 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 this market. And what’s happening is that the emphasis used to be on just making it work you know. And that was especially true for the software. And that pushes you know 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 it earlier Chris. It’s the growth of complexity across, you know, just everything: electronic sensors, actuators, communications. You know. And it’s not just the product complexity. I mean the engineering teams are also dealing with the complexity of partnerships, their partnerships with suppliers and their own distribution chain. You know. 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 you know really is a sort of 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 you know for each individual making a decision about tools. But the point is that modeling tools are increasingly able to generate code automatically. You draw the system diagrams. The tools generate the code and, you know, these tools effectively bypass that a whole load a number of the implementation tools. So you get the work being done in 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… I mean everybody’s known you know from time immemorial that, yes you should spend time on requirements. You should spend time on the upfront planning. And there’s all those statistics about you know issues or bugs found downstream in the product life cycle cost or whatever it is, you know, 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 system’s architecture. I’m not sure i’m not sure it’s even possible anymore.
Peter: I think that’s right and I think it was um someone in the us who used that phrase, which I mean possibly is a bit of a cliche now. But it’s some solve the right problem first then worry about solving it right.
Chris: And it might even and as I when you say that actually i’m also thinking that um yeah I think there’s an in there’s increased competition in the development of products as well. There seem to be because of perhaps a global economy. There’s more companies. 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 kind of design for manufacture the design for maintenance that maybe even the design for recycling thinking you know that’s systems engineering stuff at a large scale. And people are trying to optimize across this huge range, you know. It’s not just make a product that works. You know make that product and it’s got to be able to be right for the maintenance guys. Be right for the recycling effort. It’s got to be right for integration with other systems. It’s got to be all that broad scope. And it seems that companies believe that the way to competitive advantage can be to the unit to broaden the scope of optimization so that they really can offer well sometimes it’s you you know better life cycle costs. Sometimes it’s to support their own change of a business model as they want to move towards kind of some sort of pay-as-you-go pricing for their product. So you need a lot of things going on but it does mean that you get these engineering teams who you know need to folk drill down and focus on on the specifics and at the same time are 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 growing need and importance of the requirements management tool, do you think that’s also related to to the growth and the importance of software uh in these various products because it just one one often thinks that the more complex requirements management has tended to come along with uh 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 you know the fact that software is there and 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 the you know the core unit that are developing these products. I mean I suppose I found some organizations where they are they recognize it as disruptive but they’re determined to get through this disruption. And what 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 um to move them forward. And the thing they like is the kind of agile development you know, which is pretty much chapter and verse for software development these days. But the 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. You know? They can just take initial regard an initial specification, rig up 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 that’s a kind of a part of it so you know. This disruptive change, it ends up you see it in things like the use of requirements tools and other tools such as simulation. It’s because software is different, which you know gives people some 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. You know? It’s not all good but they can take some good points from that right.
Chris: 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, you know kind of leading the way if you will. And then software was introduced in somewhere along the product cycle or the 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 just agile way of of thinking and working to lead the way and kind of infiltrate the hardware organization, hardware engineering organization, they’re the ones that I think are benefiting the most. And you see like you said you see this the agile word, if you will, you know, 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 kind of user or customer-oriented way of engineering and developing product.
Peter: Yeah I would agree with that. But you know the truth is software and software engineers are indeed different. They’re used to a a rate of change you know 100,000 times faster than most traditional hardware change processes are designed for. So you know it’s going to be a if not a clash there’s got to be an an appreciation of the coming together of the technologies that it’s 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, what moves better with better simulation and so on tools. But also with the development of 3D printing and certainly I think we’re very nascent stages of that. It’s probably overhyped to some degree but 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 you know there are some true engineering benefits from that. You know actually having something in your hand to look at and so on. And alongside that, there’s obviously the fantastic benefit in kind of maintaining support for a project and maintaining engagement from a management team or from the top management through the marketing group through everybody involved. You know. If you can get a physical prototype in their hands and stand them in front of a screen which shows the simulated unit, you know, the model being simulated, then suddenly you get inputs. You get enthusiasm. You get, you know, all sorts of possibilities. But yes that means you 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 when we have last one that we have time for, Peter, is in this development or trends of these various tools that you’re looking at there have traditionally been I guess two camps of overall product lifecycle tools – development tools or management tools rather. One typically called PLM and the other ALM or application life cycle management, used to be called SDLC – software development life cycle. Do you – These have grown up side by side. I would say they were both viewed as… PLM at least is used as an enterprise tool, ALM more or less these days I think more and more and yet they seem to kind of 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 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 you know software in software is different software engineers are 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 you know the source code trees all the include files, the build scripts, the runtime library versions, it just doesn’t fit into a traditional bill of materials structure. And when you examine that, you think “well no it doesn’t. It 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 the actual manufacture the actual manufacturer. A normal software environment with the include files that build scripts the runtime libraries is 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 you know 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… 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 um you know if you think of something like a railway locomotive or indeed a coach a carriage for a railway, you know 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. And for you to give the confidence to a customer – so I’m speaking now as the manufacturer is one of these things, you know – for you to be able to speak to your customer and convince them that yes, in 10 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 you know the bill of materials dependencies, which are pretty well covered these days. And whatever extensions the software needs. And I think that’s you know 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 no well actually i’ve got to be able to believe that I know all of these dependencies.” So you know it means the example of a CPU being no longer available after five years. Gotta 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 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 kind equivalent of a where used inquiry that routes you through from that change of processor right through to the software that might be involved because of you know 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 they’re first in as you quite rightly pointed out as the kind of enterprise system. The system that looks after this product information. But the smart product manufacturers absolutely know this ALM stuff’s got to get in there somewhere.
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 it’s 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 churn 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 kind of 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 you know a really robust way of solving the problem is to track everything back to the originating requirement. So if you can do that you know and you can get software that links the requirement, you can get the electrics and the electronics to the same requirement, and you know the mechanical parts, if you you could use that as the hub and you know 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! Well that’s wonderful. Peter, I think we’re probably out of time today but this just 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.
You’re listening to the SPK and Associates podcast.
