DYNAMIC PAGE -- HIGHEST POSSIBLE CLASSIFICATION IS
TOP SECRET // SI / TK // REL TO USA AUS CAN GBR NZL
(U) Building Our House of Stone
FROM: Kevan L. Barton
Lead, SIGINT Requirements Analysis Center of Excellence (S01R)
Run Date: 04/07/2004
FROM: Kevan L. Barton
Lead, SIGINT Requirements Analysis Center of Excellence (S01R)
(U) People who have read the Department of Defense acquisition documents DoD 5000 and
CJCSM 3170 can't escape the terminology and sometimes find themselves in a mental
straitjacket just trying to figure out what the documents are saying. Folks working in a program
-- transformation or not -- are held by that same binding and may not even recognize it.
(U) One of those areas that gets confusing is the use of the term "architectures." It's not the
term itself that causes questions, but how the documents use it. It seems like a chicken and egg
problem, or even an infinite do-loop process. Thinking that the creation of new architectures is
built upon architectures, and how those architectures feed back to mature and then justify
themselves is just plain weird!
(U) The great bulk of what the agency builds, buys, or procures is IT-based in one way or
another. Therefore, it's logical that architectures are the fundamental means of communicating
the capability gap to the finders and builders of the solution to the gap. Just think in terms of
software engineering and the centricity of good designs! But, if this is truly understood, why
does DoD 5000 and CJCSM 3170 cause perplexed looks on the faces of so many involved in
engineering and acquisition? Maybe it's the problem of melding the two fields into a consistent,
well-understood process having the same goals.
(U//FOUO) SIGINT Requirement's Analysis Center of Excellence (SR ACE) stepped out a couple
of weeks ago (17-19 February 2004) and conducted a workshop on the "Analysis of
Conceptual Information Technology Based Systems." The workshop didn't attempt to
tackle all of the multi-various uses of the term architectures, but focused on them as the central
building blocks of constructing solutions that will bring the needed capabilities to NSA. The ACE
knows that program analysis is a requirement in all we do, i.e. the statutory and regulatory
aspects of conducting an Analysis of Alternatives, but recognizes the lack of knowledge and
experience in carrying out such analysis.
(U) The workshop was attended by folks from all over the United States and within the DoD
community and focused on sharing information on the methodologies, tools, process, and
techniques in assessing and analyzing conceptual IT-based systems. It also included briefs on
the expectations of the JROC and Program Analysis and Evaluation (OSD PA&E). The goal was to
bring to the NSA the best of what's out there so that our own processes can be matured and a
program analysis culture can be institutionalized. This can only increase our ability to bring
needed capability to the users more quickly and completely.
(U//FOUO) The briefs from the workshop have been posted. Do you want to know what PA&E
expects from our programs? Do you need to understand "3170" a bit better? How about
squeezing performance data out of DoDAF (DoD Architecture Framework) in ways that you'd
never expect? Do you know which DoDAF view is the central design product of any set of DoDAF
products? Or, are you simply wanting to understand the problems of costing? These are just a
few of the answers you can find. Go exploring! So successful was the workshop, that we've
already got another planned for Oct of 2004. Perhaps we'll see you there.
(U) Appropriate use and understanding of architectures are just two of the stones that build a
strong foundation for acquisition.
"(U//FOUO) SIDtoday articles may not be republished or reposted outside NSANet
without the consent of S0121 (DL sid_comms)."
DYNAMIC PAGE -- HIGHEST POSSIBLE CLASSIFICATION IS
TOP SECRET // SI / TK // REL TO USA AUS CAN GBR NZL
DERIVED FROM: NSA/CSSM 1-52, DATED 08 JAN 2007 DECLASSIFY ON: 20320108