How Different is Aras Requirements Engineering?

How Different is Aras Requirements Engineering?

Many years ago, I’ve heard a very serious marketing joke. How to create enterprise software? It is easy – just take one of the words from the lexicon of manufacturing company and add the word “management”. I hope you’ve got my point – Product Data Management, Material Management, Supply Chain Management, Manufacturing Planning Management, CAD data management, BOM management… I can continue the list.

The requirement is one of these words. As products are getting more complex, requirements traceability becomes a big deal. How to coordinate customer and system requirements with tons of features and product capabilities.

The requirements is a core element of system engineering workflow in so-called RFLP approach (Requirements, Functional, Logical, Physical). RFLP approach is used by many companies as a framework and it is also referred by PLM vendors as part of MBSE (model-based system engineering).

My attention was caught by Aras press release – Requirements Engineering is Now Available on Aras Platform.

The rising complexity of products and systems across the industrial landscape and the ever-expanding regulatory environment is driving the need for transformational technologies to manage requirements in the context of total product configuration at every step of the lifecycle. Many organizations struggle with digital transformation because they rely on a combination of standalone requirements management tools and monolithic documents. These organizations need an aligned technology that will accelerate their time to market by establishing traceability between different requirements types and related design artifacts and manage the related configurations on a single platform.

However, the following passage is the most interesting:

“Siloed management of requirements in monolithic documents prevents organizations from transforming to a truly traceable and collaborative process required for design of today’s complex products and systems,” said Pawel Chadzynski, Senior Director, Product Management, at Aras. “The Aras Requirements Engineering application, together with the Aras Innovator Platform, eliminates this obstacle.”

I think a single version of the truth is still the most effective sales paradigm for PLM systems. It sounded like Aras is planning to eliminate Requirements silo by bringing requirements under Aras PLM umbrella. Also, the notion of “engineering” connected to requirements was sound unusual.

Pawel Chdzynski was generous to offer me a web meeting to discuss Aras Requirements Engineering. So, here are a few things I learned from him earlier today.

1- Aras PLM platform is used to create a model of requirements including structured content, ontology, relationships, traceability and many other aspects of the requirement management process. The data can be stored in Aras PLM platform and linked to Requirement management authoring tools.

2- Existing tools will be linked to Aras platform using API and integration services. The later will require a special discussion and I plan to talk about it separately. Although, it is obvious to me that data is extracted from existing tools and moved to Aras.

3- Aras Requirements Engineering is not planning to replace existing Requirements management tools (eg. Doors), but will be open to provide such option to customers.

4- Aras API provides access to all other tools that will need to consume requirements for decision making, traceability, and other needs.

Here is a slide Pawel shared with me to describe Aras Requirements Engineering.

Aras is replacing requirements management with requirements engineering? What does it mean? For users, it means migrating from one application to another (Aras will provide a migration path). However, a more interesting question is how different is Aras Requirements Engineering from other tools?

The core differentiation is Aras modeling engine used to create a data model of the requirement management process. While I believe every single requirement management tool will have such or similar model implemented, to have it done as part of Aras PLM will provide a big advantage of vertical integration with other domains of product development and manufacturing.

On the other side, integration with existing tools can be difficult. Aras open API and partnership model provides all ways to create integration. But the real question is who will be motivated to create and maintain such complex integrations with requirement management systems like Doors, Jama and many others.

Another aspect is the connection to system engineering. Will Aras Requirements Engineering become a part of the overall model-based system engineering approach? Will Aras plan to implement and support an entire RFLP process? These are questions I still have open (heads up – I do plan to have a meeting and discuss the latest Aras Modelon partnership and hope to get some of these questions answered. Stay tuned).

What is my conclusion? Aras is using their flexible modeling engine to capture requirements and turn it into structured information. It is definitely important. That’s probably a meaning behind “engineering” term Aras is using to rename Requirements Management into Requirements Engineering. Besides this important differentiation, everything else seems to be a typical enterprise software model with rich metadata sets, formulas and rich visualization mechanism. By introducing these features, Aras is making a step towards acquiring more information about the product. More data means more value and data is a new oil in a new digital world. Just my thoughts…

Best, Oleg

Disclaimer: I’m co-founder and CEO of OpenBOM developing cloud-based bill of materials and inventory management tool for manufacturing companies, hardware startups, and supply chain. My opinion can be unintentionally biased.

Share

Share This Post

  • Pingback: GHZ Partners | IT Services, Software()

  • Interesting article, I enjoyed it a lot, as it addresses a number of interesting questions, far beyond Aras. A few thoughts:

    Although, it is obvious to me that data is extracted from existing tools and moved to Aras.

    I am sceptical: I am still waiting to see a tool vendor offering a solution that gets EVERYTHING right. requirements will be moved only if Aras requirements is as good or better than, say, Jama. I have not seen it (looked for videos).

    Besides, there are alternatives:

    who will be motivated to create and maintain such complex integrations

    There is a market for such integration hubs, like Tasktop and Opshub. They do a fine job on integrating best-of-class tools. And more importantly…

    a single version of the truth is still the most effective sales paradigm for PLM systems

    A single version of truth does not require all information to reside in one place. You can still have one tool for requirements, another one for modeling and yet another one for PLM. As long as you know where the “truth” resides for each item, you’re good (of course, you need a seamless integration and cross-tool traceability).

    I am not saying that this is always doable or the best approach. I am just saying that a single data repository is not a prerequisite for “single source of truth”.

    Will Aras Requirements Engineering become a part of the overall model-based system engineering approach?

    Not sure about Aras – but I’d say that there has been agreement for a while that RE is part of MBSE. After all, this was one of the drivers of creating a requirement type in SysML, back in 2003.

    I’d quite enjoy a post on your thoughts on model integration and tool ecosystems in general, not just in the context of a specific tool.

  • beyondplm

    Hi Michael, Thanks for your comments and insight!

    Few comments about integrations and single version of truth.

    1- The idea of seamless integration / federation / data placed in the right places is still the one that used by all vendors in public. Unfortunately ,there is no PLM company yet that created a business model that will not use “data locking”. Eventually every PLM vendor today wants the data to be hosted in the tool/platform and then up-sell components, applications, packages to use this data.

    2- A market for tools integrating data indeed exists and it is mostly because of the problem I stated above in #1 – business model. If each product holds the data making integration complex, integration business will profit and actually will not encourage PLM vendors owning the data to change the status quo.

    3- Yes, a single version version of truth doesn’t require data to be in a single platform. But, based on what I’ve seen in the last 15-20 years, “distributed truth” is much harder to sell.

    I look forward to you comments!

    Best, Oleg

  • Hi Oleg – by background is not really, PLM, I am primarily active in requirements engineering (RE) and systems engineering. My comment reflects what I’ve seen there. The underlying issues (data federation, single source of truth, etc.) are similar, but the history is different.

    Specifically, requirements must allow collaboration, and the tool vendors were trying hard to lock in their users. They pushed back in the 2000s, by creating an open exchange format (ReqIF), and an architecture for integrating the various tools for product lifecycle management (OSLC).

    I see two dynamics at play here: Small tool vendors open their platforms, as they only cover a fraction of product development activities. This allows customers to integrate them in their ecosystem. Customers welcome this, as it gives them independence from big vendors, and allows them to integrate best-of-class solutions.

    It can be sensible to get a turn-key solution from a big vendor with a product that covers all required PLM functions. The downside is that this is rarely a best-of-class solution, and the customer risks vendor lock-in.

    Both approaches have their place, but it’s important to be aware that both approaches exist. And customers should know this and demand choices. 🙂

  • beyondplm

    Hi Michael, I can see your point. Indeed vendors in connected to PLM spaces are making their tools more open. At the same time big PLM platforms providers are attempting to expand via development or M&A. The demand for choice exists, but in practice, it is more a balancing act for customers between multiple providers. Aras is playing “land and expand” strategy trying to push large PLM vendors out of their comfort zone.