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…
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.