Federated architecture from the ground up

The Defense Department is working to define a federated approach to enterprise architecture to tame the sprawling complexity of the military’s communications and computing systems. Although many DOD officials agree that a federated enterprise architecture is a good idea, they must first decide what approach to take.

During the past year, DOD performed a series of federated architecture tests that produced significantly different approaches to the concept. Now the challenge is to fuse them into a set of recommendations and requirements.

A DOD Federated Architecture Working Group composed of representatives from the military services met in August to develop a set of guidelines that the group plans to release later this year. Federated architecture is a divide-and-conquer approach to achieving enterprise architecture. Federated architecture recognizes that the military services — and all of DOD – are too large for a comprehensive picture of their systems that would fit within a single diagram or set of documents.

Instead, the idea is to build a master plan by creating architectures for each system development program and thoroughly documenting its interfaces with other systems. The goal of enterprise architecture is to create a set of plans that define all the elements of an enterprise and how they interact, just as an architectural plan for a home or an office building defines everything from its physical structure to its electrical and plumbing systems.

But in the military, the interlocking web of systems is so complex that the task is more like mapping the architecture of a city – or multiple cities – rather than a building. Thus, it’s helpful to think of DOD’s federated architecture as akin to the division of responsibilities among federal, state, county and city governments. In this case, the hierarchy starts at DOD’s level and moves down to each service, then to individual programs and products, with what architects refer to as tiered responsibility at each level.

Ultimately, the point is to better align the architectural planning so systems designed to work together actually do so. To accomplish that goal, the interfaces among systems should be thoroughly documented using common terms.

Brian Wilczynski, director of enterprise architecture and standards at DOD’s Office of the Chief Information Officer, said piecing together
an enterprise architecture also provides a method of identifying missing and inadequately documented pieces. “Working from a blank canvas, if we start painting in the picture, then we can start to see where all the gaps are,” he said.

Mandatory info needed
DOD has already decided that the federated approach is the only practical way for the department to define its enterprise architecture, in keeping with a mandate from the Office of Management and Budget, Wilczynski said. Systems architects are already encouraged to publish their architecture plans to the DOD Architecture Registry System (DARS), a Web-based repository of architectural documents.

The challenge is to define the minimum mandatory information that architects must record in a DARS entry. Different military services and development programs might want to maintain independent architectural repositories to support their specific requirements, but they will also be expected to share their work through DARS.

For example, the Air Force has implemented a repository based on DARS with service-specific extensions and has defined what it calls the Fit for Federation framework for how individual program architectures should fit in. The Air Force registry is designed to synchronize data with DARS.

“We wanted a single registry process and maximum reuse,” said Wing Commander Shaun Harvey, an exchange officer with the United Kingdom’s  Royal Air Force who worked on the  implementation. The value comes from improving joint forces interoperability by making Air Force architectures fit better into DOD overall, he said.

The Navy is taking a different path toward the departmentwide coordination of architectures. At the DOD Enterprise Architecture Conference in April, DOD recognized technology consulting firm Booz Allen Hamilton with the department’s first Enterprise Architecture Achievement Award for its work helping the Navy with a federated architecture pilot project. The Navy’s effort was ranked as the best of several pilot programs conducted as part of a broader DOD initiative that explored the concept of federated architecture.

“This is a way of trying to get a handle on the fact that these departments are so large and have so many architectural efforts under way that it’s unrealistic to hope to bring them under a single integrated data set,” Wilczynski said.

“The work that the Navy did in particular is helping them internally. It will allow them to get the big picture.”

The theory behind federation holds that although the most closely related programs should have tightly intertwined architectures, on a larger scale, it makes more sense to define high-level requirements, organize other architectural work around portfolios of related programs and then map the relationships among those programs.

Booz Allen Hamilton Vice President Tom Greenspon and Senior Associate Frank Brady said they found  the federation framework to be a practical approach to achieving more consistency, although in a decentralized manner.

Among other difficulties, trying to create an architectural center of excellence that has authority over the entire Navy would likely run into too many political roadblocks, Greenspon said. “It could be threatening, like you’re trying too hard to get into someone else’s business,” he said, adding that, in comparison, a federated approach is more practical and manageable.

“Federation is a methodology where as you develop architectures for various segments, you make sure to represent the enterprise in consistent, coherent ways,” Brady said. “You’re identifying the common touch points between the various levels.”

That segmented approach can be tricky, he said. “If not careful, you end up with a lot of disparate efforts, but they don’t add up to an enterprise.”

Different interpretations
Just as a plan for a city doesn’t include every detail about every building, the overarching federated architecture should be generalized. Rather than trying to model the details of specific systems, the federation is based on the theory that although systems come and go, the activities an organization performs remain relatively constant, Brady said.

The pilot project, conducted with a handful of Navy programs, worked well enough that the Navy CIO’s office is drafting a policy that would make a federation a standard requirement for Navy architecture, he said.

However, the federated approach is no cure-all, Brady said.

“I’ve run into a number of people who told me they thought federation was going to be an easy way of getting around the hard parts of doing architecture,” he added. “But you still have to have the architecture. You can’t federate nothing.”

Meanwhile, the Army has invested a little more effort in technological experimentation to support its federated architecture pilot, using a semantic wiki technology from Revelytix, a software developer based in Hunt Valley, Md., and data integration technology from Enterprise Elements, an enterprise architecture services provider, to support collaboration among architects and extract meaningful information from architectural documents.

Enterprise architecture “can be an easier sell if you broaden it more,” said Robert Damashek, chief architect of the Binary Group, an information technology company that specializes in business transformation and has been consulting with the Army on its architectural efforts.

During the pilot project, the Army tried to reach out to stakeholders other than the architects by asking service officials what questions they would like to be able to get better answers to. Those responsible for various Army missions wanted to be able to better distinguish between the long-range promises and the near-term, realistic deliverables for systems under development. “They wanted us to be able to give them the best picture of capabilities over time,” Damashek said.

The different pilot projects came up with different interpretations of federation, Damashek said. “We focused more on these Web 2.0 technologies to get people on the same page,” he said. The different pilot projects tackled “different pieces of federation, but we’re all talking about the same thing,” he said. Now, through the DOD working group, “we’re trying to come to agreement on the different intended uses of a federated architecture,” he said, indicating that he expects at least some aspects of the Army’s approach to be incorporated into the final recommendations.

Wilczynski said the variation in the federation tests was intentional “because we wanted to see what was possible. We’re in the process now of defining which concepts from the pilots we’re going to adopt for our implementation guidelines.” The trick will be to mandate enough standardization to support interoperability of architectural registries – and ultimately the systems they define – without being too heavy-handed.

For example, although in principle it might be possible to impose a single, centralized architectural registry on all military programs, it probably wouldn’t be practical. So in addition to federating the documentation of architectures, DOD is effectively applying another federation to the systems that contain that documentation, Wilczynski said.

“The emphasis is not so much on where it is or what format it is in as the fact that it’s discoverable and accessible by the organizations that need it,” he said.