The concept of sharing does not always come naturally to human beings or legacy systems. But a service-oriented architecture effort within the U.S. Department of Defense's intelligence community is helping DoD in the effort to better share information as well as modernize systems.
"To win on the modern battlefield, it's all about information collaboration," said Tod Hagan, director, ISR Software Solutions, Modus Operandi Inc., based in Melbourne, Fla. "In the past, systems that collected intelligence existed in silos, which were not good at sharing information. They were all developed with different technology and different data models. SOA has been a huge success in that area; it hides all that legacy system ugliness."
Modus Operandi, a software and information integration technology company, has used ontology modeling and semantic enrichment tools to develop a number of services within the SOA-based Distributed Common Ground System (DCGS) for the intelligence community.
Specifically, Modus Operandi is helping the intelligence community to better utilize and share information in unstructured text. "The information produced by intelligence systems today is largely unstructured text—narratives in documents, paragraphs, sentences," Hagan said. "There's a lot of information within that unstructured data that's not getting used. The problem with the DoD, and the commercial space, is there's an overwhelming volume of it. There's more unstructured data coming in than intelligence analysts can process manually; they need automation to help."
Using textual analytics and natural language processing, Modus Operandi developed a service that analyzes and parses unstructured data and pulls out events or information and alerts the analyst quickly. "Now they can process thousands of documents a day," Hagan said.
Another service Modus Operandi developed relates intelligence information and projects to other disciplines. "Now that you have all that information in a common model, what does it mean when you relate different forms of intelligence—how does this image relate to this phone call? Or you can put a speaker at a location at a given time. Fusing elements from different types of information sources is very important."
Lessons learned on SOA trail
As with all SOA efforts, there are lessons to be learned. The following are some tips and advice Hagan has gleaned from his organization's SOA work:
- Think evolution, not revolution. "We learned early on that it will be an evolutionary process. Everyone in the SOA community now realizes that. SOA is a design paradigm; it's not overnight.
- Form communities of interest. "It worked well for the DoD. Form communities of interest where you agree on the conceptual architecture and models. That lays the foundation for going forward. … You need a common model and a common vocabulary, which is challenging. These problems are often more social engineering than technical engineering."
- Agree on governance and data models before moving on. "Get the community to agree on governance and data models from the outset. That will drive the requirements for the SOA system—what does the interface look like and what are the rules for sharing. SOA is put on top of legacy systems to expose data, but often the big pitfall of these legacy systems is they're not designed for the volume they're going to see in net-centric and SOA environments. They're not designed to handle all the requests for information when they're exposed to SOA. It gets back to governance and what are the rules for sharing."
- Prioritize the most critical functions/applications/services. After deciding on the architecture and models, "identify the most important, the most mission-critical functions that need to be exposed via SOA. Often it's very atomic. For example, in the DoD it's the ability to convert from one location format to another. The DoD had 50 different location formats, so a location conversion service is a nice atomic service that can be used with other services to construct more complex services."
- Identify granular services that can be used by many. "Our textual analytic service is not specific to one community of interest. It's a granular service; you feed in a document and get extracted concepts. It's conceptually pretty simple and can be used by many people within the community."
- Recognize that not everything can be or should be shared. "The community needs to realize that different departments and different organizations have different missions, so you won't be able to share services or construct services for everything each department does. It doesn't make sense. For example, there are different services for logistics vs. accounting."
- Funding an SOA effort remains problematic. "When you form a community of interest there is a lot of reuse of knowledge, ideas, models, so there is some cost saving there. But it still continues to be an issue, how to decide how community members pay for this."
- Make stone soup. "When you form a community of interest and make stone soup, everyone contributes a little to the soup and you have larger products to show for it. No one organization can do it, and shouldn't."
This was first published in November 2010