Built for Service
WHILE SERVICE-ORIENTED ARCHITECTURES CAN DELIVER QUICKER AND CHEAPER CAPABILITIES, IMPLEMENTATION REQUIRES A MAJOR EFFORT.
Emerging as the preferred methodology of the Department of Defense for implementing network-centricity, the concept of service-oriented architectures (SOA) is attracting increasing attention from military organizations and a host of companies that want to help them put the approach into practice.
A new version of the DoD Architecture Framework (DoDAF) was released recently with changes designed primarily to accommodate descriptions of service-oriented architectures. The DoDAF, initially released three years ago, is intended to facilitate network-centric operations by ensuring that architecture descriptions could be compared and related across organizational boundaries.
A service-oriented architecture refers to an approach toward the development of applications and capabilities through the integration of loosely coupled, reusable elements. These modules, published in a directory, are drawn upon and combined by developers into packages known as services. In this way, a services orientation promotes not only interoperability and efficiency, but also the multiplication of capabilities.
SOAs rely on some relatively new technologies and methodologies, such as the Universal Description, Discovery and Integration (UDDI) protocol, which is used to publish and discover application elements and Web services in a registry. But the SOA phenomenon is not strictly a technological development.
The services created by combining reusable elements are essentially capabilities that support business or mission processes. A service-oriented architecture, therefore, is closely aligned to those processes. Further, the cultural changes characteristic of network-centricity—increased jointness and information-sharing—are present as well, perhaps even more so, in developing and implementing a service-oriented architecture.
“Traditionally, DoD systems were implemented with all the functionality they needed,” explained Fatma Dandashi, a DoDAF development leader at MITRE and a member of the DoDAF working group. “The application elements were tightly coupled so it was impossible to rely on other applications for functionality.”
From a technology standpoint, the concept of a service, in contrast to traditional applications, involves the creation of “repeatable events, like those that occur in an operating system,” according to Anthony Nadalin, an engineer and security architect at IBM. Allowing modules to be reused in services requires “protocols and standard definitions for the various components,” Nadalin added. “Otherwise they don’t mesh very well.”
But getting the most value out of a service-oriented architecture requires thinking beyond the realm of software programming, according to Mike Tiemann, chief executive officer of EA Werks, an enterprise architecture consultancy. “A service-oriented architecture is the set of things you have to do in order to implement a variety of technologies to support the business and mission,” he said. “SOA is really the merger of technology and business activities.”
The impact of a well-implemented SOA on organizational activity is that “you can change direction without having to redo the IT architecture and strategy,” said Eric Marks, chief executive officer of AgilePath, an SOA consulting firm that recently announced new contract awards with the Defense Information Systems Agency (DISA) and National Geospatial- Intelligence Agency (NGA).
Traditional applications are constrained by their stovepipes, making changes to them difficult and expensive. “With a SOA, instead, you are delivering capabilities composed of services that are more agile and fluid,” Marks noted. “It doesn’t force you to rewrite the underlying code, just the underlying process using orchestration tools.”
The whole premise, for Marks, is that SOA is a more graceful and evolved architecture that enables organizations to better adapt to and anticipate change. “By decoupling business processes from technology, you can recompose and re-orchestrate a process instead of rebuilding it from scratch,” he said. “This allows more flexibility from a mission and business perspective.”
The flexibility inherent in a services orientation also helps consumers of services, Marks contended. “The warfighter can reach back and get the capabilities he needs,” he argued. “When you expose the right kinds of services, you enable things on the consumption side based on real requirements, whether it is an answer to a question or to more quickly deliver a capability.”
NO BIG BANG
While service-oriented architectures are endorsed and promoted at the highest levels of DoD, they are being implemented on a more limited basis locally. This gradual approach is entirely appropriate, according to those with experience.
“You don’t implement a SOA with a big bang,” said Greg Black, director of eGEOINT at NGA. “Taking an iterative approach is considered to be an industry best practice. Architecture changes take a lot of time. By walking into the process, you get to learn a lot about the process while you’re doing it.”
Another reason for taking a piecemeal approach is that military services, agencies and systems are still largely segregated and still await the cultural sea change required to alter this mentality. “The motivations for causing the various services to get together and design common systems are not as strong as the motivation to remain separate,” said Tiemann. “The services remain culturally separate even through they share all kinds of functions and even though some activities could very well be centralized.”
Service-oriented architectures, therefore, are being implemented in many different and separate pockets around the military and intelligence communities. DISA, for example, is building a SOA foundation for the delivery of information security services for consumption by others with the help of Agile- Path, according to Marks.
NGA’s National System for Geospatial-Intelligence is in the process of building a SOA that enables the storage, retrieval and sharing of geospatial intelligence. The initiative began shortly after the attacks of September 11, 2001, when the need for intelligence system interoperability and net-centricity became evident, in order to promote information sharing. NGA has been working on implementing a SOA for over a year, according to Black.
The new information-sharing mentality represents a dramatic development in the culture of intelligence agencies, and spurred the development of NGA’s SOA. “Analysts’ knowledge is the sweet spot of our mission,” said Black. “The implementation of the SOA will allow analysts to share their knowledge. An opposing approach might have been to build some really interesting tools for analysts to use on their desktops. We rejected this insular and inwardly looking approach.”
NGA takes a mission-driven, as opposed to a technology-driven, approach toward development of its SOA, according to Black. “The way I like to talk about SOA is in being increasingly able to support the warfighter and intelligence communities by sharing information,“ he said, “and in developing the agility and the ability to react new and emerging needs across those communities. We also tend to say our approach to SOA is a mission-driven operational model based on an ability to share and reuse enterprise assets, data, information and analyst knowledge.”
The current focus of NGA’s SOA activities involves “expending resources in the areas of information access and visualization,” Black added. “There is not much point of accessing our type of information unless you can see it on some form of twodimensional map, or sometimes a threedimensional representation of geospatial information. In the past 12 months, we have extended exposure of the number and breadth of our data stores to customers and partners. We have been building strong momentum in that direction.”
Because NGA is now in the business of sharing intelligence, its activities to open its enterprise information doors have had effects on other areas of the military. “We have partnered with key customers, those we consider to be early adopters of a services approach,” said Black. “Some of these are specific groups inside some of the combatant commands. Another one is the U.S. Strategic Command in Omaha, which is working on a lot of interoperability and data access initiatives.”
Yet another NGA partner is the Joint Forces Command. “We are working with JFCOM to develop a joint geospatial activity, and we are particularly focused in developing the capability of getting geospatial information to areas that are bandwidth challenged,” said Black.
Critical to NGA’s SOA activities is the development and adoption of standards for information sharing and services functionality, according to Black. “There is a need to develop a common lexicon to promote interactivity with other agencies,” he explained.
To that end, NGA stood up the National Center for Geospatial Intelligence Standards to develop and coordinate data standards with other DoD, intelligence and civil agencies, as well as private industry and foreign partners. NGA has also founded the Geospatial Intelligence Standards Working Group, which last summer became a registered community of interest within DoD.
CULTURE SHIFT
The development of standards, while important, is one of the tactical aspects of implementing a service-oriented architecture, according to Warren Ellmore, president of Everware CBDI North America, an enterprise architecture consulting firm. Ellmore contends that too many organizations, including the military, for a variety of reasons neglect the strategic aspects of SOA implementation. Chief among the strategic considerations involved in developing and implementing a service-oriented architecture is an organizational culture shift. “A culture shift in enterprise architecture is challenging for many reasons,” Ellmore said. “A successful SOA at the enterprise level will be most successful when there is a level of accord between strategic management at an executive level coupled with a standards-based implementation process at the project level.”
One of the pitfalls Ellmore has noticed in SOA implementations is that there is too great an emphasis on the tactical at the expense of the strategic. “The project level is where the funding is,” he explained. “It is difficult for the enterprise level to have a significant impact on preparing an organization for change. This is a particular challenge in the government because there is such a systemic inertia in the way software gets developed. Some fundamental organizational issues do often get in the way of the enterprise adoption of a SOA.”
For Ellmore, much of the focus within the U.S. military is in improving the way existing software works together. “They are using a services approach to create better interfaces,” he contended. “I would consider that a tactical approach. But leveraging new standards to try and build common services for information sharing—that generally isn’t happening.”
While it is difficult to get large organizations to focus at the enterprise level, it is particularly difficult for the military. “The military is preoccupied and expends its energy at the funding level,” Ellmore explained. “They need fairly tactical results in order to get a continued funding stream. As a result, there is little activity going on in adopting SOA at the enterprise level as a long-term strategy.”
Beyond the challenges of implementing a services-oriented architecture, there are also several unique problems in running and maintaining them. Implementing a services-oriented architecture in some ways increases the complexity of an organization’s IT landscape. In the case of traditional systems and applications, performance issues become readily evident as they happen. They can be identified, diagnosed and treated.
Not so in the case of services, because of the complexity of the interaction among their various elements. This speaks to the need for a heightened level of governance for SOAs, according to John Emerson, vice president for federal at AmberPoint, a provider of SOA governance tools.
“Because services are loosely coupled, when things break it is not always obvious,” said Emerson. “Several different things are being done in parallel. If you click on a URL and nothing comes back, the cause is not obvious. You need mechanisms to deal with that.”
Among the services AmberPoint provides for its customers is to generate a graphic depiction of how services interoperate. “The next thing the customer wants us to do is to get an idea how the services are performing,” Emerson said. “They want to know how many faults services are generating and how available the service is. Availability is a particularly acute problem with service-oriented architectures. The basic idea is to help discover, monitor and manage SOA components.”
AmberPoint accomplishes these tasks by inserting agents within a customer’s IT infrastructure that monitor network traffic and gain visibility on how the various components interoperate.
SECURITY CHALLENGE
Security is also a challenge in a service oriented environment. Traditional IT systems authenticate users, noted IBM’s Nadalin. “When you look at users in this environment, you also have to look at services as users,” he said. “You need a mechanism to determine how services get authorized to use other components.”
Perimeter defenses are useless when organizational and enterprise boundaries and perimeters are being destroyed, Nadalin noted. “Services are crossing these boundaries and user identities must be managed across boundaries.”
Key to security enforcement in a services- oriented architecture is to institute trust management mechanism at the system- to-system, business-to-business and application-to-application levels, Nadalin said.
One of the results of a successful SOA implementation should be the reduction of functional redundancies within the architecture, according to MITRE’s Dandashi. “Different services and agencies run systems with similar functional capabilities,” she said. “The first thing is to figure out is which systems provide the same or similar functionality and then identify the best candidate within the enterprise architecture to provide that functionality. The Navy, for example, can reuse functionality from an Army system through a published interface, and then can stop using and maintaining its own system.”
In the view of many, however, the U.S. military is not at the point where it is taking a sufficiently broad enterprise view so as to implement efficiencies on such a grand scale. For Emerson, the biggest step toward an enterprise view of the defense information technology environment is the development of communities of interest.
“Communities of interest are defining capabilities and functionalities to be shared by multiple groups,” he said. “Some communities of interest have taken some baby steps in that direction. Ultimately, communities of interest are likely to be the biggest drivers in the development of services.”
A broader enterprise view is also likely to emerge gradually from the ripple effects of programs such as NGA’s, which interacts with other agencies.
In the shorter term, the military is likely to see more tactical than strategic results from the implementation of SOAs. In the commercial sector, organizations have seen savings of 20 percent to 30 percent in application development costs and 40 percent savings in their systems maintenance budgets, according to Marks.
“The numbers can add up fast considering the Defense Department spends seven billion dollars a year on information technology,” he said.
NGA’s Black acknowledges that is it still too early to realize the ultimate benefits of implementing SOAs. “NGA may be much farther along than others, but I think the jury is still out on how successful we will ultimately be.
“Although there have been a lot of success stories, a lot more needs to be done,” he continued. “The ultimate question is whether we have done our best for our partners and our users and I’ll leave the answer to that for those outside of NGA.” ♦
