Manuela Kohlhas is an experienced marketing expert with over a decade of experience, focusing on B2B technology companies. She has held senior positions in various organizations, where she has driven strategic marketing initiatives. She holds a degree in business administration and studied for a Master's in Innovation Management & Entrepreneurship at the Nuremberg Institute of Technology and Linköping University in Sweden.
Complex products demand coordination across mechanical, electrical, electronic, and software engineering. PTC Ignition helps teams establish a shared product architecture, connect functional intent to design decisions, manage critical interfaces, and carry architecture context into downstream engineering work.
Product complexity has changed. Has your architecture approach kept pace?
Ask an engineering leader where the definitive product architecture lives, and the answer is rarely simple. Part of it may exist in a document. Another part may be represented in a systems model, a CAD assembly, or a spreadsheet. Critical interface knowledge may be scattered across different systems, email threads, and the experience of individual engineers.
At the same time, products have become increasingly multidisciplinary. Mechanical, electrical/electronic, and software engineering teams must work together around a shared understanding of the product. A decision in one engineering domain can have consequences across several others, but those dependencies are not always visible to everyone involved.
This creates a fundamental challenge: How can organizations give more engineers a clear, shared understanding of the product architecture without requiring every engineer to become a modeling specialist?
Why current approaches break down
For many organizations, the problem is not a lack of systems engineering expertise. It is that architecture information is difficult to create, consume, and maintain across the broader engineering organization. The result is a recurring set of challenges:
- Product architecture is fragmented across multiple engineering tools, documents, and domain-specific views.
- Functional intent is disconnected from design decisions, making it difficult to show why a component exists or which requirement it supports.
- High-level architecture loses its connection to CAD, PLM, ECAD, requirements, and software as detailed design progresses.
- Interfaces, dependencies, and ownership are not explicit enough, allowing integration problems to surface late.
- Multidisciplinary teams struggle to understand what changed, what the change affects, and what work follows from the decision.
- Specialist modeling approaches can be difficult to scale to every engineer who needs to contribute to or consume architecture information.
PTC Ignition is designed to address these challenges by providing an accessible, governed foundation for product architecture that connects systems thinking with engineering execution.
Making systems engineering practices accessible to more engineers
Model-based systems engineering, or MBSE, provides powerful methods for managing product complexity. For organizations that need deep behavioral modeling, formal analysis, and simulation, SysML-based MBSE remains essential.
However, broader adoption can require specialized expertise, modeling languages, and dedicated tools. This can leave many engineers relying on documents, spreadsheets, presentations, or disconnected domain-specific systems to understand architecture decisions.
PTC Ignition offers a different starting point
PTC Ignition is a web-based systems engineering application that enables engineering teams to:
- Define what the product must do
- Build a multidisciplinary product architecture
- Allocate functions to the components that realize them
- Define and manage critical interfaces
- Connect architecture decisions with requirements, CAD, PLM, ECAD, software, and other engineering information across the digital thread
Rather than asking every engineer to learn a formal modeling language, PTC Ignition structures the experience around concepts engineers already recognize: functions, architecture, allocation, interfaces, and the work that follows.
Connect what the product must do with how it will be built
A product architecture should be more than a static representation. It should help teams understand decisions, dependencies, responsibilities, and potential impacts throughout development.
PTC Ignition connects functional and product architecture in one environment.
Teams can begin by defining product functions in solution-neutral terms. These functions describe the capabilities and behaviors the product must provide, before committing to a particular design. Functions can be structured into hierarchies, connected through dependencies, and linked back to requirements. This helps teams identify potential gaps, including requirements that are not supported by a function or functions that cannot be traced to a requirement.
For teams managing requirements in Codebeamer, PTC Ignition extends this context into the product architecture, connecting requirements to the functions they drive and the architecture elements that realize them. This helps maintain traceability from product intent into downstream engineering.
Teams can then describe the physical and logical solution across systems, subsystems, modules, and components. Mechanical, electrical, electronic, and software elements can be managed within a shared, multidisciplinary structure rather than understood only through separate domain views.
The connection between these two perspectives is established through allocation. By allocating functions to the components responsible for realizing them, teams make design decisions and technical ownership more explicit. They can also identify functions that have no assigned component, functions allocated across several areas, or components carrying more responsibility than expected.
Bring critical interfaces into view
Many product integration issues emerge at the boundaries between components and disciplines. Yet interface definitions are frequently distributed across different documents, tools, and teams.
PTC Ignition treats interfaces as managed elements of the product architecture. Teams can define different interface types, including data, signal, power, fluid, mechanical, and spatial interfaces, together with relevant engineering parameters such as timing, bandwidth, pressure, tolerance, or connector type.
Provider-consumer relationships help clarify how architecture elements interact. Interface specifications can make the relevant information available to stakeholders, while versioning and change control help teams evaluate the potential consequences of a proposed change.
This gives teams a more systematic way to understand dependencies before changes reach detailed design or integration.
Turn engineering targets into actionable insight
Product architecture becomes more valuable when it can reveal whether the product is moving toward or away from its engineering targets.
PTC Ignition properties can represent parameters such as mass, power, cost, latency, reliability, and criticality. These parameters can be carried from requirements into the product architecture, detailed design, and test information.
For example, a system-level mass target can be decomposed into subsystem allowances. Component estimates can then roll up through the architecture, helping teams identify a potential breach before detailed design is complete.
Instead of serving only as something engineers review, the architecture can provide meaningful information to support technical decisions.
Make the product architecture part of the development process
Defining an architecture is only useful if the organization can act on it.
Because PTC Ignition is built on Windchill PLM technology, teams can apply capabilities such as lifecycles, roles, baselines, design reviews, managed collections, subscriptions, configuration management, and change management to architecture information. This governance can also extend across suppliers and development partners.
Architecture elements can be connected to existing reusable designs or created as placeholders for planned work. This helps teams distinguish what can be reused, what must be modified, and what needs to be created. Ownership can be assigned across internal teams and development partners.
In this way, the architecture can become an active foundation for planning and execution:
- An unallocated function can reveal work that has not yet been assigned.
- A placeholder component can represent a future work package.
- A defined interface can clarify a technical dependency and its ownership.
Complementing established MBSE approaches
PTC Ignition is not intended to replace every existing MBSE environment.
Organizations that require deep behavioral modeling, formal analysis, and simulation can continue to use SysML-based MBSE tools such as PTC Modeler. PTC Ignition is designed to work alongside these environments through OSLC linking and synchronization, with data exchange based on a subset of SysML v2 and the Reusable Asset Specification.
This supports a practical enterprise approach: specialists can perform rigorous systems modeling where it is required, while a broader population of engineers gains a governed environment for working with functions, architecture, allocation, and interfaces.
Part of PTC's Integrated Product Engineering vision
PTC Ignition is part of PTC's Integrated Product Engineering approach for engineering complex, multidisciplinary products.
It provides a shared source of truth for product functions and architecture and is complemented by other PTC capabilities:
- Product Relationship Explorer provides a consolidated, explorable view of engineering product data and relationships across PTC and third-party products.
- Task and Change Collaboration coordinates, automates, and synchronizes change processes between PTC Ignition and Codebeamer.
- PTC Jetstream provides a cloud-native environment for secure and traceable collaboration on product data alongside formal product development processes.
Together, these capabilities help organizations connect product architecture with the broader digital thread and bring greater clarity to multidisciplinary engineering decisions.
A more accessible path to better product architecture
Systems engineering knowledge and good practices already exist across the industry. The challenge is making those practices accessible and actionable for the broader engineering organization.
PTC Ignition helps teams move beyond architecture information that is scattered, outdated, or understood by only a small group of specialists. It provides a governed environment in which more engineers can understand what the product must do, how functions are allocated, where critical interfaces and dependencies lie, what can be reused, and what a proposed change may affect. By maintaining connections into downstream engineering, teams can preserve architecture context as the product moves from intent into detailed design, change, and validation.
Learn more about how PTC Ignition can help your organization make product architecture a connected, actionable part of engineering.