Today’s embedded software development processes are complex, involving multiple teams of chip designers, engineers, developers and testers each working at different rates and using a wide variety of design and development tools. Version management – often referred to as software configuration management (SCM) – systems have become an integral part of this critical process. They are comprehensive and flexible tools that help keep vast amounts of information, projects – and not to mention costs – on track, enabling better coordination and collaboration of teams even when they are dispersed across different locations and time zones. Put simply, version control can provide businesses with a competitive advantage, enabling frequent releases and faster product time to market.

However, some organisations may question if their systems are up to the job. For those that have not reviewed their version control requirements in several years, or as a result of mergers and acquisitions with multiple legacy systems, it is definitely worth taking a look at recent developments in the market.

1. Determine why you want new version control

This may sound like an obvious question, but there will be differing objectives between a “first time” user of version control (increasingly rare) and, for instance, a company that has inherited multiple versioning tools and now wants to standardise on a single system to reduce complexity and costs. Another driver might be a desire to collaborate on the same versioning platform as partners or customers. Other issues include global expansion (where the need to have systems that support cross-border collaboration becomes more pressing), or the desire to have version control systems that support development trends such as continuous delivery and Agile.

2. Define what you need from version control

From the outset, it’s important to specify requirements for the embedded industry. Taking a top-level view, embedded designers typically require version control systems that support rapid time to market, but, at a more “grassroots” level, other needs include integration with tools such as IDEs, defect-tracking and continuous integration, rapid prototyping and components-based design. The ability to include electronics diagrams, chipset designs and associated documentation within the versioning system is likely to be important too.

Also consider whether collaboration with third parties is required (for instance, if working in an OEM or subcontractor environment) and what platforms and operating systems need to be considered (is support for open-source software, such as Git, necessary?).

3. Define your users

The range of people using version control systems is now much broader than ever. Traditionally, it was the sole province of software engineers, but these days, versioning has pervaded just about every part of the organisation. While specific job roles of those needing to use version control will vary considerably according to the organisation, in the embedded design market, typical users range from technical staff, to marketing and product management staff (who are responsible for getting the product out into the marketplace) and external third parties (for instance, independent testing organisations).

Here is a quick user checklist to consider:

• Software developers, software architects, system administrators and other IT staff
• QA teams
• Operations and production teams
• Non-technical content producers (such as designers and marketing teams)
• Non-technical support and administration staff
• Management
• Outside contributors (such as freelancers and subcontractors)
• Partners and customers

Each of these roles will 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. Each role may also require different levels of training and support. Interview a diverse cross-section of staff to find out their challenges and where in the product lifecycle they interact with version control. Alternatively, consider inviting representatives from different job functions to form a “version control tool selection team.”

4. The evaluation process

Best practice dictates choosing three to five vendors to evaluate. More than that can become overwhelming, fewer can be problematic too, because it may raise questions down the line about how the decision was made. Three forces the selection process to be narrowed down to “good, better, best.” (Arguably, in organisations where politics rule, there is a case for putting your true choice as the middle option, if there is a tendency towards moderation.)

Next, we move on to scheduled demos, but make sure requirements and processes are provided in advance so that the demo is truly tailored to your organisation’s needs. Of course, skipping this step and going straight to free trials is an option, but, importantly, demos have the advantage of putting faces to the software and providing a sense of what it is like interacting with the vendor (useful for future support calls).

Having made the likely selection, ask for a free trial and at this point it is often wise to keep this to a pilot team, or to ask different stakeholders to evaluate different tools and report back.

5. Calculate real costs

Calculating ROI can be complex, as there are a lot of factors to consider. The vendor should be able to help with this, but make sure everything is covered, including administration, hardware, project hosting, training, consulting and support costs. Also, be aware that while open source software may be “free,” it is certainly not immune to those associated costs (plus does it provide the required performance, reliability and scalability?).

Make sure all logistical queries are covered off. Find out how often new software features and updates are provided and whether the latter are included in the price. Get clarification on hardware and network requirements, plus be certain that security and intellectual property protection needs will be met. Ask for clear explanations of the licencing, flat fee, subscription or other payment model. How much will support cost? Are charges predictable as usage expands? 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 vendor need to support 5, 50, 500, or 5,000 users?

If migrating from more than one existing system, then it may be wise to invest in consultancy services, whether from the vendor or one of its preferred partners. For instance, organisations can have half a dozen legacy versioning systems, often as a result of mergers and acquisitions and bringing all of that legacy data into a single new version control environment is certainly not impossible, but it can be challenging.

6. Support and community

Given that versioning is usually at the heart of the product development process, support needs to be top-notch, so ask around and find out what other users think of the support offered by the vendor in question. Ask if the vendor also provides community, training, best practice resources, consulting, and user events. Check the vitality of the “ecosystem” around the tool in terms of third party integrations, consultancies, customer-built mods, and forums.

7. Will it make a real difference?

Last, but definitely not least, this final check-point is important because version management systems can provide a competitive edge, enabling users to bring products to market more quickly. Versioning vendors should be viewed as strategic partners, because after all, they are entrusted with their customer’s valuable IP. It can be tempting to choose a version control tool just because it is well established, or because it was what was used in a previous job or by the main competition.

Ask for customer examples in the embedded design market. Does the vendor really know your market space? Attending user events and conferences is a great way to check out references informally. Seek out analyst reports to gauge the strength, credibility, and longevity of the contenders. How often is the product portfolio refreshed and does the vendor have a forward-looking product roadmap?

In summary, changing version management systems can seem daunting and complicated, but by following some simple “best practice” steps, it means embedded computing designers can reap the considerable commercial and operational benefits that modern versioning systems have on offer – right across their business functions.

Mark Warren is Marketing Director, Europe, for Perforce Software.