The Evolution of the Engineering Value Chain
The concept of a “supply chain” is common across many industries: a collaboration between an organization and its suppliers to deliver a product. Historically, supply chains focused on the production aspects and physical attributes of a product. They were simple and linear, with material requests cascading from the primary organization to its suppliers and to their sub suppliers, and contractual deliverables conveyed upward through the same chain. Partner relationships were often long standing with well-defined communication channels. Such partner relationships often included organizations within the same company operating as separate entities.
In recent years, market pressures have increased the need for collaborative partnerships. Technology continues to advance rapidly. Speed to market is critical. Software has emerged as a key differentiator in many products – from cars to washing machines to thermostats – with a growing internet of things connecting them. New entrants are disrupting traditional business models and ecosystems. To remain competitive, organizations must innovate constantly to create new and differentiating capabilities. To innovate constantly, organizations must collaborate with many non-traditional partners to create new and differentiating capabilities.
The supply chain is evolving
In response, the supply chain, has evolved into a complex network of distributed organizations, including traditional and non-traditional suppliers, and even competitors, participating in an “engineering value chain” to deliver innovation and business results. The automotive industry is a prime example of this ecosystem. The promise and complexity of adaptive technologies and autonomous vehicles are driving many new partnerships and joint initiatives on various components, features, and technologies.
The evolution of the engineering value chain is also driving a transformation in engineering and design processes. Traditionally, organizations have collaborated across boundaries imposed by their individual engineering environments, separated by a network or air gap. Most exchanged engineering data using manual and asynchronous methods, importing and exporting files or even sending hard copy documents. These mechanisms work, even across heterogeneous engineering tools. However, they tend to be slow and asynchronous, and often lose metadata and lifecycle traceability, affecting quality and agility. As organizations explore closer partnership collaborations and even co-development ventures, these traditional models fall short in terms of speed and effectiveness.
When collaboration is the answer, the problem becomes security
To address the challenges of these new business and partnership models, many organizations are considering working together in a single shared engineering environment on a common set of data. While this approach can foster more immediate and direct collaboration, as well as data integrity and traceability, it poses other challenges. Security is a major concern. How do you ensure collaborators access and modify only the data pertinent to them, and restrict visibility to internal and sensitive data? Reuse is another issue. Organizations often want to reuse content across other products or variants, or in context of other partnerships. Even with a shared engineering environment, organizations still need to define boundaries and develop strategies to exchange information across those boundaries
When determining how to collaborate with partners, three questions become important to consider:
- What kind of boundary can you draw? A boundary might be defined by the network connection, by the traceability of the information, through the READ and WRITE access control, or by tool domains within the engineering environment.
- Where do you draw the boundary? The lines depend partly on the type of boundary, and includes how we group artifacts or types of artifacts.
- How do you cross the boundary? There are multiple ways to cross the boundary or to exchange information across the boundaries, depending on factors like the tools used and the nature of the collaboration. An organization should choose an appropriate technique, or a combination of techniques based on the needs of each partnership and project.
This series of posts will further elaborate and explore the concepts of boundaries and how to cross them to enable more efficient and productive collaborations in an engineering value chain. Stay tuned! We will also be talking about this at the upcoming IoT Exchange in Orlando later this month, and you are welcome to come and join us in the discussion.
Join us at the Engineering Academy at the first-ever IoT Exchange in Orlando, 24-26 April
Discover how engineers can unlock the full value of your data with IoT and AI. Over 40 sessions plus demos, hands-on labs and on-site certifications.
See the full list of sessions here