Original Post Date: Wednesday, September 25, 2013

As promised in my last blog (“System and Assembly Objects in the context of Hardware AoAs”), the integration of Software COTS is a subtly different challenge.  Customers are typically presented with two scenarios:  integration within a single system and integration within a system of systems (“SoS”).  Both cases are handled well by TruePlanning™ with specific parameter choices that control multiple activities relevant to software integration.  As I’ve come to appreciate PRICE’s competitive advantage with our Framework’s approach to the latter SoS case, I thought describing these two scenarios would help allow you to distinguish the drivers and effectively model both.


By definition, integration of COTS require activity efforts above and beyond those for a component-only custom build.  Feasibility analysis is needed to discern appropriateness of purchasing/ modifying COTS, given stated requirements as well as issues specific to possible vendors as well as their business terms.  A two-stage search follows:  initial identification of COTS candidates, followed by detailed evaluation.  Drivers for this process are of course the counts of compliant products searched and then evaluated, the technical requirements, and the ultimate operating specification that mandates “-ilty” demands.  After purchase/ lease, the largest activity efforts of COTS software integration are twofold:  tailoring and glue code.  In the first case, the driver is a direct function of the functionality required from the product.  Even if no additional code is necessary to customize the COTS (which is rare), I’ve come to realize that just becoming familiar and conversant with the code takes additional effort.  Secondly, glue code development addresses both utilization of the COTS capability and communication with the internally developed code, in addition to interfaces with other COTS.  Glue code also addresses data translation as well as problem resolution due to shortcomings/constraints in the COTS.  Drivers for glue code are similar to component development:  size, organizational productivity, complexity and tool availability.  What I appreciate after recent projects is that these parameters can have distinctly higher values, given that the integrators are not the original developers and usually have no access to the source code.  Necessary testing is driven by functionality and quality levels, as well as compatibility issues between multiple COTS instances.  This latter situation is addressed more below in reviewing the SoS scenario.  In terms of COTS support:  upgrades, updates and bug-fixes (either by the vendor or by the purchasing organization) also affect the effectiveness of overall integration.  Drivers are again similar to glue code and testing, as well as the COTS’ suppliers level of responsiveness, if any. 

System of Systems

The TruePlanning™ Framework is designed to accommodate the modeling of systems of systems, which by definition deliver an aggregated capability above and beyond the collection of individual functions of the combined component and COTS systems.  In the case of the latter, integration drivers are the level of data translation and communication protocols to support interoperability within the SoS.  In addition, by virtue of requirements that are typically not fully defined, as in a single system, as well as the overall size, scope and interoperability challenges, complexity is typically much higher for a SoS project.  Also, as magnitude increases, integration activities can center on the capability of COTS to meet functionality needs.  Specifically, system engineering is significantly higher, driven by technical maturity as well as necessary compromise on requirements to level-set the components.  Minimizing vendor counts will significantly reduce the impact of these drivers.  Likewise, if protocols and data interfaces are also standardized.  SoS is accommodated well by our model.  The challenge is size, both in functionality scope and vendor count, in addition to escalated complexity.  As we continue to model these types of projects here at PRICE, through our consulting and mentoring assignments, we will definitely take advantage of this experience base to enhance our model’s capture of the drivers to these challenges!  One final comment:  remember that software integration is also addressed in the hardware component object, where the “hardware/software integration factor” indicates the extent, if any, of this effort at the parent assembly level.