How SWFs and SWIGs can Assist the DoD

The DoD-level organizers do a fantastic job putting plans and strategies together for the betterment of the force moving forward. It’s at the policy level, industry practices, and modern technologies are incorporated very well. New policies and standards are setting the foundation for transformation across the DoD to become a modern technology-driven enterprise.  One of the only things that make sense regarding the translation between industry and DoD. Where issues arise is bridging the strategic documents into tangible shifts across all echelons from strategic to operational and tactical organizations. New technologies and organizational capabilities can dramatically alter operational effectiveness.

Also understanding the mistranslation comes into play when you read those strategies and then wonder why the rest of the force isn’t following closely to those standards. With Software Factories (SWF) and Software Integration Groups (SWIGs), I think we can assist with some of these mistranslations. This is how SWIGs and SWFs can assist the DoD.

The lack of unity of effort is hindering adoption.

While understandable, a significant gulf exists between the strategy being laid out by DoD CIO and service component CIOs/CTOs/CSOs, and organizations with the responsibility to keep warfighters and systems ready for the fight. Well, one of the main reasons why is across service branches, it is no one person’s job right now to implement the new technologies is disaggregated across acquisitions programs, higher echelon commands, and commanders at the Unit of Action level for each service. In fact, at the tactical/operational level, their main job is to meet the mission. Because without the necessary training and build-out of that new technology, it is useless to the tactical/operational units. They could care less about the newest technology that has come out. These units are going at breakneck speed and have very little room to stop and play with new equipment. Even though, this new equipment could make their lives so much easier.

Why it is so Hard to Implement New Tech

One key example is the use of tactical edge devices, Kubernetes, and the cloud. Though we all see these technologies as a must-have, most see them as a nuisance. Why is this the case? There are a few key reasons that are more about people, than technology.  1) Current OPTEMPO, Training, Administration, and Readiness Requirements at the Operational/Tactical echelon. Because between each big exercise, they have 1 small exercise, a maintenance/medical/training stand-downs, etc. Additionally, they then must prepare for the big muscle movement for the big exercises. They don’t have the time to get the new equipment in, learn how to use it, and then build out the infrastructure.

In fact, in some cases, it is easier to just stay with the equipment you have. Because it decreases the workload. Which, in turn, reduces stress levels. So, though getting in the new gear/solution will make their lives easier, in the long run. It will, in fact, cause a massive nuisance in the short run. This leads us to ask how we fix this, which seems like a circular issue. Receiving and fielding new hardware and systems may provide longer-horizon benefits to the members of the receiving units. The resistance comes when operational pressures, training requirements, planning, moving, and executing exercises require all the unit’s time. Since the mid-2010s, units at all echelons are inundated with innovation theater and tech buzzwords. The messaging to translate value or impact to the mission has lagged the policy changes.

The Solution

In order to discuss this, I will use the Marine Corps as an example. The situation provided above is rampant all around the Marine Corps with individuals within the tactical/operational units hoping that HQMC will come up with the solution, implement it and then deliver it to the fleet with documentation and onboarding help. That isn’t happening.

So, the solution would be to one stand up a Software Factory (SWF), and 2, establish an organization of solutions architects and engineers. This organization has the mission to provide technology solutions and capabilities to the operational and tactical units. For now, we can call them Software Engineering Group (SWEG). The SWF will be the home of developers (in the MC’s case HQ will be in Austin). Additionally, the SWF will be the home of where the software applications will be created and configured based on what the customer (tactical/operational unit) is looking for.

The SWEG groups will be the Solution Architects (in uniform). Whose sole focus is to combine the hardware with the software and then deploy it to the tactical unit requesting the necessary equipment and implementing it in the unit’s infrastructure. The SWF will house these SWIG groups in Austin as well. But will work closely with the Network Battalions in order to make sure all 3 network battalions, hire, and tactical/operational units are all on the same page.

Where Software Factories Fit In

We will have a standing body of 54 developers in Austin at the MCSWF. The MCSWF will focus primarily on providing adaptive architecture and developer-enabling services for the total force. With this, we should plan on having each MEF, Division, and Regiment (this being the lowest level that has a DevSecOps team) have a team of 8-10 developers attached. This way they are able to coordinate back to the MCSWF HQ (in Austin). We will only develop software applications based on future use cases and customer-specific needs (the customer being the warfighter).

Where Software Integration Groups Fit in

So, as we talk about the map structuring for the SWF, we will also have additional map structuring for the SWEG groups. Meaning we will have a standing body of 54 (SWF and 54 SWEG) in Austin. Then we will have a team of 8-10 devs for SWF attached to each MEF, Division, and Regiment. With an additional 3 Solution Architects (SAs) personnel attached to each MEF, Division, and Regiment. The only difference is we will have 3 more at the Network Battalions as liaisons. Whose whole job is to talk to his other SAs and coordinate. The liaisons that are attached will be under the Solutions Architect structure and not the Network Battalions structure. This is to maintain accountability for innovation.

Additionally, the SWEG bringing in SAs that are only there to develop and implement new technologies for the force will be another Talent Management tool for the force. One, it allows for people who are interested in technology but aren’t interested in developing to still maintain the ability to stay in uniform.

I know of at least 20 Marines that want to go to the MCSWF but aren’t developers and want to be able to still maintain an outward-facing presence to the technology. They want to work with the cloud, 5G, and advanced networking. They want to be able to interact with their customers and help them deploy the entire IT infrastructure.

But because that is what they want to do they won’t be invited into the MCSWF which is solely software based. Still a good initiative but doesn’t solve the whole picture. Which is why we are making the distinction here.

Takeaway

As mentioned earlier, one of the main issues for the force not being able to adopt the new technologies even though there is a need for it is solely based on the fact that it is no one specific job to implement it. We need individuals that actually want to do this and be a part of something special. We need to implement talent management strategies in place here. Put individuals who are interested and understand the new tech in these positions. Not just place someone there because of rank and past performance. Just because someone is good doesn’t mean they care about getting or understanding new technologies.