Pick up an Information Technology (IT) strategic plan from virtually any organization today and you will read statements like "our goal is to migrate from the current multitude of separated systems toward a single, integrated, system capable of ... we will provide users with a secure network environment allowing them to access shared data and applications, regardless of location ...the right information anytime, any place!" Interoperability and information assurance are major objectives of IT, and it is enterprise architecture that will provide the analytical methodology that will let us 1) explicitly visualize the obstacles along our path, and 2) make the right decisions to effectively attain our mission capability objectives.
Consider This Situation
In reference to the development of a Command, Control, Communications, Computer and Intelligence Support Plan (C4ISP), required for the acquisition milestone decisions of a major new weapon system, a Program Manager (PM) asked, "How can I develop the Information Exchange Requirements (IER) for my system (as specified for the C4ISP), if I don't know who I will be exchanging information with?" This doesn't seem possible. A multi-billion dollar defense program, and we don't know who's talking with whom? After subsequent discussion though, what the PM was validating was really the "case" for enterprise architecture.
With enough resources and fortitude anyone can roll up their sleeves and get on with the business of collecting the data that comprises IERs for systems existing today. It's pretty much an exercise in due diligence as described in the Department of Defense (DoD) Architecture Framework. You're a program manager and you know how your particular system exchanges information within the context of the System-of-Systems (SoS) or Family-of-Systems (FoS) in which you currently operate. Documenting these IERs in C4ISP format may be a bit time consuming, but you can collaborate with other affected PMs and gather the information with whatever tool you're comfortable with and be done with it. What you have then is a static snapshot of your system's IERs (and hopefully, what is needed to satisfy interoperability and information assurance requirements).
Interfaces Under Development
But now let's think about a major DoD weapon system that won't be delivered for seven years or more. Consider directing this PM with the challenge: "Document all of your IERs." OK - they know how their system is going to work seven years from now because the program is "spec'ed-out", and it's under configuration management. Cost, schedule, performance changes as the program moves through the Programming, Planning, and Budgeting System (PPBS)? No problem. The PM is right on top of it. But what about the other programs that are similarly evolving over time and with which this system plans to exchange information? Our PM has no control over these, yet they too are subject to the perturbations of the PPBS. How will programmatic changes within these future SoS/FoS be collectively assessed for their unforeseen impact on IERs and the resultant mission capability that these major acquisition are expected to provide?
Clearly, we have a case for enterprise architecture and specifically, robust tools to support its development and analysis. From the example presented here, we have a requirement to document existing and evolving systems in a centralized repository that authorized managers can use to ensure that the interoperability and information assurance thresholds established early on in the development of warfighting capability are, at a minimum, maintained when the systems comprising that capability go into operation years later.
The DoD Architecture Framework
The DoD Architecture Framework provides a construct for fully documenting the details of an IT system, as well as its inter-relationship to a SoS and FoS. The Framewor