System of systems integration might be an overused term as we enter the age of the Internet of Things, where your fridge, toaster and coffee maker will regularly provide each other with status updates. But it remains the most accurate way to think about the multifaceted integration of the often intricate systems that comprise a modern military platform. And as General Motors and other auto manufactures have recently shown, the complexity of working with multiple suppliers can expose tremendous risk.
Chris Pogue is vice president of strategy and business development for General Dynamics C4 Systems International, a company with decades of experience developing projects for the Canadian army, navy and air force, as well as for public safety and emergency management. As Canada prepares for some of its largest systems integration projects in recent memory under the National Shipbuilding Procurement Strategy, he spoke with editor Chris Thatcher about some of the challenges.
There was a time when many systems, even in a military aircraft or vehicle, were fairly straightforward. Today, it’s not just the sophistication of each system that makes integration complex, but almost everything is also networked. How do you view system of systems integration (SoS)?
When you think of a large scale defence or public safety procurements, it’s no longer a system, it’s a system of systems which becomes very complex because you have multiple interfaces. Maier in the 1990s provided a unique framework that describes a SoS as having five fundamental characteristics: operational independence (the individual components have some operational capability by and of themselves); managerial independence (the components might be operated by different entities); evolutionary development (SoS will change over time but not all the parts will change at the same pace); geographical distribution (in other words, the bits and pieces of a SoS could be geographically distributed); and then the fun one, emergent behaviour – something that cannot be attributed to any single subcomponent but is created by a unique combination of systems. Maier didn’t say emergent behaviour is good or bad, he just said, “emergent behaviour.”
In good SoS design, we want to deal with the managerial independence, and a lot of that can be contractual; deal with the geographic distribution – the Internet is a good example of that; deal with the operational independence by virtue of having a well understood concept of operations; deal with evolutionary development by having a very clear operational architecture that shows a natural development over time; and then have positive emergent behaviour – unique new things that will make a valid operational difference. For a company like General Dynamics, because we have been dealing for decades with this increasing complexity and the dynamics of system of systems, experience lends itself well to finding ways to create the emergent behaviour that is desirable to achieve the operational mission.
Why militaries exist hasn’t changed a lot in the past couple thousand years: if you think of the Roman Legions and our militaries of today, what they do and why they do it is still pretty much the same; how they do it is a whole lot different. The breadth and range of programs we do – land, naval, air, even public safety programs with other government departments – means the “hows” are better understood. You couple that with tools like robust operational architecture and a sound understanding of the concept of operations and the way end users want to operate, that lends itself to generating system of systems configurations that can deal with those five characteristics and deliver beneficial emergent behaviour.
Does the fact that almost every component will have to operate in a Joint environment, that it must communicate and interoperate with everything else, affect how you approach a project for a specific service?
If you were designing communications systems, for example, through the lens of the army, you would get a certain level of capability but you certainly would not address the breadth of a system of systems because the army must talk with navy, the air force and other government departments. Under the JIMP construct we have in Canada – Joint, Interagency, Multinational, Public – that system has to talk with agencies and people it might not regularly work with. You have to build your systems with the idea that they will require that level and breadth. This is where experience matters the most: knowing that you have done it before across multiple environments and departments and integrated with legacy systems and emerging systems.
If I use the example of what is happening with cellular technology and the movement towards LTE, my daughter has in the palm of her hand the type of technology we want to give to first responders and militaries, and we know at some point they will have to as part of a multi-agency response. That is a true SoS problem. Those are managerially independent, geographically distributed, operationally independent, and they have their own evolutionary development. So the emergent behaviour is this interoperable system of systems – that’s what we want. But all the bits and pieces need to be understood.
The integration of the new with the old is a persistent problem for militaries. Are we improving how that is managed?
What we are really digging at is the idea of evolutionary development. And one of the key principles is that you have to build it right. You have to build the infrastructure recognizing it has to be scalable to be able to reach out to evolutionary change. You have to be able to reach back to touch those legacy systems but also be able to see where a technology is going and get out in front of it. If you build a scalable architecture in the beginning for your system, it will lend itself to that degree of flexibility. What I have noticed is we do not lack the ingenuity to find ways to do that.
It’s been said with large tech projects that although advanced detailed plans might seem critical for success, what is far more important is flexibility and agility to quickly adapt because of the level of uncertainty and rapidly changing technology. Given the length of many military projects, how do you deal with this?
There is a great phrase that you can’t get a rocket to the moon just by aiming it; you have to have the ability to course correct, which I always thought was an appropriate concept. You don’t get a major system delivery to a military customer without being able to course correct. Evolutionary development and new technology that wasn’t there when you first envisioned your program will demand course correction. The “how” will change and the ability to adapt to that inevitable change is crucial to success.
One of the things we have within General Dynamics that is helping us is called the Engineering Development Framework (EDF). It is a methodology that we built over a number of years of experience with these large-scale system of systems projects that captures lessons observed and makes them new best practices so that the next generation of engineers, of program managers, can benefit. Also, we have the benefit of working with a lot of different partners, and those partners have a lot of smart people. So we take full advantage when they are on our team of drawing their insights into this.
With the complexity of all the components and the fact that you are partnered with so many suppliers, how do you manage the risk in all this?
Again, I think experience allows you to perceive where risk can exist and how to be proactive in considering and addressing this risk. The EDF also lends itself as a risk identifier. But one of the most important pieces is a robust measurement framework that measures a number of different pieces of any project – and this isn’t just, are we meeting scheduled dates? That robust measurement structure gives you the ability to see problems coming before others might see them and then impose normal business practices to manage that risk.
Successful programs thrive because all the partners on the program are operating as partners; it’s not just a contractual relationship. So if GD were to see an issue in a supplier that our metrics told us about, we would instantly reveal that to help them identify and move in the right direction. And vice versa, we would expect the same from them in return….but that’s characteristic of true partnership.
Has the nature of the risk changed over the years?
I think it has. I think the depth of buried risk is probably higher today than it has ever been as systems become more complex. By buried risk, I mean risk that, unless you have the experience to seek it out or the measuring framework that triggers you to ask the right question, you may not see it until it is manifest in lots of other ways.
How do you address the security challenge? Too often, the criticism of many systems is that the security features are bolted on at the end.
This comes back to what we talked about earlier: you’ve got to build it right. You have to design it to be secure. When you stick security on top, at the end, it is far more expensive, more fraught with risk, and has way more knock on effects then you would like. If it is designed in, it is part of the system architecture and much more effective. For GD, we have recognized security as a cornerstone of how we operate. Information must get there and it must be secure, and you must be able to trust it. So it is part of the way we think about a system from the very beginning – it’s never an add-on.
How does that apply to partners who bring a widget into your system?
I think they are learning, and many of them readily adapt to that environment because they see what we see – it makes the most sense.
Given that complexity and the need for flexibility, how do you then cost programs for a customer that increasingly needs things well defined?
This isn’t meant to sound cliché: an experienced customer is our best customer. They have an appreciation for the things that could happen. A customer who accepts a low-cost solution just because someone says it will work, that is a risk. You don’t know what you don’t know, so the more experience you have and the wider range of programs and types of customers you have served, the fewer “unknown unknowns” you have.
I think there are things we can do better to help that customer. One of the projects I have been involved with is the use of operational and system architecture. The idea of architecture as a practice and a discipline, where you capture all the bits and pieces and represent the mission in various architectural views – all the subsystems and all the technical characteristics – that is a powerful way to help both the delivery agents and all the partners and the end customer appreciate the complexity. It adds an ability to create transparency in what you are trying to do.
What are some of the biggest challenges SoS integrators regularly encounter?
We’ve touched on this, but one obvious challenge is being able to integrate with legacy systems. The army’s Combat Net Radio is a good example where we have been able to take a legacy radio and essentially make it like new by virtue of a lower cost upgrade as opposed to a brand new radio. That is the type of challenge we will face over the next decade because I don’t think we are going to spend a ton more on buying new systems. We’ve got to make the stuff we have last a little longer while delivering the right capability to the end user.
The other thing is ensuring that the end user doesn’t just grab the next shinny “bit.” That shinny object might not have had human factors designed in, might not have been built with evolutionary development over time, and it might create emergent behaviours that are undesirable. That’s not necessarily a customer problem. In fairness, we all want the next shiny thing. It’s our ability to ensure that we know how to evolve technology and make it effective for the end user that matters most.
Elsewhere in this issue, we have an interview with Colonel Steve Hall on the army’s C4ISR developments. One of his largest challenges is education and training. That would seem to be a common problem as new and legacy systems are integrated.
I think what Colonel Hall seems to be experiencing is analogous to bolting it on at the end – oh yeah, we’d better do some training. One of the ways to get incrementally to where it appears he wants to go would be to make a trained operator part of the procurement. So understanding what capacities are required to operate any one system or the entire SoS needs to be designed in just like everything else, as opposed to here, we’ve got something, now we will go train you on it.
I do think in the longer term there will be less and less need for the training paradigm of today. People will just do it out of the box. It will be intuitive. All the things we are learning about how humans interact with technology are helping us design technology, tailored for the way humans interact with it. There is a great story about a kid who got an iPad for Christmas, set it aside, and a three-year-old picked it up and was playing a game within a few minutes. There is something about that class of device that is intuitive. That is a beacon on the horizon that will one day address Colonel Hall’s problem…I think it’s centred in the idea that you don’t need a manual; it’s just obvious how to use it.
Partners may contribute to the complexity of SoS, but they are key to delivering capability. What’s the role of GD’s EDGE Innovation Network in helping identifying them?
We did an analysis and over a million innovators are part of the network, and that was a conservative estimate when you consider the number of companies involved. The EDGE is a mechanism by which we get privileged exposure to companies all across Canada, and for that matter around the world, that are doing very unique things, companies that we wouldn’t necessarily bump into. Some of them have innovative technologies or capability that can help ratchet a program to the next level. For some of these companies, they are now touching an international market through GD that they probably would not have been able to reach on their own – it’s a classic “win-win” relationship.
What is also unique is that you generate diversity of thought. You generate the opportunity to interact with people who may not be in the same sectors as you, doing different things, and you’d be shocked by how differently they might see something. I never learn more than when I talk with someone who is looking at a problem through a different lens than I am. It causes me to rethink. All of a sudden whole new ways of operating or of solving the problem emerge. That’s one of the things I love most about the EDGE, the chance to get into collaborative dialogue with people who think differently.
Does it help you get a sense of emerging technology for future systems before it’s widely recognized?
Absolutely. One of the tools we have is a call for innovations to explore a problem. For example, 18 months ago we wanted to look at what was going on in the world of power sources. For a soldier operating in remote or isolated areas, power is life or death. We wanted to understand how batteries have changed in the past few years, who is working on clothing that generates or collects energy, solar units embedded in clothing, etc. The EDGE is a powerful environment that lets us get inside some of these areas.
Are there specific technology trends you are following?
Size, weight and power are always an issue. But an emerging trend that I see as huge is recognizing that we are moving toward commonality and COTS (commercial off the shelf) technology – maybe we call it “COTSification.” That is a good thing and potentially a risk. If you don’t really understand the system of systems characteristics, COTS parts can cause no end of problems because they are not necessarily built to be part of a SoS. The other thing that I think we really need to observe closely is the way in which this next generation interacts with technology…that leans back on our earlier topic on the future of training.
In GD, we use a human-centred design approach, which causes us to embed that kind of thinking in the design. As with security, we don’t stick the human in at the end. GD and the defence companies that we work with have a clear understanding of the end user and what they want to do. If you ever get disconnected from deeply understanding how they want to operate, you run the risk of building a system of systems that is not useful to them. So it’s never far from our thinking. We’re lucky: the end users we operate with relish that interaction.
Last thoughts?
One last thought that might explain what SoS is all about. Future intent drives near-term actions, whether they are goal achieving or tension relieving. What I mean is that if you have the future intent of still supporting that customer 50 years from now, that would drive your near-term actions today. And is your near-term action about achieving a goal or just relieving some tension you have right now? That is part of what the system of systems problem needs: people who are goal-achieving and are carrying out near-term actions that have a future intent.
It is interesting how much it is a people problem, despite the technology in every project. Success and failure in companies and organizations is about getting people aligned around some common objectives and shared vision.
