Building virtual worlds at Boeing

Want to see how an F-16 will react to the latest antiaircraft weapons? Tip Slater is your man.

Want to see how an F-16 will react to the latest antiaircraft weapons? Tip Slater is your man. 

As director of virtual operations for The Boeing Company’s Integrated Defense Systems group, Slater is responsible for creating virtual environments that Boeing customers, chiefly the U.S. Department of Defense, use to test the latest wares and ideas. His team of engineers must collaborate effectively to make sure the events live up to customer expectations and go off without a hitch, especially considering a four-star general may well be looking on. Boeing uses various tools to collaborate among its far-flung business units, but Slater says it’s the processes surrounding the tools that determine whether they do any good.

Can you describe what your job entails?

I belong to an organization called Analysis Modeling Simulation Experimentation. Our job is to create an environment in which we can test out concepts and ideas for our customers, the majority of which are military. If a customer wants to try a wartime scenario, he can’t afford to fly or move all the military [equipment] that he wants, and you can’t afford to blow it up either. So, we provide an environment where we bring in live, simulated and computer-generated entities. 

Our job is to pull together this synthetic environment so that we can test out a concept or a hypothesis. For example, we can actually take an F-16 flying over the desert in southern California, and the pilot will see on his radar scope all of the virtual and computer-generated entities that we have in the environment. So, we’ve got a real plane that gets the signatures in his cockpit that state that there are other entities working around him, when in fact those entities are digital [creations]. And that allows us to put the assets into an environment and test them out. So it gets to be a very complicated environment.

And LabNet is the network that connects the various Boeing labs that may participate in these events?

Yes. We usually operate about 70 to 100 labs on the network at any one time. We’ve got the capability of connecting [all 700 Boeing labs], but we’ve never done it. The network is very fast and very capable. I can only handle probably 10 milliseconds of latency before the pilot actually sees it on the screen.

What is the role of Web 2.0 and other collaborative technologies in that environment?

When we run an event, it’s like a production. Behind the scenes we’ve got a number of people at each one of the labs who are managing the network and the visualization that’s going on. And the tools that they use to collaborate are instant messaging and some unique voice systems. It’s like behind the scenes of Monday Night Football. The event producer is connected to all the different labs that are involved in the event and maintaining the control of the operation. Those are the collaboration tools to make sure that the system operates.

Outside of the actual events, what collaboration technologies do you use to get work done more effectively?

When we set up a demonstration or an experiment, we have to bring people from across the enterprise to make it work. That’s where we use collaborative tools. For each event we set up an event site using Microsoft SharePoint. People can post their announcements in there and drop in briefs and so forth. We use Microsoft Project on SharePoint as a communication platform. Information, charts, notes, schedules and such are posted there, as opposed to using e-mail. We use WebEx routinely [for Web conferencing].

We’re just starting to use wikis to help build events. We’re using instant messaging, primarily when the software folks are working on coding. So, if we’ve got somebody in Washington, D.C., and he’s working with a software coder in Anaheim, [Calif.], they use instant messaging to talk to each other while they’re developing the coding.

We’re looking at bringing in some collaboration tools that will allow us to do computer-to-computer collaboration. One too we’re evaluating is called the TouchTable, [which is a computerized table] that exists in two locations and both operators are looking at the same screen. And they can expand the screens, contract the screens; there’s a lot of visualization involved. They can be looking at a map and deciding what to use as a target area. Somebody can highlight a spot on the map and say, ‘This is the area we’re looking at. Do you think that will work?’ Another guy says, ‘Yes, but that means the ingress doesn’t meet the customer’s expectations. We have to get something that takes us through a mountainous area or else the hypothesis is wrong.’ And they’ll have that collaboration among themselves.

What about digital white boarding?

We use digital white boards in different areas. One is facility management, where we have three facilities that we operate at the same time with customers in all three of our [major event] locations. They’ll use the digital white boards to describe what the screen layout for all the three locations is looking like, and how we are going to handle the customers in each location.

And the network operators will use the digital white board to describe things like their network design for any given operation. We’re moving some of the networks overseas and we hook into other organizations’ networks, and there are a number of rules and regulations that we have to have on how the networks are designed to meet government and company requirements. So they’ll use the digital white board to talk to each other across the ocean. We’ve been doing that for about a year and a half.

What’s been your approach to getting people to use these collaboration tools?

The primary approach is, before we go purchase a tool we say, what’s the concept of operations? In other words, how are you going to use this? We just can’t go buy a tool and throw it out there. We did that, about four or five years ago. We purchased some tools, threw them out there, and nobody used them, so it was a waste of money. You need to have buyoff where a couple of organizations say, ‘Yes, we’ll use it and here’s the concept we have in mind.’ That’s enough to kick it off.

But can you really predict how you’re going to use the tool before you’re actually using it?

The concept of operation is there to ensure that you have more than one person agreeing to the fact they’re going to use the tool. Then you initiate the concept and it usually morphs into something else. Which is fine, because that just means people are using it. Probably 80% of the time we end up using the tool differently than we thought we were going to. What you don’t want to do is have a smart engineer who’s very articulate come in and sell an idea, and we buy a tool and nobody else uses it. It just languishes.

What happens if you have teams in one or two locations that are all excited to use a certain tool, but the third location that’s involved doesn’t want to do it?

What happens is the tool comes in and let’s say team A and team B are using the tool and team C can’t get there from here without the tool. They actually have to buy into it. For example, we’ve got a voice tool that allows us to do collaboration. It’s a unique voice box, a radio system. There are two or three on the market, and they don’t integrate together. So site A doesn’t want to buy that box because they’re used to using a different box. 

But if sites B and C are used to using that box, then you basically say, ‘I’m sorry, I can’t afford to bring your box into three different locations when all I have to do is add one box to your location.’ So it goes in and that becomes the collaborative tool that we use.

Have you been able to determine any kind of ROI on any of these collaboration tools?

Interesting question. I cannot put a number to it. But the rule of thumb in our operation is, we have to maintain the same number of people but expand our capability every single year. I’ve got to expand the [simulation] environment that I described earlier. I’ve got to take it to more places, integrate more labs and more capabilities, and I’ve got the same number of people to do it. And we’ve been able to do that.

Collaboration is the key to making this work. I’ve got the same number of people, they’re located across the enterprise, and I’ve got to do more things every single day than I did yesterday. The only way we can get there is with collaboration tools. It also requires us to change the way we operate, so we’re constantly looking at tools and operational concepts. In other words, how do we manage what we’re doing? It’s a constant battle.

There are two key elements to this. Management’s role is to provide the direction, the vision and the tools. And then the engineer’s role is to provide the processes around how to use the tools and to standardize the way we’re doing things, so we can do it across the enterprise. You can put the tools in place but if you don’t have a common language or common process, they don’t help you.

We’ve also put together a team of folks to look at the different software and hardware tools that we use across this LabNet enterprise. We have representatives from every site on that team, working on which tools they’re going to use and how they’re going to do it. That’s been in place about a year.

And how is that working out so far?

Actually, pretty good. People truly do understand. We only have so much budget and you can’t afford to buy different tools to do the same thing for all the different sites. It’s just not cost effective.

What would you say has surprised you the most about your deployments of collaboration technology?

I expected the tools to give us more than they gave us, but what it boils down to is the culture of the organization. When you go across the country, you’ll find different cultures in the different organizations that you’re working with, even though they work for the same company. Until you get the cultures to agree to a common terminology and a common process, the tools don’t enable anything to happen.

What have been the most challenging aspects of implementing collaboration tools?

That gets back to the culture thing. I’m currently in Anaheim, and have sites in St. Louis, some in D.C., and some in Seattle. They’re all over the place. Each site has a number of tools and its own processes. And they came from other companies— Rockwell, Boeing, McDonnell Douglas, they had all their processes. 

So these people, a lot of them are very experienced engineers, come into the environment with ideas and processes and procedures that came out of that heritage company and heritage site. We bring them all together and say, ‘You’re now going to collaborate and you’re going to make this live virtual constructive environment, and all these labs are going to work together in this environment and they’re going to produce this product.’ And people stand up and say that sounds like a great vision. We love it. We want to work it.

Then you start putting the tools in place and they say, wait a minute; we don’t use that tool here in St. Louis. You’ve got to use this tool. Well, where did that tool come from? What were the site processes? What were the engineering processes? And pretty soon, you’ve got this chaotic stuff going on because of the cultures that they came from.

So what we’ve had to do is bring them together and step back and say, ‘Look, you’re working at the enterprise level. Forget your sites. What is the enterprise process and what is the best way we’re going to move forward on this?’ And it’s taken us a while to get there, but we’ve started chipping away the different tools, and people begin to realize the tool isn’t the issue, it’s how you use the tool that’s the issue, and that gets into the processes and how you develop those processes. 

And if there is one competitive advantage I think we’ve got it’s the fact that we work across the enterprise and we recognize culture is probably the one thing that’s going to stop us. We have to attack that first and foremost.Any company or enterprise that’s going use collaboration tools, they’re going to have to approach it that way. If somebody in the United States wants to work with India or Hong Kong, or anywhere else, you’d better figure out how you’re going to [work together] first before you add a tool onto it, because the tool isn’t going to do anything for you.

Desmond is events editor for Network World and president of PDEdit, an IT publishing company in Southborough, Mass. Reach him at paul@pdedit.com.