Product Lifecycle Management (PLM)

In the Eye of the Storm (PLM Strategies Column)

29 Feb, 2008 By: Kenneth Wong

An IBM researcher anticipates business-oriented engineering.

Even though the blue October sky was perfectly clear when we spoke, Dr. Vijay Srinivasan insisted a storm was approaching — "a perfect storm," to use his exact words. As IBM's point man for research, standards, and academic programs for global product lifecycle management (PLM), Srinivasan was referring to a metaphorical climate change, a dramatic shift in the manufacturing universe, brought on by three coinciding developments:

  • 1. The maturity of product data and metadata standards
  • 2. The emergence of service-oriented architecture (SOA)
  • 3. The availability of robust middleware

So what will happen when the storm arrives? "We'll have an entirely different approach to PLM — as a combination of engineering processes and business processes," Srinivasan predicted.

In this article
In this article

If he's correct, the oncoming blast is a blessing. We can then expect the frosty relationship between engineering and enterprise systems to thaw. It sounds more like a bellwether than bad weather.

Data Matters

The importance of product data is a given. After all, it's the lifecycle of the product that is being managed. But Srinivasan reminds us that metadata is just as important, perhaps even more critical for those integrating engineering systems (CAD/CAM/CAE) and business systems (enterprise resource planning [ERP], accounting, inventory, customer-relationship management).

Whereas product data comprises geometric attributes (essentially the 2D/3D CAD files that define the shape of the product itself), metadata is made up of bills of materials (BOMs), part numbers, assembly configurations, sourcing information, approval records, and other facts and figures required to design, manufacture, market, and service a product.

Product data still resides primarily in the engineering domain, though it may occasionally wander outside. For example, while the engineers at Ford were designing the new Ford Edge, the same CATIA file might be forwarded to Ford's advertising agency so it can develop a photorealistic rendering of the new model destined to appear in an issue of Car and Driver magazine. Metadata, on the other hand, is not confined to engineering. It circulates widely throughout the entire enterprise, from purchasing and accounting to maintenance.

Writer–Reader Collaboration
Writer–Reader Collaboration

Srinivasan acknowledges that product data interoperability is still a headache for many discrete manufacturers dealing with files from different CAD systems, but he also points out that intermediary formats like STEP and IGES have emerged to facilitate geometry exchange. In the observation of Doug Cheney, a CAD interoperability consultant and a member of PDES, an industry/government consortium dedicated to the ISO 10303 standards, "STEP's international, collaborative development process ensures that it best covers the technical requirements of dissimilar software systems and data formats" ("Incompatible Software Makes Past Design and Manufacturing Data Unreadable," PDES, August 13, 2007).

In metadata standardization, Srinivasan points to the widespread adoption of XML and credits organizations like the Open Applications Group (OAGi) for doing much of the legwork.

Industry consensus to use STEP for product data and XML for metadata, Srinivasan reasoned, gave the engineering systems and business systems a common language to communicate with one another, so to speak. It may change how we view engineering processes. OAGi, in fact, views many of them as business processes, according to Srinivasan.

Service Matters

Their bitter rivalry notwithstanding, Oracle and SAP agree on the importance of SOA in business systems. Even their definitions are eerily similar. Oracle calls SOA a "truly flexible, adaptable IT infrastructure," whereas SAP defines it as a "blueprint for an adaptable, flexible, and open IT architecture." According to IBM, SOA is a "business-centric IT architectural approach that supports integrating your business as linked, repeatable business tasks or services."

Srinivasan has a more accessible definition: "SOA is how we maintain a complex network among the people with whom we must share information, whether it's related to finance, asset, or engineering." For more on SOA, see "PLM's Growing Pains," Cadalyst, January 2006, and "Open Up and Connect," Cadalyst, February 2006.

Two years ago, after attending SAP's SAPPHIRE user conference, IT expert and author Naeem Hashmi summed up his cautious attitude toward the SOA hype in the title of his article "Well on Our Way to SOA? Still Much to Do" (Intelligent Enterprise, July 2005). Apparently, IBM has done much of what's required in the past two years. According to Srinivasan, Big Blue is putting SOA into practice in some of its own facilities.

IBM's procurement and manufacturing centers, which are largely based in China, India, Taiwan, and other Asian outsourcing nirvanas, have been scooping up local talents straight out of colleges and universities. The user interface most familiar to these young IBM troopers "is Internet Explorer or Mozilla Firefox," observed Srinivasan.

So IBM decided to let them delve into the business systems through role-based portals. "If you're a procurement engineer, you access procurement information using Explorer through your portal, which looks like a regular Web page," Srinivasan explained. But what these users don't know (and probably don't care) is that, behind the scene, IBM has used SOA to combine three major systems: a PDM system (Dassault's ENOVIA), a part-selection system (i2's eXplore), and a technical database (housed in an IBM DB2 installation).

"We exposed all of the [software systems' functions and features] as services then made the relevant ones available to the people through the portals," Srinivasan said. That means the new hire in Mumbai or Beijing will never have to learn to use a PDM system. Nor does he or she need to know how to query a DB2 database.

For IBM, "85% of these users, we found out, are read-only users," Srinivasan remarked. "They're not editing the info." So why teach them to use a complex piece of software? This has enormous financial implications for a global enterprise like IBM. One of the line items it can dramatically reduce with this method is the training cost.

But SOA is still in its early stages of success. IBM is able to launch a pilot project because it's a hardware/IT giant with $24.1 billion in annual revenues (as reported for Q3 in 2007). The initial cost of developing the middleware necessary to implement SOA can be "literally billions — with a big B," admitted Srinivasan. That's why, he predicted, industries with much bigger coffers — for instance, finance, insurance, and healthcare — may take the lead. Because the middleware is not industry specific, the rest will benefit from their early investment.

The Middleman

Currently, IBM has partnership agreements with all three PLM titans: Dassault, PTC, and Siemens PLM Software (formerly UGS). Over the years I have tried, to the best of my ability, to sort through the artfully obscured marketing phraseology to understand where IBM's loyalty lies, but to no avail. I've come to the conclusion that, when it comes to lifecycle management, IBM prefers to be the proverbial middleman.

For the purpose of this column, middleware is, as the term suggests, the software that sits somewhere between the operating system and the purpose-built application. As one of the largest middleware merchants, neutrality benefits IBM the most.

"The big three, as you call them," Srinivasan said, "are in fact provid-ing CAD, CAM (computer-aided manufacturing), CAE (computer-aided engineering), and PDM (product data management) systems." The implication is, they're supplying a collection of solutions, not a single solution that covers the entire lifecycle.

"Most businesses I speak to have as big an investment in SAP or Oracle as they do in engineering systems," Srinivasan said. "So, if you are talking about the lifecycle, of course you need to include [enterprise systems such as Oracle and SAP] too."

Most PLM vendors disagree with the inclusion of enterprise/business systems into the category, but they won't dispute that the engineering applications must be able to communicate effectively with the rest so they can realize their ultimate PLM vision.

So what allows metadata to travel back and forth among CAD systems (CATIA, NX, Pro/ENGINEER), PDM systems (Dassault's ENOVIA, Siemens PLM's Teamcenter, SolidWorks' PDMWorks, PTC's Windchill), and ERP systems (Oracle, SAP)? Middleware implemented on SOA.

Teaching Business- Oriented Engineering

In addition to his role as a 25-year veteran researcher at IBM, Srinivasan also happens to be a professor at Columbia University. In line with his vision, he's proposing classes that teach engineering and business skills in parallel. It's an approach inspired by what he's seen at Stanford and MIT, he said.

The business education will cover "business strategy, the extent to which business strategy affects the product strategy; marketing, the use of sophisticated computer models and virtual products to study what products people prefer, what configurations they respond to, and so on; and finance, the study of sourcing, cost estimation, funding, and pricing," Srinivasan said.

Such a class may well be the birthplace for a new breed of engineers who are just as conscious of profit and loss as they are of XML.

About the Author: Kenneth Wong

More News and Resources from Cadalyst Partners

For Mold Designers! Cadalyst has an area of our site focused on technologies and resources specific to the mold design professional. Sponsored by Siemens NX.  Visit the Equipped Mold Designer here!

For Architects! Cadalyst has an area of our site focused on technologies and resources specific to the building design professional. Sponsored by HP.  Visit the Equipped Architect here!