Before I jump into the exciting world of ALM/PLM, I thought that you may enjoy a small view into what is happening inside the walls of Aras.
I would love to tell you about the highly guarded, moated and secure facility that is Aras - with an entrance like this. But alas, we are located in a fairly typical office building north of Boston. (Can you name the location in the above picture?) At Aras, the Product Management team sits together - we even have a windows! Our team is made up of 5 Product Managers, an intern, our Chief Architect and our VP of Product Mgt. Our individual backgrounds bring in experience from many different parts of the PLM space. When not heads down, we have "fireside chats" to work out ideas, indulge in chocolates and have some laughs. Discussions are often punctuated with flying mints or Jolly Ranchers - we have a magical endless supply. Our proximity leads to plenty of shared ideas and assistance designing our products. Of late, our team has had many conversations on the connections between Configuration Management, MBSE, and ALM/PLM.
I spent some time with Pawel Chadzynski discussing the latest progress on our PLM/ALM journey. Pawel is our Product Manager leading the ALM efforts in conjunction with IBM and Airbus. Getting into all the nitty gritty of our conversation would make for a very long post. To keep this post to a readable length I will paraphrase and condense a bit.
One of the things Pawel is most happy with is the fact that the PLM/ALM linkage is a "data connection with process around it." The culture clash between the AML and PLM crowds is often palpable. Some of this is due to prior PLM implementations trying to take over ALM. Pawel has been keen to ensure that will not happen in our efforts. We can all get along!
Pawel's perspective is that "Process is what PLM does very well. With our ALM integration we are leveraging OSLC to add the capability to create external changes. These changes are controlled by relevant Domain Specific Processes." That sounds good - but let us dissect a bit. We will start with a look at Pawel's whiteboard:
We have successfully taken this whiteboard concept and proven is the ability to connect from Aras PLM to IBM ALM using OSLC. We create links from the source environment to the related environment(s) - but the source always retains control! One example Pawel walked me through is creating linked requirements in Aras from the IBM Doors module. Even more exciting are the features in the Aras change processes that create "child changes" on the IBM side and triggering equivalent actions in their workflows. These connections and parent/child links are built in the Requirements, Change and Part/Software domains - giving us full coverage of a product design.
It is worth noting that in the change domain the connection from Aras to IBM allows us to have a thorough Impact Analysis. We have exposed the ability to study the impact of a product change across parts, software and requirements. This is a critical capability of the Aerospace Use Case we will be demonstrating at the ProSTEP iViP implementer forum. This capability will give our users the ability to use domain specific tools and processes for parts, BOMs, source code and builds AND have an integrated process to capturing configuration and change. All while PLM manages the overall configuration of the product. The best of both worlds!
One concept Pawel picked up in his travels is, "When you get impact analysis answer (for a product change), how do you know what the question was? You don’t unless you have the physical configuration context from PLM – and that is the context that PLM ECR gives you. In this case, the impact analysis included the external ALM environment - giving us a complete picture."
Thanks for reading!
-Dave