How to ensure your SCM system is fit for purpose in today's electronics design industry

4 mins read

A couple of decades ago, version control – often referred to as software configuration management (SCM) – was largely unheard of outside the software development industry. Then the sheer volume and variety of the different elements which electronics designers have to keep track of began to increase. That pushed the electronics industry to adopt version control, to the point where, today, the approach is pretty much ubiquitous.

This is largely driven by the fact that teams of chip designers, engineers, developers and testers each work at different rates using a wide variety of design and development tools that need to be coordinated. Version management can help keep the vast amounts of information and work on track, including across distributed teams.

Beyond software code, SCM is also being used increasingly for other 'assets' – potentially, everything that an electronics design project might include, such as CAD material, technical manuals, simulations, test case, graphics and much more. These assets are any company's 'crown jewels' --- the IP on which it depends. That means access control, versioning and auditing are critical. It is vital that organisations protect this IP from external threat, but are also able to monitor any suspicious internal activity that may lead to IP loss.

Time to review the status quo

As electronics projects become more complex and with greater pressure on getting products to market more quickly, companies need to consider reviewing their version control requirements. Although legacy systems may have performed perfectly well for the past decade, it could be time for them to be upgraded to the latest version or even replaced with something more fit for the purpose.

Mergers and acquisitions typically lead to a range of different software systems being used across an organisation and version control systems are no exception to this. Multiple systems increase complexity and risk, while reducing opportunities for reuse. Rationalisation should be a priority.

Another driver for change may be the adoption of new development methodologies. For example, some sectors of the electronics industry – such as automotive – have been enthusiastic adopters of Agile and Continuous Delivery as a means to bring their products to market more quickly. Some version control systems are better suited to these methodologies than others. Plus, there is the simple fact that version control systems have evolved a great deal in the past decade, so users could be missing out on new functionality of which they are not aware.

So far so good, but evaluating and, potentially, replacing version control software can seem overwhelming – the choice is vast. Here are some suggested 'best practice' criteria.

* Evaluate what you want the system to do.

First of all, define what you need from version control. This may sound obvious, but the needs of the electronics industry differ from, say, a games development or enterprise software user. Embedded designers typically require version control systems that can handle complex file types, not just source code. They also need integration with tools widely used across the industry, such as Mathworks' Simulink, static code analysis tools such as Parasoft, and ALM/PLM tools like Polarion.

The embedded design industry has often involved multiple external collaborators (particularly in OEM and sub contractor environments) and there is a growing trend towards even tighter integration across the supply chain. This leads to new requirements on how to share products safely with customers, without risking the company's IP and ensuring the correct variants are delivered to the appropriate customers. The version management platform can provide the access control and recording tools such environments need.

* A good fit for users

The system may need to support a diverse range of technical knowledge – from code savvy developers through to non technical product marketing staff – with access to different levels of data, types of permission and training.

Each of these roles may also have a preferred interface and process for interacting with the version management system, be it via a GUI, a seamless plug in or even an integration that allows use of an offline versioning tool, while maintaining full accountability with the enterprise versioning system.

* Evaluation

Most companies tend to evaluate three to five vendors and this seems to be a good balance between having enough choice without becoming overwhelming. Make sure that the company's requirements have been shared before a demo takes place, so that the presentation can be tailored. This is also a good opportunity to get a sense of what it will be like to work with the vendor; important for future support requirements.

Find out how often new software features and updates are provided and whether these are usually included in the price. As well as clarifying hardware and network requirements – is one server enough or would more be needed? – ask questions around security and IP protection. Does it support Agile or Continuous Delivery methodologies, for example?

* Room for growth

Check scalability; while some version control systems are great at supporting small teams, they can 'fall over' once they are asked to handle large data repositories and bigger teams. Does your prospective vendor need to support 5, 50, 500 or 5000 users?

Of course, it is a good idea to ask for customer references, but also have a look at the 'vitality' of the ecosystem or user community – is the attitude generally positive and how responsive is the vendor to questions? How effective is the vendor at communicating news and does it hold user events, either physically or online? Are knowledge resources freely available?

* The bottom line

Any reputable vendor should be able to assist with calculating the likely return-on-investment, but make sure everything is covered, including administration, hardware, project hosting, training, consulting and support costs. If you are looking at an open source solution, don't forget to factor in associated costs, such as support and what happens if the system has to rapidly scale.

* Implementation

Most vendors should be prepared to offer a free trial and it makes sense to focus on a pilot team or to ask different stakeholders to evaluate different elements and then report back. If migrating from an existing system or consolidating data from multiple legacy systems, then investing in consultancy services – whether from the vendor or a third party – is a smart move. Even the most knowledgeable in house team will find it very difficult and time consuming to import the data from half a dozen existing systems into a new one.

Changing version management may seem like a massive step, but it's not an insurmountable one if the right steps are taken. More to the point, however, the potential gains – for instance, a system that supports, rather than hinders, more efficient processes – are definitely worth the effort.

Author profile:

Mark Warren is marketing manager, EMEA, with Perforce Software.