“MBSE modeling solution supports standard system modeling languages–creating an integrated product architecture solution.”

You are looking at a picture of one of the most famous landmarks in the world–the leaning tower of Pisa. If our Italian friends will forgive me, I don’t know if this tower is the greatest one ever made–but it is the most famous.What makes it special of course is its obvious flaw, which causes people from around the world to come and see it and get their pictures taken trying to straighten it up–as my friend here is doing…

From what we know about the history of the bell tower, we don’t know who the original architect was, it took over 200 years to build, and apparently it began tilting during construction (we know that because the builders apparently tried to straighten the tower using longer pillars on the lee side—giving it a banana type shape). In more recent years, the tower has begun to tilt more and lots of money has been spent studying and applying ways to shore up the ground underneath it to keep it from falling over (www.towerofpisa.org and https://en.wikipedia.org/wiki/Leaning_Tower_of_Pisa)

I use it here today as an example of what happens to a product when the architecture of product is not correct…it stretches the build time (although maybe not 200 years), when things go wrong (as they inevitably will) short term bandage solutions are used rather than root cause fixes, and it sets up an organization to spend 10x the cost of original development on correcting the problems, and lastly, these types of failures usually get lots of people’s attention and you end up with a reputation you don’t want (which is probably why we don’t know who the architect of the tower is).

The value of product architecture…  

This is the same for product architecture…In prior blog posts we discussed the value of product architecture, how it establishes the blue prints for the downstream development disciplines to build an integrated solution we envisioned, but also creating the “digital thread” that we will need when it comes time to understand the impacts of change to the product.Just as we keep blue prints on hand to understand how a building fits together, we need to keep the product blue prints around to understand how the product fits together. This product architecture is a critical part of defining and managing the product lifecycle, so it should be inside/part of PLM.If it’s kept somewhere else (like disconnected diagramming tools), it’s disconnected from the lifecycle and becomes stale and untrustworthy; eroding its value since we can’t trust that the architecture documentation matches the current product configuration. 

…integrated with the product lifecycle

Teamcenter, the keeper of product truth, is already the keeper of the product models used to create the product, it also needs to be the keeper of the product architecture (with configurations, variants, change, et al) so you have a configurable digital thread of sufficient altitude to maintain/see the big-picture and enable cross-discipline optimized decisions.

Today, when a change comes along, first we need to find the blue prints/architecture diagrams (sometimes kept in people’s heads), then gather the related experts, and discuss where things go, starting a process that could take days, weeks, months or longer to understand the implications of a change. Of course, things are moving on with or without us, so when we finally come up with an action plan everyone has already moved on without us (without the plan) resulting in churning, wasting valuable resources, et al. Imagine how different that would be if we had an integrated architecture that could gather the models based on impact and query them for feedback on the change.

Siemens Systems Driven Product Development, (integrated MBSE) espouses an integrated approach–once architecture/interfaces/relationships are established in Teamcenter, we make decisions about how something will be accomplished—SW, electrical, mechanical, etc. while considering the other downstream disciplines like mfg, cost, reliability, support, materials, et al.The domain specific information is passed along those digital threads into the downstream development tools (skipping the unscalable document/specification process) for fulfillment/realization. Later as unexpected domain specific issues are uncovered, we pass that information back up the thread to the higher altitude cross-product architecture where cross-domain impacts/decisions can be understood-creating the cross-domain infrastructure needed to optimize multi-domain products. 

Example Capella Functional, Logical, Physical Architecture Diagrams…using best-in-class product architecture/system modeling tools 

Many of you may have seen the System Modeling Press Release that went out earlier this month that announces a partnership with Obeo Open Source system modeling environment to extend our MBSE modeling solution to support various standard system modeling languages, such as SysML and Capella–creating an integrated product architecture solution that brings standard system modeling into the entire product lifecycle (change, variants, etc.).This creates the most comprehensive integrated model-based product architecture solution available starting with the product definition, requirements, architecture, moving through the allocation process, down to implementation, into the downstream disciplines which are all working from same set of blue prints under the watchful oversight/management of PLM. 

You can get more information on our integrated System Modeling solution at our website.

Mark Sampson