The Navy Department’s enterprise architecture management view is modeled on the Global Information Grid Architecture Federation Strategy, which the assistant secretary of Defense for networks and information integration released in August.
Developing an enterprise architecture presents an inherent challenge, according to that strategy document.
It notes that architects typically try to represent complex information as simple constructs that don’t lend themselves to meaningful decision-making, or they compile massive amounts of data that make comprehension difficult at best.
“One of the primary objectives of enterprise architectures is to describe the enterprise so that decision-makers can make informed decisions,” the GIG strategy document states. “Architects, therefore, must constantly balance complexity with utility.”
The Defense Department’s approach to the GIG is to use current architecture efforts and give DOD decision- makers the information they need to make future IT decisions.
“Federating existing architectures allows disparate architectures to be meaningfully related,” according to the GIG strategy.
— Peter Buxbaum
The size of the Navy Department and the diversity of its missions make it impossible to describe the service in a single integrated architecture.
That appears to be the subtext of an enterprise architecture document that the Navy’s chief information officer released last month.
The enterprise architecture should help decision-makers position technology initiatives within the context of the Global Information Grid (GIG), the document states.
The document introduces the concepts of architecture federation and management view. The management view shows relationships among existing and divergent service architectures and maximizes the reuse of common components, the Navy document states. The new enterprise architecture presents a federated approach to architecture, following the lead of a Defense Department document released over the summer.
“The ultimate vision is to use the document as a decision-support tool,” said Michael Jacobs, the Navy’s chief technology officer. “It is a guidepost for management decisions and not an end in itself.”
The Navy intended for the document to be one that executives, managers and decision-makers primarily use, Jacobs said.
The Navy’s enterprise architecture management view categorizes architecture development and positions related to architecture efforts for federation into a larger enterprise view, the document states. “As a result, [Navy] decision-makers will be better informed and able to make more accurate and timely decisions.”
The management view’s approach to a federated architecture involves cataloging departmental architecture development so that users can identify and build relationships.
The management view “will be used to understand architecture information as it is developed across the department, how it relates to different missions and functions, and how it aligns with DOD architectures across the GIG,” Jacobs said. “Then we can make determinations about where there might be gaps or overlaps in architecture development.”
The Navy identifies two key elements as part of the architecture federation process: maximizing the reuse of existing architectures and shifting from the product-centric approach of the Defense Department Architecture Framework to a data-centric architecture approach focused on common semantics.
Jacobs compared the architecture effort to the development of a city plan, in which multiple buildings are built separately but to the same set of standards and inspection criteria. “Our effort will allow common core architecture elements to be identified so that architecture efforts can be aligned to those same standards,” he said.
Common architecture elements include technical standards, mission areas, business processes and data taxonomies.
“If a common core element is missing from a [Navy] architecture, we will put a process in place to allow those gaps to be filled,” Jacobs said. “We will also create efficiencies by allowing common core elements to be reused in different architectures so that they don’t need to be created from scratch every time.”
