Category Archives: work

10 years of Net-Centric Data Strategy

On May 9th, 2013 it will be the 10th anniversary of the issuance of the DoD’s Net-Centric Data Strategy. In honor of this, I would like to highlight a collection of slides that were used (many, many times) to illustrate the concepts of net-centricity, the data strategy, Communities of Interest, and User-Defined Operational Pictures.

These slides are quite dated… last updated in 2006, but there are some great illustrations and concepts that remain relevant.  The Data Strategy was a brilliant work that had great promise for changing the way people see IT in defense, in my opinion. It’s tragic that various personnel changes and other events shifted the focus elsewhere.

VistA, MUMPS and NoSQL

[Extra disclaimer: I am not currently involved in any deliberations with regard to AHLTA or VistA or iEHR, and have no particular knowledge of current thinking on EHR inside the Pentagon. I briefed the Hon. Beth McGrath on Open Source Software in April 2011 – a long time ago.]

As some of you probably know, Jon Stewart of the Daily Show recently ran a clip about AHLTA vs VistA. (embedded below for convenience)

One of the interesting side-stories from this is the open-source vs proprietary angle which Stewart did not address.  The VA was (is?) a big supporter of Open Source Software.  (It is less clear how much commitment remains, now that both Roger Baker and Peter Levin have left the VA.)

An Open Source Software model makes perfect sense for VA. They had the business problem of 133 treatment facilities with 133 custom versions of VistA.  One of the beautiful things about VistA was that it was open to customization at the various installations so that it could be tailored to specific needs and this allowed innovation at point of service.  The problem is that the overall operational cost increases over time as the versions diverge, and there is the possibility that interoperability decreases.  The VA created OSEHRA to bring these forks back together.  By using open source methodologies, they created a common “VA Enterprise VistA” baseline, gives a place for all those local improvements to be merged into a best-of-breed VistA.

This collaborative model is a huge win for innovation and continuous modernization.  Allowing local innovation is both good and bad: the innovation part is good, but the loss of standardization is bad.  Coupling a tolerance for local innovation with a enterprise reference standard makes the prospect win-win.

I’ve personally fixed three bugs in the Linux kernel, and successfully gotten those patches incorporated into the Torvalds-approved kernel. I fixed the bugs because they affected me personally.   I worked to get them into the upstream because I didn’t want to have to keep re-applying my patches every time a new kernel was released.  There is also a non-trivial pride and ego-boost associated with that accomplishment.  These same incentives will cause VA doctors and IT staff to work to improve VistA locally, and also to merge those changes into an enterprise baseline.

These arguments in favor of an open-source development model could apply to the DoD also, or to a joint DoD-VA approach.

What’s not clear to me is how much VistA should play a starring role in that future.

Here’s an issue:  building a vibrant, collaborative community around a software development project is about people and process as much as it is about technology.  Some great books have been written about this.  It will be difficult to get bright, talented software engineers to work on VistA, because of the 30-year old tools and design practices.  I have two degrees in computer science from MIT and you couldn’t pay me enough to work on VistA.  Literally.  Even if you aren’t a software engineer, take a look at this random sample of VistA source code, which is barely distinguishable from line noise:

 ;;3.0;CONSULT/REQUEST TRACKING;**1,5,12,15,22,33,47,66**;DEC 27, 1997;Build 30
 ; This routine invokes IA #2638 (^ORD(100.01,), #3991 (ICDAPIU), #10117 (VALM10)
 ;                         #10103 (XLFDT), #10104 (XLFSTR), #10060 (access ^VA(200)), #2056 (GET1^DIQ)
EN(GMRCO) ;GMRCO=IEN of consult from file 123
 ;GMRCSS=To Service   GMRCPROC=Procedure Request Type
 ;GMRCURG=Urgency     GMRCPL=Place Of Consultation
 ;GMRCATN=Attention   GMRCINO=Service is In/Out Patient
 ;GMRCPNM=Patient Name  GMRCDIAG=Provisional Diagnosis
 ;GMRCERDT=Earliest Appr. Date
 ;GMRCPROS=Prosthetics Service y/n
 I $L($P(^GMR(123,+GMRCO,0),"^",12)) S ^TMP("GMRCR",$J,"ED",GMRCLNO,0)="  CURRENT STATUS: (Not Editable): "_$P(^ORD(100.01,$P(^(0),"^",12),0),"^",1),GMRCLNO=GMRCLNO+1
 .I $P(^GMR(123,+GMRCO,40,GMRCDD,0),"^",2)=19 S LN=0 D
 ..I '$D(^GMR(123,+GMRCO,12)) D
 ...S GMRCPERS=+$P($G(^GMR(123,+GMRCO,40,GMRCDD,0)),"^",5)
 ..I $D(^GMR(123,+GMRCO,12)) D
 ...I $P(^GMR(123,+GMRCO,12),U,5)="P" D
 ....S GMRCPERS=$P($G(^GMR(123,+GMRCO,40,GMRCDD,2)),U,1)
 ...I $P(^GMR(123,+GMRCO,12),U,5)="F" D
 ....S GMRCPERS=$P($G(^GMR(123,+GMRCO,40,GMRCDD,0)),U,5)
 ..S LN=$O(^GMR(123,+GMRCO,40,GMRCDD,1,LN)) Q:LN=""!(LN?1A.E)  I $L(^GMR(123,+GMRCO,40,GMRCDD,1,LN,0))>75 S FLG=1 D WPSET^GMRCUTIL("^GMR(123,+GMRCO,40,GMRCDD,1)","^TMP(""GMRCR"",$J,""ED"")","",.GMRCLNO,"",FLG)
 ..I '$D(FLG) S LN=0 F  S LN=$O(^GMR(123,+GMRCO,40,GMRCDD,1,LN)) Q:LN=""!(LN?1A.E)  S ^TMP("GMRCR",$J,"ED",GMRCLNO,0)=^(LN,0),GMRCLNO=GMRCLNO+1
 ..S ^TMP("GMRCR",$J,"ED",GMRCLNO,0)="",$P(^(0),"-",79)=""
 S GMRCSS=$S($D(GMRCEDT(1)):GMRCEDT(1),1:$P(^GMR(123,+GMRCO,0),"^",5)_U_$P(^GMR(123.5,$P(^GMR(123,+GMRCO,0),"^",5),0),U))
 S GMRCPROC=$S($D(GMRCED(1)):GMRCED(1),1:$P(^GMR(123,+GMRCO,0),"^",8)_U_$GET1^DIQ(123.3,+$P(^GMR(123,+GMRCO,0),"^",8),.01))
 I '$D(GMRCINO) S GMRCINO=$P(^GMR(123,+GMRCO,0),U,18)_U_$S($P(^(0),U,18)="I":"Inpatient",1:"Outpatient")
 S GMRCURG=$S($D(GMRCED(3)):GMRCED(3),1:$P(^GMR(123,+GMRCO,0),"^",9)_U_$GET1^DIQ(101,+$P(^(0),"^",9),1))
 S GMRCPL=$S($D(GMRCED(4)):GMRCED(4),1:$P(^GMR(123,+GMRCO,0),"^",10)_U_$GET1^DIQ(101,+$P(^(0),U,10),1))
 .S GMRCERDT=$S($D(GMRCED(5)):GMRCED(5),1:$P(^GMR(123,+GMRCO,0),"^",24)_U_$FMTE^XLFDT($P(^GMR(123,GMRCO,0),U,24)))
 S GMRCATN=$S($D(GMRCED(6)):GMRCED(6),1:$P(^GMR(123,+GMRCO,0),"^",11)_U_$GET1^DIQ(200,+$P(^(0),U,11),.01))
 I '$D(^GMR(123,GMRCO,30.1)) D
 . I $D(GMRCED(7)),$L($P(GMRCED(7),U,2)) D  Q
 .. S GMRCDIAG=$P(GMRCED(7),U)_" ("_$P(GMRCED(7),U,2)_")"
 . S GMRCDIAG=$S($D(GMRCED(7)):GMRCED(7),1:$G(^GMR(123,+GMRCO,30)))
 I $D(^GMR(123,GMRCO,30.1)) D
 . I $D(GMRCED(7)),$L(GMRCED(7)) D  Q
 .. S GMRCDIAG=$P(GMRCED(7),U)_" ("_$P(GMRCED(7),U,2)_")"
 . S GMRCDIAG=$G(^GMR(123,+GMRCO,30))
 S GMRCREQ=$S(+$P(^GMR(123,+GMRCO,0),U,17)="P":"Procedure",1:"Consult")
 S ^TMP("GMRCR",$J,"ED",GMRCLNO,0)="SENDING PROVIDER (Not Editable): "_$S($P($G(^GMR(123,+GMRCO,12)),U,6):$P(^GMR(123,+GMRCO,12),U,6),$P(^GMR(123,+GMRCO,0),"^",14):$GET1^DIQ(200,+$P(^GMR(123,+GMRCO,0),"^",14),.01),1:"UNKNOWN"),GMRCLNO=GMRCLNO+1
 . I $D(^TMP("GMRCED",$J,20)) D  Q
 .. N ND S ND=0
 .. F  S ND=$O(^TMP("GMRCED",$J,20,ND)) Q:'ND  D
 ... S ^TMP("GMRCR",$J,"ED",GMRCLNO,0)=^TMP("GMRCED",$J,20,ND,0)
 . N ND S ND=0
 . F  S ND=$O(^GMR(123,+GMRCO,20,ND)) Q:ND=""  D
 .. S ^TMP("GMRCR",$J,"ED",GMRCLNO,0)=^GMR(123,+GMRCO,20,ND,0)
 I $D(^TMP("GMRCED",$J,40)) D
 . S ^TMP("GMRCR",$J,"ED",GMRCLNO,0)="  New Comment:",GMRCLNO=GMRCLNO+1
 . N ND S ND=0 F  S ND=$O(^TMP("GMRCED",$J,40,ND)) Q:'ND  D
 .. S ^TMP("GMRCR",$J,"ED",GMRCLNO,0)=^TMP("GMRCED",$J,40,ND,0)
 ..S ^TMP("GMRCR",$J,"ED",GMRCLNO,0)="",GMRCLNO=GMRCLNO+1,^TMP("GMRCR",$J,"ED",GMRCLNO,0)="ADDED COMMENT (Not Editable) Entered: "_$P($FMTE^XLFDT($P(^GMR(123,+GMRCO,40,GMRCDD,0),"^",1)),"@",1)
 ..S GMRCRESP=$S($L($P($G(^GMR(123,+GMRCO,40,GMRCDD,0)),"^",5)):$GET1^DIQ(200,$P(^GMR(123,+GMRCO,40,GMRCDD,0),"^",5),.01),$L($P($G(^GMR(123,+GMRCO,40,GMRCDD,2)),"^",1)):$P(^GMR(123,+GMRCO,40,GMRCDD,2),"^",1),1:"UNKNOWN")
 ..;S ^TMP("GMRCR",$J,"ED",GMRCLNO,0)=^TMP("GMRCR",$J,"ED",GMRCLNO,0)_" BY: "_$S($L($P(^GMR(123,+GMRCO,40,GMRCDD,0),"^",4)):$P(^VA(200,$P(^GMR(123,+GMRCO,40,GMRCDD,0),"^",4),0),"^",1),1:"UNKNOWN"),GMRCLNO=GMRCLNO+1
 ..S LN=$O(^GMR(123,+GMRCO,40,GMRCDD,1,LN)) Q:LN=""!(LN?1A.E)  I $L(^GMR(123,+GMRCO,40,GMRCDD,1,LN,0))>75 S FLG=1 D WPSET^GMRCUTIL("^GMR(123,+GMRCO,40,GMRCDD,1)","^TMP(""GMRCR"",$J,""ED"")","",.GMRCLNO,"",FLG) Q
 ..S LN=0 F  S LN=$O(^GMR(123,+GMRCO,40,GMRCDD,1,LN)) Q:LN=""!(LN?1A.E)  S ^TMP("GMRCR",$J,"ED",GMRCLNO,0)=^(LN,0),GMRCLNO=GMRCLNO+1
RVRS(LINE,EDITED) ;reverse video for fields that can be edited

Not all the VistA code is this bad; some of it is worse.

That said, the DoD alternative (AHLTA) – and in fact the most well-known proprietary alternative  – all share the same obscure programming language (MUMPS) and are almost certainly equally bad – but since their code is not public, it’s harder to critique them.  In fact, I would expect them to be worse since they were not written with collaborative development in mind.

Say all the nice things about MUMPS you want:  In the end, the choice of an ugly, archaic technology will decrease interest in any project by prospective contributors, thus decreasing the value of the collaborative model.  This is Technical Debt we may not be able to repay.

Interestingly, Philip Newcomb, CEO of The Software Revolution Inc., has asserted that his company’s technology could convert VistA from MUMPS to J2EE in about a year for $10m. If true, this would be a bargain, IMHO.  I’ve met with Phil twice in the past decade, and his claims are impressive, although I have no personal experience with the results of his company’s work.  Other companies perform similar services – Hatha Systems for example claims to do automated analysis of MUMPS.

Tom Munnecke, one of the original architects of VistA has eloquently defended the MUMPS database design, pointing out that medical data is rarely suited to the structured, SQL-esque approach of relational databases.  He makes some fabulous points, and I actually think that he’s right in that many of the decisions that were made for MUMPS and VistA were remarkably prescient.  It’s taken the rest of the IT world three decades to rediscover document-structured non-relational databases, now known collectively as NoSQL.  Now that there’s a huge-amount of energy and expertise focused on large-scale non-relational data stores, maybe we should consider how to use that talent and energy for EHR?

In short, I think the VA should keep doing the OSEHRA thing to consolidate and modernize VistA.  There’s two threads to that:  first, they need to consolidate into an enterprise version of VistA for the VA to bring together the forks (which they are doing), and second, they should refactor and modernize the architecture and the tooling (which they claim they are doing).  I am suspicious that they aren’t being bold enough, but I don’t know.

I remain skeptical that VistA can survive in the long term as a vibrant, community-driven open source project, if it continues as it is.  In order to make VistA a viable project, the current MUMPS-based database need  to be replaced with a modern NoSQL datastore of some kind, and the hyper-abbreviated MUMPS code needs to be replaced with something readable and maintainable.  A colleague of mine (David Wheeler) once pointed out that MUMPS code doesn’t have to be unreadable, but the coding practices of VistA do not lend themselves to readability.  A bold step would be to re-write the thing in Java or some other modern language; a mimimalist step would just re-write it in MUMPS that doesn’t suck so much.  In  David’s words:

I think you should note another alternative as well: Keep MUMPS, but translate the current MUMPS into readable code.

Yes, you’d still be working in an uncommon language.  But that transformation would be especially trivial to do (and trivial to automate), and the risks from auto-translation would be far lower because the underlying environment and assumptions would be unchanged.

It seems to me that the big problem here isn’t really MUMPS, it’s the way MUMPS has been used.  Developers have used MUMPS’ “you can abbreviate anything” combined with “use bad names”, which perhaps made sense 30 years ago but is a bad idea today.  But you do not *HAVE* to create ugly code in MUMPS.

Using the Wikipedia MUMPS article example, here’s some line noise:

hello() w "Hello, World!",! q

But here’s legal MUMPS – it’s the same code, but unencrypted:

    write "Hello, World!",!

I have no idea if translating to another language would be a better trade-off than translating it to readable MUMPS.  But it’d be easy to hire somebody to briefly investigate the options, pros, and cons, so that a reasonable decision (based on EVIDENCE) could be made.  And I think, in fairness, that alternative should be considered.

I also have concerns about the governance model of OSEHRA, but, as this blog post is already too long, I’ll save that for another article.

As promised at the top: Jon Stewart on AHLTA vs VistA:

Alas, this video is no longer available on Comedy Central. It was from March 2013, and was hilarious but tragic. If you can find it, post a link in the comments.

On regulations


When I was in pilot training, I had a crusty, old, retired C-130 pilot as a ground instructor.  He liked to tell us wet-behind-the-ears lieutenants that:

Regulations are guidance to the wise,
and for the strict obedience of fools.

And he would go on to explain that Continue reading

The Ethics of Blogging as a Fed

[mirrored on Intelink-U]

[Update, 1 May 2014:  The issue of 1st amendment free-speech protection as a fed is more complicated than I knew at the time this post was written.  I’ve recently learned of the 2006 Supreme Court Decision, Garcetti v. Ceballos, which significantly restricts the protection for speech as a government employee.  I will probably write a new post once I’ve read the Court’s opinions and understood the implications thereof.]


I got in trouble for blogging.  Sorta.  And I got applauded too.  More on that later.

One of the posts on my blog got noticed.  People were offended that I would speak out of turn.  Apparently, a senior military officer printed a copy of the post and handed it to my boss’s boss’s boss, and recommended that I receive ethics counseling. I suspect that he has not read the Cluetrain Manifesto.

To the great credit of my leadership, they took this under advisement.  Some of them even read the blog.  One of the comments that got back to me was, “That was a well written post.”  My supervisor did call the Standards of Conduct Office, and he recommended that I go speak with an Ethics Official (an attorney), just so I would know what the boundaries were, and what I could (or could not) do.  I met with a very informed and articulate attorney and had a pleasant conversation with her.

Here is a synopsis of what I’ve learned about defense-civilian-blogger’s rights:  (side commentary in green)

  • I absolutely have a first-amendment right to free speech and my leadership was very respectful of that right. [UPDATE: The first-amendment protections apply to me as a citizen, but not to my speech as an employee, under Garcetti v. Caballos]
  • As a federal employee who is not an official spokesperson, I cannot speak in a public forum without a disclaimer that I speak for myself and not the government.  (JER 3-305.a, & 5 CFR § 3601.108 I knew this and had such a disclaimer already.  The attorney reviewed my disclaimer and found it adequate.
  • Use of the word ‘we’ to refer to the Defense Department or to government civilians could create the (mis-)impression that I was acting as a spokesperson, which is forbidden (see above).  I was strongly discouraged from using the word “we” in this way, especially considering that it is not necessary to do so to make my points.
    My inner lawyer wanted to argue this point, but it’s fundamentally reasonable.  (I subsequently edited my posts to avoid this practice.)
  • “DoD personnel, while acting in a private capacity and not in connection with their official duties, have the right to prepare information for public release through non-DoD fora or media. This information must be reviewed for clearance if it meets the criteria in DoDI 5230.29.” (DoDD 5230.09) “Writing that pertains to military matters, national security issues, or subjects of significant concern to DoD shall be reviewed for clearance by appropriate security and public affairs offices prior to publication.” (JER 3-305.b & DoDD 5230.09 para. 4.b, emphasis added)
    The dilemma with this restriction, of course, is that the definition of “military matters, national security issues, or subjects of significant concern” is subjective. I was given two pieces of advice:

    • Recommendation #1: In order to avoid the running afoul of this restriction, I could submit my blog posts to the Office of Security Review.
      Years ago, I authored a briefing and submitted it to the OSR, and it came back to me, as a subject matter expert, to review and approve. Ever since, I’ve been disinclined to waste the time and resources of the OSR.  (Waste is officially frowned upon, BTW.)
    • Recommendation #2: I could submit posts to my supervisor to review, prior to publication.
      This is similarly unsatisfying, in my humble opinion.  To the extent that anything I might post is controversial (but protected) speech, the consequences are risks that I must be willing to accept.  It is unfair, and perhaps even cowardly, to shift this risk to my supervisor, who as a federal civilian, is naturally risk averse. (q.v. previous post on Risk Aversion)
  • An employee shall not use his official title or position to identify himself in connection with his writing, except that he may include his title or position as one of several biographical details, provided that his title or position is given no more prominence than other details. (5 CFR § 2635.807)
  • “An employee shall not engage in a financial transaction using nonpublic information, nor allow the improper use of nonpublic information to further his own private interest or that of another, whether through advice or recommendation, or by knowing unauthorized disclosure.”  (5 CFR § 2635.703, emphasis added)
    “Non-public information” is defined as, “information that the employee gains by reason of Federal employment and that he knows or reasonably should know has not been made available to the general public.” (5 CFR § 2635.703)
    This point I found very interesting.  Several government employees that I spoke with believed that it was inappropriate or impermissible to disclose any nonpublic information gained as a result of public employment, for any reason.  The actual guidelines do not say that, and to do so would run contrary to the many whistleblower-protection laws that exist.  The statute does say that it is unethical use non-public information to “further his own private interest or that of another“.  On the contrary, using non-public information (i.e. my personal experiences in gov’t service) to illustrate a principle about efficiency of government activities, is precisely not to further my own private interest, but rather to further a public interest.
    In short, “insider trading” is forbidden;  “inside baseball” is not.  (Unless it’s classified or otherwise controlled information.)

That was my official “ethics counseling” on blogging as a federal civilian.  There was one additional issue, concerning cross-posting to Intelink-U.  Separately,  I asked this question to a colleague on Intelink staff, who passed it on to local counsel.  Here is an excerpt from the response, which is too precious not to share:

Having read the blog, I have couple of observations on the blog and its content–

  • I see nothing in the content that violates the Intelink Terms of Use
  • A blog, by definition, is personal commentary on a relevant topic.
  • I see nothing in the content that conflicts with the Federal employee ethics regulations codified in 5 C.F.R. Part 2635: Standards of ethical conduct for employees of the executive branch.

Based on a close read of Mr. Risacher comments, it could be reasonably argued that his commentary directly relates to his ethical obligations under 5 CFR Part 2635.101 (b) (11), “Employees shall disclose waste, fraud, abuse, and corruption to appropriate authorities. Albeit, it is not “politically correct/wise” to use a public forum as the method of “disclosure.”

His use of a “real” example to make his points about the well known disconnects between many “program management” and “operations” activities. Without such a concrete example, however, his commentary would have been vague and hypothetical, and dismissed as such.

And, oh by the way, while he is not a DNI employee one of the core values and performance measure is Courage…”moral, intellectual, even physical. We have the integrity (indeed, the duty) to seek and speak the truth, to innovate, to change things for the better, regardless of personal or professional risk.” In fact, a key assessment criteria for all DNI employees under the Personal Leadership and Integrity section is “a commitment to excellence, and the courage and conviction to express their professional views”
There are a few relevant questions one should consider:

Is is therefore appropriate to punish Mr. Risacher for doing what would be demanded of an IC professional?
In fact, is it not contrary to such principles to suggest such a notion?

He has effectively thrown a “stupid flag” and now someone is more concerned about the fact that his comments might be professionally embarrassing/inconvenient. Nowhere in the ethics regulations, does it say that it is ethical to shoot the messenger of inconvenient truths.

Amen. Thank you.

Last stop for the Cluetrain: Federal Government

[Intelink-U mirror]

I’ve been reading the Cluetrain Manifesto (10th Anniversary Edition), a book that examines the impact of the Internet on both markets (consumers) and organizations.  The over-the-top introduction reads like this (with minor editorial deletions/additions):

A powerful global conversation has begun. Through the Internet, people are discovering and inventing new ways to share relevant knowledge with blinding speed. As a direct result, markets are getting smarter—and getting smarter faster than most companies government agencies.

These markets are conversations. Their members communicate in language that is natural, open, honest, direct, funny and often shocking. Whether explaining or complaining, joking or serious, the human voice is unmistakably genuine. It can’t be faked. Continue reading

Risk Aversion and Job Security

[Intelink-U mirror]

Most federal civilians have really good job protections: while they are subject to furlough and sequestration, taking actual punitive actions against a general schedule civilian employee is pretty uncommon.  In particular, things like the Employee Rights & Appeals process, and Merit Systems Protection Board exist to protect employees, and they do this so well that when I was a military officer with civilian subordinates, I was candidly advised not to bother – demoting or firing civilians was just too hard.  (Unless their performance was really bad.)

Now, if you had really strong job security – as most federal civilians do – you could afford to take a few risks, couldn’t you?  So long as you aren’t committing an actual crime – what’s the worst that’s gonna happen to you? If your project doesn’t work or you make a mistake, you’re gonna come to work tomorrow and keep collecting the same pay.

So why are federal civilians so unbelievably risk averse?  Continue reading

Cost As an Independent Variable (CAIV)

[Intelink-U mirror]

What the heck is CAIV?

CAIV is an idea that when buying systems, Cost should be treated As an Independent Variable (CAIV). The concept and term were popularized in the 1990s Defense Acquisition Reform efforts, and (I think) comes from the Military Operations Research community.

Traditionally, there is a waterfall-like process for buying things in the military: first, ask the “warfighter” what they need, and they come up with requirements. Then figure out what that costs, ask Congress for the money, and build it.

Wait, what? The users decide what they think they need, before considering how much it will cost? How does that work? Continue reading

Title 10, Authority and Responsibility

[mirror on Intelink-U]

In the DoD, “Title 10” is a big deal.  “Title 10” means Title 10 of the United States Code – the law that defines the structure of the United States Military. There are other portions of US Law that affect the military – much of the Federal Acquisition Regulations derive from Title 41. Titles 40 and 44 includes stuff about Chief Information Officers of Federal Agencies. Title 17 is the Copyright Act, which we have to follow, yadda yadda yadda.

But at the end of the day, in DoD, most people are only familiar with Title 10. Even then, people just say it like it’s a mantra. “Title 10, y’know,” they sigh discontentedly, as if that explains all the dysfunctions of the day.

Continue reading