Augmenting System Change

Design experts from many domains have a new way to collaborate change that doesn’t affect their tool flow or development process.

By John Blyler, Founding Advisor And Affiliate Professor, Systems Engineering Department, Portland State University

The one constant in the design of complex systems has been the necessity to communicate and manage change. Since the earliest days of modern systems design, change has been an issue. Fredrick Book’s in his Mythical Man-Month lamented that project groups of the 1970’s would often change their design requirements and assumptions without informing other team members. His solution was to have all members remain in constant contact with each other in as many ways as possible such as emails, phone calls, meetings and memos.

Thankfully, technology and tools have evolved significantly in the last several decades. Today, we have enterprise grade Product Lifecycle management (PLM) and enterprise resource planning (ERP) tool suites to coordinate the design and manufacturing of major development efforts. Internet-based HTTP collaboration technologies now enable a global level of connectivity. Yet the typical engineer still works primarily within their domain-specific tools and communicates via the old ways of email, phone calls, meetings and memos.

This paper explores an efficient and non-intrusive way for the global, multi-discipline system design community to share critical change information without altering their design process or domain-specific tools. First, we’ll establish the context for change in today’s middle-out engineering process. Next, a case will be made for augmented tools to enable change management. Information links to handle different rate of changes will finally lead to the introduction of Open Services for Lifecycle Collaboration (OSLC) as a mechanism to enable the productive and efficient management of change.

Middle-Out

Complex designs within a global supply chain require close collaboration among multi-discipline technical and business professionals. Such collaboration must occur throughout the product lifecycle and at all stages of system decomposition and integration.

From the higher architectural levels, one would hope that the overall product configuration would be carried through the various lower level, domain specific modeling tools. “Otherwise, you are encouraging silo thinking and disconnected modeling problems,” cautions Mark Sampson, Product Manager and Evangelist at Siemens.

But the rate of change in the design is often far greater within the lower level domain environments than at the higher level PLM space. An increase in the rate of change requires a corresponding increase in the rate of collaboration. Changes that are not communicated with other team members in a timely manner (such as minutes or hours) will adversely affect productivity and efficiency.

Change flows from the top-down at the higher levels and from the bottom-up at the lower levels of the product development hierarchy. Both top-down and bottom-up changes intersect at the middle, which is exactly where most product designs occur.

Very few real-world projects start with a blank sheet of paper. Instead, most projects take place within the context of legacy systems and require a middle-out design approach, which is a concurrent combination of top-down and bottom-up activities. The benefit of a middle-out approach is that it preserves the top-level requirements and functional allocations while incorporating the known, detailed requirements and functions from bottom-level system elements.

It should be noted that the terms “top-down” and “bottom-up” are not meant to convey levels of importance but rather levels of abstraction. The higher-levels refers to the abstract design space where requirements are still vague objectives and architectures are often little more than functional block diagrams. In contrast, the lower-levels represented the detail-rich implementation space where the high-level vagaries have been decomposed to a sufficient detail that various engineering disciplines can begin to create subsystem and component solutions.

The key element to the success or failure of the middle-out approach is the effective communication of change. How will this change impact the on-going design within the team and beyond? Both top-down and bottom-up product design professionals must constantly communicate to ensure that the right product is made in the right way.

Technology has improved the ways in which design teams can communicate quickly and efficiently with one another. Social media mechanisms are a key example. But product designers and their managers are reluctant to utilize such mechanisms, even behind the safety of the corporate firewall. It’s understandable. Engineers have spent long years in study and work experience to become experts in their domain areas. They have neither time nor inclination to learn a lot of new tools just to ensure that everyone else –even their own team members – knows about daily change activities that result from constantly shifting design requirements and constraints.

Augmenting Flows

Traditionally, PLM tool suites have been used to gather all the design information into a single (usually proprietary) database. In the technical space, PLM tools tend to focus on system requirements management and design version control. By their very nature, such highly structured tool suites require that designers leave their domain tool environment to report design changes within a PLM specific application.

Today, there is an emerging trend to augment existing domain tools to enable and manage the necessary communication of change all within the designer’s work environment. Additionally, such tools track the dependencies of such change and assess the impact of the changes – among other things.

Nowhere is change more prevalent that in the semiconductor and electronics industries. For one thing, the last few decades have been witness to a significant increase in mergers and acquisitions (M&A), resulting in both companies and technical domains being thrown together in often unprepared ways.

Even without the added complication of a company merger, collaboration of design information between different engineering groups is difficult. Digital-analog, hardware-software, design-manufacturing often use different approaches and tools to deliver their design implementations.

“I think that traditional PLM tools have been good at documenting the results of collaboration,” notes Kurt Bittner Principal Analyst of Application Development & Delivery at Forrester Research. “But organizations found that they also needed tools to actually facilitate the collaboration that produces some conclusion.” In other words, traditional PLM tools communicate specifications but miss a lot of discussions that occur in which alternatives are examined and accepted or rejected. Those discussions can be very free-format and unstructured, which makes them difficult for the structure of PLM tools to capture.

A variety of different tools are useful for that unstructured work, depending on the problem being solved – prototyping (digital or physical), modeling (conceptual or mathematical), as well as tools that facilitate conversations and discussions, that is, chat-specific tools like Slack to virtual workspace and collaboration tools like Sococo, explains Forrester.

Let’s consider a practical example. A requirements engineer is working with a major requirements management tool like IBM’s Rationale DOORS. They must communicate with a system architect, who is putting together the functional breakdown of the target design. How is a change in requirements communicated? Often that communication talks place in an email or at the weekly staff meeting. The email is one of hundreds that most of us receive on a daily basis and can be overlooked. The staff meeting is held only once a week.

Neither approach is very efficient. Further, both require the initiator of the change to take personal steps to communication the change and decide who best to receive information. The former is time consuming and the latter is prone to human error as to whom should receive the information.

But the domain-specific people who are doing the work are using very specific tools. “Let’s utilize the fact that they are working in those technical tools to capture the fact that a change has occurred,” explains Bill Chown, Product Marketing Director, System Level Engineering Division at Mentor Graphics. “Fortunately, a new technology has emerged over the past few years that does this just. It’s called the Open Services for Lifecycle Collaboration (OSLC).” The value and implementation of OSLC will be covered in more detail later in this paper.

Context is Key

The one constant of design is that change is inevitable. That’s why change management is necessary. In the past, change management has meant extra work for the engineers already deeply involved in the actual design of the product or system.

It’s true that many tools provide some type of collaboration capabilities. Top-down, PLM software can connect directly within their own set of tools, e.g., requirements management to architectural functional design. Even bottom-up, engineering domain specific tools are expanding ‘upward’ to include PLM-type features (change, workflow, variation, etc.), notes Mark Sampson. The collaboration challenges occur as the linkage between different tools grow from a couple to many links.

But linking together every tool in the design and PLM chain leads to an N² complexity problem. It’s better to collect changes in one place, analyze them and then alert those who need to know. The last point is important. Everybody in the project seldom needs to know about every change that occurs. The impact of each change must be assessed and conveyed to the appropriate group and not spammed to everyone else.

Further, the frequency of design change notifications varies with the discipline. For example, the rate of change in design tends to be higher for software than mechanical engineers. Programmers are constantly changing and updating code, while mechanical engineers tend to make far less incremental tweaks in the design. These different rates of change require different approaches to handle the work in progress (WIP). The structured nature of a PLM system can be at odds with the rate of change that is more easily handled within domain-specific tools, for example, a software integrated development environment (IDE).

Links are needed to the domain specific tools in which the actual design work is taking place and where the immediate design information is located. Any change management system should start there, where the change is actually occurring and where the dependencies are known. The challenge is to create these links in a non-intrusive way, without requiring special APIs, proprietary communication protocols or the downloading of massive amounts of design data among the various tools.

The Missing Link

One of the biggest barriers to adoption of any technology is inertia. Designers are comfortable using the tools they’ve learned to do their jobs, both domain-specific tools and information manipulation and sharing applications like Excel. But the collaborative nature of Internet technology provides a simple way to link all kinds of tools and share information that doesn’t alter the existing tool chains in any way.

A new technology – based on Internet protocols – has emerged over the last few years that is called Open Services for Lifecycle Collaboration (OSLC) (see Figure 1). OSLC is built upon the same technology as HTTP, which enables a remote view of information. It operates in the same way as a Google search query in that Google doesn’t copy all queried information back to the user but only a view (a link to) the results. Using this same process, domain-specific engineering tools can be linked together.

In this process, individual design tools don’t need to link to a design data repository directly (as in a PLM suite) because the design tools know all about the relevant data. Instead, the OSLC enabled tools share information by discretely providing a web-based list. The list allows the user to decide what level of detail about the change is needed. In some cases, it even allows changes to be made across tools. In this way, all the tools become participants in the design, augmenting the product development life cycle.

“With web technologies such as RESTful services and standards such as OSLC, it is now possible to have light process integration that allows each team to continue with their methods but also achieve the end goal of having better collaboration at the integration level,” notes Martin Hall, High-Tech Industry Solutions at Dassault Systemes.

OSLC-based tools typically link to a central concentrator-server that collects all changes, tracking where they occurred and noting the associated dependencies throughout the development process. In this way the entire change process is recorded to be used for process verification and compliance with process standards.

Linked data enables cross-discipline tracking and handling of changes without a central data repository. Removing the traditional repository can also reduce associated assess restrictions and save costs.

Further, OSLC and supporting tools enable similar functionality across multiple domains. Relevant information is shared so each domain can operate in an optimal fashion while collaborating where required in order to deliver a final correct configuration or any incremental deliverable.

While this approach seems intuitive, the implementation can be challenging. But it can be achieved with coordinated focal points that are linked with well-managed tools and local data sets. It is a potentially new world, one which the even the PLM world seems to reluctantly acknowledge based upon their support of open source tools.

PLM vs PDM

PLM tools do provide a top-level environment for all cross domain and life cycle phase specific tools. As Sampson notes, the problem is that domain specific tools (SW or EE for example) still see the world through narrow eyes and ignore the cross-domain impacts of change in one domain on the others.  It’s at these boundaries where most of the problems turn up (i.e. a change in one domain not be communicated to others). That’s why a cross-domain environment is needed, to mitigate highly optimized but un-manufacturable designs.

One must be careful to note the distinction between the MBSE and the lifecycle capabilities that product lifecycle management (PLM) vendors are increasingly offering and the (managed) product data management (PDM) role that is the predominant use case of the PLM products.

PLMs and PDMs are commonly treated as the same thing. But whereas PLMs are cross-organizational and discipline tools for collection and control of product configurations, PDM combine with CAE/CAD software to form a specialized design environment. That is why PLM objects are typically represented in a database while the main artifact of a PDM is a CAD file.

There are many capable solutions at the front end of design providing requirements management, architecture modeling and hierarchical partitioning, which do not necessarily come from nor directly have to be PLM or PDM exclusive solutions.

Still, the collaboration challenges between top-down PLM and bottom-up domain- tools mirrors the same challenges that occur between technical professionals on both levels, namely, sharing information about inevitable changes. Today, thanks to Internet technology, there is a way to link domain-specific tools that doesn’t require transferring or manipulating data within the highly structured PLM tool suites. The Open Services for Lifecycle Collaboration (OSLC) standard allows engineering experts to remain within their tool environment while sharing changes and other information amongst themselves and other domains.

Better yet, this approach doesn’t change the existing work flow. Further, no data has to be moved nor do the design tools have to change. Instead, this approach merely adds capabilities to the set of tools that designers use every day. This approach even augments the less efficient traditional collaboration methods of email, phone calls, meetings and memos. In so doing, it improves upon a change management issue that has challenged project teams for decades.

Originally published by Mentor Graphics