The bleeding edge By Air Force Col. (Ret.) Andy Marotta C4ISR Journal January 1, 2009 U.S defense intelligence leaders are struggling to adopt service-oriented architectures that would serve many users with a single set of applications. But improperly implementing SOA risks hemorrhaging budgets without gaining capability, warns Andy Marotta of the National Geospatial-Intelligence Agency. U.S. information-sharing policy has evolved from “need to know” to “responsibility to provide.” Military leaders are looking for ways to operationalize this new information strategy, and they are turning to service-oriented architectures, or SOAs. In a SOA (pronounced SO’-uh) approach, software applications are not stored on an individual’s computer. They are stored on a centralized Web infrastructure that numerous users can access for a variety of information services. In the private sector, this approach has saved time and money through the reuse of applications by multiple users. Unfortunately, the SOA Holy Grail has proven to be an elusive quest for U.S. military services that hope to use it to push more data into the war zones. They have been bogged down by legacy security policy, insufficient communications, stove-piped storage strategies, outdated acquisition processes and underinvestment in human capital. If the Defense Department does not coordinate its SOA activities and invest in the storage and communications systems they require, SOA could become a bleeding-edge technology that would hemorrhage any real return on investment. SOA systems would be cost multipliers instead of force multipliers for the war-fighter information technology (IT) enterprise. The Pentagon’s interest in SOAs is laudable and promising. Numerous SOA success stories can be cited in the business sector. EBay’s SOA manages 2 petabytes of data, or 200 times the information contained in the Library of Congress. IBM trimmed its inventory of 16,000 software applications in 1998 to 4,000 applications today.   So what does SOA strategy buy the intelligence world? SOA promotes two key advantages over traditional IT approaches: software reuse and agility. Because the software is maintained at one location, IT experts can easily upgrade it or fix it. There is no need to travel to the field or send out software updates. If there is a downside to SOA, it is that developing the ability to reuse applications requires sizeable upfront investment and establishment of maintenance teams. “Our calculation is it’s about 2.5 times more expensive to make something reusable as not,” Ian Koenig, senior vice president of Thompson Financial, told an audience of software experts, according to the online magazine Application Development Trends. A SOA requires multilevel security, content discovery, help-desk functions, and net-operations monitoring. Costs can be driven through the roof if the investment is not spread over a large user base. A SOA may not be right for every type of user. A service-client architecture may be more efficient in an organization with a low number of users. “You really shouldn’t be looking at revamping your architecture if you don’t have a dynamic business with lots of change,” said Comcast CIO Andy Baer in a 2007 interview with the Web magazine CIO.com. Some Defense Department users might not need a SOA. But by and large, the military certainly fits the model of a dynamic enterprise, and today’s threat environment is anything but a static replica of the Cold War past. So why has SOA implementation across the Defense Department stumbled out of the blocks and not kept pace with the business sector? In short, the Defense Department has mistaken an embrace of SOA for establishment of an end-to-end war-fighting information superiority capability. As Baer warns, SOA is not synonymous with creation of such an architecture. “SOA is an enabling technology, but it is not enterprise architecture,” he told CIO.com. “I don’t think of technology and tools. I think of billing, ordering, customer service.” The Defense Department would benefit from adopting Baer’s approach and basing SOA development on the war fighter’s mission architectures. For example, in the areas of intelligence, operations, and command and control, key military mission requirements should be the lens through which the Pentagon crafts a vision for leveraging SOA’s key advantages of reuse and agility. Mission effectiveness across intelligence, C2 and operations must be the driving force behind architecture investment, and serve as the metric for gauging SOA success. Understanding the mission architecture enables SOA developers to select the best enterprise SOA strategy. Intelligence users may prefer a centralized approach to enhance security, but this strategy may not be scalable enough to deal with a large number of highly mobile operational units and weapons systems. The challenge is finding a SOA strategy that supports the mission architecture across intelligence, operations and C2. A SOA is powerful, but there must be an adequate communicationsand storage infrastructure surrounding it, and a staff of SOA-smart experts to maintain it. Unfortunately, no single government organization controls the resources for creating an end-to-end information superiority capability. For example, one of the four military services might be responsible for an aircraft mission-planning system, but the National Geospatial-Intelligence Agency would be responsible for producing aeronautical data and products, and the Defense Information Systems Agency would be responsible for providing the communications and data storage pieces. Inadequate governance and policy when funding large information systems of systems across multiple Defense Department entities results in disconnected fielding of SOA-based capabilities. Military commands, the services and agencies end up investing in their own independent SOA capabilities, which can leave them with SOA stove pipes that do not leverage reuse. Information-sharing policy developed during the “need to know” era can also limit the cost savings of applications reuse. It confines SOA to narrow communities of interest. Examples of this would be analysts working within restricted intelligence security domains or a U.S.-only C2 network at a coalition headquarters. Information-sharing policies in some coalition scenarios must be modernized to allow SOA services to support mission architectures across multiple communities and across the war-fighter IT enterprise, especially intelligence, C2 and operations. Multilevel security capabilities are key enablers for further leveraging reuse; however this technology is not fully mature. Lack of multilevel security capabilities combined with legacy information-sharing policy ultimately leaves war fighters with domain-centric information stove pipes that require numerous, expensive SOA instantiations. Another impediment to bang for the buck occurs when organizations focus on SOA implementation to the exclusion of the rest of the IT enterprise consisting of user interfaces, services, storage and communications systems. This can drive unanticipated costs to other parts of the IT enterprise. When SOA developers work only the services portion of the enterprise, they do not factor in the impact of SOA on the rest of the IT architecture, especially the impact on data storage and communications bandwidth. We will not have gained anything from our SOA investment if we increase the demand for services but drive the IT enterprise to its knees due to inadequate bandwidth or a poor storage strategy. Agility can also be a double-edged sword for Defense Department SOA implementation. SOA strategies enable loosely coupled services to be rapidly added, deleted or changed without interfering with the rest of the IT enterprise. This agility to quickly adopt new services in intelligence and C2 systems is certainly a desirable capability and can aid in reducing decision cycle times for commanders. However, once a commander’s intent is disseminated, operators must execute the order. To take full advantage of the agility offered by SOA, the Defense Department would need to make legacy weapons SOA-enabled so they would adopt new services as quickly as intelligence and C2. Tactical weapons systems need to plug and play with C2 and intelligence systems at the strategic, operational and tactical levels. Most weapons systems in the U.S. inventory are costly to modify and do not lend themselves to rapid technology insertion because they rely on low production, proprietary information systems that are not software reprogrammable. Redesigning the IT backbone in thousands of legacy platforms such as the 50-year-old B-52 would be time-consuming and cost-prohibitive. Acquisition strategies such as “adopt, buy, create” have enabled the C2 and intelligence communities to successfully adopt commercial hardware and software. But integrating commercial off-the-shelf hardware into legacy weapons systems is not as practical today. There are just a handful of future weapons systems ready for delivery with software reprogrammable backbones. The challenge will be to develop responsive acquisition processes that enable legacy and future weapons systems to adopt commercial semiconductor best practices. Failure to address this acquisition reform will result in a widening gap between the IT maturity in intelligence-C2 systems and operational weapons systems, which ultimately would reduce SOA impact on combat effectiveness. There also is an urgent need for more skilled personnel to support enterprise-level SOA development and implementation. Staying one step ahead of Moore’s Law and the lightning-fast pace of change in IT hardware, software and communications has proven to be a formidable task for software development staffs. Beyond that, there is an emerging shortfall in the number of data subject matter experts or data stewards. Very few people understand data models, metadata and production standards, which are necessary components of enterprise-level data management. The advantages of investing in SOA can quickly erode if data is not considered as part of the SOA strategy. Data that is not produced to an enterprise standard requires additional processing before it can be application ready. Nonstandard metadata tagging reduces search-and-discovery effectiveness. Poor data model development and tuning induces sub-optimal database performance. To maximize the advantages of SOA, the Defense Department will require more highly trained strategic thinkers at the juncture of IT expertise and data expertise. The Defense Department’s SOA advocates should focus attention in five areas in their quest for the SOA Holy Grail. First, key organizational mission requirements should drive a capabilities-based IT architecture and SOA development. Long-term cost reductions and ease of maintenance should be ancillary benefits. Second, SOA development cannot be done in a vacuum. DoD should use balanced investment strategies across the entire war-fighter IT enterprise of user interfaces, services, storage and communications. Third, achieving return on investment from SOA implementation will necessitate collapsing the number of security domains and busting apart organizational stovepipes through governance and policy reforms that target programmatic and information sharing roadblocks. Fourth, acquisition reform is crucial to enable legacy weapons systems to quickly integrate commercial off-the-shelf technology. Those reforms are necessary if operations are to keep pace with intelligence and C2 SOA advancements. Finally, the Defense Department must address the shortage of skilled, strategic-level IT architecture specialists and an even bigger gap in the number of data stewards who understand data management and its impact on the IT enterprise. Net-centric capabilities and SOA-enabling technologies add complexity and risk to war-fighter systems. Firewalls, communications outages and corrupt data can reduce mission effectiveness. Tracking down the sources of these problems can often be next to impossible from thousands of miles away if the SOA infrastructure does not encompass an end-to-end information superiority capability. Will SOA be the Pentagon’s Holy Grail or a bleeding-edge technology in the global war on terrorism? The answer depends on how it decides to use SOA enabling technologies. The overarching vision should never be to implement a SOA. SOA must be developed as part of a capabilities-based war-fighting mission architecture with adequate data storage, sufficient communications bandwidth and a sound data strategy. SOA strategies must be interoperable across intelligence, C2 and operations or we risk leaving warfighters with little advantage on the battlefield and skyrocketing SOA startup costs for multiple communities of interest and security domains. Leveraging SOA-enabling technologies to enhance war-fighter information superiority is perhaps one of the most daunting tasks facing the military today. Retired Air Force Col. Andy Marotta is the technical executive in the office of military support at the U.S. National Geospatial-Intelligence Agency. (Archives)