These conclusions come from a new study entitled “SOA What? Who and What is Driving SOA Adoption in the Federal Government?” The study surveyed 196 government IT professionals, including those employed by the Department of Defense, the State Department and other federal agencies.
Although the report was sponsored by the Merlin Federal SOA Coalition, a consortium of SOA vendors, it does not present a rosy-eyed picture of SOA adoption in the government.
For instance, fully half of the survey’s respondents said they had never heard of Service Oriented Architecture. Of the 49% who said they had, only 70% were able to identify the correct definition of the technology.
(The correct definition was “SOA is an architecture built around a collection of services on a network that communicate with each other. The services are loosely coupled, have well-defined, platform-independent interfaces, and are reusable.”)
Government adoption of SOA appears to be the mirror opposite of private industry. A recent Aberdeen Group study reported that 90% of large enterprises have adopted or will move to adopt SOA by the end of 2006. Yet the Merlin study found that only 13% of civilian governmental IT staffers have implemented SOA; in the Department of Defense this figure falls to 8%.
“It sounds like an early market to me,” says Fred Holahan, co-founder of Active Endpoints (one of the study’s sponsors), of the lagging pace of federal adoption.
As to why government’s adoption falls so far behind, Holahan tells Datamation he isn’t sure. However, “Commercial organizations have got a more hard-driving imperative to push the business forward, and the federal government is a little more laid back in that regard.”
However sluggish, there is movement toward SOA in the government: the study found that while only 11% of SOA projects are complete, 62% are beyond the planning stages.
But a completed federal SOA project doesn’t equal a successful project. The study asked, “If completed, how would you describe the project?” The respondents reported a decidedly mixed experience:
• “Successful,” 22%
• “Partially Successful,” 50%
• “Not Successful,” 22%
• “A Fiasco,” 14%
In other words, a third of all government SOA projects were a failure – a remarkably high failure rate, presuming that federal agencies were contracting with knowledge vendors.
But this failure, or perception of failure, may be a case of federal IT staffers having inflated expectations for the projects, Holahan says. “And that’s not uncommon in early adoption cycles of technology.”
Additionally, “In other parts of the study, the respondents were clearly saying to us that they didn’t have enough skills to properly pull these projects off.” Again, he found that reflective of an early adoption cycle.
Next page: Turf wars
Asked if their agency would benefit from implementing SOA, 37% said “I do not know,” while 56% said “Yes.”
More positively, of those who have experienced SOA, 73% said they would recommend other agencies move to a SOA environment.
Among respondents who had completed a SOA project, some of the most significant challenges were: lack of established standards (38%) and lack of SOA knowledge within the agency (50%).
Also causing drag on SOA projects was an “organizational reluctance to change from the status quo” (47%). This might be classic governmental foot-dragging, or it may point to something larger. Holahan notes that the attitude toward SOA may depend on a staffer’s level in the hierarchy,
“If you’re selling to the executives in the agency who are really looking at the budget,” then the automated nature of SOA – which might result in layoffs – would be more favorably viewed, he says.
“But if you’re trying to sell to an agency that’s really got manually-intensive processes, and they’re thinking ‘Oh, my gosh, we’re going to have to lay off a bunch of people,’ you could get a different answer.” SOA’s automated nature is actually a threat to some.
The biggest obstacle to government-wide adoption of SOA is “ownership/turf battles between agencies,” according to 28% of respondents, while 20% pointed to lack of SOA knowledge in the government IT community.
Whatever the problems indicated by the study, it provided valuable insight, Holahan says. “By placing the federal government on a continuum, it gives us [vendors] instructions for the kind of help we can bring.”
For instance, “On the commercial side, maybe we wouldn’t invest in training and methodological stuff, because some of that ground had already been covered in some of the early adoptions. Whereas in the government, one of the key takeaways for us is that [training] may very well be a place where we should be investing time.”
Next page: Cost Benefit?
Another possible factor hindering federal adoption of SOA – though not addressed by the study – is that the financial benefit of this new technology is not yet specifically quantified. A SOA sales rep can’t simply say, “Your dollars spent today will save you 35% in the years ahead.”
“In the current world, I don’t think there are those sort of empirical financial considerations yet because SOA still is pretty early,” Holahan says. But SOA vendors are now working to create detailed cost benefit analysis.
Mark Zalubus, CTO of Merlin International, notes that SOA’s return on investment may take time to fully achieve. “Typically, when you create those services, especially for reuse, they tend to be a little more expensive than building an object or a service for a onetime use or for a specific purpose. Where the real benefits arise is later down the line, when there are a critical mass of services in the marketplace that can then be consumed by people with unique ideas.”
Developing a number of SOA-based services that act in concert – creating something larger than the sum of its parts – is the Holy Grail of this new technology, Zalubus tells Datamation. This could eventually take place in federal agencies. Disparate agencies, from a mapping agency to the Social Security administration, could tap into a suite of integrated applications.
Regardless of the today’s ROI from SOA, investing in this new technology is about preparing for the future, he says.
“Why would I choose to use SOA? Because the world changes.” That is, new technologies emerge without forewarning, from the Internet to PDA to wireless. This creates a challenge: “Now I’ve got these old applications, and I need to make them fit the new world…in the past we’ve been pretty stuck.”
So SOA’s payoff “may come for something in the future. And I can’t assess that at the time I build my app, but I know that the static apps that I’ve built for the last 30 years are holding me back.”
However, “If I’ve architected on a SOA and a very flexible infrastructure, I can accommodate new regulations, new technologies, and new sequencing…very easily.”