Category Archives: work

The ’90s called, they want their C&A process back

michael-douglas-wall-street[This is mirrored on Intelink-U]

In a previous post, I traced through the various policy documents that describe the certification and accreditation processes for the Department of Defense, ultimately tracing back to OMB Circular A-130.  In summary, “systems” need accreditation, while “applications” do not, and the distinction (per A-130) turns on the highly subjective decision of whether it is a “major” application.

In tracing this definitional tangle, I unwittingly provided a roadmap for how to get your system “application” on a DoD network without a full-blown Approval To Operate (ATO).  I was not trying to  provide an easy-out for getting operational without being accredited … although the method is a well-trodden path with a lot of history.  I’m was trying to show that our C&A policy is at-least-slightly broken, and we generally don’t even understand it ourselves.

Again, to summarize, this is what not to do:  Continue reading

Case Study: Defense Connect Online

[mirrored on Intelink-U][followup to this post]

The Mystery of the Missing Service Provider

In the Defense Department, there is  a web-conferencing service called “Defense Connect Online“.  Until about two weeks ago, no one was responsible for providing this service.  DCO is a finalist for the 2013 awards, and no one was responsible for providing the service.  (i-kid-you-not)  This service has 800,000+ registered users, and there were over a half-billion user-conferencing-minutes used last year across the DoD.  It is a huge success, especially in an era of declining budgets and severe travel restrictions.  People love it, and they hate it too.  They love it because it helps them do their jobs.  They hate it because they see how much more it could be.  Even the people who criticise DCO, (and there are such) do so because they absolutely need the capabilities it provides them, and they wish it did more.

How could this be?

Continue reading

Case Study: cASM

[Mirrored on Intelink-U]

Here’s another story about buying systems without a clear concept of who is going to operate it:

I was at my neighborhood spaghetti dinner and I happened to sit across from some guy who – it turns out – also works for OSD.  He’s a contractor working for OUSD(AT&L) on a system that he was quite enthusiastic about called “Contingency Acquisition Support Model (cASM)”.  (I have no idea why they capitalize it that way.)  This system, cASM, is a web-based application designed to assist people responsible for initiating contracting requirements in an contingency or expeditionary environment.  I understand it as workflow automation for contracting in a crisis.

Since I’d been thinking about this a lot, I immediately asked him, “Who is going to run it?”  and he said, “Oh, it’s hosted by DISA.”

I tried not to choke, and said something like, “That’s not what I meant.  Okay, DISA hosts it, but who is going to run it?”

Continue reading

Case Study: ERPs

This is the one of several posts to illustrate the difference between “acquiring a system” and “providing a service”, that I raised in a previous post. [Intelink-U cross-post]

Several  years ago (~2006), I was on three peer-review-teams for big DoD ERP implementations (DEAMS, GFEBS, and IDE-GTN Convergence)

These “ERAM” reviews had a bunch of process and structure, but the important thing was that we had a team of smart folks do several days of on-site interviews with involved personnel:  we interviewed everyone from the 3-star sponsor to the GS-9 users, the contracting officer, the gov’t Program Manager (PM), the Program Executive Officer (PEO), the chief engineer, the contractor’s PM, the software jocks writing the code, and anyone else we could think of.

OriginalNipperOne of the questions I remember asking folks in the PMO (Program Management Office) was this:  “When you are done building this system, who is going to operate it?”

Generally, when we asked this question, we would get a puzzled, head-cocked-to-the-side look, like the RCA dog.

Continue reading

Requirements at the wrong level of detail

[This is a repost of my 30 Nov 2012 post on Intelink-U]

I just got tasked to review and comment on the UCR 2013. (That’s “Unified Capabilities Requirements 2013”, for the uninitiated.)

It’s 916 pages. I was given 2 weeks.


Another needed change is common documentation in all three processes and, at the same time, reducing considerably the number of pages and reviews of the common documents. An example of how the requirements process should be simplified and streamlined is found in a statement by an Air Force Vice Chief of Staff: “Our long-range bomber is a great example. The requirements document left the Air Force and in a short period there were so many additional items hung on the platform it was quickly unaffordable. The requirements document had grown to over 1000 pages. We really needed the aircraft so three senior leaders sat down and re-wrote a three page requirements document that could not be changed without the approval of the SECDEF.

(emphasis added)

Continue reading

Buying systems vs. providing services

[Intelink-U mirror]

lightbulb moment

I’ve had a “lightbulb moment” about the problem with the acquisition of IT systems in the Defense Department. The flash was so blinding that several of my co-workers have now filed for disability benefits.

Like most blinding-flashes-of-the-obvious, the insight was that the question was wrong.

Let me lead up to it: Beth McGrath (the DoD Deputy Chief Management Officer) famously testified to Congress:

Our current approach to implementing IT systems takes too long, costs too much, and often fails to deliver the performance improvements we seek. On average, it takes 81 months in DoD from when an IT program is first funded, to when it is fielded. Given the rapid state of improvement in the IT field, this means that we are delivering systems that are outdated before we ever turn them on. In contrast, the iPhone took two years from concept to delivery. It is clear that we need a different approach.

DoD personnel are completely fascinated by, and oriented towards, buying systems. Here’s the problem: in today’s world, most IT systems exist to implement a service.  There are not even words in our government lexicon for this; it is hard to even ask the right questions. A “system” is just a tool. It exists to make some task easier or possible. Operating an IT system is often complicated; it requires specialized expertise and there’s more to providing a service than is immediately apparent.  By itself, the operation of an IT system could be a service, but really it’s the mission function that the system enables that is the actual service being provided. “Running ATAAPS” (Automated Time and Attendance Production System) is a service, but it’s not running the software application that matters – the real service is timecard processing and reporting.

Continue reading

System vs. Application: when is C&A required in DoD?

[This is a repost of my 9 Nov 2011 post on Intelink-U]
[There is a follow-up post]
[There is an update]

Suppose you are responsible for developing a network-based application for the DoD. Your team has cobbled together (i.e “integrated”) off-the-shelf components into a cool tool that meets a mission need of your agency or component. You intend to host and operate this application out of a datacenter somewhere on the GIG. Do you need to go through full-blown Certification & Accreditation… having a DAA, IATT, IATO, ATO?

Let’s see what the policies are:

DoDI 8510.01, “DoD Information Assurance Certification and Accreditation Process (DIACAP)” establishes that it is DoD policy that we shall certify and accredit “ISs” (Information Systems) through … yadda yadda yadda. It goes on to define “Information System” as “See Reference (d)”.

Reference (d) of 8510 is DoDI 8500.2 “Information Assurance (IA) Implementation”. It defines “DoD Information System” as:

“Set of information resources organized for the collection, storage, processing, maintenance, use, sharing, dissemination, disposition, display, or transmission of information. Includes AIS applications, enclaves, outsourced IT-based processes, and platform IT interconnections (NSTISSI No. 4009, reference (c) modified to include the four DoD categories).”

DoDI 8500.2 defines “Automated Information System (AIS) Application” as:

“For DoD information assurance purposes, an AIS application is the product or deliverable of an acquisition program, such as those described in DoD Directive 5000.1. (reference (u)). An AIS application performs clearly defined functions for which there are readily identifiable security considerations and needs that are addressed as part of the acquisition. An AIS application may be a single software application (e.g., Integrated Consumable Items Support (ICIS)); multiple software applications that are related to a single mission (e.g., payroll or personnel); or a combination of software and hardware performing a specific support function across a range of missions (e.g., Global Command and Control System (GCCS), Defense Messaging System (DMS)). AIS applications are deployed to enclaves for operations, and have their operational security needs assumed by the enclave. Note: An AIS application is analogous to a “major application,” as defined in OMB A-130 (reference (v)); however, this term is not used in order to avoid confusion with the DoD acquisition category of Major Automated Information System (MAIS).”

OMB A-130, Appendix III, defines “major application” as:

“a use of information and information technology to satisfy a specific set of user requirements that requires special management attention to security due to the risk and magnitude of harm resulting from the loss, misuse or unauthorized access to or modification of the information in the application. All applications require some level of security, and adequate security for most of them should be provided by security of the general support systems in which they operate. However, certain applications, because of the nature of the information in them, require special management oversight and should be treated as major. Agencies are expected to exercise management judgement in determining which of their applications are major.”

So, pulling the thread:

Policy says you gotta C&A an Information System. Information System is one of 4 things: AIS applications, enclaves, outsourced IT-based processes, and platform IT interconnections. In the scenario I presented above, you obviously aren’t an enclave, an outsourced IT-based process, or a platform IT interconnection. So, are you an AIS application? Definition of an AIS application says that it’s the deliverable of an acquisition program… you’re not that… but it also references the OMB Circular A-130 definition for a “major application”, which it defines as “requiring special management attention to security due to risk…” It further notes that agencies are expected to exercise judgement in determining which of their applications are major.

So, reasonably, if your program is not the output of a 5000.2 acquisition program, nor does it require special management attention due to risk, then it isn’t a “major application”, (in A-130 speak) so it isn’t a “AIS Application” as defined by 8500, and therefore isn’t one of the four categories of “Information Systems”. If you aren’t an Information System, then C&A doesn’t apply to your thing-that-isn’t-an-IS, per the “APPLICABILITY AND SCOPE” section of DoDI 8510 (although it would apply to the enclave where your application is hosted.)

I had this conversation with Eustace King once, (at the time, the primary author of DoDI 8510), and he acknowledged the policy problem that the definition of an “application” ultimately turns on the definition of “major” as used in OMB Circular A-130, which is grossly subject to interpretation. When pressed, he said: “I know one when I see one.” As a fellow policy wonk, I found this completely unsatisfying. My experience is that the interpretation of this across DoD varies widely, leaving significant capabilities untenable based on the caprice of policy interpretation of the local IA person.

I contend that many folks are getting put through the DIACAP wringer who shouldn’t be, according to policy. Am I wrong? Does the policy need to be fixed, and if so, how?

The Fundamentals of Net-Centricity (a little late)

[Intelink-U copy of this post]

I work in the Office of the DoD CIO.  For more than 10 years, “Net-Centricity” was the buzzword that we hung our hats on.  This is the sort of trick that policy wonks like me use: we make up a term, and try to get everyone else to buy into it.  To understand what the term means, you have to adopt a little piece of our worldview.  Even if you don’t agree with the idea, you still have to buy into it a little, just to be able to converse with us.  “Net-Centricity” was such a term.  It meant whatever we wanted it to mean.  We belittled people for doing things that weren’t “net-centric”, without explaining what we meant in English.  Ah, the good old days.

Even the true believers could disagree vehemently about whether something was “net-centric”, or net-centric enough.   And I was definitely a true believer.  Maybe I still am.

Sadly, perhaps, the term is falling out of vogue.  We promised too much; eventually the people we were trying to convince became disillusioned.  We actually accomplished a lot, but now it’s fashionable to belittle “net-centricity” in favor of the next-big-thing.   (At the moment, that appears to be “data-centricity” – (but it means the same thing).

Now that the term is deprecated, I can finally tell you what it means. Are you ready?  There is a fundamental theory and a fundamental premise.  Here is what “net-centric” means:

“Better information leads to better decisions, which in turn, leads to better outcomes.”

This, I emphasize, is only a theory.  It is easy to point out situations where it is wrong.  For example, there is a well-documented phenomenon sometimes called “analysis paralysis”, wherein a decision maker becomes so accustomed to getting new information that he becomes incapable of making a timely decision, preferring to wait for more data.  Another weakness in the theory is the definition of “better”.  What does “better” mean, in the context of information, decisions, or outcomes?

In general though, it’s a pretty good theory and even verges on being tautological.  Consider, for a moment, that the word “information” simply means “a fact which informs a decision”.

All the ideas of net-centricity are rooted in this theory, combined with practical observations about information technology, which helps us get that information when we need it.

Taking best-practices and design patterns from the development of the Internet, and applying them to defense problems helps decision makers to make better informed decisions.

The existence of a ubiquitous computer network (The Internet) has changed the way we shop, the way we travel, the way we meet people, the way we do research, the way we bank, the way we invest, the way we communicate, the way we raise money, the way we goof-off, and the way we vote.  It is just barely beginning to change the way we fight wars and defend our nation.

Net-centricity was just a buzzword in the Defense Department that meant, “Why can’t we be more like the Internet?”  Now you know the secret.

Part of the shift away from the term “net-centricity” is based on the absolutely true observation that it’s the data, the information, that really matters.  The net is just the technology that gets the information to us.  In DoD, it became easy to get distracted by “wireheads”, people who were only interested in building networks.  Wireheads fall into two camps: ones who don’t understand Metcalfe’s law (the value of a telecommunications network is proportional to the square of the number of connected users of the system), and are constantly trying to build new networks to get systems to talk to each other, and ones who do understand Metcalfe’s law and are therefore trying to eliminate redundant networks by connecting them into the master fabric.

The focus on networking technology was unfortunate.  The visionaries who really understood net-centricity: John Stenbit, Priscilla Guthrie, Dave Alberts, (and many others) never made this mistake.  For a year or two, there was a ridiculous internal debate about the difference between “network-centric” and “net-centric”.  Folks would make the distinction that “network-centric” was about networking technology, but “net-centric” was about the data on the network.   (I personally observed at the time that ‘net’ was either shorthand for ‘network’ or it was a piece of fishing equipment, and the whole conversation was stupid, IMHO.)

At the end of the day, the internet does a lot of things right that we still don’t really understand inside government.  As just one example, on the internet, people go out of their way to make stuff discoverable.  There’s a whole career field called “Search Engine Optimization”.   In government, sadly, we still keep our information on the “H:” drive (or whatever), and the idea that someone else might want to see our data is often seen as abhorrent.

It’s 2013 and I proclaim: “net-centricity” is dead;  Long live “data centricity”! Or the “Joint Information Environment”.  Or whatever.  Out with the old buzzwords, in with the new!  And do it in the Cloud with Social Media!  Oh, and Digital Government!

Hopefully some of the good ideas will still be there with new hats.