Federation of Architectures

The Department of Defense is seeking enterprise IT views
in order to reduce costs and optimize efficiency and investment.

By Peter A. Buxbaum
 

The ultimate goal of the Department of Defense’s IT strategy is to unify networks, systems, functions and data into a single, integrated enterprise. The linchpin of that strategy, the Global Information Grid, is being designed to make information accessible whenever and wherever it is needed.

The GIG is envisioned as a singular entity through which data can flow to become available to and understood by all who are authorized to view it. Actualizing that dream requires that DoD IT acquisitions conform to prescribed standards in order to assure the interoperability of services and the utility of data.

DoD is attempting to accomplish that goal by developing enterprise architectures—descriptions of organizations and systems through which planners can map their IT strategies and acquisitions. The goal is to make sure that acquired systems comply with established standards, organizations are in synch with other portions of the enterprise, and economies can be achieved in areas of overlap where resources can be shared.

But the size of DoD and the diversity of its missions make it impossible to describe the department within a single integrated architecture. That is why DoD has adopted a strategy of federating architectures, having the various services and defense agencies develop their own and then finding ways to connect them.

Various forms of enterprise architectures have been sprouting across DoD, all of which take their inspiration from DoD’s GIG Architecture Federation Strategy, which was released last August by Assistant Secretary of Defense for Networks and Information Integration/Chief Information Officer John Grimes. Each is designed to help decision-makers better position IT initiatives within the context of the GIG.

At the acquisitions level, enterprise strategies are in evidence in the procurement of IT systems. That is the case with a recent solicitation from the Office of the Secretary of Defense, which is letting a contract to consolidate IT acquisitions across the 14 units of that organization. At the strategic level, such an endeavor will have to refer to enterprise architecture concepts.

Mandatory Blueprint

Developing and referring to architectures is not optional within DoD, but is mandated by congressional legislation and DoD directive. The Government Accountability Office, the congressional watchdog agency, in the past has found fault with organizations that deviate from that norm.

Earlier this year, for example, then-Comptroller General David Walker blasted an Army decision to invest $5 billion in its General Fund Enterprise Business System, Global Combat Support System-Army Field/Tactical and Logistics Modernization Program. The Army’s approach “did not include alignment with an Army enterprise architecture,” Walker told Congress. The Army “runs the risk of investing significant resources in business systems that do not provide the desired functionality and efficiency,” unless it updates its investment management approach to include a high-level enterprise view of the capabilities being sought, he contended.

“An enterprise architecture is like a blueprint for a house,” said Dennis Wisnosky, chief technical officer and chief architect for the business mission area at DoD’s Business Transformation Agency. “You want to have various views of the house so that the plumber knows where to put the pipes, the electrician knows where to run the lines, and the family is happy with how it looks from the street.”

That is why, for an enterprise architecture to be complete, it must encompass more than one view of the organization, explained Eric Marks, chief executive officer of AgilePath, a consulting firm. “An enterprise architecture should include all of the associated logical and physical views of the enterprise,” he said. “The classic views include the business architecture, the information architecture and the technical architecture.”

“The best first step is to develop the business architecture,” according to Lieutenant General Pete Cuviello (Ret.), a former CIO of the Army who currently serves as a senior strategist at BearingPoint. “This describes what business processes and functions you have ongoing, and ideally how you would like them to work.”

“Typically, the architectures describe the current state of affairs as well as where the enterprise wants to go,” said Marks. “They describe how to build solutions to the new architecture, including details of industry and DoD standards to comply with as well as governance requirements.”

All of this is to help decision-makers and acquisition officials understand “how the organization is physically structured and arranged and how to align policies and organizational resources in order to implement different kinds of capabilities,” said Mike Tiemann, chief executive officer of EAWerks, an enterprise architecture consultancy. “When systems and technologies are built, they are then hooked into this overall approach.”

Getting from the current state to the desired state requires a migration plan. “It is a long process to make legacy applications into services, separating data from applications and applications from hardware and devices,” said Marks.

Such a process involves a continual “molding of the operational architecture,” said Cuviello, adding that the implementation of systems in accordance with a systems architecture must be done “when you can do it and when you can afford it.”

Navy Enterprise

The Department of the Navy decided to tackle its part of the effort toward developing the GIG by introducing its “enterprise architecture management view” earlier this year. Rather than strive for a unitary enterprise architecture (EA), the management view seeks to create relationships among existing and divergent DON architectures and to maximize the reuse of their common components.

“The DON EA management view is a categorization of DON architecture projects aligned to DON goals and objectives,” a document outlining the view noted. “The primary goal is to create a centralized resource that captures domain-level architecture efforts across the DON.”

A domain is defined as a comprehensive mission area such as warfighting, business or infrastructure.

“The ultimate vision is to use the document as a decision support tool,” said Michael Jacobs, DON’s chief technology officer. “It is a guidepost for management decisions and not an end in itself.”

The management view’s approach to a federated architecture involves cataloging departmental architecture development to allow relationships to be identified and built. “It will be used to understand architecture information as it is developed across the department, how they relate to different missions and functions, and how they align to DoD architectures across the GIG,” said Jacobs. “Then we can make determinations about where there might be gaps or overlaps in architecture development.”

A key element identified by DON as part of the architecture federation process involves maximizing the reuse of existing architecture components. Common architecture elements include technical standards, mission areas, business processes and data taxonomies. “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,” Jacobs said. “If a core element is missing from a DON architecture, we will put a process in place to allow those gaps to be filled.”

BTA’s Wisnosky is in charge of DoD’s Business Enterprise Architecture (BEA), which along with warfighting, intelligence and infrastructure is one of the four domain architectures within the department.

“The purpose of the Business Enterprise Architecture is to constrain investment,” Wisnosky said. “Before an agency is allowed to spend allocated money on an IT investment, it must show that it is compliant with the enterprise architecture.”

A fourth major iteration of the BEA is scheduled to be delivered early next year.

The BEA has progressed through its versions by moving from an emphasis on functions and activities, to establishing authoritative sources of data, to building and delivering capabilities. The latter two characteristics, especially, come to promote service-oriented architectures, an approach through which capabilities are developed by integrating loosely coupled, reusable elements such as software functionality and data.

“Credentialing is a good example of how enterprise architectures can direct technology investment,” said Wisnosky. “All systems do authentication and access control. That is something that could possibly be done better by deploying the Defense Information Systems Agency [DISA] service that provides centralized single sign-on to systems. A user can move from one system to another to gather information, with each authenticating his credentials using the DISA service while, to the user, it appears as if he never left his departmental system.”

Net-Centric Solutions

One attempt to develop an enterprisewide technology infrastructure is ongoing within OSD, which earlier this year released a solicitation for its CIO Net-Centric Solutions (CINS) program. OSD is currently evaluating contract bids.

The request for proposals envisions the award of two contracts—one, with a spending ceiling of $450 million, on the basis of open competition, and the second, capped at $50 million, as a small business set-aside.

The first contract is designed to procure services in the areas of customer support; systems operation, administration and maintenance; engineering services; applications development, maintenance and support; and business continuity. The second contract will include task areas involving information assurance and CIO mission support. The scope of both contracts includes procurement of IT hardware, software, licenses, maintenance and support products. The solicitation envisions a base period for the contracts of 24 months beginning in July, with three additional 12-month option periods.

Although the solicitation has been touted by some for its enterprise architecture attributes, its true nature involves more nuts-and-bolts IT procurement than in developing strategic views. Still, an enterprise architecture is implicit in the approach taken by OSD.

“The title of the program is something of a misnomer,” said Tom Greenspon, a vice president at Booz Allen Hamilton. “It gives the contract a super DoD-wide architectural flavor, but in reality it is just inside the Pentagon and the actual work being sought is for IT services support. OSD has evolved into many stovepipes, and this vehicle has been put in place in an effort to streamline IT procurement and to reduce redundancy.”

“Although the announcement didn’t say much about enterprise architectures, what they appear to be trying to do is to establish a common set of capabilities drawn from an architecture-driven plan,” said EAWerks’ Tiemann. “It would normalize a lot of technology and take a standards-based approach to service offerings through the various technology layers.”

At the core of CINS is the consolidation of acquisitions among the different units within OSD.

“Back in 2005 they realized that OSD operated in 14 different fiefdoms or domains, each one going out and buying IT services, telephones, BlackBerries and networks, and all of the maintenance contracts that go with them,” said Cuviello. “The DoD CIO realized this was not his bailiwick, so he gave the OSD CIO the challenge to start organizing contracts and getting to the point where they could start taking a federated approach to IT.”

In essence, CINS takes all OSD IT procurements and places them under a single umbrella. “They will be replacing technology over time,” said Cuviello. “And they will immediately start standardizing and moving towards a more federated number of systems, processes and technologies. They can’t afford to blow everything up and replace it.” The approach taken in the solicitation is “the easiest and most sensible thing to do,” he added.

A federated approach to IT procurement within OSD would involve breaking down the walls that separated the fiefdoms and domains that have acquired technology separately until now. “Maintenance contracts will probably be an early target of the program,” said Cuviello. “They will start moving from many contracts and toward just a few.”

The consolidation of communications systems also represents some potential early successes for the eventual CINS contractors. These kinds of improvements will help move OSD along toward the implementation of enterprise applications and systems, according to Cuviello.

Shared Capabilities

Cost savings top the list of potential improvements to be achieved through the CINS contract, Cuviello said. “The second one is operational efficiency. The ability to implement large functional processes and business systems is a whole lot easier and a lot more efficient when you are starting from a common baseline.”

“It is more difficult to control costs when you have various capabilities and entities being supported by multiple contracts and vehicles,” Tiemann observed. “The more diversity in your technology base, the more costly it becomes. But what they are ultimately trying to do is to improve their capabilities.”

The consolidation of acquisitions across OSD implies that decision-makers will have access to enterprise views that will enable them to acquire systems and capabilities that coordinate with the overall plan, said Booz Allen’s Greenspon. Although the solicitation does not call for a great deal of strategizing, Greenspon believes that some architectural work is baked into the approach being taken by OSD.

Such a strategic view could involve baselining of existing missions and functions as well as benchmarking against relevant peer groups to identify best practices. Checking for gaps and redundancies in capabilities will help acquisition officials decide which capabilities need to be acquired and which can move to a shared environment.

“That can be the most threatening aspect of this process to an organization,” said Greenspon. “A group used to having dedicated capabilities and support may feel uneasy about the transition to a shared capability. Managing change and especially the human dynamic is key to this process. It must be done one step at a time.”

Sharing capabilities also means that some units may have to forgo their legacy systems in favor of the new, shared ones. This represents another human aspect to the change that needs to be carefully managed, noted Cuviello.

In general, Greenspon said, the concept and discipline of enterprise architecture has been moving in recent years, from a compliance focus to a strategic focus that attempts to solve business problems. The compliance approach to enterprise architecture was designed to make sure that an organization was aware of all of the systems and applications it had deployed, and that they conformed to certain standards.

“The goal of compliance-driven architecture was often more in the nature of a checklist,” Greenspon explained. “It was important to have a full picture of everything out there.”

A more advanced approach, which DoD is striving towards, seeks an enterprise view that will enable decision-makers to pinpoint areas of required investment within budgetary constraints.

“Just knowing what is out there doesn’t give you insight into potential solutions to problems,” Greenspon explained. “Sometimes compliance architects work in a vacuum and create a disconnect between programming and the IT budgeting process. It is important to have those two tightly coupled in order to discover investment opportunities and to do so in synch with the budget and priority processes. Too often people are working only on their little piece of the puzzle. We think that this is suboptimal.

“We feel it is important to understand the relationship between architecture programs and IT investment programs,” he continued. “Architectures can yield great insights and using architectures can be an effective tool to foster investment decisions. The blending of these two disciplines can really be a critical aspect to making progress.” ♦