Aras on Systems Thinking: Connecting the Red Dots Toward Continuous Transformation

In March 2021, Aras introduced its new systems architecture app, bringing together model-based systems engineering (MBSE) and systems thinking—connecting systems engineering to verification and validation, as well as closing the loop between requirements, engineering, configuration variants, simulation data, and so on. In this previous article, I elaborated on Aras’s new systems architecture app and suggested that it would be interesting to understand how it contributes to connect multiple methodologies and tools; hence, the following four questions:

1. How would these external methodologies and tools be embedded into the Aras platform?
2. What level of configuration and integration might be required to pull information from multiple sources under a single umbrella to manage traceability and feedback loops?
3. Is Aras referring to systems architecture in the wider sense, or in the context of a given dataset or application set?
4. Does this approach include external simulation engines and other data sources?

In this article, I discuss follow-up responses that Aras provided to the above questions, and I elaborate on systems thinking and continuous transformation following a recent discussion with Mark Reisig, vice president of Aras Product Marketing, and Pawel Chadzynski, senior director of Aras Product Marketing.

Aras Innovator combines a low-code modeling engine to build business logic across multiple apps and associated platform services. As Reisig put it, the platform is already strong with 1,000 bespoke apps across 400 customers—following the customize as you wish mantra. Contrary to other product lifecycle management (PLM) vendors advocating “out-of-the-box platform adoption” and “minimum customization,” Aras clearly promotes the need for customization to adapt and integrate the PLM platform within the wider enterprise digital landscape and operations.

What does systems thinking refer to? If 20 different people were asked this question, there would likely be 20 different responses. Note that we refer here to the broad term system and not simply an IT system.

Based on an exhaustive literature review, Amold and Wade (2015) summarized the systems thinking discipline as “the capacity of identifying and understanding systems, predicting their behaviors, and devising modifications to them in order to produce the desired effects.” In their article, Amold and Wade (2015) also highlight that “the use of systems thinking transcends many disciplines, supporting and connecting them in unintuitive but highly impactful ways.”

Building on the company’s red box concept, as presented several years ago by John Sperling, senior vice president of Product Management, the Aras product strategy is based on an overlay approach and containerization that supports data integration and effective management of object relationship visualization and management.

Putting the systems thinking in perspective by connecting data across teams, functions and interfaces with third-party tools, I discussed the following questions with Reisig and Chadzynski.

As Reisig and Chadzynski described it, systems thinking contributes to managing ever-increasing product complexity—a holistic, interactive and recursive view of products across their life cycle that focuses on how systems interact, rather than on how assemblies are structured.

Aras commented that the Aras “platform does not embed third-party tools, nor does it enforce any specific methodology. It provides a set of critical apps (e.g.: Requirements Engineering, Systems Architecture or Simulation Management and others) each with a dedicated data model and a pre-defined set of relationships between these various data models.”

Chadzynski illustrated the importance of enterprise architecture with the above figure, highlighting “the need to know the business”—and how it wants or needs to operate going forward. Furthermore, “transforming the business is not about making things digital, … not fighting change, but embracing it, starting with small steps” toward that direction and “create[ing] a momentum.”

The objective is for users to “adapt and extend the platform to meet their specific needs and methodologies,” with Aras Innovator as an overlay platform across other enterprise platforms and third-party authoring tools. This approach entails various opportunities for applicability and extendibility to many use cases based on an architecture tailored to a given industry and which can be tailored and augmented across functions, logical models, stakeholder views, data relationships and more.

Aras’s view is that the world of PLM is moving from a bill of materials (BOM)-centric view (management of design details) to a systems-centric perspective that is truly focused on the management of the design’s intent (aka the operating model of an organization).

Systems model captures the design intent first, before digital thread views are configured for a specific purpose. These views evolve as stakeholder requirements change or become augmented.

Building an effective and holistic digital thread is on every organization’s mandate these days when it comes to enterprise process and platform integration. This even extends to building a digital tapestry when combining multiple threads. Most PLM solutions offer levels of integration with other solutions, with custom connectors and APIs to connect the dots. As Reisig pointed out, however, it is common to find that “many threads are actually not connected.”

The idea of system thinking is to build and manage these interdependencies to bridge functional and data silos, which are located beneath the organization’s operating architecture. Furthermore, Chadzynski explained that there are indeed multiple threads, which need to be extended and customized to the required functions, capabilities and data requirements—navigating the V-model throughout the product development. Working across multiple business views.

To that extent, Aras data models can be “populated with data authored within Aras or with data authored in external tools,” and this typically allows teams to:

• Perform centralized data studies and what-if scenario analyses, pulling data from multiple sources of truth (from associated integrated the authoring tools)
• Drive data release processes with dedicated workflows and life cycle states (which must be managed by a PLM platform across all engineering domains and teams)
• Visualize data relations and maintain traceability between the PLM platform and the data in the external tools, enabling cross-domain versioning and configuration management across a given thread

Chadzynski explained that the “Systems Architecture app data structures are always in the context of a specific system under design, and this may or may not have additional datasets or application sets.” Organizations can select the relevant anchor items based on the needed level of granularity according to:

• The level of organizational maturity: requirements will differ between a start-up vs an established business.
• The current strategy and business imperative: requirements to mature or integrate a new capability or business.
• The PLM scope managed within Aras vs other PDM/PLM solutions or native authoring toolsets: requirements of a lean yet personalized integration landscape.

This seems to be a powerful approach based on master data strategies and the required level of integration: only integrating the minimum viable product through the red dots—making the PLM platform effective while keeping it lean. This approach clearly aligns with the scalability of the software as a service (SaaS) model, as organizations are likely to better manage iterative changes once they adopt agile deployment iterations that contribute to helping them optimize their operating model.

According to Aras, “the system architecture data in Aras is by no means limited to representing MBSE structures such as SysML-based MagicDraw models. It is generic enough to represent architectures (the FL of RFLP) from any source that defines functional/architectural breakdown such as CAD hierarchies, system architecture of electronics schematics, software architecture, etc.”

Aras presents its PLM platform as “authoring tool agnostic.” To that extent, it does not embed detailed authoring tools for engineering domains, such as MCAD, ECAD or other simulation engines. Nevertheless, Aras allows these tools to be connected with its managed data structures that are derived from, or synchronized with, these external tools via connectors. Chadzynski elaborated that these capabilities are managed at the “business model” level, above the “data model” layer. Also, this means that “services can be created independently of the data construct, focusing on data behaviours and functional breakdown.” This approach contributes to facilitating future upgrades, as underlying changes or enhancements can be introduced with little to no impact on overlayed configurations and customizations.

Finally, Aras explained that “Ansys, the market leader in simulation, presently focuses on the simulation wand and could plug into Aras’s overall implementation of a Digital Thread. Simulation data therefore is no longer in its own silo—the rest of the Digital Thread provides full context for the simulations and traceability across the lifecycle.”

What are your thoughts?

• Reisig, M., and Chadzynski, P. (2021). Aras: Systems Thinking.
• Keer, P. (2021). ACE2021: Systems Thinking and Design of Complex Products (registration required).
• Grealou, L. (2021). Systems Architecture App from Aras: Bringing Together MBSE and Systems Thinking, engineering.com
• Grealou, L. (2021). Beyond the Digital Thread: from the Digital Tapestry to the Digiverse (ref. Lockheed Martin), virtual+digital.
• Grealou, L. (2021). Aras Continues to Extend Its Low-Code Platform Capabilities to Build Intelligent Automation, engineering.com.
• Amold, R., and Wade, J. (2015). A Definition of Systems Thinking: A Systems Approach, Conference on Systems Engineering Research.