"By the end of the calendar year, our goal is to be able to expose both enterprise services and content across the enterprise," according to Matthew Swartz, branch head of Enterprise Initiatives for the US Navy. "What we are building is the ability to move information between systems. Right now not only the Navy, but across the defense department, we have a large precense of legacy applications, or applications that are currently disconnected from our network."
Swartz's remarks were part of a roundtable discussion at the recent SOA in Action conference, moderated by Dave Chesebrough, president of the Association for Enterprise Information (AFEI). Swartz was also joined by Dan Risacher, staff member with the CIO's office at the Department of Defense and Mike Darretta, JBoss solutions architect for Red Hat.
The US Navy is also taking an enterprise view of its information technology,
according to Matt Swartz. The availability of the Navy Enterprise
Portal, along with the Navy Enterprise Information System (NEIS) is
seen as a key "initial tactical step towards enabling SOA-type services
or the ability for our users in the Navy to access enterprise
services."
The various systems and portals are being integrated and federated through an enterprise service bus, he says. "We see this as one day potentially being an enterprise service bus for other capabilities or enterprise SOA services across the Navy, and ultimately connect and federate with other DoD services" he adds.
These capabilities are now delivered via two platforms -- Oracle Fusion middleware for NEIS and Microsoft SharePoint for the portal, Swartz elaborates. "We belive that the portal environment will allow us to bring distributed applications together, and also enable information sharing that not currently available to the sailor or the warfighter in these distributed environments."
As with any service orientation effort, the Navy is not immune from the push and pull of buying versus building solutions. "Right now, our acquisition approach is very program and platform centric," he explains. "What that creates in an environment at the platforms in some aspects not all of those solutions are interoperable. We identify the services and provide and implement those solutions from an enterprise perspective. But, ultimately its going to evolve to point where things are procured at an enterprise level, and no longer be part of platform implementations."
(Dan Risacher's observations on the role of SOA across the US Department of Defense can be found here in my previous post.)















I've seen some movement towards understanding SOA by the US Navy. What I can't seem to locate is the source of any push towards implementing a SOA either aboard ship, on the ground, or in the air aside from a grass roots effort. I have also seen SOA implemented within certain products like AN/TPX-42 v14 FC1 through FC3. As well as in DFS in the early 1990's. Though SOA has changed over the years people tend to forget that is has been around for quite some time. Today we tend to include orchestration in a SOA design but most publish and suscribe architectures back in the day tended to follow what we now call a SOA architecture.
Any insight as to where the SOA push is originating? Any documents regarding direction to look into SOA for the US Navy or the US Gov't as a whole?
John D Lamb
Sr Principal Software Engineer
L-3 Communications