Download the authoritative guide: Cloud Computing 2018: Using the Cloud to Transform Your Business
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 surveys 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.
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 studys sponsors), of the lagging pace of federal adoption.
As to why governments adoption falls so far behind, Holahan tells Datamation he isnt 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 doesnt equal a successful project. The study asked, If completed, how would you describe the project? The respondents reported a decidedly mixed experience:
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 thats not uncommon in early adoption cycles of technology.
Additionally, In other parts of the study, the respondents were clearly saying to us that they didnt 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 staffers level in the hierarchy,
If youre 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 youre trying to sell to an agency thats really got manually-intensive processes, and theyre thinking Oh, my gosh, were going to have to lay off a bunch of people, you could get a different answer. SOAs 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 wouldnt 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 cant simply say, Your dollars spent today will save you 35% in the years ahead.
In the current world, I dont 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 SOAs 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 todays 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 Ive got these old applications, and I need to make them fit the new world in the past weve been pretty stuck.
So SOAs payoff may come for something in the future. And I cant assess that at the time I build my app, but I know that the static apps that Ive built for the last 30 years are holding me back.
However, If Ive architected on a SOA and a very flexible infrastructure, I can accommodate new regulations, new technologies, and new sequencing very easily.