Improve Product and Software Development by Integrating ALM and PLM (Part 1 of 4)

In today’s complex development environments, organizations find themselves facing an uphill battle trying to successfully orchestrate their disparate teams. The clear demarcation of the boundary between product development and software development is blurring fast as software increasingly becomes a major component of products. Should companies be integrating the management of their product and software development? Is there a business benefit in doing so? My answer is a resounding YES, for reasons I’ll discuss in this and following articles.

Is it an easy hill to climb? Definitely not! But I will try to give you a clear picture of why you need to start climbing if you haven’t already, and I’ll give you some concrete tips gleaned from actual experiences of our many Global 1000 customers who are already on the on their way to the top. At the end of the series, you’ll be able to get the full content as a handy, free eBook.

The Mountain Road and the Motivation

A mountain trek is a good analogy for ALM-PLM integration. At the summit you have your product and software development teams working hand-in-hand, innovating, communicating, all on the same wavelength, with goals and objectives clearly delineated and transparent to all involved. The view from the summit is clear: your company is delivering what your customers want with efficiency and quality levels that leave your competitors behind. But as with all mountains worth climbing, the road to the summit isn’t easy. Let’s take a look at the landscape you’ll likely have to contend with as you start for the top.

The current landscape is characterized by chasms

Almost everywhere today, the landscape is one of division. Product Development teams manage hardware requirements, design, testing and production using a Product Lifecycle Management (PLM) platform. Software Development teams manage software requirements, design, testing, building, and deployment using an Application Lifecycle Management (ALM) platform… if they’re lucky. Often as not, “ALM” is a cobbled-together amalgamation of office documents and point products that can’t manage and trace artifacts and information such as requirements and test cases across functional boundaries.

THE CHASM DIVIDING PLM AND ALM

Typically, Product Development (PD) hands Software Development (SD) some requirements as an office document (because SD doesn’t use the PD platform). At some point SD hands PD back a software component. This is fine as long as everything works, and nothing has since changed on the PD side. But in today’s complex development environments it’s no longer a safe way to travel. Making matters worse, as soon as there’s a failure (hopefully occurring during testing and not with customers), it’s extremely difficult to trace a failure caused by software back to, for example, a design requirement. When the environment is one in which functional safety and governmental regulation add to the complexity, as this kind of trace-back has to be documented, things get very complicated and difficult, very quickly.

The chasm dividing ALM and PLM is a recipe for delays to market, increased costs, and reduced competitiveness. It is also a main reason for mounting recall efforts across industries. I think it’s pretty clear already that there are real business benefits to integrating ALM and PLM. We’ll take a look at the main ones, along with some recommendations in Part 2 of this series.

---

You might also be interested in:

FREE WHITEPAPER:

Why ALM and PLM Need Each Other