{"id":12529,"date":"2022-10-12T16:06:00","date_gmt":"2022-10-12T20:06:00","guid":{"rendered":"https:\/\/blogs.sw.siemens.com\/teamcenter\/?p=12529"},"modified":"2026-03-26T08:59:03","modified_gmt":"2026-03-26T12:59:03","slug":"cut-integration-time-and-cost","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/teamcenter\/cut-integration-time-and-cost\/","title":{"rendered":"\u231a Ready to cut system integration cost by 50%?"},"content":{"rendered":"\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n

Why spend 1\/2 your program schedule and resources on system integration? <\/h2>\n\n\n\n

<\/p>\n\n\n\n

System Integration consumes a major portion of program schedules and resources as you bring software, electronics, and mechanics together. <\/p>\n\n\n\n

In my blog Extending MBSE into your supply chain<\/a> I described how you actually plan for integration issues and spend 30%-70% of your program schedules\/resources bringing everything together on the right side of the V.  <\/strong><\/p>\n\n\n\n

<\/div>\n\n\n\n

Why we have integration problems…<\/h2>\n\n\n\n

Looking at the V process the reason is clear:<\/p>\n\n\n\n

\"\"
ARP4754 Standard development process<\/figcaption><\/figure>\n\n\n\n

Looking at the standard Aero ARP4754 process shows how the various development silos fit into the V process. Requirements are developed in one silo, tests used to verify those requirements is in another silo, architecture is somewhere else, and so on. This means there is no single source of truth, no cross-domain traceability, no lessons learned passed on, etc. as each silo is doing its own thing with its own toolsets.<\/p>\n\n\n\n

You could blame the V process, but this V lays on top of an organization, which according to Conway\u2019s Law<\/a> says, organizations develop products that match their organization structures \u2014 that is we develop in silos and wait until we get to the right side of the V to do system integration, discover the integration problems, and THEN start integrating.<\/p>\n\n\n\n

The Aerospace Vehicle System Institute (AVSI) Systems Architecture Virtual Integration Project (SAVI) <\/a> says this has to change as it is no longer affordable to build airplanes how we used to (see Augustine\u2019s Law #16<\/a>) \u2014 crossing the affordability limit for both commercial and military aircraft back in 2013.  <\/p>\n\n\n\n

The project has gathered various measures of complexity from member organizations like this one for Source Lines-of-Code (SLOC):   <\/p>\n\n\n\n

\"\"
One measure of aero system complexity taken from Aerospace Vehicle Systems Institute ( https:\/\/savi.avsi.aero\/about-savi\/)<\/figcaption><\/figure>\n\n\n\n

They suggest a change from the current \u201cspec-design-integrate\u201d process to a \u201cintegrate, then build\u201d process or as they put \u201cstart integrated, stay integrated\u201d.  So why do we put up with this? As one aero person put it to me, “because that’s how we’ve always done it.”<\/p>\n\n\n\n

How to start integrated, stay integrated…<\/h2>\n\n\n\n

Putting aside the organization issues needed to do that shift for the moment, \u201cstarting integrated\u201d <\/strong>will require capture and management of the cross-domain product drivers (architecture, requirements, parameters,\u2026) in the organization\u2019s Product Lifecycle Management (PLM) system so it can drive continuous integration:<\/p>\n\n\n\n