Regina_Daniels
New Member
What Systems of Systems Integration (SOSI) concept? What is it intended to do for the warfighter? Why is it does the Army find it so difficult to implement?
Is the System of Systems Integration (SOSI) concept a myth?
- Thread starter Regina_Daniels
- Start date
Which Army are you referring to?
The system of systems concept refers to all of the elements in a force capability being sympathetic with each other as well as providing "support"
its a difficult construct but in an NCW environment is more or less a fundamental need if your capability is to work seamlessly and effectively.
you probably need to be more specific though as its a "how long is a piece of string" type question
weasel1962
New Member
Re:
SOSI is an integration unit (directorate) in the US Army handling systems integration.
Most armies of developed countries have systems integrators. It is relevant for acquisitions (cos you don't want to get a piece of equipment that can't be used or worse, detrimental to other systems).
Definitely no myth.
SOSI is an integration unit (directorate) in the US Army handling systems integration.
Most armies of developed countries have systems integrators. It is relevant for acquisitions (cos you don't want to get a piece of equipment that can't be used or worse, detrimental to other systems).
Definitely no myth.
The systems approach to problems is concerned with performance of the total-system taken as a whole, not on their parts taken separately. Meanwhile one definition I have seen of a system of systems is a set or arrangement of interdependent systems that are related or connected to provide a given capability Just out of curiosity I searched systems of systems and wiki has an interesting definition : " System of systems is a collection of task-oriented or dedicated systems that pool their resources and capabilities together to obtain a new, more complex, 'meta-system' which offers more functionality and performance than simply the sum of the constituent systems." Any thoughts?
I believe a goal of this system of systems integration is to provide warfighters with equipment that is interoperable with other Army and other Services (thus Joint) equipment to ensure these systems can work together to accomplish the larger task at hand. By doing this may also lesson the amounts and types of different equipment necessary because they can all "talk" thus eliminating redundant systems.
One example I can think of is before establishing the Joint Capabilities Integration and Development System (JCIDS) in 2004, Services pretty much could pick their own solutions to solve service identified problems without consideration for other Services and even other parts of the Army. This resulted in radios that could not talk between Army, Navy, Air Force, multiple acquisition programs trying to solve the same problem, and within the Army stove piped solutions that would only work for a portion of the Army. While I would agree that certain requirements require a very specific solution that may be a stand alone "system", if these interoperability issues with other systems that this solution may have to interact with are not considered, we will again have another system that cannot be used in the larger scheme.
As for why it has been so hard to implement. The Army itself is a large bureaucratic organization and it takes a large amount of time to change the culture of any organization let alone one the size of the Army. While I believe that the Army (and DoD) in general have made strides in this area due to lessons learned in the past few years, the culture has not completely changed from the old stove pipe culture (if you will) to a system of systems process. There are many other contributing factors such as the way resources are allocated by Congress to each service separately but I believe the overarching issue is mainly the time it takes to change a culture in a huge organization such as the Army.
Major Wayne Nitzschner
Student, CGSC
Disclaimer: "The views expressed in this forum are those of the author and do not reflect the official policy or position of the Department of the Army, Department of Defense, or the U.S. Government."
Last edited:
Joint in JCIDS
Wayne,
I think that you nailed the overall intent of the systems approach with the JCIDS example. However, my biggest problem with JCIDS is that Jointness/interoperability is basically the last step. While a centralized Joint led process will probably not yield systems/programs/training (fill in the DOTMLPF) to meet the needs of the services, the need to consider Jointness earlier in the JCIDS process exists.
Also, with regard to the which Army question, I think that there is another relevant point. Especially, in a time that international cooperation has been renewed. How are we ensuring that the solutions we choose (esp. the material ones) will integrate with our most critical partners (ABCA)? I have seen enough frustration in exercises with British, Australian and Canadian staffs that convinces me that this needs to be at least a cursory requirement.
MAJ Dave Brines
Combat Developer, USAMEDD
Disclaimer: "The views expressed in this forum are those of the author and do not reflect the official policy or position of the Department of the Army, Department of Defense, or the U.S. Government."
Wayne,
I think that you nailed the overall intent of the systems approach with the JCIDS example. However, my biggest problem with JCIDS is that Jointness/interoperability is basically the last step. While a centralized Joint led process will probably not yield systems/programs/training (fill in the DOTMLPF) to meet the needs of the services, the need to consider Jointness earlier in the JCIDS process exists.
Also, with regard to the which Army question, I think that there is another relevant point. Especially, in a time that international cooperation has been renewed. How are we ensuring that the solutions we choose (esp. the material ones) will integrate with our most critical partners (ABCA)? I have seen enough frustration in exercises with British, Australian and Canadian staffs that convinces me that this needs to be at least a cursory requirement.
MAJ Dave Brines
Combat Developer, USAMEDD
Disclaimer: "The views expressed in this forum are those of the author and do not reflect the official policy or position of the Department of the Army, Department of Defense, or the U.S. Government."
daniel.s.green
New Member
Dave, I think your point about solution integration is an important one.
Keeping the question close to our own force, we have certainly been grappling with the challenge of what gear is necessary, what equipment to take on deployment, or what is needed for this or that assignment. Rapid response to requirements originates with the Army, at some level, recognizing a need for a particular solution with a goal of producing results as quickly as possible at the lowest cost and ultimately fielded for Soldiers' use.
Prototype development - from customer-developed requirements to competitive prototyping and testing, have come to the fore for generating material solutions. With specific requirements defined, understanding of the need that will be addressed, and what resources are required for project development, both government and contractors take a developed proposal including staff requirements and cost data and move ahead with project development.
The Soldier is the ultimate end-user. Delivery to, and integration with Soldiers becomes crucial to their success. Training, as a component of fielding, must be clear, concise, and actionable by users. Rapidity gets a developed, tested and integratable solution into Solider's ruck with an aim to improving their ability, enhancing their capability, and augmenting their range of action. Speed is important, but holistic program quality must not be sacrficed. An improperly vetted piece of equipment intended to be a solution could acutally prove to be detrimental. With a Soldier-focus always in mind, and with the right proccesses in place and working, the Army can (and has) achieve success with getting a needed solution to Soldiers in quick fashion.
Disclaimer: "The views expressed in this forum are those of the author and do not reflect the official policy or position of the Department of the Army, Department of Defense, or the U.S. Government."
Keeping the question close to our own force, we have certainly been grappling with the challenge of what gear is necessary, what equipment to take on deployment, or what is needed for this or that assignment. Rapid response to requirements originates with the Army, at some level, recognizing a need for a particular solution with a goal of producing results as quickly as possible at the lowest cost and ultimately fielded for Soldiers' use.
Prototype development - from customer-developed requirements to competitive prototyping and testing, have come to the fore for generating material solutions. With specific requirements defined, understanding of the need that will be addressed, and what resources are required for project development, both government and contractors take a developed proposal including staff requirements and cost data and move ahead with project development.
The Soldier is the ultimate end-user. Delivery to, and integration with Soldiers becomes crucial to their success. Training, as a component of fielding, must be clear, concise, and actionable by users. Rapidity gets a developed, tested and integratable solution into Solider's ruck with an aim to improving their ability, enhancing their capability, and augmenting their range of action. Speed is important, but holistic program quality must not be sacrficed. An improperly vetted piece of equipment intended to be a solution could acutally prove to be detrimental. With a Soldier-focus always in mind, and with the right proccesses in place and working, the Army can (and has) achieve success with getting a needed solution to Soldiers in quick fashion.
Disclaimer: "The views expressed in this forum are those of the author and do not reflect the official policy or position of the Department of the Army, Department of Defense, or the U.S. Government."
Regina_Daniels
New Member
- Thread Starter Thread Starter
- #7
SOSI Response
Wayne, Dave and Dan,
Thanks for your perspective on the SoSI subject. I purposely left the first question open ended because I wanted to get different perspectives on the subject. The SoSI concept takes on different meanings because there is no universally accepted definition. SoSI can be hardware-to-hardware or hardware-to-software integration. For most hardware-to-hardware integration, SoSI is really hard to do when you’ve developed a system and trying to integrate a component or subcomponent into the system. The Terminal High-Altitude Area Defense (THAAD), Lightweight Water Purification System (LWPS) and Firefinder radar programs are examples of hardware-to-hardware integration. These programs use the 3 kilowatt generator to power their respective systems. Some PMs use the SoSI concept to leverage existing technologies to develop their requirements with great success while others do not. For all intents and purpose, the Army has not done a really good job with the SoSI concept.
I believe many Combat Developers do not fully consider their power generation requirements during the requirement generation process. Instead, power generation only becomes a PM issue during the Engineering and Manufacturing Development (EMD). If the Army waits until the EMD phase to integrate power generation, it’s all ready too late. I personally believe that SoSI must begin at the user level. Combat Developers writing requirements for systems which consume power must reach out to the Sustainment Center of Excellence (SCOE) Combat Developer to address their power requirements during the requirements generation process. This will reduce high volatility, uncertainty, complexity, and ambiguity (VUCA) upfront. SoSI should be a done in a collaborative environment which fosters teamwork and cooperation to build a weapon system that meets the Army needs in our current fight. I view SoSI as an iterative process that begins from idea conception through sustainment.
The Army named the DoD Project Manager – Mobile Electric Power (PM MEP) as the Systems of Systems Integrator for Battlefield Electric Power Integration in 2008. PM MEP, SCOE and others are currently collaborating on the next Tactical Electric Power (TEP) Operational Requirements Document (ORD) to meet the Army’s current and future needs. I believe the Army still has work to do in this area, but it’s a step in the right direction.
MAJ Regina Daniels
Student, CGSC
Disclaimer: "The views expressed in this forum are those of the author and do not reflect the official policy or position of the Department of the Army, Department of Defense, or the U.S. Government."
Wayne, Dave and Dan,
Thanks for your perspective on the SoSI subject. I purposely left the first question open ended because I wanted to get different perspectives on the subject. The SoSI concept takes on different meanings because there is no universally accepted definition. SoSI can be hardware-to-hardware or hardware-to-software integration. For most hardware-to-hardware integration, SoSI is really hard to do when you’ve developed a system and trying to integrate a component or subcomponent into the system. The Terminal High-Altitude Area Defense (THAAD), Lightweight Water Purification System (LWPS) and Firefinder radar programs are examples of hardware-to-hardware integration. These programs use the 3 kilowatt generator to power their respective systems. Some PMs use the SoSI concept to leverage existing technologies to develop their requirements with great success while others do not. For all intents and purpose, the Army has not done a really good job with the SoSI concept.
I believe many Combat Developers do not fully consider their power generation requirements during the requirement generation process. Instead, power generation only becomes a PM issue during the Engineering and Manufacturing Development (EMD). If the Army waits until the EMD phase to integrate power generation, it’s all ready too late. I personally believe that SoSI must begin at the user level. Combat Developers writing requirements for systems which consume power must reach out to the Sustainment Center of Excellence (SCOE) Combat Developer to address their power requirements during the requirements generation process. This will reduce high volatility, uncertainty, complexity, and ambiguity (VUCA) upfront. SoSI should be a done in a collaborative environment which fosters teamwork and cooperation to build a weapon system that meets the Army needs in our current fight. I view SoSI as an iterative process that begins from idea conception through sustainment.
The Army named the DoD Project Manager – Mobile Electric Power (PM MEP) as the Systems of Systems Integrator for Battlefield Electric Power Integration in 2008. PM MEP, SCOE and others are currently collaborating on the next Tactical Electric Power (TEP) Operational Requirements Document (ORD) to meet the Army’s current and future needs. I believe the Army still has work to do in this area, but it’s a step in the right direction.
MAJ Regina Daniels
Student, CGSC
Disclaimer: "The views expressed in this forum are those of the author and do not reflect the official policy or position of the Department of the Army, Department of Defense, or the U.S. Government."
When the FCS program was cancelled, the TRADOC Capabilities Manager (TCM) FCS became TCM Integration. This is due to the multiple systems the TCM had been handling (and integrating) under FCS. It was a logical choice to have this TCM tasked with integrating new systems being developed for Brigade Modernization. This became more than just FCS technologies. This also grew to include integrating existing and draft requirements documents and programs of record.
SOSI is an important function in simple to robust programs. An ammo pouch is a system on a MOLLE system. Much like a sensor is a system on a vehicle. The more complicated the program, the more emphasis and attention must be on SOSI.
The views expressed in this blog are those of the author and do not reflect the official policy or position of the Department of the Army, Department of Defense, or the U.S. Government
SOSI is an important function in simple to robust programs. An ammo pouch is a system on a MOLLE system. Much like a sensor is a system on a vehicle. The more complicated the program, the more emphasis and attention must be on SOSI.
The views expressed in this blog are those of the author and do not reflect the official policy or position of the Department of the Army, Department of Defense, or the U.S. Government
Last edited: