In recent research interviews, Cambashi asked leaders of embedded system development projects about the role of software development tools. One response captured the broad shape of the findings – “The value is at the front-end, but the volume is in the downstream detail .”
The context of this answer was a large project – multiple connected control subsystems for a complex piece of industrial machinery using wireless communication to allow remote monitoring and control. So it is not hard to appreciate the realities behind the comment – system architecture choices have a major impact on the complexities of later implementation.
And of course this is true for development projects large and small in every technical discipline – in a contest between “solve the right problem,” and “solve it right,” the greater opportunity to create value is in those early choices, defining, scoping and framing the problem.
So why is it that tools to help with early stage software and system architecture command only a small share of the global revenue for embedded software development tools? It’s just 14% according to Cambashi’s market data for systems engineering and embedded software development tools. Twice that, maybe more, would seem closer to the importance of the problem these tools are trying to solve.
The case against front-end design tools is full of caveats and assertions, which are not always untrue, for example:
* Not many projects are free to change the architecture (so there’s no reason to use the tools)
* We can’t tell the difference between good and bad architecture until we do the detailed design and development (so we depend on our architects’ prior experience and luck – not tools)
* Initial design and architecture is always entrusted to a small senior team (they’re senior people, they don’t need/use tools)
* Freedom of choice in architecture is almost zero by the time you have handled the real constraints of suppliers, project time scale, available skill sets, risk of change (so tools can’t really make much difference)
* We only really understand what the architecture should have been after we’ve built the system (so we’ll get it right next time).
It is time to consign these doubts to history. The growing capability and use of high-level modelling, simulation and systems engineering tools is enabling tool-supported workflows for the early stages of projects. Add a bit of education and training, and the front-end stages of most projects will follow a pattern:
* Model (so you can communicate ideas)
* Simulate (so you can measure performance)
* Assess (What? No requirements to use as yardsticks? You’d better talk to the stakeholders!)
* Iterate (it will be better next time round)
It has always been possible to model systems – for example, flowcharts in the 1950s and structured development in the 1970s. But modern modeling tools support richer semantics (for example, UML and SysML), and some, just like simulation tools, allow you to ‘execute’ the model and thus simulate the behavior of the high-level design. The ‘assess’ stage will always include eyeballing and discussion, but a systems engineering approach will help organize ideas into requirements statements and associated tests.
Designers still have big questions to answer (such as which elements to include in a model – software, electronics, sensor and actuators, mechanicals). But the benefits of modeling are not restricted to the early stages of design. Some teams attribute increased re-use of software – across platforms and projects – to their use of models in the development process.
So next time you are making, reviewing or approving the case for investment in software development tools, don’t let the volume of need from the later development stages blind you to the value you can obtain up front.
Peter Thorne is Managing Director for Cambashi Ltd. He researches and advises on the new product introduction process, e-business, and other industrial applications of information and communication technologies. He has applied information technology to engineering and manufacturing enterprises for more than 20 years, holding development, marketing and management positions with both user and vendor organizations. He has a Master of Arts degree in Natural Sciences and Computer Science from Cambridge University, is a Chartered Engineer, and a member of the British Computer Society.